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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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
>in 
>the code-motion patch (which cannot, I think, be causing the HVM
>crash).

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?

>
>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
>minus 
>qemu plus a handful of hypercalls, and most of the changes in the
>domain 
>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?
>
>  -George
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxx
>http://lists.xen.org/xen-devel



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