Re: [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain. - Marek Marczykowski-Górecki

From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Ian Jackson <ian.jackson@citrix.com>
Cc: Simon Gaiser <simon@invisiblethingslab.com>,
	xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>, Eric Shelton <eshelton@pobox.com>
Subject: Re: [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
Date: Wed, 17 Oct 2018 18:05:59 +0200	[thread overview]
Message-ID: <20181017160559.GB2755@mail-itl> (raw)
In-Reply-To: <23495.21043.960987.833172@mariner.uk.xensource.com>

[-- Attachment #1.1: Type: text/plain, Size: 2292 bytes --]

On Wed, Oct 17, 2018 at 04:16:03PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain."):
> > [stuff]
> 
> So, I only got a little way through this series, but it was a while
> ago and you say things are done differently now.  I'm not sure if it
> is useful for me to review the rest of it.
> 
> Would it be better for me to await a repost ?

All the xenconsoled stuff is unchanged (and unlikely to change), so it
should be safe to review it. Patches 06 and 07 also shouldn't change.

The thing that will change is qemu cmdline and qmp handling. TBH I'm not sure
if its better to touch qmp now, or after reworked qmp handling by
Anthony will be merged. There will definitely be some conflicts and it
may even affects what underlying mechanism is chosen for qmp transport.
Based on discussion here, and in libxl__ev_qmp_* thread, I see two
viable options:

1. libvchan
  pros:
   - out of band reset support, so qmp capabilities negotiation can be
     handled gracefully
  cons:
   - more work, require patching qemu (or adding vchan->socket proxy),
     adds dependency on libvchan to libxl (probably not a problem)
   - possibly more complex libxl__ev_qmp_* handling, or at least needs
     separate handling of send/receive for stubdomain case
2. pv console
  pros:
   - no qemu modifications
   - same read()/write() on libxl side
  cons:
   - no out of band reset, needs libxl handling for that (skipping
     negotiation)
   - possibly other problems from that (events filling up some buffers
     when no one is listening?)

In both cases, there is only one simultaneous connection to qemu, so
some locking will be needed at libxl side.
BTW Does libxl listed for qmp events?

There is also third option: xenstore, but that would probably require
totally separate libxl__ev_qmp_* implementation, so I'd rule it out.

If problems with pv console could be solved, I'd go this way. But
otherwise libvchan seems like a good alternative.

Adding Anthony.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel