On Tue, 2023-10-31 at 08:14 -0700, Sean Christopherson wrote: > > > Discussion from the EPT+MTRR enabling thread[*] more or less confirms that Sheng > > > Yang was trying to resolve issues with passthrough MMIO. > > > > > > * Sheng Yang > > > : Do you mean host(qemu) would access this memory and if we set it to guest > > > : MTRR, host access would be broken? We would cover this in our shadow MTRR > > > : patch, for we encountered this in video ram when doing some experiment with > > > : VGA assignment. Not sure what does the "VGA assignment" mean, but I have a doubt whether it was about passthrough MMIO. Theoretically if it was passthrough MMIO, the host shouldn't need to access it. But the above text seems the issue were host/guest accessing memory together. If we are talking about the video ram here (e.g., for framebuffer) IIUC it isn't passthrough MMIO, but just some memory that used by guest as video ram. KVM needs to periodically write protect it (and clear dirty) so that Qemu can be aware of exact what video ram has been updated to correctly emulate the video ram, i.e., showing on the console of the VM. So I guess the issue was both host and guest access of video ram, while guest sets its memory type to WC or UC. But IIUC host only *reads* from video ram, but never *writes*, thus I don't see there's any real problem if host is accessing via WB and guest is accessing via WC or UC. AMD SDM: VMRUN and #VMEXIT flush the write combiners. This ensures that all writes to WC memory by the guest are visible to the host (or vice-versa) regardless of memory type. (It does not ensure that cacheable writes by one agent are properly observed by WC reads or writes by the other agent.) > > > > > > And in the same thread, there's also what appears to be confirmation of Intel > > > running into issues with Windows XP related to a guest device driver mapping > > > DMA with WC in the PAT. Hilariously, Avi effectively said "KVM can't modify the > > > SPTE memtype to match the guest for EPT/NPT", which while true, completely overlooks > > > the fact that EPT and NPT both honor guest PAT by default. /facepalm I think Avi was not talking about guest PAT but guest MTRR, which is not honored by NPT/EPT at all. ? > > > > My interpretation is that the since guest PATs are in guest page tables, > > while with EPT/NPT, guest page tables are not shadowed, it's not easy to > > check guest PATs to disallow host QEMU access to non-WB guest RAM. > > Ah, yeah, your interpretation makes sense. > > The best idea I can think of to support things like this is to have KVM grab the > effective PAT memtype from the host userspace page tables, shove that into the > EPT/NPT memtype, and then ignore guest PAT. I don't if that would actually work > though. I think you are assuming "host userspace page tables" will always have the same memory type in guest's MTRR? I am not sure whether it will always be the case. I haven't checked the Qemu code, but theoretically, for things like video ram, the guest can have its memory as WC/UC in MTRR but host can map it as WB perfectly, because host only needs to read from it. I think we can just get rid of guest MTRR staff completely, i.e. enforce KVM to expose 0 fixed and dynamic MTRRs. Then we don't need to "look at memory type from host userspace page tables", but simply set WB to NPT/EPT. The reason is as you said NPT/EPT honor guest's PAT by default. If guest wants WC then it sets WC to PAT then guest will access it using WC. Host side for passthrough MMIO host should never access it anyway, and for things like video ram host will only read from it, thus it should be safe to map WB in the host. Or do we need to consider host being able to write using WB some memory while it is accessed as WC/UC in the guest? And does kernel-direct mapping worth consideration? Hmm.. But it's possible I am talking non-sense.. :-)
