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

Re: [Xen-devel] [V10 PATCH 0/4] pvh dom0 patches...

On 05/08/2014 01:12 AM, Mukesh Rathor wrote:
On Wed, 7 May 2014 15:38:26 +0200
Roger Pau Monnà <roger.pau@xxxxxxxxxx> wrote:

On 07/05/14 15:20, Konrad Rzeszutek Wilk wrote:
For example, right now the Linux PV code can run with an E820 that
looks like swiss cheese - aka like the hosts' one. That is easily
seen if you boot an PV guest with PCI passthrough devices - as the
libxl 'e820_host' option gets turned on which creates an E820
that looks like the hosts. Granted it does not populate the P2M
as such (it is all linear). But the point is that the Linux
code is capable of dealing with this and bring the P2M to sync.

Hoisting this up in the hypervisor would be a plus - as the
Linux code wouldn't have to do this anymore.
IMHO doing it in the hypervisor is clearly the right solution, forcing
the guest OS to do all this on it's own just promotes code duplication
across the several OSes with PV(H) support.
I am in agreement with you, but my point was code exists for PV already,
so if you address pvh only, then that code still has to exist in
the guest until PV reaches EOL.

FWIW, my agreement with previous maintainers was to keep PVH as close to
PV as possible.

Wait, which maintainers are you talking about?

One of the big long-term wins of PVH is to get rid of a lot of the cruft in Linux resulting from the PV interface. "As close as possible" should mean that if there are several equally supportable / low-cruft ways to do something, do it the way PV does. But the "as possible" escape hatch means that when we can reduce cruft / code required in the Linux kernel, we should try.


Xen-devel mailing list



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