| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] domU hardware access
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Luca Lucchesi
> Sent: 28 February 2007 00:33
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] domU hardware access
>
> >( this is explained in the xen manuals, keyword pciback.hide)
>
> Thank you very much!
>
> >Cant say anything about the dat drive. How is the dat-drive
> connected ?
>
> The DAT drive is connected with a SCSI controller, so I think
> I have to let
> the domU to access to the SCSI controller.
> This is not my case, but what about if I want to let one domU
> to access to
> one SCSI drive and another domU to access to another SCSI
> drive on the same
> SCSI controller?
That's not allowed - each PCI device must belong as a whole to one
domain only. A SCSI controller is normally a single PCI device [you find
out by using lspci - if you have one card and there shows up two devices
of that type, then it's two PCI devices, and you could divide the card
into two devices].
The reason you can't share devices between domains is that there's no
guarantee of atomicity, and most PCI devices have complex command/data
correlations, such as you write one place to say "Here's the buffer" and
some other place to say "here's where I want it on the LUN" and
someplace else "I want to write the buffer". Each of those locations to
write need to be filled in by one domain and the command completed
before another domain could possibly access the same PCI device. Just
imagine what happens if one domain says "Here's the buffer", "place at
LUN" - another domain gets scheduled in and decides to say "Here's my
buffer", "place at LUN", "Go Read it" - then schedule back to first
domain who says "Go write it" - now we've overwritten something of the
other domains data, completely at random.
Since there's no way to make sure that the domains don't collide like
descibed above, we can't allow the same device to be shared (other than
completely rewriting the driver - and then we're probably better off
with the PV split driver model anyways).
--
Mats
>
> Luca.
>
> _________________________________________________________________
> Sudoku, Calcio, Duel... Prova i nuovi giochi di Messenger!
> http://get.live.com/messenger/features#ID0EKG
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home