qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio crypto


From: Gonglei (Arei)
Subject: Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio crypto device specification
Date: Mon, 18 Sep 2017 13:23:31 +0000

> -----Original Message-----
> From: Halil Pasic [mailto:address@hidden
> Sent: Monday, September 18, 2017 9:08 PM
> Subject: Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio
> crypto device specification
> 
> 
> 
> On 09/18/2017 02:13 PM, Gonglei (Arei) wrote:
> >> Destroy does not need to specify queue_id. That means session_id's aren't
> >> queue scoped from namespace perspective. The question remains what is
> >> queue_id good for, and whether a session type op request should be
> >> rejected if the the session id originates from a session creation
> >> request specifying a different dataqueue (not the dataqueue containing
> >> the given request)?
> >>
> > My original idea about the queue_id is using the queue_id to specify which
> > datequeue of the following data requests will be used. But after deep
> thinking,
> > I find that the queue_id is superfluous, and the current code in QEMU also
> > don't use the queue_id value as well. That's because the we can use
> session_id
> > to find the pervious session information and get the current dataqueue id
> > from the used virtqueue .
> >
> > So maybe we should drop the queue_id this time.
> >
> >
> 
> Sounds reasonable to me. We can make it reserved and ignored in
> the specification. Linux uses it, but it's always set to 0 as we only
> support one data-queue (if I'm not wrong). So reserved and must be zero
> is an option too.
> 
Makes sense to keeping compatibility. 

Thanks,
-Gonglei

reply via email to

[Prev in Thread] Current Thread [Next in Thread]