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