Re: [Xen-devel] [PATCH v3.1 09/15] xen/x86: allow the emulated APICs to be enabled for the hardware domain

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Fri, Nov 04, 2016 at 04:21:02AM -0600, Jan Beulich wrote:
> >>> On 04.11.16 at 10:47, <roger.pau@xxxxxxxxxx> wrote:
> > On Fri, Nov 04, 2016 at 03:19:11AM -0600, Jan Beulich wrote:
> >> >>> On 29.10.16 at 10:59, <roger.pau@xxxxxxxxxx> wrote:
> >> > --- a/xen/arch/x86/domain.c
> >> > +++ b/xen/arch/x86/domain.c
> >> > @@ -509,6 +509,27 @@ void vcpu_destroy(struct vcpu *v)
> >> >          xfree(v->arch.pv_vcpu.trap_ctxt);
> >> >  }
> >> >  
> >> > +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> >> > +{
> >> > +
> >> > +    if ( is_hvm_domain(d) )
> >> > +    {
> >> > +        if ( is_hardware_domain(d) &&
> >> > +             emflags != 
> >> > (XEN_X86_EMU_PIT|XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC) )
> >> > +            return false;
> >> 
> >> Why are hardware domains required to get all three?
> > 
> > The PIT is always enabled for hardware domains, although we might consider 
> > disabling it for PVHv2 Dom0? TBH, I don't have a strong opinion here.
> 
> I think unless there's a reason to require it, it should be optional.

Ack.
 
> > The local APIC and IO APIC are required in order to deliver interrupts from 
> > physical devices (this is only for PVHv2 hardware domains).
> 
> I can see the need for an LAPIC, but I don't think IO-APICs are
> strictly necessary. Therefore I'd like the option of it being optional
> at least to be considered (perhaps by way of a brief note in the
> commit message).

While it should be possible to run without an IO APIC, AFAICT most USB 
controllers still only support legacy PCI interrupts, and then the SCI ACPI 
interrupt is also delivered from a ISA IRQ. I could make the IO APIC 
optional, but it's going to hinder the functionality of a Dom0 IMHO if 
disabled.

What about adding a no-ioapic option to the dom0= list of options?

Roger.

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