[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



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

Well...  I think you could hook it into the PCI layer reasonably cleanly by 
using function pointers to ensure that one set of arch functions got called 
for dom0 operation and another set get called for driver domains.

Bear in mind we don't necessarily need to interpose the PCI virtualisation 
code on accesses to the device itself, just those to the PCI bridges.  Access 
to the device itself can be made directly (although see my comment below).
> 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.

That sounds like the sort of thing I was expecting but I can't tell you where 
to look off the top of my head...

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

1.x: PCI core code and device drivers in Xen, only virtual devices in guest
2.x: PCI core code in Xen, device drivers in domains
3.x: PCI core code in dom0, no driver domains yet...

In the 1.x architecture there just weren't any driver domains, Xen had all the 
drivers (except the graphics driver, which lived in the X server as usual).  
In 2.x the PCI core was in Xen, with guests' PCI layer making hypercalls 
instead of doing direct hardware access.  Giving a guest a device consisted 
of: allowing it to see *just* that device in config space (reported in the 
hypercall interface), modifying its IO bitmap and memory mapping privileges 
so that it could access these things.

Since all this is yanked out of Xen now, we don't have quite such convenient 
mechanisms for hiding things from the guest; hence config space access needs 
to be able to go through another channel, or (as you have been working 
towards) emulated somewhere.

Had you considered retasking some of the existing "IO packet" stuff as used by 
the Qemu device model to pass requests up to userspace?  Since this is only 
for device discovery the performance hit shouldn't be an issue.  This avoids 
adding code to Xen *and* avoids special-casing in the PCI code.

While I'm on the subject, I'd personally like to see guests granted IO access 
slightly differently.  There are two ways to grant IO access on x86: change 
the IOPL (giving the guest access to all IO ports) or set IO bits in the TSS 
(giving fine grained control).  The problem with the latter is that guest 
*apps* will be able to access the hardware; essentially x86 gives you coarse 
grained control and ring-level protection, or vice-versa.

Since people often like to partition their systems using Xen, I don't really 
like giving apps easy access to the hardware in this way.  I'd like to have 
the option of trapping IO port writes in Xen and verifying the guest's IO 
privileges in software, then emulating the write.  It is my hope that this 
won't hurt too much on decent hardware (e.g. devices that use an in memory 
buffer descriptor queue) and that on less clever hardware it won't matter too 
much...

Thoughts?

Cheers,
Mark


>   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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.