Re: [Xen-devel] [PATCH] xl: remove apic option for PVH guests

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 13, 2018 at 10:31:20AM +0000, Roger Pau Monné wrote:
> On Mon, Mar 05, 2018 at 08:43:48AM -0600, Doug Goldstein wrote:
> > On 3/2/18 5:29 AM, Jan Beulich wrote:
> > >>>> On 02.03.18 at 12:09, <wei.liu2@xxxxxxxxxx> wrote:
> > >> On Thu, Mar 01, 2018 at 05:01:55PM +0000, Roger Pau Monné wrote:
> > >>> On Thu, Mar 01, 2018 at 04:01:23PM +0000, Wei Liu wrote:
> > >>>> On Thu, Mar 01, 2018 at 03:57:18PM +0000, Andrew Cooper wrote:
> > >>>>> On 01/03/18 12:22, Wei Liu wrote:
> > >>>>>> On Wed, Feb 28, 2018 at 10:20:53AM +0000, Roger Pau Monne wrote:
> > >>>>>>> XSA-256 forces the local APIC to always be enabled for PVH guests, 
> > >>>>>>> so
> > >>>>>>> ignore any apic option for PVH guests. Update the documentation
> > >>>>>>> accordingly.
> > >>>>>> I think how I will approach this is to dictate that PVH always has 
> > >>>>>> LAPIC
> > >>>>>> in our in-tree document, then use that as the justification for this
> > >>>>>> change. That's the consensus from 2 years ago, right?
> > >>>>>>
> > >>>>>> Or we're just working around the limitation in our code base, and 
> > >>>>>> users
> > >>>>>> may demand a no-LAPIC PVH guest just because...
> > >>>>>
> > >>>>> Currently, Xen enforces that HVM guests have an LAPIC.  This is 
> > >>>>> because
> > >>>>> making the non-LAPIC case function correctly/safely devolved into a
> > >>>>> massive rats nest and I stopped trying to fix it after 2 days of 
> > >>>>> trying.
> > >>>>>
> > >>>>> At the moment, it would be wise to discuss whether the non-LAPIC case 
> > >>>>> is
> > >>>>> actually sensible.  I personally see no value in keeping it.
> > >>>>>
> > >>>>
> > >>>> +1
> > >>>>
> > >>>>> If someone can come up with a convincing usecase for keeping it, then
> > >>>>> ok, but the barrier for this is increasing all the time, especially 
> > >>>>> now
> > >>>>> that hardware acceleration and posted interrupts means that a
> > >>>>> pipeline-virtualised APIC is faster and more efficient than any of our
> > >>>>> event channel mechanisms.
> > >>>>
> > >>>> +1
> > >>>
> > >>> I've looked at the in-tree pvh document and it just refers to the local
> > >>> APIC in this sentence:
> > >>>
> > >>> "AP startup can be performed using hypercalls or the local APIC if 
> > >>> present."
> > >>>
> > >>> I guess the trailing "if present" could be removed, but it's not
> > >>> colliding with this patch.
> > >>>
> > >>> I'm happy with rebasing this patch and applying the above change, is
> > >>> there any other document that should be changed?
> > >>
> > >> Can we make it more explicit. Like
> > >>
> > >>   VCPUs for PVH must have local APIC and it can't be disabled.
> > >>
> > >> ?
> > > 
> > > To be honest I liker Roger's suggestion better. And yet better
> > > would imo be if we left that sentence alone, unless we really mean
> > > to close that road for anyone wanting to take on making APIC-
> > > less guests work securely.
> > > 
> > > Jan
> > 
> > I believe that's exactly what Andrew proposed in
> > https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg00089.html
> > removing the wording doesn't exclude someone from adding it later but it
> > does make it clear that its not available today.
> 
> I'm kind of lost regarding whether we reached consensus or not. Is the
> current patch suitable, or should I change some of the wording?

I'm fine with the wording of the doc for now.

Ian had a question on HVM path that is yet to be answered.

Wei.

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