xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, keir.xen@gmail.com
Subject: Re: [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes
Date: Tue, 8 Oct 2013 10:39:49 +0100	[thread overview]
Message-ID: <5253D2E5.6040107@eu.citrix.com> (raw)
In-Reply-To: <5253D87802000078000F9771@nat28.tlf.novell.com>

On 10/08/2013 09:03 AM, Jan Beulich wrote:
>>>> On 08.10.13 at 09:51, "Jan Beulich" <JBeulich@suse.com> 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).

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.

  -George

  reply	other threads:[~2013-10-08  9:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 21:03 [RFC 0 PATCH 0/3]: PVH dom0 construction Mukesh Rathor
2013-09-25 21:03 ` [RFC 0 PATCH 1/3] PVH dom0: create domctl_memory_mapping() function Mukesh Rathor
2013-09-26  7:03   ` Jan Beulich
2013-09-25 21:03 ` [RFC 0 PATCH 2/3] PVH dom0: move some pv specific code to static functions Mukesh Rathor
2013-09-26  7:21   ` Jan Beulich
2013-09-26 23:32     ` Mukesh Rathor
2013-09-25 21:03 ` [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes Mukesh Rathor
2013-09-26  8:02   ` Jan Beulich
2013-09-27  0:17     ` Mukesh Rathor
2013-09-27  6:54       ` Jan Beulich
2013-10-03  0:53         ` Mukesh Rathor
2013-10-04  6:53           ` Jan Beulich
2013-10-04 13:35             ` Konrad Rzeszutek Wilk
2013-10-04 14:05               ` Jan Beulich
2013-10-04 16:02                 ` Konrad Rzeszutek Wilk
2013-10-04 16:07                   ` Jan Beulich
2013-10-04 20:59                     ` Konrad Rzeszutek Wilk
2013-10-05  1:06                       ` Mukesh Rathor
2013-10-07  7:12                         ` Jan Beulich
2013-10-08  0:58             ` Mukesh Rathor
2013-10-08  7:51               ` Jan Beulich
2013-10-08  8:03                 ` Jan Beulich
2013-10-08  9:39                   ` George Dunlap [this message]
2013-10-08  9:57                     ` Jan Beulich
2013-10-08 10:01                       ` George Dunlap
2013-10-08 10:19                         ` Lars Kurth
2013-10-08 12:30                     ` Konrad Rzeszutek Wilk
2013-10-09 13:02                       ` George Dunlap
2013-10-09 13:13                         ` Andrew Cooper
2013-10-09 13:16                           ` George Dunlap
2013-10-09 14:37                             ` Andrew Cooper
2013-10-09 17:50                       ` Tim Deegan
2013-10-09 22:31                         ` Mukesh Rathor
2013-09-27  1:55     ` Mukesh Rathor
2013-09-27  7:01       ` Jan Beulich
2013-09-27 23:03         ` Mukesh Rathor
2013-09-30  6:56           ` Jan Beulich
2013-10-08  0:52             ` Mukesh Rathor
2013-10-08  7:43               ` Jan Beulich
2013-10-09 21:59                 ` Mukesh Rathor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5253D2E5.6040107@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir.xen@gmail.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).