Re: [Xen-devel] frontend and backend devices and different types of hw - pci for example

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 08/29/2005 06:45:51 AM:

> >  I had looked at the code of 2.0.*  under xen/arch/x86 saw
> > pci-irq.c and pci-pc.c and pci-x86.c which as I understand handle pci
> > devices other than net/usb.
> > However, I did not saw such modules in the unstable version.
> > May I ask : is this PCI support for non net/usb PCI devices  removed
> > (or temporarily removed) from the unstable version? or maybe I simply
> > missed it ?
> 
> Dom0 now basically owns anything to do with PCI whereas previously Xen 
> controlled core PCI stuff and dom0 just accessed devices.  Support for 
giving 
> device access to other domains will need to be implemented in dom0 (this 

> hasn't been done yet but it's hoped the feature will be back in time for 
the 
> release).

Do you think that an emulated PCI layer underneath every domU could be a 
possibility for a solution of moving PCI devices to user domains? I have 
had some success with it and got as far as for example moving a PCI 
ethernet card or the whole USB controller to a user domain and making the 
user domain kernel activate its drivers. I did this by reading the PCI 
config space (256 bytes) from the device and presenting the data to the 
user level in the emulated PCI bus. However I have then encountered a 
couple of problems afterwards when trying to activate the IRQ. There seems 
to be some translation going on of a PCI IRQ number to the actual number 
the system is using (due to APIC I suppose) and so the data exchange with 
the device did not start.

  Stefan
> 
> > >Note that giving direct physical access to a PCI device has security
> > >implications since the guest can potentially use the cards' DMA
> > > capabilities to access all of physical memory.
> >
> > Will IOMMU support help solving this security problems ?
> 
> Yes but only if it enforces access permissions fully i.e. I don't think 
the 
> IOEMU in AMD64 machines is sufficient.  From the looks of Pacifica it 
might 
> have sufficient support to control the DMA problem, I'm sure Intel have 
a 
> similar solution (although I don't think it's implemented in Vanderpool 
- 
> they'll probably need chipset support).
> 
> Cheers,
> Mark
> 
> >
> > Regards,
> > Sting
> >
> > On 8/28/05, Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote:
> > > > What about other devices ? let's say a PCI sound card (or any 
other PCI
> > > > device). Where is the software that should handle it ? I remember 
I saw
> > > > somewhere some discussion about PCI configuration space, but I 
don't
> > > > remember where.
> > >
> > > That code is in Xen itself in Xen 2.0.  Xen controls access to the 
PCI
> > > configuration spaces so that guests can only see the devices they 
have
> > > access to.  It also controls the IO memory / ports that domains are
> > > allowed to access in order to control PCI devices.
> > >
> > > Note that giving direct physical access to a PCI device has security
> > > implications since the guest can potentially use the cards' DMA
> > > capabilities to access all of physical memory.  The front/back-style
> > > devices do not have this limitation.
> > >
> > > Btw, I've laid some groundwork for a virtual sound device but 
haven't had
> > > much time to hack on it yet.
> > >
> > > Cheers,
> > > Mark
> 
> _______________________________________________
> 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