Re: [libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci

2019-12-22 Thread Cole Robinson
FYI there's some more recent discussion over here:
https://www.redhat.com/archives/libvir-list/2019-December/msg00817.html

There isn't any objections to using  for
vhost-user-blk, so maybe that's a good place to start.

Thanks,
Cole


On 10/15/19 7:34 AM, Li Feng wrote:
> Cole Robinson  于2019年10月15日周二 上午1:48写道:
>>
>> On 10/14/19 3:12 AM, Li Feng wrote:
>>> Hi Cole & Michal,
>>>
>>> I'm sorry for my late response, I just end my journey today.
>>> Thank your response, your suggestion is very helpful to me.
>>>
>>> I have added Michal in this mail, Michal helps me review my initial 
>>> patchset.
>>> (https://www.spinics.net/linux/fedora/libvir/msg191339.html)
>>>
>>
>> Whoops I missed that posting, I didn't realize you had sent patches!
>>
>>> All concern about this feature is the XML design.
>>> My original XML design exposes more details of Qemu.
>>>
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>
>>> As Cole's suggestion, the better design with all vhost-user-scsi/blk
>>> features would like this:
>>>
>>> vhost-user-blk:
>>>
>>> 
>>> 
>>> 
>>>  
>>> 
>>> 
>>>  >> function='0x0'/>
>>> 
>>>
>>> vhost-user-scsi:
>>>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>
>> I think my SCSI idea is wrong, sorry. vhost-user-scsi is for passing a
>> scsi host adapter to the VM, correct? If so, then it's not really a
>> , and so using the existing vhost-scsi support in  is
>> probably better.  could possible be used for vhost-user-blk as well
>>
>> Can you provide some examples of full qemu command lines using
>> vhost-user-blk and vhost-user-scsi? Just linking to examples else where
>> is fine, but I'm wondering if there's more context
> 
> You could check the vhost-user-scsi/blk examples from SPDK pages:
> https://spdk.io/doc/vhost.html
> 
>>
>> Internally we already have an abstraction for vhost-scsi:
>>
>> 
>>   
>> 
>>
>>
>> The obvious extension would be
>>
>> 
>>   > path='/path/to/vhost-user-scsi.sock' mode='client'/>
>> 
>>
>> Internally implementing this will be weird. The  parameters are
>> only dictated by the hostdev type= field, but in this case they would be
>> dictated by the  field, and we would want to reuse the
>> internal chardev abstraction.
>>
>> vhost-user-blk could be implemented similarly, but with type='storage'
>> which is the way we pass through block devices to LXC guests, but it
>> isn't currently supported in the qemu driver.
>>
>> I dunno. Maybe Michal or danpb can provide guidance
>>
> @Michal, @danpb, could you give some guidance?
>>
>>> Conclusion:
>>> 1. Add new type(vhostuser) for disk label;
>>> 2. Add queue sub-label for disk to support multiqueue(>> num='4'/>) or reusing the driver label
>>> (>> Qemu support multiqueue like this:
>>> -device vhost-user-scsi-pci,id=scsi0,chardev=spdk_vhost_scsi0,num_queues=4
>>> -device vhost-user-blk-pci,chardev=spdk_vhost_blk0,num-queues=4
>>>
>>
>> num-queues is already supported by libvirt for both  and 
>> with , so whether we use  or  you won't
>> need to add any new XML here.
> Got it.
> 
>>
>>> Another question:
>>> When qemu is connecting to a vhost-user-scsi controller[1],  there may
>>> exist multiple LUNs under one target,
>>> then one disklabel() will represent multiple SCSI LUNs,
>>> the 'dev' property() will be ignored, right?
>>> In other words, for vhost-user-scsi disk, it more likes a controller,
>>> maybe the controller label is suitable.
>>>
>>
>> Yes you are right, and this was my understanding. But then its not
>> really a  in libvirt's sense because we can't attach
>> emulated devices to it, so it's more a fit for the existing 
>> vhost-user support. Unfortunately it's not really a clean fit anywhere,
>> there will have to be some kind of compromise. And I'm not sure if
>>  or  is right for vhost-user-blk, but hopefully others
>> have more clear opinions.
> 
> I'm also confused about it.
> Thanks for your reply.
> 
> Thanks,
> Feng Li
> 
>>
>> Thanks,
>> Cole
>>
>>> I look forward to he

Re: [libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci

2019-10-14 Thread Cole Robinson
On 10/14/19 3:12 AM, Li Feng wrote:
> Hi Cole & Michal,
> 
> I'm sorry for my late response, I just end my journey today.
> Thank your response, your suggestion is very helpful to me.
> 
> I have added Michal in this mail, Michal helps me review my initial patchset.
> (https://www.spinics.net/linux/fedora/libvir/msg191339.html)
> 

Whoops I missed that posting, I didn't realize you had sent patches!

> All concern about this feature is the XML design.
> My original XML design exposes more details of Qemu.
> 
>  
>  
>  
>  
>  
>  
> 
> As Cole's suggestion, the better design with all vhost-user-scsi/blk
> features would like this:
> 
> vhost-user-blk:
> 
> 
> 
> 
>  
> 
> 
>   function='0x0'/>
> 
> 
> vhost-user-scsi:
> 
> 
> 
> 
> 
> 
> 
> 
> 

I think my SCSI idea is wrong, sorry. vhost-user-scsi is for passing a
scsi host adapter to the VM, correct? If so, then it's not really a
, and so using the existing vhost-scsi support in  is
probably better.  could possible be used for vhost-user-blk as well

Can you provide some examples of full qemu command lines using
vhost-user-blk and vhost-user-scsi? Just linking to examples else where
is fine, but I'm wondering if there's more context

Internally we already have an abstraction for vhost-scsi:


  



The obvious extension would be


  


Internally implementing this will be weird. The  parameters are
only dictated by the hostdev type= field, but in this case they would be
dictated by the  field, and we would want to reuse the
internal chardev abstraction.

vhost-user-blk could be implemented similarly, but with type='storage'
which is the way we pass through block devices to LXC guests, but it
isn't currently supported in the qemu driver.

I dunno. Maybe Michal or danpb can provide guidance


> Conclusion:
> 1. Add new type(vhostuser) for disk label;
> 2. Add queue sub-label for disk to support multiqueue( num='4'/>) or reusing the driver label
> ( Qemu support multiqueue like this:
> -device vhost-user-scsi-pci,id=scsi0,chardev=spdk_vhost_scsi0,num_queues=4
> -device vhost-user-blk-pci,chardev=spdk_vhost_blk0,num-queues=4
> 

num-queues is already supported by libvirt for both  and 
with , so whether we use  or  you won't
need to add any new XML here.

> Another question:
> When qemu is connecting to a vhost-user-scsi controller[1],  there may
> exist multiple LUNs under one target,
> then one disklabel() will represent multiple SCSI LUNs,
> the 'dev' property() will be ignored, right?
> In other words, for vhost-user-scsi disk, it more likes a controller,
> maybe the controller label is suitable.
> 

Yes you are right, and this was my understanding. But then its not
really a  in libvirt's sense because we can't attach
emulated devices to it, so it's more a fit for the existing 
vhost-user support. Unfortunately it's not really a clean fit anywhere,
there will have to be some kind of compromise. And I'm not sure if
 or  is right for vhost-user-blk, but hopefully others
have more clear opinions.

Thanks,
Cole

> I look forward to hearing from you as soon as possible.
> 
> [1]: https://spdk.io/doc/vhost.html
> 
> Feng Li
> 
> Cole Robinson  于2019年10月10日周四 上午6:48写道:
>>
>> Sorry for the late reply, and thanks Jano for pointing out elsewhere
>> that this didn't receive a response.
>>
>> On 8/12/19 5:56 AM, Li Feng wrote:
>>> Hi Guys,
>>>
>>> And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support
>>> for libvirt.
>>>
>>> The usage in qemu like this:
>>>
>>> Vhost-SCSI
>>> -chardev socket,id=char0,path=/var/tmp/vhost.0
>>> -device vhost-user-scsi-pci,id=scsi0,chardev=char0
>>> Vhost-BLK
>>> -chardev socket,id=char1,path=/var/tmp/vhost.1
>>> -device vhost-user-blk-pci,id=blk0,chardev=char1
>>>
>>
>> Indeed that matches what I see for the qemu commits too:
>>
>> https://git.qemu.org/?p=qemu.git;a=commit;h=00343e4b54b
>> https://git.qemu.org/?p=qemu.git;a=commit;h=f12c1ebddf7
>>
>>> What type should I add for libvirt.
>>> Type1:
>>>   
>>>   >> path='/tmp/vhost-scsi.sock'>
>>>   
>>>   
>>>
>>>
>>> Type2:
>>>
>>>   
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>   
>>>
>>>
>>>   
>>> 
>>> 
>>> 
>>

Re: [libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci

2019-10-09 Thread Cole Robinson
Sorry for the late reply, and thanks Jano for pointing out elsewhere 
that this didn't receive a response.


On 8/12/19 5:56 AM, Li Feng wrote:

Hi Guys,

And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support
for libvirt.

The usage in qemu like this:

Vhost-SCSI
-chardev socket,id=char0,path=/var/tmp/vhost.0
-device vhost-user-scsi-pci,id=scsi0,chardev=char0
Vhost-BLK
-chardev socket,id=char1,path=/var/tmp/vhost.1
-device vhost-user-blk-pci,id=blk0,chardev=char1



Indeed that matches what I see for the qemu commits too:

https://git.qemu.org/?p=qemu.git;a=commit;h=00343e4b54b
https://git.qemu.org/?p=qemu.git;a=commit;h=f12c1ebddf7


What type should I add for libvirt.
Type1:
 
 
 
 


Type2:

 
   
   
   
   
   
   
   
 


 
   
   
   
   
   
   
   
 



I think wiring this into  makes more sense.  is really an 
abstraction for assigning a (typically) physical host device to the VM, 
so it handles things like hiding a PCI device from the host, and passing 
that exact device to the VM.


In the vhost-user-scsi/blk case, the host device is just a special 
process running on the other side of a socket, and the device 
represented to the guest is a typical virtio device. So to me it makes 
more sense as a  with a  that points at that socket.


target bus=virtio vs bus=scsi is already used to distinguish between 
virtio-blk and virtio-scsi, so I think we can keep that bit as is, with 
the  to match. We just need to differentiate 
between plain virtio and vhost-user


network devices already have vhostuser support:

  


  

Internally that  is a virDomainChrSourceDefPtr which is our 
internal representation of a chardev. So I think something akin to this 
is the way to go. It will likely require updating a LOT of places in the 
code that check disk type= field, probably most places that care about 
whether type=NETWORK or type=!NETWORK will need to be mirrored for the 
new type.



  
  



  
  


- Cole

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


[libvirt] Add support for vhost-user-scsi-pci/vhost-user-blk-pci

2019-08-12 Thread Li Feng
Hi Guys,

And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support
for libvirt.

The usage in qemu like this:

Vhost-SCSI
-chardev socket,id=char0,path=/var/tmp/vhost.0
-device vhost-user-scsi-pci,id=scsi0,chardev=char0
Vhost-BLK
-chardev socket,id=char1,path=/var/tmp/vhost.1
-device vhost-user-blk-pci,id=blk0,chardev=char1

What type should I add for libvirt.
Type1:






Type2:


  
  
  
  
  
  
  




  
  
  
  
  
  
  



Could anyone give some suggestions?

Thanks,
Feng Li

-- 
The SmartX email address is only for business purpose. Any sent message 
that is not related to the business is not authorized or permitted by 
SmartX.
本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list