RE: [Xen-users] Xen support for AMD's IOMMU

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: Daniel McAllansmith [mailto:dm.maillists@xxxxxxxxx] 
> Sent: 27 February 2007 00:07
> To: Petersson, Mats
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Xen support for AMD's IOMMU
> 
> On Tuesday 27 February 2007 01:50, Petersson, Mats wrote:
> > > Hello.
> > >
> > > What is the status of support for AMD's (hardware/Pacifica)
> > > IOMMU in xen
> > > 3.0.2/3/4?
> >
> > Considering that we haven't yet got a part available with IOMMU, the
> > software to fullfill that function is pretty much a moot 
> point, right?
> >
> > As to a direct answer to the question: There is no AMD 
> IOMMU software in
> > 3.0.{2,3,4}. There's been a patch supplied by Mark 
> Langsdorf to use the
> > GART in the current AMD64 architecture for IOMMU operations 
> (same way as
> > the Linux kernel itself uses this portion of the chip). 
> This is NOT to
> > be confused with the REAL IOMMU design.
> 
> Ahhh, my mistake.  I thought that both the DEV and the IOMMU 
> had been added to 
> the Pacifica architecture.
> 
> When a 'real' IOMMU is added (perhaps in the Barcelona), and 
> supported, will 
> that allow unmodified drivers on unmodified guest OS's total 
> control of 
> devices?  Or will IRQ delivery issues still require 
> modifications to the 
> guest driver/OS?

There should be no need to modify any of the guest-OS's driver. IRQ
delivery will have to be handled via the hypervisor, but the guest
should "know no difference (compared to real hardware)". Aside from a
little extra latency, there shouldn't be any real difference (and most
modern hardware allows you to fire off more than one piece of work
before an interrupt need to be acknowledged, so there shouldn't be any
BIG performance hit). 

To clarify: the hypervisor interaction is necessary, as the guest
waiting for the interrupt may not be running at the time of the
interrupt. So the HV takes the interrupt, and forwards a "virtual"
interrupt to the guest. The guest then accesses the hardware as it sees
fit, just like in "real hardware". The other difference will be that the
interrupt controller itself is emulated in the hypervisor - in this case
because there is only ONE real interrupt controller in the system, so
the hypevisor needs to: 
1. Make sure the interrupt controller is still working correctly for
other guests (i.e. if one guest disables all interrupts, no other guest
would ever run after that - we don't really wish for that, do we?)
2. Be able to control the interrupt controller for it's own purposes to
allow the hypervisor full control of the hardware. 

--
Mats
> 
> 
> Cheers
> Daniel
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users