Messages in this thread |  | | Date | Thu, 04 Jun 2015 16:23:41 +0800 | From | Xiao Guangrong <> | Subject | Re: [PATCH 14/15] KVM: MTRR: do not map huage page for non-consistent range |
| |
On 06/03/2015 03:55 PM, Paolo Bonzini wrote: > > > On 03/06/2015 04:56, Xiao Guangrong wrote: >> >> >> On 06/01/2015 05:36 PM, Paolo Bonzini wrote: >>> >>> >>> On 30/05/2015 12:59, Xiao Guangrong wrote: >>>> Currently guest MTRR is completely prohibited if cache snoop is >>>> supported on >>>> IOMMU (!noncoherent_dma) and host does the emulation based on the >>>> knowledge >>>> from host side, however, host side is not the good point to know >>>> what the purpose of guest is. A good example is that pass-throughed VGA >>>> frame buffer is not always UC as host expected >>> >>> Can you explain how? The original idea was that such a framebuffer >>> would be kvm_is_reserved_pfn and thus be unconditionally UC. >> >> Yes, frame-buffer is always UC in current code, however, UC for >> frame-buffer causes bad performance. > > Understood now, thanks. > >> So that guest will configure the range to MTRR, this patchset follows >> guest MTRR and cooperates with guest PAT (ept.VMX_EPT_IPAT_BIT = 0) to >> emulate guest cache type as guest expects. > > Unlike e.g. CR0.CD=1, UC memory does not snoop the cache to preserve > coherency. AMD, has special logic to do this, for example: > > - if guest PAT says "UC" and host MTRR says "WB", the processor will not > cache the memory but will snoop the cache as if CR0.CD=1 > > - if guest PAT says "WC" and host (nested page table) PAT says "WB" and > host MTRR says "WB", the processor will still do write combining but > also snoop the cache as if CR0.CD=1 > > I am worried that the lack of this feature could cause problems if > guests map QEMU's VGA framebuffer as uncached. We have this problem on > ARM, so it's not 100% theoretical.
CR0.CD is always 0 in both host and guest, i guess it's why we cleared CR0.CD and CR0.NW in vmx_set_cr0().
> > So, why do you need to always use IPAT=0? Can patch 15 keep the current > logic for RAM, like this: > > if (is_mmio || kvm_arch_has_noncoherent_dma(vcpu->kvm)) > ret = kvm_mtrr_get_guest_memory_type(vcpu, gfn) << > VMX_EPT_MT_EPTE_SHIFT; > else > ret = (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) > | VMX_EPT_IPAT_BIT;
Yeah, it's okay, actually we considered this way, however - it's light enough, it did not hurt guest performance based on our benchmark. - the logic has always used for noncherent_dma case, extend it to normal case should have low risk and also help us to check the logic. - completely follow MTRRS spec would be better than host hides it.
|  |