WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] frontend and backend devices and different types of hw - pci for example
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Sat, 3 Sep 2005 14:42:19 -0400
Cc: Sting Zax <zstingx@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 03 Sep 2005 18:40:18 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200509031846.24834.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/03/2005 01:46:24 PM:

> > 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.
> 
> Possibly...  I would have been inclined to do it using some sort of 
> interdomain communication rather than using an emulator in Xen but I'm 
> actually open to persuasion that I'm wrong on this point ;-)

I thought about interdomain communication for emulating PCI devices. It 
'feels' like this would rip apart both  domain's PCI layers quite a bit.

> 
> > 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

I wrote this wrong: I am not presenting this to the user level, but to the 
user domain kernel.

> > 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.
> 
> Thanks for the extra detail.
> 
> Hmmm.  Sounds a bit weird...  Afraid I'm not sure what might be going on 
here.

What's going on here is for example that the PCI configuration space says 
the interrupt the Ethernet card is on is IRQ '9', but in reality the 
system is using for example interrupt '21' for this device - this happens 
through translation in other parts where APIC or ACPI-related code plays a 
role. I haven't had the time to find out what part of the system is doing 
that. Another issue is that the code in /xen/.../io_apic.c is not 
activated at all in a user/driver domain. 

I believe the architecture for access to PCI was different in Xen 1.0 
where PCI was in the HV. With 2.0 this changed and PCI access was moved to 
domain 0. Did driver domains work with that? If yes, then what was done in 
domain 0 to prepare a domain's access to a device?

  Stefan
> 
> Cheers,
> Mark
> 
> >   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
> >
> > migh - 
> >
> > > 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


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