On 21/04/2015 13:25, Jan Kiszka wrote: > On 2015-04-21 13:09, Paolo Bonzini wrote: >> >> >> On 20/04/2015 19:25, Jan Kiszka wrote: >>> When hardware supports the g_pat VMCB field, we can use it for emulating >>> the PAT configuration that the guest configures by writing to the >>> corresponding MSR. >>> >>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> >> >> I'm not sure about this. The problem is that, unlike Intel, AMD has no >> way for the host to force its PAT value and ignore the guest's. I'm >> worried about potential performance problems in the guest. > > I think the guest needs to get what it requests - see my remark in > http://thread.gmane.org/gmane.comp.emulators.kvm.devel/135271. > >> >> This is not as bad as on ARM, because the guest cannot disable the cache > > You mean AMD, I guess. No, I meant ARM. :) On ARM the guest can even disable the cache snooping protocol, making things particularly messy when QEMU accesses the processor caches and the guest doesn't. At least on AMD you cannot do this. >> snooping protocol and thus cache coherency is guaranteed (see tables >> 7-10 and 15-20 in the AMD docs), but still I think I'd prefer having >> some knob (module parameter) to enable/disable gPAT. It's okay to make >> it enabled by default. > > I still don't get the scenario where we want to override the guest > settings. Maybe you can help out - would be valuable for the reasoning > in code or commit logs as well. Basically it's an optimization. The guest can set the UC memory type on PCI BARs that are actually backed by RAM in QEMU, and then accesses to these BARs will be unnecessarily slow. It would be particularly bad if, for example, access to ivshmem were slowed down because the guest PAT says the memory is uncacheable. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
