search for: virtqueue_map_desc

On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > OK I thought this over. While we might need these new APIs in > > > > the future, I think that at the moment, there's a way to implement > > > > this feature that is significantly simpler. Just add each s/g > > > > as a separate input buffer. > > > > > > Should

On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > OK I thought this over. While we might need these new APIs in > > > > the future, I think that at the moment, there's a way to implement > > > > this feature that is significantly simpler. Just add each s/g > > > > as a separate input buffer. > > > > > > Should

...ize). > And then do what? For the free pages, the info will be used to clear the corresponding "1" in the dirty bitmap. For balloon pages, they will be made DONTNEED and given to other host processes to use (the device won't write them, so no need to set "write" when virtqueue_map_desc() in the device). > >> I think it should be like this: >> the cmd hdr buffer: input, because the hypervisor would write it to >> send a cmd to the guest >> the payload buffer: output, for the hypervisor to read the info > These should be split. > > We have: &gt...

...urce left off without guest help. > > > > I'm afraid it would be difficult to pass the entire VirtQueueElement to the > destination. I think > that would also be the reason that stats_vq_elem chose to rewind from the > guest vq, which re-do the > virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to > the guest physical > address relationship may be changed on the destination). Yes but note how that rewind does not involve modifying the ring. It just rolls back some indices. > > How about another direction which would be easier - using two 3...

...urce left off without guest help. > > > > I'm afraid it would be difficult to pass the entire VirtQueueElement to the > destination. I think > that would also be the reason that stats_vq_elem chose to rewind from the > guest vq, which re-do the > virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to > the guest physical > address relationship may be changed on the destination). Yes but note how that rewind does not involve modifying the ring. It just rolls back some indices. > > How about another direction which would be easier - using two 3...

...; destination to continue where source left off without guest help. > I'm afraid it would be difficult to pass the entire VirtQueueElement to the destination. I think that would also be the reason that stats_vq_elem chose to rewind from the guest vq, which re-do the virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to the guest physical address relationship may be changed on the destination). How about another direction which would be easier - using two 32-bit device specific configuration registers, Host2Guest and Guest2Host command registers, to replace the ctrlq for c...

On Mon, Oct 02, 2017 at 04:38:01PM +0000, Wang, Wei W wrote: > On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > > > +static void ctrlq_send_cmd(struct virtio_balloon *vb, > > > + struct virtio_balloon_ctrlq_cmd *cmd, > > > + bool inbuf) > > > +{ > > > + struct

On Mon, Oct 02, 2017 at 04:38:01PM +0000, Wang, Wei W wrote: > On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > > > +static void ctrlq_send_cmd(struct virtio_balloon *vb, > > > + struct virtio_balloon_ctrlq_cmd *cmd, > > > + bool inbuf) > > > +{ > > > + struct

...thout guest help. >>> >> I'm afraid it would be difficult to pass the entire VirtQueueElement to the >> destination. I think >> that would also be the reason that stats_vq_elem chose to rewind from the >> guest vq, which re-do the >> virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to >> the guest physical >> address relationship may be changed on the destination). > Yes but note how that rewind does not involve modifying the ring. > It just rolls back some indices. Yes, it rolls back the indices, then the following virtio...

...t; > For the free pages, the info will be used to clear the corresponding "1" in > the dirty bitmap. > For balloon pages, they will be made DONTNEED and given to other host > processes to > use (the device won't write them, so no need to set "write" when > virtqueue_map_desc() in > the device). > > > > > > > I think it should be like this: > > > the cmd hdr buffer: input, because the hypervisor would write it to > > > send a cmd to the guest > > > the payload buffer: output, for the hypervisor to read the info >...

...t; > For the free pages, the info will be used to clear the corresponding "1" in > the dirty bitmap. > For balloon pages, they will be made DONTNEED and given to other host > processes to > use (the device won't write them, so no need to set "write" when > virtqueue_map_desc() in > the device). > > > > > > > I think it should be like this: > > > the cmd hdr buffer: input, because the hypervisor would write it to > > > send a cmd to the guest > > > the payload buffer: output, for the hypervisor to read the info >...