Messages in this thread | | | Date | Mon, 21 Nov 2022 16:03:07 +0100 | From | Borislav Petkov <> | Subject | Re: [Patch v3 07/14] x86/hyperv: Change vTOM handling to use standard coco mechanisms |
| |
On Wed, Nov 16, 2022 at 10:41:30AM -0800, Michael Kelley wrote: > Hyper-V guests on AMD SEV-SNP hardware have the option of using the > "virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP > architecture. With vTOM, shared vs. private memory accesses are > controlled by splitting the guest physical address space into two > halves. vTOM is the dividing line where the uppermost bit of the > physical address space is set; e.g., with 47 bits of guest physical > address space, vTOM is 0x40000000000 (bit 46 is set). Guest phyiscal
Unknown word [phyiscal] in commit message. Suggestions: ['physical', 'physically', ... ]
Please introduce a spellchecker into your patch creation workflow.
...
> @@ -108,6 +115,7 @@ u64 cc_mkenc(u64 val) > switch (vendor) { > case CC_VENDOR_AMD: > return val | cc_mask; > + case CC_VENDOR_HYPERV: > case CC_VENDOR_INTEL: > return val & ~cc_mask; > default: > @@ -121,6 +129,7 @@ u64 cc_mkdec(u64 val) > switch (vendor) { > case CC_VENDOR_AMD: > return val & ~cc_mask; > + case CC_VENDOR_HYPERV: > case CC_VENDOR_INTEL: > return val | cc_mask; > default:
Uuuh, this needs a BIG FAT COMMENT.
You're running on SNP and yet the enc/dec meaning is flipped. And that's because of vTOM.
What happens if you have other types of SNP-based VMs on HyperV? The isolation VMs thing? Or is that the same?
What happens when you do TDX guests with HyperV?
This becomes wrong then.
I think you need a more finer-grained check here in the sense of "is it a HyperV guest using a paravisor and vTOM is enabled" or so.
Otherwise, I like the removal of the HyperV-specific checks ofc.
Thx.
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |