On 22/07/2020 10:34, Jan Beulich wrote: > On 22.07.2020 11:26, Roger Pau Monné wrote: >> On Tue, Jul 21, 2020 at 06:22:08PM +0100, Andrew Cooper wrote: >>> @@ -2085,6 +2091,22 @@ static int svm_msr_write_intercept(unsigned int msr, >>> uint64_t msr_content) >>> goto gpf; >>> break; >>> >>> + case MSR_K8_VM_CR: >>> + /* ignore write. handle all bits as read-only. */ >>> + break; >>> + >>> + case MSR_K8_VM_HSAVE_PA: >>> + if ( (msr_content & ~PAGE_MASK) || msr_content > 0xfd00000000ULL ) >> Regarding the address check, the PM states "the maximum supported >> physical address for this implementation", but I don't seem to be able >> to find where is this actually announced. > I think you'd typically find this information in the BKDG or PPR only. > The PM is generic, while the named two are specific to particular > families or even just models.
Furthermore, the BKDG/PPR's are misleading/wrong. For pre Fam17h, it is MAXPHYSADDR - 12G, which gives a limit lower than 0xfd00000000 on various SoC and embedded platforms. On Fam17h, it is also lowered dynamically by how much memory encryption is turned on (and therefore steals bits from the upper end of MAXPHYSADDR). However, neither of these points are relevant in the slightest to nested-svm because we don't ever map the HyperTransport range into guests to start with - we'd get #PF[Rsvd] if we ever tried to use these mappings. Last time I presented this patch (nearly 2 years ago, and in the middle of a series), it got very bogged down in a swamp of nested virt work, which is why this time I've gone for no functional change, and punting all the nested virt work to some future point where I've got time to deal with it, and its not blocking the improvement wanted here. ~Andrew
