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

Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

  • To: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 31 May 2007 07:49:54 +0100
  • Delivery-date: Wed, 30 May 2007 23:45:53 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acei7YJ0pr6pL1ntT2Wzdmq3YT+WeAABwdLMAAN25GAAE1/hMg==
  • Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

On 30/5/07 23:02, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:

>> How does this new scheme work? Can it supplant the
>> ioapic_ack=new method?
>> Clearly requiring the use of a hacky command-line option to
>> make use of a
>> new core feature is not very nice to say the least.
> Basically, the calls to mask_IO_APIC_irq()/unMask_IO_APIC_irq()
> in arch/x86/io_apic.c were replaced with
> write_fake_IO_APIC_vector()/restore_real_IO_APIC_vector
> - where the fake vector is an unused vector.
> Since the global interrupt from chipset only occurs during
> masked interrupts, this avoids that chipset bug that cause
> you to switch to ioapic_ack=new last year.  I believe it can
> supplant ioapic_ack=new method.

I'm not against removing the 'new' ioapic-ack method entirely if this is
better. I just don't fully understand this replacement method yet. I'll need
a walkthrough of the new mask/unmask replacements, most likely!

 -- Keir

Xen-devel mailing list



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