| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] frontend and backend devices and different types of hw -
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
|
|
|
| |
|
Home