2015-04-20 20:41+0200, Jan Kiszka: > On 2015-04-20 20:33, Radim Krčmář wrote: > > 2015-04-20 19:45+0200, Jan Kiszka: > >> On 2015-04-20 19:37, Jan Kiszka wrote: > >>> On 2015-04-20 19:33, Radim Krčmář wrote: > >>>> 2015-04-20 19:21+0200, Jan Kiszka: > >>>>> On 2015-04-20 19:16, Radim Krčmář wrote: > >>>>>> 2015-04-20 18:14+0200, Radim Krčmář: > >>>>>>> Tested-by: Radim Krčmář <rkrcmar@xxxxxxxxxx> > >>>>>> > >>>>>> Uncached accesses were roughly 20x slower. > >>>>>> In case anyone wanted to reproduce, I used this as a kvm-unit-test: > >>>>>> > >>>>>> --- > >>>> | [code] > >>>>> > >>>>> Great, thanks. Will you push it to the unit tests? Could raise > >>>>> motivations to fix the !NPT/EPT case. > >>>> > >>>> It can't be included in `run_tests.sh`, because we intenionally ignore > >>>> PAT for normal RAM on VMX and the test does "fail" ... > >>> > >>> That ignoring is encoded into the EPT? > > > > Yes, it's the VMX_EPT_IPAT_BIT. > > > >> And do you also know why is it ignored on Intel? Side effects on the host? > > > > I think it is an optimization exclusive to Intel. > > We know that the other side is not real hardware, which could avoid CPU > > caches when accessing memory, so there is little reason to slow the > > guest down. > > If the guest pushes data for DMA into RAM, it may assume that it lands > there directly, without the need for explicit flushes, because it has > caching disabled - no? Yes, the guest can't tell a difference. In the presence of an assigned device, we always consider PAT; with VFIO, ignoring PAT is decided by coherent DMA capability. Emulated DMA requests are handled by the host, so the IPAT bit optimizes cases where we know that caches are always right, but the guest doesn't. -- 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
