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

Re: [Xen-devel] [PATCH RFC 00/10] x86 passthrough code cleanup


  • To: Wei Liu <wei.liu2@xxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Sat, 24 Feb 2018 03:23:48 +0000
  • Accept-language: en-US
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Sat, 24 Feb 2018 03:24:02 +0000
  • Dlp-product: dlpe-windows
  • Dlp-reaction: no-action
  • Dlp-version: 11.0.0.116
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHTq123XYaCRNfRBEiKENXrs72vpaOxcjMwgAAx6ACAAUIKAA==
  • Thread-topic: [Xen-devel] [PATCH RFC 00/10] x86 passthrough code cleanup

> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: Saturday, February 24, 2018 12:08 AM
> 
> On Fri, Feb 23, 2018 at 05:12:05AM +0000, Tian, Kevin wrote:
> > > From: Wei Liu
> > > Sent: Thursday, February 22, 2018 5:47 AM
> > >
> > > Hi all
> > >
> > > At some point I would like to make CONFIG_HVM and CONFIG_PV work.
> > > The
> > > passthrough code is one of the road blocks for that work.
> >
> > Can you elaborate the motivation of this change? why does someone
> > want to disable HVM or PV logic completely from hypervisor?
> >
> 
> At some point in the future, we would like to utilise as many hardware
> features as possible and have an HVM / PVH only setup. At that point PV
> code will be necessarily and should be preferably compiled out to reduce
> code size and attack surface.
> 
> Having PV compiled out also enable Xen to reclaim some address space
> from the PV ABI.
> 
> But, we understand that PV is here to stay for at least a while and
> could be useful for some other niche use cases, so upstream have
> developed a PV-in-PVH shim to continue to support PV guests. The shim is
> actually yet another configuration of Xen running as a PVH guest but
> exposes PV ABI to PV guests. We want to disable HVM code in that case,
> again, to reduce code size and attach surface.

since it's only temporary, do we really care about code size or attacking
surface in such case? or is it worthy of the effort regarding to the gain
which you anticipate?

I sort of buy-in CONFIG_PV, but not sure whether CONFIG_HVM is
required.

> 
> There is also the long term benefit to make Xen more maintainable and
> approachable in the future.
> 
> See
> https://www.slideshare.net/xen_com_mgr/xpdds17-keynote-towards-a-
> configurable-and-slimmer-x86-hypervisor-wei-liu-citrix
> 
> Wei.

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

 


Rackspace

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