Re: GPU passthrough performance regression in >4GB vms due to XSA-60 changes

[Tomasz Wroblewski <tomasz.wroblewski@gmail.com>]

>>>> ... and after even more I see that the type is uncached at the time the
>>>> relocation is happening because mtrr is disabled at that time and
>>>> get_mtrr_type() function exits with uncached value in the first few
>>>> lines of it. Later when guests enabled MTRR, ept is not updated. So
>>>> maybe the EPTs should be updated in some way at that time,
>>> Which is what -unstable is now doing.
>> Right.
>>> But the question remains why this region doesn't get marked UC or
>>> WC, but WB.
>> The region doesn't seem to be marked in any way in mtrr so it just goes
>> off the default type for that mtrr ((struct mtrr_state*)->def_type)
>> which seems to be WB.
> I was expecting this for the relocated (above 4Gb) region, but is this
> also the case for the one below?
You're right, I had a silly typo in the pfn number I was testing, the 
lower region indeed does have entry in the MTRR and it is set to UC. The 
relocated region doesn't.

> In any event - all MMIO regions of passed through devices absolutely
> have to be represented in the MTRRs as long as the regions' types
> in the host MTRRs differ from the default type in the guest ones,
> though in the end this makes me (once again) question whether
> defaulting to WB and setting up exceptions for MMIO isn't the wrong
> approach especially when pass-through is being used. This used to
> be the other way around until April 2008 (commit a6a82232:
> "x86, hvm: Lots of MTRR/PAT emulation cleanup").
>
> If I coded up a patch to deal with this on -unstable, would you be
> able to test that?
Willing to give it a go (xen major version updates are often problematic 
to do though so can't promise success). What would your patch be doing? 
Adding entries to MTRR for the relocated regions? I do fear it might not 
be enough since thru recent debugging it seems there are more wrongs 
done by the relocation code - the p2m entries for the relocated region 
are not setup with p2m_mmio_direct for example but rather default 
p2m_ram_rw (unless this has changed again past 4.3.2).


> Jan
>