On Tuesday 02 February 2010 22:37:06 Keir Fraser wrote:
> On 02/02/2010 14:32, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
> >>> Okay, so that leads to the obvious next question: why do you want to
> >>> avoid using INIT-SIPI-SIPI?
> >>
> >> Because we don't have IOAPIC/LAPIC...
> >
> > Is it necessary to remove the LAPICs completely? If you go very far down
> > the route of ripping emulated stuff out of HVM, it starts to feel like
> > starting with a pure PV guest and HVMing it up is closer in spirit to
> > what you might be aiming for.
>
> The other thing is, removing some of this stuff weakens the argument that
> the hybrid approach lets us 'ride the wave' of improving hardware virt
> support. For example, LAPIC is pretty architectural these days, and is ripe
> for fuller hardware virtualisation. If you put HVM onto event channels and
> totally rip out the LAPIC, where does that leave us if full LAPIC virt
> comes along, with all its potential for especially improving device
> passthru performance?
In fact, our target is improving device passthru performance(before full LAPIC
virtualziation ready in every server). And what we mostly targeted is MSI/MSI-
X interrupt intensive devices. This didn't include in this patchset(we have
experiment patches of course), because that can't avoid touching the some
generic kernel code, e.g. MSI related things in ioapic.c, make it harder to be
checked in. The code to support hybrid MSI/MSI-X device can be shared with
pv_ops dom0, so that is what we planed next step.
And these hybrid features are component based. I admit, sooner or later, these
PV solutions would be replaced with hardware features. If you got new enough
hardwares, you can simply disable them; if you didn't, you can still benefit
from them. Of course, as you know, it takes time to get new enough machine for
everyone. So I think, it's better to do something now rather than simply
waiting for hardware feature come. :)
--
regards
Yang, Sheng
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home