Re: [Xen-devel] Re: Xen is a feature

Jeremy Fitzhardinge
2009-05-29T23:26:48Z

Nakajima, Jun wrote:
> I think we still need some (or all?) of additional dom0 PV ops even for HVM (Hardware-based VM) dom0. Hardware-based virtualization can significantly clean up the CPU-related PV ops (including some for local APIC), but they have nothing to do with dom0.
>
> Some hooks in the host could be removed by reusing the HVM-specific code with modifications to the virtualization logic, but I think people need to tell which specific ones are intrusive, to be fair.
>

I think two things will significantly clean up the dom0 apic patches:

One is to adjust the LAPIC and IOAPIC probing code so that it
behaves correctly if the APIC cpuid flag is clear. That would
remove a lot of the init-time ad-hoc Xen changes I made.

The other is to implement Ingo's suggestion of a proper ioapic
driver layer. I think that would not only resolve the low-level
IO-APIC register access issue, but probably clean up a lot of the
vector allocation/handling, and make a clear path for MSI support.
With luck it will also clean up things like x2apic support

I'm planning on putting some time into investigating these next week.

Once we've nailed down the details of how to make PAT work for PV guests
on the Xen side, we should be able to implement that fairly easily in
Linux with no core x86 changes.

I really don't think emulating MTRR register writes is the right way to
implement Xen MTRR support, given that a much more semantically
appropriate interface already exists, but we can do that if nothing else
gets merged.

IanC is restructuring the swiotlb changes in a way that I hope will be
acceptable to all.

At that point, I think we really will have resolved all the high-level
concerns expressed about the overall architecture of the patches, and
maybe we can finally see some progress.

J