Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Ian Jackson]

Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits into qemu"):
> Comments?

Please do not apply these patches.  They will make my life very
difficult.

If Gerd wants to rewrite the Xen/qemu support he should come to
xen-devel and submit his patches there.

Ian.

Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Anthony Liguori]

Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits into qemu"):
>   
>> Comments?
>>     
>
> Please do not apply these patches.  They will make my life very
> difficult.
>   

As I've said before, I won't apply these patches until there's agreement 
that this is the right approach for QEMU and upstream Xen so no worries 
there.

> If Gerd wants to rewrite the Xen/qemu support he should come to
> xen-devel and submit his patches there.
>   

Actually, I think Gerd is taking the right approach.  How Xen (and KVM 
for that matter) integrates with QEMU is something that ought to be 
discussed in both communities.  That will make the long term merge 
prospects easier.  Working things out on xen-devel doesn't necessarily 
mean you're any closer to getting into QEMU if qemu-devel has been left 
out of the discussion.

Regards,

Anthony Liguori

> Ian.
>
>
>   

Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Blue Swirl]

On 8/11/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Ian Jackson wrote:
>
> > Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits into
> qemu"):
> >
> >
> > > Comments?
> > >
> > >
> >
> > Please do not apply these patches.  They will make my life very
> > difficult.
> >
> >
>
>  As I've said before, I won't apply these patches until there's agreement
> that this is the right approach for QEMU and upstream Xen so no worries
> there.

What about nodisk_ok? That should not make merging too hard.

Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Ian Jackson]

Blue Swirl writes ("Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu"):
> On 8/11/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >  As I've said before, I won't apply these patches until there's agreement
> > that this is the right approach for QEMU and upstream Xen so no worries
> > there.
> 
> What about nodisk_ok? That should not make merging too hard.

Sorry, yes.  That is a good change.

Ian.

Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Gerd Hoffmann]

Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits into qemu"):
>> Comments?
> 
> Please do not apply these patches.  They will make my life very
> difficult.

Go to http://kraxel.fedorapeople.org/patches/qemu-xen/.  Apply the
patches to your tree.  Run them through the XenSource regression
testing.  Complain if I broke something.  It can't be much easier than
that for you.

> If Gerd wants to rewrite the Xen/qemu support he should come to
> xen-devel and submit his patches there.

Huh?  Patches are posted to xen-devel too.

Puzzled,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Samuel Thibault]

Gerd Hoffmann, le Mon 11 Aug 2008 22:07:08 +0200, a écrit :
> Ian Jackson wrote:
> > Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits into qemu"):
> >> Comments?
> > 
> > Please do not apply these patches.  They will make my life very
> > difficult.
> 
> Go to http://kraxel.fedorapeople.org/patches/qemu-xen/.  Apply the
> patches to your tree.  Run them through the XenSource regression
> testing.  Complain if I broke something.  It can't be much easier than
> that for you.

Well, maybe having a version of the patch that does not convert the code
into the qemu identation would help a lot for on-list review.

Also, would it be possible to just have the backend core and
console+framebuffer patches alone?  I don't see why we would need to
change xen_machine_pv.c at all.

That being said, I guess we should wait for a pull in the qemu-xen tree.

Samuel

Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Gerd Hoffmann]

Samuel Thibault wrote:

> Well, maybe having a version of the patch that does not convert the code
> into the qemu identation would help a lot for on-list review.

Hmm, dunno how to do that best, git-format-patch seems to lack an
equivalent of "diff -b" ...

> Also, would it be possible to just have the backend core and
> console+framebuffer patches alone?  I don't see why we would need to
> change xen_machine_pv.c at all.

To stay closer to upstream?  Upstream xen_machine_pv.c will in the
future also have some bits to handle xen emulation which will never be
actually used when running on the xen hypervisor.  You don't really need
that.  But I think using the same source code it is a good idea
nevertheless, it will be less maintainance work long-term.

> That being said, I guess we should wait for a pull in the qemu-xen tree.

I'd prefer to not have a patch backlog with tons of unmerged stuff ...

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Samuel Thibault]

Gerd Hoffmann, le Mon 18 Aug 2008 14:45:08 +0200, a écrit :
> Samuel Thibault wrote:
> > Well, maybe having a version of the patch that does not convert the code
> > into the qemu identation would help a lot for on-list review.
> 
> Hmm, dunno how to do that best, git-format-patch seems to lack an
> equivalent of "diff -b" ...

In verson 1.5.6.3 at least there is a -b option.

> > Also, would it be possible to just have the backend core and
> > console+framebuffer patches alone?  I don't see why we would need to
> > change xen_machine_pv.c at all.
> 
> To stay closer to upstream?

To limit the amount of changes involved at a time.  If something breaks,
it's easier to know simply from testing a few changesets whether that's
because of this or that.

> > That being said, I guess we should wait for a pull in the qemu-xen tree.
> 
> I'd prefer to not have a patch backlog with tons of unmerged stuff ...

I doubt you'll be able to produce tons of stuff until that happens.

Samuel

Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Gerd Hoffmann]

Samuel Thibault wrote:
> Gerd Hoffmann, le Mon 18 Aug 2008 14:45:08 +0200, a écrit :
>> Samuel Thibault wrote:
>>> Well, maybe having a version of the patch that does not convert the code
>>> into the qemu identation would help a lot for on-list review.
>> Hmm, dunno how to do that best, git-format-patch seems to lack an
>> equivalent of "diff -b" ...
> 
> In verson 1.5.6.3 at least there is a -b option.

Ok, next respin will have version with that turned on for review.

>>> Also, would it be possible to just have the backend core and
>>> console+framebuffer patches alone?  I don't see why we would need to
>>> change xen_machine_pv.c at all.
>> To stay closer to upstream?
> 
> To limit the amount of changes involved at a time.  If something breaks,
> it's easier to know simply from testing a few changesets whether that's
> because of this or that.

Hmm, that calls more for a patch reordering in the xen patch series to
make it more bisect-friendly (i.e. first put in the new backend drivers,
then update xen_machine_pv.c).  Right now each step single step builds,
but there are a few inbetween which are not fully functional due to old
backends being turned off and new ones not patched in yet ...

>>> That being said, I guess we should wait for a pull in the qemu-xen tree.
>> I'd prefer to not have a patch backlog with tons of unmerged stuff ...
> 
> I doubt you'll be able to produce tons of stuff until that happens.

Even right now the patch queue is uncomfortably long for my taste.

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

[Qemu-devel] [PATCH 00/11] merge some xen bits into qemu

[Gerd Hoffmann]

  Hi folks,

This is the third version of the xen support for qemu patch series,
addressing review comments, mostly the ones from the xen folks.

The console and framebuffer backend drivers are largely based on the
xen code, the other bits are rewritten from scratch.  Nevertheless
the code should be functionally identical.

Overview (individual patches have longer descriptions):

  #1  -- Handle terminating signals.
  #2  -- add DisplayState->idle
  #3  -- add container_of() macro to osdep.h
  #4  -- move GUI_REFRESH_INTERVAL define from vl.c to console.h

  #5  -- groundwork: build system, cmd line options, ...
  #6  -- xen backend driver infrastructrure
  #7  -- xen console backend driver
  #8  -- xen framebuffer backend driver

  #9  -- xen block backend driver
  #10 -- xen nic backend driver
  #11 -- allow xen disks and nics being configured via qemu command
         line options.

The first four patches are preparing patches.  They put some stuff in
place the other xen patches depend on.

With the next four patches in place upstream qemu can replace xen's
qemu-dm for paravirtual domains.  The block and nic backend drivers
are full userspace implementations using the grant table device
(gntdev).

xen support is implemented using another machine type.  xen's qemu-dm
already uses the machine type to switch between paravirtualized and
fully virtualized machines, so this was the natural choice.  qemu has
gets a new "xenpv" machine type additionally to the "pc" and "isapc"
ones.

The patches are also available here, together with some not-yet submitted
work-in-progress bits:
	http://kraxel.fedorapeople.org/patches/qemu-upstream/

There is also a patch queue for qemu-dm, so the patches can get a
test-drive there.  Looks slightly different because I left vl.c and the
build system largely alone.  Also the preparing patches are not needed
there.  And the last two patches are not ported over (yet), but xen
probably wouldn't use these bits anyway ...
	http://kraxel.fedorapeople.org/patches/qemu-xen/

Comments?

cheers,
  Gerd