search for: host2guest

...ical > 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 32-bit device > specific configuration registers, > Host2Guest and Guest2Host command registers, to replace the ctrlq for > command exchange: > > The flow can be as follows: > > 1) Before Host sending a StartCMD, it flushes the free_page_vq in case any > old free page hint is left there; > 2) Host writes StartCMD to the Host2Guest regis...

...ical > 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 32-bit device > specific configuration registers, > Host2Guest and Guest2Host command registers, to replace the ctrlq for > command exchange: > > The flow can be as follows: > > 1) Before Host sending a StartCMD, it flushes the free_page_vq in case any > old free page hint is left there; > 2) Host writes StartCMD to the Host2Guest regis...

...out was sent to the host, so that when the host rewind one previous entry, it can always get the free_page_cmd_in buffer (may be not a very nice method). > >> 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 >> command exchange: >> >> The flow can be as follows: >> >> 1) Before Host sending a StartCMD, it flushes the free_page_vq in case any >> old free page hint is left there; >> 2) Host writes StartCM...

...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 command exchange: The flow can be as follows: 1) Before Host sending a StartCMD, it flushes the free_page_vq in case any old free page hint is left there; 2) Host writes StartCMD to the Host2Guest register, and notifies the guest; 3)...

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

...g the ID to the command path? This would avoid the above > trouble. > > For example, using the 32-bit config registers: > first 16-bit: Command field > send 16-bit: ID field > > Then, the working flow would look like this: > > 1) Host writes "Start, 1" to the Host2Guest register and notify; > > 2) Guest reads Host2Guest register, and ACKs by writing "Start, 1" to > Guest2Host register; > > 3) Guest starts report free pages; > > 4) Each time when the host receives a free page hint from the free_page_vq, > it compares the ID fiel...

...g the ID to the command path? This would avoid the above > trouble. > > For example, using the 32-bit config registers: > first 16-bit: Command field > send 16-bit: ID field > > Then, the working flow would look like this: > > 1) Host writes "Start, 1" to the Host2Guest register and notify; > > 2) Guest reads Host2Guest register, and ACKs by writing "Start, 1" to > Guest2Host register; > > 3) Guest starts report free pages; > > 4) Each time when the host receives a free page hint from the free_page_vq, > it compares the ID fiel...

...In this case, if the dst_cid is wrong, maybe the only issue is that the getsockname() returns an inconsistent address (the cid returned is the one received from the guest) - from v5.4 we support multi-transport, so the L1 VM (e.g. L0 assigned cid 5 to this VM) can have both Guest2Host and Host2Guest transports. In this case, we have these possible issues: - L2 (or L1) guest can use cid 0, 1, and 2 to reach L1 (or L0), instead we should allow only CID_HOST (2) to reach the level below. Note: this happens also with not malformed guest that runs Linux v5.4 - if a malformed L2 guest...

...In this case, if the dst_cid is wrong, maybe the only issue is that the getsockname() returns an inconsistent address (the cid returned is the one received from the guest) - from v5.4 we support multi-transport, so the L1 VM (e.g. L0 assigned cid 5 to this VM) can have both Guest2Host and Host2Guest transports. In this case, we have these possible issues: - L2 (or L1) guest can use cid 0, 1, and 2 to reach L1 (or L0), instead we should allow only CID_HOST (2) to reach the level below. Note: this happens also with not malformed guest that runs Linux v5.4 - if a malformed L2 guest...

...e only issue is that the getsockname() > > returns an inconsistent address (the cid returned is the one received > > from the guest) > > > > - from v5.4 we support multi-transport, so the L1 VM (e.g. L0 assigned > > cid 5 to this VM) can have both Guest2Host and Host2Guest transports. > > In this case, we have these possible issues: > > - L2 (or L1) guest can use cid 0, 1, and 2 to reach L1 (or L0), > > instead we should allow only CID_HOST (2) to reach the level below. > > Note: this happens also with not malformed guest that runs...

On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote: >> - guest2host_cmd: written by the guest to ACK to the host about the >> commands that have been received. The host will clear the corresponding >> bits on the host2guest_cmd register. The guest also uses this register >> to send commands to the host (e.g. when finish free page reporting). > I am not sure what is the role of guest2host_cmd. Reporting of > the correct cmd id seems sufficient indication that guest > received the start command. Not getti...

On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote: >> - guest2host_cmd: written by the guest to ACK to the host about the >> commands that have been received. The host will clear the corresponding >> bits on the host2guest_cmd register. The guest also uses this register >> to send commands to the host (e.g. when finish free page reporting). > I am not sure what is the role of guest2host_cmd. Reporting of > the correct cmd id seems sufficient indication that guest > received the start command. Not getti...

...st_cid is wrong, maybe the only issue is that the getsockname() > returns an inconsistent address (the cid returned is the one received > from the guest) > > - from v5.4 we support multi-transport, so the L1 VM (e.g. L0 assigned > cid 5 to this VM) can have both Guest2Host and Host2Guest transports. > In this case, we have these possible issues: > - L2 (or L1) guest can use cid 0, 1, and 2 to reach L1 (or L0), > instead we should allow only CID_HOST (2) to reach the level below. > Note: this happens also with not malformed guest that runs Linux v5.4 > -...

...v 14, 2017 at 08:02:03PM +0800, Wei Wang wrote: > On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote: > > > - guest2host_cmd: written by the guest to ACK to the host about the > > > commands that have been received. The host will clear the corresponding > > > bits on the host2guest_cmd register. The guest also uses this register > > > to send commands to the host (e.g. when finish free page reporting). > > I am not sure what is the role of guest2host_cmd. Reporting of > > the correct cmd id seems sufficient indication that guest > > received the sta...

...at 08:02:03PM +0800, Wei Wang wrote: >> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote: >>>> - guest2host_cmd: written by the guest to ACK to the host about the >>>> commands that have been received. The host will clear the corresponding >>>> bits on the host2guest_cmd register. The guest also uses this register >>>> to send commands to the host (e.g. when finish free page reporting). >>> I am not sure what is the role of guest2host_cmd. Reporting of >>> the correct cmd id seems sufficient indication that guest >>> recei...

...at 08:02:03PM +0800, Wei Wang wrote: >> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote: >>>> - guest2host_cmd: written by the guest to ACK to the host about the >>>> commands that have been received. The host will clear the corresponding >>>> bits on the host2guest_cmd register. The guest also uses this register >>>> to send commands to the host (e.g. when finish free page reporting). >>> I am not sure what is the role of guest2host_cmd. Reporting of >>> the correct cmd id seems sufficient indication that guest >>> recei...

When we receive a new packet from the guest, we check if the src_cid is correct, but we forgot to check the dst_cid. The host should accept only packets where dst_cid is equal to the host CID. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vhost/vsock.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/vhost/vsock.c

When we receive a new packet from the guest, we check if the src_cid is correct, but we forgot to check the dst_cid. The host should accept only packets where dst_cid is equal to the host CID. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vhost/vsock.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/vhost/vsock.c

...wrote: > > > On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote: > > > > > - guest2host_cmd: written by the guest to ACK to the host about the > > > > > commands that have been received. The host will clear the corresponding > > > > > bits on the host2guest_cmd register. The guest also uses this register > > > > > to send commands to the host (e.g. when finish free page reporting). > > > > I am not sure what is the role of guest2host_cmd. Reporting of > > > > the correct cmd id seems sufficient indication that gu...