On Mon, 2009-08-31 at 14:53 -0700, Alok Kataria wrote:
> Hi James,
>
> Thanks for your comments.
>
> On Mon, 2009-08-31 at 11:00 -0700, James Bottomley wrote:
> > On Mon, 2009-08-31 at 10:28 -0700, Alok Kataria wrote:
> > > VMware PVSCSI driver - v2.
> >
> > OK, so the first thing that springs to mind is that we already have one
> > of these things: the ibmvscsi ... is there no way we can share code
> > between this and the other PV drivers?
>
> I took a quick look at the ibmvscsi driver, and there are lot of
> differences between the two, mainly the ABI that is shared between the
> hypervisor and driver differ.
Well, that's pretty abstractable, surely? However, there is an
interesting question of what the best hypervisor interface actually is.
> Also the ibmvscsi driver seems to offer a
> lot of other features as well, like the SRP.
SRP is the protocol transfer abstraction. It's just a way of packaging
up SCSI commands for transfer over a DMA protocol (OK, so it was
envisaged that the DMA protocol would be RDMA, but a hypervisor
interface is also a DMA protocol).
> The pvscsi driver is a simple SCSI adapter driver and is basically no
> different than any other SCSI driver written for a particular HBA.
Well, it is really ... hopefully all the hypervisor interfaces won't
decide to be completely incompatible, so there's a good chance of code
sharing between them.
James
Hi James,
On Tue, Sep 1, 2009 at 7:23 AM, James Bottomley<[email protected]> wrote:
> On Mon, 2009-08-31 at 14:53 -0700, Alok Kataria wrote:
>> Hi James,
>>
>> Thanks for your comments.
>>
>> On Mon, 2009-08-31 at 11:00 -0700, James Bottomley wrote:
>> > On Mon, 2009-08-31 at 10:28 -0700, Alok Kataria wrote:
>> > > VMware PVSCSI driver - v2.
>> >
>> > OK, so the first thing that springs to mind is that we already have one
>> > of these things: the ibmvscsi ... is there no way we can share code
>> > between this and the other PV drivers?
>>
>> I took a quick look at the ibmvscsi driver, and there are lot of
>> differences between the two, mainly the ABI that is shared between the
>> hypervisor and driver differ.
>
> Well, that's pretty abstractable, surely? ?However, there is an
> interesting question of what the best hypervisor interface actually is.
>
>> ?Also the ibmvscsi driver seems to offer a
>> lot of other features as well, like the SRP.
>
> SRP is the protocol transfer abstraction. ?It's just a way of packaging
> up SCSI commands for transfer over a DMA protocol (OK, so it was
> envisaged that the DMA protocol would be RDMA, but a hypervisor
> interface is also a DMA protocol).
>
>> The pvscsi driver is a simple SCSI adapter driver and is basically no
>> different than any other SCSI driver written for a particular HBA.
>
> Well, it is really ... hopefully all the hypervisor interfaces won't
> decide to be completely incompatible, so there's a good chance of code
> sharing between them.
Well, going by that theory every SCSI driver can share some code with
any other SCSI driver, In short we can come up with an low level SCSI
driver interface which every SCSI driver can make use of, to reduce
code duplicity. We don't do that, and the reason being, that its a
device and we shouldn't expect every device to share common features
or design decisions.
We already virtualize storage at the lowest (read device) level to
avoid duplicating stuff in a guest operating system.
If this was say a block level virtaulizing scheme sharing would be
more eminent, but given that we are a device its better to keep things
separate and IMHO, it might be an overkill to design a new pv-driver
or some such layer for every device that you virtualize.
Thanks,
Alok
>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Tue, Sep 01, 2009 at 09:08:48AM -0700, Alok Kataria wrote:
> Hi James,
>
> On Tue, Sep 1, 2009 at 7:23 AM, James Bottomley<[email protected]> wrote:
> > On Mon, 2009-08-31 at 14:53 -0700, Alok Kataria wrote:
> >> Hi James,
> >>
> >> Thanks for your comments.
> >>
> >> On Mon, 2009-08-31 at 11:00 -0700, James Bottomley wrote:
> >> > On Mon, 2009-08-31 at 10:28 -0700, Alok Kataria wrote:
> >> > > VMware PVSCSI driver - v2.
> >> >
> >> > OK, so the first thing that springs to mind is that we already have one
> >> > of these things: the ibmvscsi ... is there no way we can share code
> >> > between this and the other PV drivers?
> >>
> >> I took a quick look at the ibmvscsi driver, and there are lot of
> >> differences between the two, mainly the ABI that is shared between the
> >> hypervisor and driver differ.
> >
> > Well, that's pretty abstractable, surely? ?However, there is an
> > interesting question of what the best hypervisor interface actually is.
> >
> >> ?Also the ibmvscsi driver seems to offer a
> >> lot of other features as well, like the SRP.
> >
> > SRP is the protocol transfer abstraction. ?It's just a way of packaging
> > up SCSI commands for transfer over a DMA protocol (OK, so it was
> > envisaged that the DMA protocol would be RDMA, but a hypervisor
> > interface is also a DMA protocol).
> >
> >> The pvscsi driver is a simple SCSI adapter driver and is basically no
> >> different than any other SCSI driver written for a particular HBA.
> >
> > Well, it is really ... hopefully all the hypervisor interfaces won't
> > decide to be completely incompatible, so there's a good chance of code
> > sharing between them.
>
> Well, going by that theory every SCSI driver can share some code with
> any other SCSI driver, In short we can come up with an low level SCSI
> driver interface which every SCSI driver can make use of, to reduce
> code duplicity. We don't do that, and the reason being, that its a
> device and we shouldn't expect every device to share common features
> or design decisions.
Umm, we do share code between SCSI drivers. We have the ULDs (sg, sd,
sr, etc), we have the midlayer, and we have the transport classes (spi,
iscsi, fc, etc).
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On 09/01/2009 07:13 PM, Matthew Wilcox wrote:
>
> Umm, we do share code between SCSI drivers. We have the ULDs (sg, sd,
> sr, etc), we have the midlayer, and we have the transport classes (spi,
> iscsi, fc, etc).
>
This makes a tons of sense. a scsi_transport_paravirt can have lots of common
nubs. I bet administrators would love such common management facility.
Boaz
On Tue, 2009-09-01 at 09:20 -0700, Boaz Harrosh wrote:
> On 09/01/2009 07:13 PM, Matthew Wilcox wrote:
> >
> > Umm, we do share code between SCSI drivers. We have the ULDs (sg, sd,
> > sr, etc), we have the midlayer, and we have the transport classes (spi,
> > iscsi, fc, etc).
> >
>
> This makes a tons of sense. a scsi_transport_paravirt can have lots of common
> nubs. I bet administrators would love such common management facility.
I don't see how it will help a user. VMware exports a PCI device, and
this device will be available only when running under a VMware
hypervisor. If a particular device is available the OS will use the
corresponding driver.
Please note these drivers will be used by the guest operating system,
which is running virtualized.
I don't get what kind of control the administrator has on this ? can you
please elaborate.
Alok
>
> Boaz