Re: [Qemu-devel] [PATCH v2 1/3] s390x/sclp: proper support of larger send and receive masks
On Fri, 23 Feb 2018 11:31:46 +0100 Cornelia Huck wrote: > On Thu, 22 Feb 2018 17:22:57 +0100 > Claudio Imbrenda wrote: > > > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length > > event masks") we only supported sclp event masks of size exactly 4 > > bytes, even though > > s/of size/of a size of/ will fix > > the archiecture allows the guests to set up sclp event masks from 1 > > to > > s/archiecture/architecture/ will fix > > 1021 bytes in length. > > After that patch, the behaviour was almost compliant, but some > > issues were still remaining, in particular regarding the handling > > of selective reads and migration. > > > > When setting the sclp event mask, a mask size is also specified. > > Until now we only considered the size in order to decide which bits > > to save in the internal state. On the other hand, when a guest > > performs a selective read, it sends a mask, but it does not specify > > a size; the implied size is the size of the last mask that has been > > set. > > > > Specifying bits in the mask of selective read that are not > > available in the internal mask should return an error, and bits > > past the end of the mask should obviously be ignored. This can only > > be achieved by keeping track of the lenght of the mask. > > > > The mask length is thus now part of the internal state that needs > > to be migrated. > > > > This patch fixes the handling of selective reads, whose size will > > now match the length of the event mask, as per architecture. > > > > While the default behaviour is to be compliant with the > > architecture, when using older machine models the old broken > > behaviour is selected (allowing only masks of size exactly 4), in > > order to be able to migrate toward older versions. > > > > Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length > > event masks") Signed-off-by: Claudio Imbrenda > > --- > > hw/s390x/event-facility.c | 91 > > +++--- > > hw/s390x/s390-virtio-ccw.c | 8 +++- 2 files changed, 85 > > insertions(+), 14 deletions(-) > > Looks reasonable. >
Re: [Qemu-devel] [PATCH v2 1/3] s390x/sclp: proper support of larger send and receive masks
On Thu, 22 Feb 2018 17:22:57 +0100 Claudio Imbrenda wrote: > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks") > we only supported sclp event masks of size exactly 4 bytes, even though s/of size/of a size of/ > the archiecture allows the guests to set up sclp event masks from 1 to s/archiecture/architecture/ > 1021 bytes in length. > After that patch, the behaviour was almost compliant, but some issues > were still remaining, in particular regarding the handling of selective > reads and migration. > > When setting the sclp event mask, a mask size is also specified. Until > now we only considered the size in order to decide which bits to save > in the internal state. On the other hand, when a guest performs a > selective read, it sends a mask, but it does not specify a size; the > implied size is the size of the last mask that has been set. > > Specifying bits in the mask of selective read that are not available in > the internal mask should return an error, and bits past the end of the > mask should obviously be ignored. This can only be achieved by keeping > track of the lenght of the mask. > > The mask length is thus now part of the internal state that needs to be > migrated. > > This patch fixes the handling of selective reads, whose size will now > match the length of the event mask, as per architecture. > > While the default behaviour is to be compliant with the architecture, > when using older machine models the old broken behaviour is selected > (allowing only masks of size exactly 4), in order to be able to migrate > toward older versions. > > Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length event > masks") > Signed-off-by: Claudio Imbrenda > --- > hw/s390x/event-facility.c | 91 > +++--- > hw/s390x/s390-virtio-ccw.c | 8 +++- > 2 files changed, 85 insertions(+), 14 deletions(-) Looks reasonable.