[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

... 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.
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).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.