[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] frontend and backend devices and different types of hw - pci for example
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |