QEMU XenServer/XenProject Working group meeting 10th May 2017

[Jennifer Herbert <Jennifer.Herbert@citrix.com>]

QEMU XenServer/XenProject Working group meeting 5th May 2017
=============================================================

Attendees:
* Paul Durrant
* Andrew Cooper
* Ian Jackson
* Jenny Herbert
* Igor Druzhinin
* Simon Crow
* Marcus Granado

Reviewed previous action points

* Paul to carry on with Xen device model work. - Done.
* Ian - No progress with re factoring libxl split, XenStore restrictions
   or using and FD for QMP cd insert and emulated hotplug, due to feature
   freeze on 4.8.9.
* Andrew to look over Ian's patch series to see how bad extra XenStore
   permission would be.  - No.
* Jenny – XenServer is continuing to make slow progress. We have XenCentre
   patch that means it can talk to QEMU trad, working on some bugs.  Various
   other small bit of work done.

Andrew to double check dm-op sub ops for continuation support.

XenServer uses XenStore to communicate the VNC QEMU clipboard to the
guest and back.  It was concluded this isnt nice, as has caused
veriose security problems in the past.  New plan is to implement this
using a shared page.

Next XenStore restriction was discussed. Including an approach
involving using a shared ring buffer and removing the previous
xs-restrict.  Instead implementing an xs restriction prefixing command
within the xenbus command.  Slightly fiddly, but small number of
parts.  Its doable and not controversial.

Andrew had a diffident plan, to remove any use of XenStore from QEMU –
specifically for the hvm case.  Currently little us in the hvm case.
Two uses should be trivial to implement in QMP, and the other is
physmap, which Igor has been working on.

Its agreed the phymap key needs removing, and that removing the last
few uses of XenStore would be a good idea, however, if it seemed that
dealing with the physmap issue where to take a long time, the
xs-ristrict could be used as an intermidiate plan, which would allow
this project to move on while physmap or any other complications are
being sorted out.

Andrew is not convinced that allowing a guest to fiddle with the
phymap keys (as wolud have to be permitted under the xs-restict
scheme) would be safe.  Certainly the guest could destroy itself,
which in itself is permit-able, but as it changes the interval virtual
memory layout for QEMU, there might be some exploit hidden there –
this would need to be checked.

The conversation turns to the physmap keys, being the biggest XenStore
concern.  Andrew suggests that the correct way to fix it in a
compatible way would be if grant map foreign took in a pointer that
would be nmaped. The pointer would allow the range to be mapped
exactly where it pointed.  A new library call to xen foreign map could
be written, but the complication of needing compatibility for QEMU
with older versions of Xen was raised.

Ian suggested that this wasn’t really a problem, since we could do the
old thing with the old versions.  Libxl already tests for the version
of QEMU, and so if it finds this too old, it does the phymap keys
thing, otherwise, it can use QEMU-depriv including the the new physmap
mechanism.

The new physmap mechanism would not require a substitute for the
physmap keys, as QEMU already has all the information it needs.  The
keys where entirely to allow two parts of startup logic in QEMU to be
reversed.  Andrew  says that Igor has a solution but doestn think its
upstreamable.

Ian suggests that given the size of the xs-restrict patch queue, if
can fix the physmap issue relatively easily, we should, and then he
could drop most of the xs-restict patchque.  Ian offers to help with
the libxl part of the phymap work.

Igor explains an approach he tried hit a block of QXL, which
initialised certain registers and write then into various memory
locations.  He tried in each place to insert an  'if Xen and
runstate=resuming', doent touch.   But the fix is very intrusive in
terms of QXL code, and so he didn’t try to upstream it.

The idea of using helper functions was discussed.  Other helper
functions have been used before for similar problems.  A function
could be created to access vram, instead of just writing to a pointer.
All the access parts of QXL code could eb redirected though this
helper function, and that would be likely ustreamable.  In particular,
its been suggested before that helper function could be used for range
checking.  They could be added for range checking, and then also
modified for with the 'if xen and resuming' clauses.

Igor explains how another approach he had been looking at was to
change the order of QEMU startup, and move the memory map, and
actually map the memory where QEMU expects it to be mapped.  Here
again, there was the issue of compatibility.  The compact layer is
still needed to work with old versions of libxc.  It was discussed how
it would have QEMU would have to be able to work with both skews.  It
could be decided at compile time, as you at this point if you have the
new function call.  It the new function call is not available, it
would default to old behaviour.  A goal of Igors was to remove the
phymas XenStore keys code altogether, but for the depriv project, the
important bit want they where not used.  It was also noted that
compact code can eventually be retired, when its felt no one is using
it any more.

The xenserver case, using QEMU-trad, XenServer hasn’t needed to create
the physmap keys, and would rather not start.  A benefit for libXL is
it could get rid of a magic record for the migration stream.

The new libxen foreign mem call would still be need. This is too late
for 4.9, but that not a problem, and XenServer can backport.   RFCs
can be posted sooner.

The conversation returns to XenStore.  The patchque can be
substantially cut down, which is a good thing.  The other uses of
XenStore are thought to be 'start log dirty' and the 'shutdown' keys.
It was thought it was likely that QEMU might already have QMP commands
to do these things, but if not, they are likely to be very happy to
allow them to be added.  After this, XenStore can be moved into the PV
specific part of the code.

Jenny suggested ring0 could put an item on their backlog to look at
log dirty and the shutdown code.  They should also do a scan for other
uses.  The xentore clipboard problem is entirely a XenServer problem,
and they can implement the new clipboard mechanism in their own time.

Ian still on the hook for the CD and libxl work.  Will still have to
do the two QEMUs code, and all the code to do with starting and
stopping two QEMUs.  But much less painful.

Jenny has already created a confluence page linking to previously
posted meeting notes, and it was suggested this could be extended to
include action points, links to created code or links to related
discussions.

Action Items
------------

* If Andrew to double check dm-op sub ops for continuation support
* Igor to implement and post patches to create new mem map function,
   and to implement the new phymap mechanism in QEMU.
* Ian to look a using and FD for QMP cd insert and emulated hotplug,
    as well as splitting two QEMUs.
* Jenny to create internal jira tickets looking at removing other
   used of XenStore in QEMU, as well update the  confluence page.


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