|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Disabling lapic and apic: pitfalls?
> APIC is required for multiprocessor HVM guests. It can be
> lived without for UP guests.
LAPIC or (IO)APIC or both? And a key part of the question
is what does "lived without" mean (as far as functionality
or performance or stability or ??? lost)?
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Friday, March 14, 2008 12:49 PM
> To: dan.magenheimer@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Disabling lapic and apic: pitfalls?
>
>
> APIC is required for multiprocessor HVM guests. It can be
> lived without for
> UP guests.
>
> -- Keir
>
> On 14/3/08 17:55, "Dan Magenheimer"
> <dan.magenheimer@xxxxxxxxxx> wrote:
>
> > Excuse my newbie-ness in this area... I hope the answers aren't
> > too obvious or widely known.
> >
> > What are the disadvantages of disabling the LAPIC and APIC in a
> > Linux virtual machine? What functionality is lost? What class
> > of potential bugs might arise (or go away)?
> >
> > Does the answer differ for hvm vs pvm?
> >
> > Does the answer differ depending on whether the platform
> > underlying is Intel or AMD? 32-bit vs 64-bit?
> >
> > Does the answer differ for vcpus=1 vs vcpus>1 (assuming CONFIG_SMP)
> >
> > (And what about for Windows of various flavors?)
> >
> > For example, I can see that if lapic is enabled, an extra 1000
> > interrupts per second are delivered to the VM (250 for pvm).
> > Are these useful for anything? Or are they just eating VM cycles?
> >
> > I suspect that disabled apic may break driver domains or pci
> > passthrough. True? What about lapic?
> >
> > I ask all these questions because I often see problem responses of
> > the type "Try apic=0" or "Boot with noapic" and I wonder about the
> > side effects of such a cure. Or whether the cure should be
> > universally applied for VMs: Depending on the answers to the
> > above questions, perhaps the default should be off and we
> > should be saying "Try apic=1 if you need that functionality".
> >
> > Thanks,
> > Dan
> >
> >
> > ===================================
> > If Xen could save time in a bottle / then clocks wouldn't
> virtually skew /
> > It would save every tick / for VMs that aren't quick /
> > and Xen then would send them anew
> > (with apologies to the late great Jim Croce)
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|