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

Re: [Xen-devel] [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes

On 10/08/2013 01:30 PM, Konrad Rzeszutek Wilk wrote:
George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 10/08/2013 09:03 AM, Jan Beulich wrote:
On 08.10.13 at 09:51, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
And just to be clear - _any_ of the "fixme"s we intend to allow to
go in with this series is a compromise already, with - afaict - no
precedent. The more you ask for, the more likely it'll become for
at least me to start re-thinking about this. Over the past years I
think we made good progress in morphing Xen from an
experimental project to a stable, enterprise ready one. I'm not
eager to see us get pushed back significantly on that road.

Considering the thread we're in - perhaps before adding Dom0
support with more hacks/fixme-s it would be more appropriate
to eliminate all the ones in the current pending series?

Question to both of you: What's the status of this anyway? If
I'm not mistaken there was (on IRC) talk of a regression the
latest series caused for HVM guests? Was this already sorted
out? Is there going to be an updated series getting us
reasonably close to finally get this in?

Right now I've had to put PVH on the back burner: I've got a talk for
LinuxCon EU to prepare, and two for XenSummit.

There are two bugs that have been identified -- the HVM crash due to a
mistake in one of the "code motion" patches, and the bug with setting
VMXE in the guest CR.  Tim has also noticed another functional change
the code-motion patch (which cannot, I think, be causing the HVM

These issues sprang up with your patches,  not with the ones that Mukesh posted 
? Which did get tested for regression and passed with flying colours? That 
means there is a working baseline. Would that help?
Mukesh do you have any ideas what might be amiss?

The issues with the code motion patch are almost certainly mine. Andy Cooper ran one of Mukesh's versions through one of the XenRT tests (probably a nightly) and it came up fine. I just need to go through and figure out what I messed up.

The issue with the cr4 turned up because of the work Roger Pau Monne has done porting FreeBSD to PVH. The core issue here is that the guest CR4 has VMXE set even though nested virt is disabled; so when the kernel does "read, set/clear bit, write", the resulting write also has the VMXE bit set, which causes the HVM handler to crash the guest. The core issue, that the VMXE bit is set even though nested virt is disabled, was probably there in Mukesh's series. I'm not sure if his handler would crash in a similar way, but it probably did; in any case, there would have been problems when it came to live migration. But that's a one-line fix that Roger has already tested.

If it were just a question of cleaning up those bits, I could probably
have another draft posted sometime this week.  But if we're stepping
back and looking at whether this is the right approach, or whether
something like Tim has suggested -- basically making PVH to be HVM
qemu plus a handful of hypercalls, and most of the changes in the
builder rather than in Xen -- that will take a bit longer, particularly

because it would probably mean me having to understand and modify the
Linux side of things as well.  At this point I'm not really sure what
the best approach is going forward.

Arrg.  I am not really sure how to express myself here but from the start 
Mukesh has asking for assistance and review of ideas and design of this and 
gotten it and acted on it. Now after two years of going this path folks are 
suggesting a new design?

Sadly I won't be able to be on Wed (family matters) call but my opinion is that 
we should keep on heading this way. If we want HVM with less (so no QEMU) that 
could be a separate mode that would work in parallel with PVH and be a separate 
project. They should be able to coexist right?

So to begin with, the series I posted, from a guest perspective, is already close to what Tim described. The main thing a PVH guest has that an HVM guest doesn't are:
 - Starts in 64-bit mode
 - A few more hypercalls
 - PV CPUID and IO
 - More state set when bringing up a cpu

The main difference between PV and HVM CPUID is the special-casing for dom0, which would presumably have to be extended in order to run a PVH dom0 in any case; and the IO is either the same, or again has special cases for driver domains and dom0, and would need to be implemented one way or another for PVH guests as well.

Most of what Tim seems do be advocating are things that should be able to be changed "behind the scenes": having the domain builder put the guest in long mode + paging, &c.

So it might be worth just checking this version in (once it gets fixed up), and look at refactoring things at a later date.


Xen-devel mailing list



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