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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel