Re: [Qemu-devel] [PATCH] *** Vhost-pci RFC v2 ***

On 08/31/2016 08:30 PM, Marc-André
      Lureau wrote:

    

    
      
Hi

        

          

            
On Sun, Jun 19, 2016 at 10:19 AM Wei Wang
              <>

              wrote:

            

             This
              RFC proposes a design of vhost-pci, which is a new virtio
              device type.

              The vhost-pci device is used for inter-VM communication.

              

            
            

            

            
Before I send a more complete review of the spec, I
              have a few overall questions:

              

            

          

        

      

    
    Hi Marc-André, thanks for joining the reviewing process :)

    

    
      

        

          

            
 

            
- this patch is for the virtio spec? Why not patch
              the spec directly (https://tools.oasis-open.org/version-control/browse/wsvn/virtio/trunk/)
              I expect several rfc iterations, so perhaps it's easier as
              plain text file for now (as a qemu patch to doc/specs).
              btw, I would limit the audience at qemu-devel for now.

            

          

        

      

    
      

    Yes. A part of the patch is for the virtio spec. I will separate the
    patches (please see the next response). 

    I have the qemu-devel and virtio mailinglist kept here.

    

    
      

        

          

            
- I think the virtio spec should limit itself to the hw
              device description, and virtioq messages. Not the backend
              implementation (the ipc details, client/server etc).

            

          

        

      

    
    

    Agree. I will separate the device spec description from the protocol
    description. The device description will be made a virtio spec
    patch, and the protocol description will be made a qemu patch to
    doc/specs.

    

    
      

        

          

            
 - If it could be made not pci-specific, a better name
              for the device could be simply "driver": the driver of a
              virtio device. Or the "slave" in vhost-user terminology -
              consumer of virtq. I think you prefer to call it "backend"
              in general, but I find it more confusing.

            

          

        

      

    
    

    Not really. A virtio device has it own driver (e.g. a virtio-net
    driver for a virtio-net device). A vhost-pci device plays the role
    of a backend (just like vhost_net, vhost_user) for a virtio device.
    If we use the "device/driver" naming convention, the vhost-pci
    device is part of the "device". But I actually prefer to use
    "frontend/backend" :) If we check the QEMU's
    doc/specs/vhost-user.txt, it also uses "backend" to describe.

    

    
      

        

          

            
 

            
- regarding the socket protocol, why not reuse
              vhost-user? it seems to me it supports most of what you
              need and more (like interrupt, migrations, protocol
              features, start/stop queues). Some of the extensions, like
              uuid, could be beneficial to vhost-user too.

            

          

        

      

    
    

    Right. We recently changed the plan - trying to make it (the
    vhost-pci protocol) an extension of the vhost-user protocol.

    

    
      

        

          

            
 - Why is it required or beneficial to support multiple
              "frontend" devices over the same "vhost-pci" device? It
              could simplify things if it was a single device. If
              necessary, that could also be interesting as a vhost-user
              extension.

          

        

      

    
    

      

        

          
 

        

      

    

    

    We call it "multiple backend functionalities" (e.g. vhost-pci-net,
    vhost-pci-scsi..). A vhost-pci driver contains multiple such backend
    functionalities, because in this way they can reuse (share) the same
    memory mapping. To be more precise, a vhost-pci device supplies the
    memory of a frontend VM, and all the backend functionalities need to
    access the same frontend VM memory, so we consolidate them into one
    vhost-pci driver to use one vhost-pci device.

    

    
      

        

          

            
 

            
- no interrupt support, I suppose you mainly looked at
              poll-based net devices

            

          

        

      

    
    

    Yes. But I think it's also possible to add the interrupt support.
    For example, we can use ioeventfd (or hypercall) to inject
    interrupts to the fontend VM after transmitting packets.

    

    
      

        

          

            
 

            - when do you expect to share a wip/rfc implementation?

          

        

      

    
    Probably in October (next month). I think it also depends on the
    discussions here :)

    

    Best,

    Wei