[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 2/4] x86: remove PVHv1 code



On Tue, Mar 14, 2017 at 04:29:22PM +0000, Wei Liu wrote:
> On Tue, Mar 14, 2017 at 10:27:25AM +0000, Wei Liu wrote:
> > On Mon, Mar 13, 2017 at 04:50:12PM +0000, Wei Liu wrote:
> > > On Fri, Mar 03, 2017 at 12:25:06PM +0000, Roger Pau Monne wrote:
> > > > This removal applies to both the hypervisor and the toolstack side of 
> > > > PVHv1.
> > > > 
> > > > Note that on the toolstack side a new PVH domain type is introduced to 
> > > > libxl.
> > > > The "none" device model version is removed, together with the "pvh" 
> > > > field in
> > > > the create info struct (the defines announcing those features are also 
> > > > removed
> > > > from libxl.h). The canonical way to create a PVH guest in libxl is to 
> > > > add
> > > > "pvh=1" to the guest config file.
> > > > 
> > > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > > > Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > > > Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
> > > > Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > > > Acked-by: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
> > > > Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> > > > ---
> > > > Changes since v1:
> > > >  - Remove dom0pvh option from the command line docs.
> > > >  - Bump domctl interface version due to the removed CDF flag.
> > > >  - Introduce LIBXL_DOMAIN_TYPE_PVH.
> > > >  - Remove "none" from the valid device model version options.
> > > >  - Update the xl.cfg(5) man page to reflect the changes.
> > > > 
> > > > ---
> > > > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > > > Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> > > > Cc: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
> > > > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > > > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > > > Cc: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > > > Cc: Jun Nakajima <jun.nakajima@xxxxxxxxx>
> > > > Cc: Kevin Tian <kevin.tian@xxxxxxxxx>
> > > > Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> > > > Cc: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
> > > > Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
> > > > ---
> > > >  docs/man/xl.cfg.pod.5.in            |  16 +-
> > > >  docs/misc/pvh-readme.txt            |  63 --------
> > > >  docs/misc/xen-command-line.markdown |   7 -
> > > >  tools/debugger/gdbsx/xg/xg_main.c   |   4 +-
> > > >  tools/libxc/include/xc_dom.h        |   1 -
> > > >  tools/libxc/include/xenctrl.h       |   2 +-
> > > >  tools/libxc/xc_cpuid_x86.c          |  13 +-
> > > >  tools/libxc/xc_dom_core.c           |   9 --
> > > >  tools/libxc/xc_dom_x86.c            |  49 +++---
> > > >  tools/libxc/xc_domain.c             |   1 -
> > > >  tools/libxl/libxl.h                 |  22 +--
> > > >  tools/libxl/libxl_console.c         |   1 +
> > > >  tools/libxl/libxl_create.c          |  64 +++-----
> > > >  tools/libxl/libxl_disk.c            |  10 +-
> > > >  tools/libxl/libxl_dm.c              |   2 +
> > > >  tools/libxl/libxl_dom.c             |  86 ++++++-----
> > > >  tools/libxl/libxl_dom_save.c        |   7 +-
> > > >  tools/libxl/libxl_dom_suspend.c     |   4 +-
> > > >  tools/libxl/libxl_domain.c          |  18 +--
> > > >  tools/libxl/libxl_internal.h        |   1 -
> > > >  tools/libxl/libxl_mem.c             |   1 +
> > > >  tools/libxl/libxl_nic.c             |   7 +-
> > > >  tools/libxl/libxl_pci.c             |   9 +-
> > > >  tools/libxl/libxl_stream_read.c     |   8 +-
> > > >  tools/libxl/libxl_stream_write.c    |  14 +-
> > > >  tools/libxl/libxl_types.idl         | 115 ++++++++-------
> > > >  tools/libxl/libxl_usb.c             |   4 +-
> > > >  tools/libxl/libxl_x86.c             |  31 ++--
> > > >  tools/libxl/libxl_x86_acpi.c        |   3 +-
> > > >  tools/xl/xl_parse.c                 |   8 +-
> > > [...]
> > > > +                [("hvm", libxl_domain_build_info_hvm),
> > > > +                 ("pvh", libxl_domain_build_info_hvm),
> > > 
> > > This "pvh" field is never used in code - instead you fill in the hvm
> > > fields. It is problematic because people don't know how to use this.
> > > 
> > > Either we don't want this, or you would have to (tediously) fill this
> > > in. I think the latter is what Ian has asked for. Unfortunately C
> > > doesn't have good support for meta-programming.
> > 
> > On second thought, let's look at this from user's perspective. A user of
> > libxl would certainly use .u.pvh field to construct a pvh guest, so I
> > think we need the pvh struct.
> > 
> > Since .u.pvh and .u.hvm share the same layout and type-punning via union
> > is allowed even when strict-aliasing is enabled, this patch *might* just
> > work. (Can someone familiar with C standard check this?)
> > 
> > Ultimately I would like to avoid tricky code like this even it conforms
> > to C standard. Let me check if there is a way forward.
> > 
> 
> The more I think about this, the more I realise we're trying to do two
> things at the same time: to remove PVHv1 code and repurpose toolstack
> elements (xl pvh option, and b_info etc). This is the reason why this
> series has been dragging on longer than necessary. And no doubt doing
> the two at the same time will make this patch difficult to review.

Right, at first I though that I should provide a suitable replacement so that
the "pvh=1" option is always working, but since this is experimental I don't
see a need for that. I will update this patch to just remove the PVHv1 stuff
(including "pvh=1"), and then I can implement that option for PVHv2.

> Hence I propose to do one thing at a time. This patch should just remove
> the PVHv1 implementation, and leave the adding PVHv2 toolstack support
> to another patch. I have no problem with deleting pvh related stuff in
> libxl and xl because we have no obligation to maintain backward
> compatibility.

Right, I think this is correct.

Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.