Re: [Qemu-devel] [RFC v1 6/9] virtio-crypto: rework virtio_crypto_handle_request

On 05/08/2017 01:38 PM, Gonglei wrote: > According to the new spec, we should use different > requst structure to store the data request based > on whether VIRTIO_CRYPTO_F_MUX_MODE feature bit is > negotiated or not. > > In this patch, we havn't supported stateless mode > yet. The device

Re: [Qemu-devel] [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

t; > CC: Ma Liang J <liang.j...@intel.com> > CC: Griffin John <john.grif...@intel.com> > CC: Mihai Claudiu Caraman <mike.cara...@nxp.com> > CC: Halil Pasic <pa...@linux.vnet.ibm.com> > --- > acknowledgements.tex |2 + > content.tex |

[Qemu-devel] [PATCH 1/1] s390x/css: catch section mismatch on load

e problem (while trying to to load the saved vm) CC: qemu-sta...@nongnu.org Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> --- Hi! I also wonder what is the best way to do this with vmstate. I know there are VMSTATE_*_EQ

Re: [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration

On 05/08/2017 08:42 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> >> >> On 05/08/2017 07:59 PM, Dr. David Alan Gilbert wrote: >>>>>> const VMStateDescription vmstate_virtio_ccw_dev = { >>>>>>

Re: [Qemu-devel] [PATCH 09/10] s390x/css: turn on channel subsystem migration

On 05/08/2017 08:37 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> >> >> On 05/08/2017 07:27 PM, Dr. David Alan Gilbert wrote: >>> * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >>>> Turn on migration fo

Re: [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration

On 05/08/2017 06:55 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Let us use the freshly introduced vmstate migration helpers instead of >> saving/loading the config manually. >> >> To achieve this we need to hack the conf

Re: [Qemu-devel] [PATCH 03/10] s390x/css: add vmstate entities for css

On 05/08/2017 06:45 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> As a preparation for switching to a vmstate based migration let us >> introduce vmstate entities (e.g. VMStateDescription) for the css entities >> to be migrated. Al

Re: [Qemu-devel] [PATCH 03/10] s390x/css: add vmstate entities for css

On 05/08/2017 06:45 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> As a preparation for switching to a vmstate based migration let us >> introduce vmstate entities (e.g. VMStateDescription) for the css entities >> to be migrated. Al

Re: [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration

On 05/08/2017 07:59 PM, Dr. David Alan Gilbert wrote: const VMStateDescription vmstate_virtio_ccw_dev = { .name = "s390_virtio_ccw_dev", .version_id = 1, @@ -67,6 +93,14 @@ const VMStateDescription vmstate_virtio_ccw_dev = {

Re: [Qemu-devel] [PATCH 09/10] s390x/css: turn on channel subsystem migration

On 05/08/2017 07:27 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Turn on migration for the channel subsystem and the new scheme for >> migrating virtio-ccw proxy devices (instead of letting the transport >> independent child devi

Re: [Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration

On 05/08/2017 07:36 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Let us use the freshly introduced vmstate migration helpers instead of >> saving/loading the config manually. >> >> To achieve this we need to hack the conf

[Qemu-devel] [PATCH 08/10] s390x/css: add ORB to SubchDev

, or async handling of subchannel work. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Guenther Hutzl <hu...@linux.vnet.ibm.com> --- hw/s390x/css.c | 35 +++ include/hw/s390x/css.h | 1 + 2 files changed, 36 insertions(+) diff --gi

[Qemu-devel] [PATCH 06/10] virtio-ccw: use vmstate way for config migration

the stream format needs to be preserved. Still no changes in behavior, but the dead code we added previously is finally awakening to life. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- --- hw/s390x/virtio-ccw.c | 116 +++--- 1 file c

[Qemu-devel] [PATCH 05/10] virtio-ccw: add vmstate entities for VirtioCcwDevice

dead code -- which should rise to life soon. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Guenther Hutzl <hu...@linux.vnet.ibm.com> --- Note: In this patch series the config_vector issue is handled by the patch "virtio-ccw: use vmstate way for config migration&

[Qemu-devel] [PATCH 09/10] s390x/css: turn on channel subsystem migration

subsystem is not migration stream compatible with the method for handling migration of legacy machines. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Guenther Hutzl <hu...@linux.vnet.ibm.com> --- hw/s390x/ccw-device.c | 1 + hw/s390x/css.c | 5 +++

[Qemu-devel] [PATCH 02/10] s390x: add css_migration_enabled to machine class

will necessarily break the migration compatibility. So let us introduce a switch (at the machine class) and put it in off state for now. We will turn the switch on for future machines once all preparations are met. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio-ccw.c

[Qemu-devel] [PATCH 01/10] s390x: add helper get_machine_class

We will need the machine class at machine initialization time, so the usual way via qdev won't do. Let's cache the machine class and also use the default values of the base machine for capability discovery. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio-ccw.

[Qemu-devel] [PATCH 03/10] s390x/css: add vmstate entities for css

added some dead code -- which should rise to life soon. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 276 + include/hw/s390x/css.h | 10 +- 2 files changed, 285 insertions(+), 1 deletion(-) diff --git a/hw

[Qemu-devel] [PATCH 10/10] s390x/css: use SubchDev.orb

Instead of passing around a pointer to ORB let us simplify some functions signatures by using the previously introduced ORB saved at the subchannel (SubchDev). Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Guenther Hutzl <hu...@linux.vnet.ibm.com> --- hw/s390

[Qemu-devel] [PATCH 00/10] migration: s390x css migration

. Since the new vmstate infrastructure is used also for handling the migration stream for legacy machines some bits are a bit convoluted: that is, if you see something convoluted there is a good chance the reason why is compatibility. Halil Pasic (10): s390x: add helper get_machine_class s390x

[Qemu-devel] [PATCH 07/10] s390x/css: remove unused subch_dev_(load|save)

Since the functions subch_dev_load and subch_dev save are not used any more let's remove them. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Guenther Hutzl <hu...@linux.vnet.ibm.com> --- hw/s390x/css.c | 143 --

[Qemu-devel] [PATCH 04/10] s390x/css: add vmstate macro for CcwDevice

As a preparation for switching to a vmstate based migration let us introduce a vmstate macro for CcwDevice. No changes in behavior, we just added some dead code -- which should rise to life soon. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Guenther Hut

Re: [Qemu-devel] [virtio-dev] RE: [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

On 05/05/2017 07:56 AM, Gonglei (Arei) wrote: >> >> >> On 05/04/2017 03:53 PM, Gonglei (Arei) wrote: >>> Sorry, I missed one comment in the previous reply. >>> > +\end{itemize*} > + What about extensibility regarding "detailed algorithms"? Is the driver required

Re: [Qemu-devel] [virtio-dev] RE: [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

On 05/05/2017 05:39 AM, Gonglei (Arei) wrote: >> >> >> On 05/04/2017 04:13 PM, Gonglei (Arei) wrote: On 05/04/2017 03:33 PM, Gonglei (Arei) wrote: >>> +\begin{description} >>> +\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires >> VIRTIO_CRYPTO_F_STATELESS_MODE.

Re: [Qemu-devel] [virtio-dev] RE: [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

On 05/04/2017 03:33 PM, Gonglei (Arei) wrote: >>> +\drivernormative{\subsubsection}{Device configuration layout}{Device Types >> / Crypto Device / Device configuration layout} >>> + >>> +\begin{itemize*} >>> +\item The driver MUST read the ready \field{status} from the bottom bit of >> status to

Re: [Qemu-devel] [virtio-dev] RE: [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

On 05/04/2017 03:53 PM, Gonglei (Arei) wrote: > Sorry, I missed one comment in the previous reply. > >> >>> +\end{itemize*} >>> + >> >> What about extensibility regarding "detailed algorithms"? Is the driver >> required ignore algorithms >> it does not "know about"? Should we reserve the not

Re: [Qemu-devel] [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

On 05/04/2017 04:13 PM, Gonglei (Arei) wrote: >> >> >> On 05/04/2017 03:33 PM, Gonglei (Arei) wrote: > +\begin{description} > +\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_STATELESS_MODE. > +\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires

Re: [Qemu-devel] [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

On 05/04/2017 03:33 PM, Gonglei (Arei) wrote: >>> +\begin{description} >>> +\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires >> VIRTIO_CRYPTO_F_STATELESS_MODE. >>> +\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires >> VIRTIO_CRYPTO_F_STATELESS_MODE. >>>

Re: [Qemu-devel] [PATCH v18 1/2] virtio-crypto: Add virtio crypto device specification

t; > CC: Ma Liang J <liang.j...@intel.com> > CC: Griffin John <john.grif...@intel.com> > CC: Mihai Claudiu Caraman <mike.cara...@nxp.com> > CC: Halil Pasic <pa...@linux.vnet.ibm.com> > --- > acknowledgements.tex |2 + > content.tex |

Re: [Qemu-devel] [virtio-dev] [PATCH v18 0/2] virtio-crypto: virtio crypto device specification

Hi Gonglei! I've started reviewing but it's going to take some time because I've missed the previous version (vacation) and v16 was a long time ago, so I have to re-check and re-learn things. My first impression is, it reads much better that v16 but still has some space for improvement. One

Re: [Qemu-devel] [PATCH 1/1] virtio: fail device if set_event_notifier fails

On 03/23/2017 06:09 PM, Michael S. Tsirkin wrote: > On Mon, Mar 06, 2017 at 05:04:41PM +0100, Cornelia Huck wrote: >> On Mon, 6 Mar 2017 16:21:13 +0100 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 03/06/2017 03:56 PM, Cornelia Huck wrote: &g

Re: [Qemu-devel] [PATCH] cryptodev: fix asserting single queue

On 03/22/2017 01:36 PM, Halil Pasic wrote: > We already check for queues == 1 in cryptodev_builtin_init and when that > is not true raise an error. But before that error is reported the > assertion in cryptodev_builtin_cleanup kicks in (because object is being > finalized and freed)

[Qemu-devel] [PATCH] cryptodev: fix asserting single queue

as it does only harm and no good. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- backends/cryptodev-builtin.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/backends/cryptodev-builtin.c b/backends/cryptodev-builtin.c index 82a068e..137c7a6 100644 --- a/backends/cry

Re: [Qemu-devel] [PATCH v2 1/1] virtio-blk: fix race on guest notifiers

On 03/10/2017 10:08 PM, Halil Pasic wrote: > > > On 03/10/2017 05:47 PM, Paolo Bonzini wrote: >> >> On 07/03/2017 14:16, Halil Pasic wrote: >>> The commits 03de2f527 "virtio-blk: do not use vring in dataplane" and >>> 9ffe337c08 "virtio

Re: [Qemu-devel] [PATCH v2 1/1] virtio-blk: fix race on guest notifiers

On 03/10/2017 05:47 PM, Paolo Bonzini wrote: > > On 07/03/2017 14:16, Halil Pasic wrote: >> The commits 03de2f527 "virtio-blk: do not use vring in dataplane" and >> 9ffe337c08 "virtio-blk: always use dataplane path if ioeventfd is active" >> chang

Re: [Qemu-devel] [PATCH v2 2/2] postcopy: Check for shared memory

On 03/09/2017 05:06 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> >> >> On 03/09/2017 02:22 PM, Dr. David Alan Gilbert (git) wrote: >>> From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> >>&g

Re: [Qemu-devel] [PATCH v2 2/2] postcopy: Check for shared memory

block in test_range_shared * I think we could move this up so that we can return directly and do not acquire resources which need cleanup Regardless of the cosmetics: Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com> > /* > * userfault and mlock don't go together; we'll put it back later if > * it was enabled. >

Re: [Qemu-devel] [PATCH v2 1/2] RAMBlocks: qemu_ram_is_shared

On 03/09/2017 02:22 PM, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > Provide a helper to say whether a RAMBlock was created as a > shared mapping. > > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redh

Re: [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

On 03/09/2017 03:55 AM, QingFeng Hao wrote: > > > 在 2017/3/8 19:33, Halil Pasic 写道: >> >> On 03/08/2017 08:05 AM, QingFeng Hao wrote: >>> >>> 在 2017/3/7 18:19, Halil Pasic 写道: >>>> On 03/07/2017 11:05 AM, Kevin Wolf wrote: >>>>>

Re: [Qemu-devel] [PATCH 1/2] RAMBlocks: qemu_ram_is_shared

On 03/07/2017 07:36 PM, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > Provide a helper to say whether a RAMBlock was created as a > shared mapping. > > Signed-off-by: Dr. David Alan Gilbert > --- > exec.c

Re: [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

On 03/08/2017 08:05 AM, QingFeng Hao wrote: > > > 在 2017/3/7 18:19, Halil Pasic 写道: >> >> On 03/07/2017 11:05 AM, Kevin Wolf wrote: >>> Am 07.03.2017 um 10:54 hat Halil Pasic geschrieben: >>>> >>>> On 03/07/2017 10:29 AM, Kevin Wol

[Qemu-devel] [PATCH v2 1/1] virtio-blk: fix race on guest notifiers

d the guest notifier is torn down after notify_guest_bh was scheduled but before it actually runs. Let's fix this by forcing guest notifications before cleaning up the irqfd's. Let's also add some explanatory comments. Cc: qemu-sta...@nongnu.org Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.co

Re: [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

On 03/07/2017 11:05 AM, Kevin Wolf wrote: > Am 07.03.2017 um 10:54 hat Halil Pasic geschrieben: >> >> >> On 03/07/2017 10:29 AM, Kevin Wolf wrote: >>> Am 07.03.2017 um 03:53 hat QingFeng Hao geschrieben: >>>> I am not very clear about th

Re: [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

On 03/07/2017 11:03 AM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> >> >> On 03/07/2017 10:29 AM, Kevin Wolf wrote: >>> Am 07.03.2017 um 03:53 hat QingFeng Hao geschrieben: >>>> I am not very clear about th

Re: [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

On 03/07/2017 10:29 AM, Kevin Wolf wrote: > Am 07.03.2017 um 03:53 hat QingFeng Hao geschrieben: >> I am not very clear about the logic in vmstate.c, but from its context in >> vmstate_save_state, it seems size should not be 0, otherwise the followed >> for loop will keep working on the same

Re: [Qemu-devel] [PATCH 1/1] virtio-blk: fix race on guest notifiers

On 03/06/2017 03:55 PM, Paolo Bonzini wrote: > > On 03/03/2017 20:43, Halil Pasic wrote: >> Uh, this is complicated. I'm not out of questions, but I fear taking to >> much of your precious time. I will ask again nevertheless, but please >> just cut the conversatio

Re: [Qemu-devel] [PATCH 1/1] virtio: fail device if set_event_notifier fails

On 03/06/2017 03:56 PM, Cornelia Huck wrote: > On Fri, 3 Mar 2017 14:08:37 +0100 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 03/03/2017 01:50 PM, Cornelia Huck wrote: >>> On Fri, 3 Mar 2017 13:43:32 +0100 >>> Halil Pasic <pa...@linux.vnet.ib

Re: [Qemu-devel] [PATCH 1/1] virtio-blk: fix race on guest notifiers

On 03/02/2017 05:21 PM, Paolo Bonzini wrote: > > > On 02/03/2017 16:55, Halil Pasic wrote: >>>>> blk_set_aio_context(s->conf->conf.blk, qemu_get_aio_context()); >> I'm wondering if synchronization is needed for batch_notify_vqs. I think >

Re: [Qemu-devel] [PATCH 1/1] virtio: fail device if set_event_notifier fails

On 03/03/2017 01:50 PM, Cornelia Huck wrote: > On Fri, 3 Mar 2017 13:43:32 +0100 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 03/03/2017 01:21 PM, Cornelia Huck wrote: >>> On Thu, 2 Mar 2017 19:59:42 +0100 >>> Halil Pasic <pa...@linux.

Re: [Qemu-devel] [PATCH 1/1] virtio: fail device if set_event_notifier fails

On 03/03/2017 01:21 PM, Cornelia Huck wrote: > On Thu, 2 Mar 2017 19:59:42 +0100 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> The function virtio_notify_irqfd used to ignore the return code of >> event_notifier_set. Let's fail the device should thi

[Qemu-devel] [PATCH 1/1] virtio: fail device if set_event_notifier fails

The function virtio_notify_irqfd used to ignore the return code of event_notifier_set. Let's fail the device should this occur. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- This patch is most likely flawed because virtio_notify_irqfd is probably supposed to be threa

[Qemu-devel] [PATCH 1/1] event_notifier: prevent accidental use after close

reused, and corrupt the file addressed by the fd. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- No strong feelings about this, but obviously, I do think it's worth a try. The one who brought this unfortunate possibility to my attention was Michael Tsirkin. --- util/event_no

Re: [Qemu-devel] [PATCH 1/1] virtio-blk: fix race on guest notifiers

On 03/02/2017 04:32 PM, Paolo Bonzini wrote: > > > On 02/03/2017 15:49, Cornelia Huck wrote: >> On Thu, 2 Mar 2017 14:04:22 +0100 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> diff --git a/hw/block/dataplane/virtio-blk.c >>>

Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify

On 03/01/2017 08:53 PM, Paolo Bonzini wrote: > > > On 01/03/2017 17:08, Halil Pasic wrote: >> applied I do not see the problem any more. I will most likely >> turn this into a patch tomorrow. I would like to give it some more testing >> and >> thinking (se

[Qemu-devel] [PATCH 1/1] virtio-blk: fix race on guest notifiers

d the guest notifier is torn down after notify_guest_bh was scheduled but before it actually runs. Let's fix this by forcing guest notifications before cleaning up the irqfd's. Let's also add some explanatory comments. Cc: qemu-sta...@nongnu.org Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.co

Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify

On 03/01/2017 03:29 PM, Paolo Bonzini wrote: > > > On 01/03/2017 14:22, Halil Pasic wrote: >> Here a trace: >> >> 135871@1488304024.512533:virtio_blk_req_complete req 0x2aa6b117e10 status 0 >> 135871@1488304024.512541:virtio_notify_irqfd vdev 0x2aa6b0e19

Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify

On 03/01/2017 01:54 PM, Michael S. Tsirkin wrote: > On Wed, Mar 01, 2017 at 12:50:04PM +0100, Halil Pasic wrote: >> The commits 03de2f527 "virtio-blk: do not use vring in dataplane" and >> 9ffe337c08 "virtio-blk: always use dataplane path if ioeventfd is active

Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify

On 03/01/2017 01:57 PM, Paolo Bonzini wrote: > > > On 01/03/2017 12:50, Halil Pasic wrote: >> The commits 03de2f527 "virtio-blk: do not use vring in dataplane" and >> 9ffe337c08 "virtio-blk: always use dataplane path if ioeventfd is active" >> ch

[Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify

n-irqfd notification mechanism if event_notifier_set fails. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- This is probably not the only way to fix this: suggestions welcome. I did not use a fixes tag because I'm not sure yet where exactly things got broken. Maybe guys more familiar wi

Re: [Qemu-devel] [PATCH v2 3/5] migration/vmstate: fix array of ptr with nullptrs

On 02/24/2017 01:29 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Make VMS_ARRAY_OF_POINTER cope with null pointers. Previously the >> reward for trying to migrate an array with some null pointers in it was >> an illegal memory ac

[Qemu-devel] [PATCH v2 3/5] migration/vmstate: fix array of ptr with nullptrs

encounter a null pointer (element), instead of following the pointer to save/load the data behind it, we save/load a placeholder. This way we can detect if we expected a null pointer at the load side but not null data was saved instead. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Re

[Qemu-devel] [PATCH v2 5/5] tests/test-vmstate.c: test array of ptr to primitive

Let's have a test for ptr arrays to some primitive type with some not-null and null ptrs intermixed. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> --- Mainly for the sake of completeness and also to demonstrate t

[Qemu-devel] [PATCH v2 1/5] migration/vmstate: renames in (load|save)_state

things easier to understand by renaming base_addr to first_elem and addr to curr_elem. This has the additional benefit of harmonizing with other names within the scope (n_elems, vmstate_n_elems). Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert

[Qemu-devel] [PATCH v2 2/5] migration/vmstate: split up vmstate_base_addr

. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> --- migration/vmstate.c | 39 +-- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/migration/vmstate.c b/migration/vmstate.c i

[Qemu-devel] [PATCH v2 4/5] tests/test-vmstate.c: test array of ptr with null

Add test for VMSTATE_ARRAY_OF_POINTER_TO_STRUCT with an array containing some null pointer. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> --- tests/test-vmstate.c | 74

[Qemu-devel] [PATCH v2 0/5] vmstate: handle arrays with null ptrs

b's RFC v2 -> v1: * rebase * changed marker as suggested by Dave (incl. simplifications) * fixed issues pointed out by Dave * reworded some commit messages * added a test for array of ptr to primitive Halil Pasic (5): migration/vmstate: renames in (load|save)_state migration/vmstate: sp

Re: [Qemu-devel] [PATCH 2/5] migration/vmstate: split up vmstate_base_addr

On 02/21/2017 01:07 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Currently vmstate_base_addr does several things: it pinpoints the field >> within the struct, possibly allocates memory and possibly does the first >> pointer d

Re: [Qemu-devel] [PATCH 3/5] migration/vmstate: fix array of ptr with nullptrs

On 02/21/2017 01:55 PM, Halil Pasic wrote: >> It's OK to add an error_report as needed; in particular I try and avoid >> assert's on the save path where possible, since the user apparently >> has a happy running VM, so even if the migration code has an error in it >> I'

Re: [Qemu-devel] [PATCH 3/5] migration/vmstate: fix array of ptr with nullptrs

On 02/21/2017 01:22 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> >> >> On 02/17/2017 08:42 PM, Dr. David Alan Gilbert wrote: >>> * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >>>> Make VMS_ARRAY_OF_P

Re: [Qemu-devel] [PATCH 4/5] tests/test-vmstate.c: test array of ptr with null

On 02/21/2017 11:49 AM, Dr. David Alan Gilbert wrote: >> +static void test_arr_ptr_str_0_save(void) >> +{ >> +TestStructTriv ar[AR_SIZE] = {{.i = 0}, {.i = 1}, {.i = 2}, {.i = 3} }; >> +TestArrayOfPtrToStuct sample = {.ar = {[0], NULL, [2], [3]} }; >> +uint8_t wire_sample[] = { >> +

Re: [Qemu-devel] [PATCH 3/5] migration/vmstate: fix array of ptr with nullptrs

On 02/17/2017 08:42 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Make VMS_ARRAY_OF_POINTER cope with null pointers. Previously the >> reward for trying to migrate an array with some null pointers in it was >> an illegal memory ac

[Qemu-devel] [PATCH 5/5] tests/test-vmstate.c: test array of ptr to primitive

Let's have a test for ptr arrays to some primitive type with some not-null and null ptrs intermixed. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- Mainly for the sake of completeness and also to demonstrate that it works since in the previous version I wrongly stated i

[Qemu-devel] [PATCH 4/5] tests/test-vmstate.c: test array of ptr with null

Add test for VMSTATE_ARRAY_OF_POINTER_TO_STRUCT with an array containing some null pointer. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> --- tests/test-vmstate.c | 51 +++

[Qemu-devel] [PATCH 3/5] migration/vmstate: fix array of ptr with nullptrs

encounter a null pointer (element), instead of following the pointer to save/load the data behind it, we save/load a placeholder. This way we can detect if we expected a null pointer at the load side but not null data was saved instead. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Re

[Qemu-devel] [PATCH 2/5] migration/vmstate: split up vmstate_base_addr

-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- migration/vmstate.c | 39 +-- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/migration/vmstate.c b/migration/vmstate.c index 36efa80..836a7a4 100644 --- a/migration/vmstate.c +++ b/migration/vms

[Qemu-devel] [PATCH 1/5] migration/vmstate: renames in (load|save)_state

things easier to understand by renaming base_addr to first_elem and addr to curr_elem. This has the additional benefit of harmonizing with other names within the scope (n_elems, vmstate_n_elems). Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert

[Qemu-devel] [PATCH 0/5] vmstate: handle arrays with null ptrs

v1: * rebase * changed marker as suggested by Dave (incl. simplifications) * fixed issues pointed out by Dave * reworded some commit messages * added a test for array of ptr to primitive Halil Pasic (5): migration/vmstate: renames in (load|save)_state migration/vmstate: split up vmstate_base_add

Re: [Qemu-devel] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 02/13/2017 02:41 PM, Stefan Hajnoczi wrote: > On Fri, Feb 03, 2017 at 07:07:02PM +0100, Halil Pasic wrote: >> >> >> On 02/03/2017 04:37 PM, Michael S. Tsirkin wrote: >>> On Fri, Feb 03, 2017 at 10:33:16AM +, Stefan Hajnoczi wrote: >>>>>

Re: [Qemu-devel] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 02/07/2017 01:59 AM, Gonglei (Arei) wrote: > Hi, > >> From: Michael S. Tsirkin [mailto:m...@redhat.com] >> Sent: Tuesday, February 07, 2017 2:20 AM >> Subject: Re: [Qemu-devel] [PATCH v16 1/2] virtio-crypto: Add virtio crypto >> device specification >> >> On Mon, Feb 06, 2017 at 03:46:25PM

Re: [Qemu-devel] [virtio-dev] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 02/08/2017 04:46 AM, Gonglei (Arei) wrote: > Hi Cornelia, > >> >> On Tue, 7 Feb 2017 12:39:44 +0100 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 01/18/2017 09:22 AM, Gonglei wrote: >> >>>> +\section{Crypto Device}\

Re: [Qemu-devel] [virtio-dev] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 02/08/2017 07:24 AM, Gonglei (Arei) wrote: > Hi Halil, > > Thanks for your comments firstly. > You are welcome :). Sorry it took so long -- I'm currently quite busy. >> >> On 01/18/2017 09:22 AM, Gonglei wrote: >>> The virtio crypto device is a virtual crypto device (ie. hardware >>>

Re: [Qemu-devel] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 02/06/2017 07:19 PM, Michael S. Tsirkin wrote: > On Mon, Feb 06, 2017 at 03:46:25PM +, Stefan Hajnoczi wrote: >> On Mon, Feb 06, 2017 at 01:48:09AM +, Gonglei (Arei) wrote: > +\item The device MUST set \field{max_size} to show the maximum size of crypto request the device

Re: [Qemu-devel] [virtio-dev] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 01/18/2017 09:22 AM, Gonglei wrote: > The virtio crypto device is a virtual crypto device (ie. hardware > crypto accelerator card). Currently, the virtio crypto device provides > the following crypto services: CIPHER, MAC, HASH, and AEAD. > > In this patch, CIPHER, MAC, HASH, AEAD services

Re: [Qemu-devel] [PATCH v16 1/2] virtio-crypto: Add virtio crypto device specification

On 02/03/2017 04:37 PM, Michael S. Tsirkin wrote: > On Fri, Feb 03, 2017 at 10:33:16AM +, Stefan Hajnoczi wrote: >>> +\begin{description} >>> +\item[0] dataq1 >>> +\item[\ldots] >>> +\item[N-1] dataqN >>> +\item[N] controlq >>> +\end{description} >>> + >>> +N is set by

[Qemu-devel] [PATCH] migration: consolidate VMStateField.start

actually partial migration for VBUFFER is not used at all. Let's consolidate the usage of VMStateField.start by removing support for partial migration for VBUFFER. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- I had a very similar patch named "migration: drop unused VMState

Re: [Qemu-devel] [PATCH v2 2/2] migration: drop unused VMStateField.start

On 01/31/2017 09:00 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> >> >> On 10/20/2016 03:25 PM, Halil Pasic wrote: >>> diff --git a/migration/vmstate.c b/migration/vmstate.c >>> index fc29acf..8767e40 100644

Re: [Qemu-devel] [RFC PATCH v2 7/8] migration/vmstate: fix array of pointers to struct

On 12/15/2016 01:33 PM, Dr. David Alan Gilbert wrote: > * Halil Pasic (pa...@linux.vnet.ibm.com) wrote: >> Make VMS_ARRAY_OF_POINTER cope with null pointers. Previously the reward >> for trying to migrate an array with some null pointers in it was an >> illegal memory ac

Re: [Qemu-devel] [PATCH v2 2/2] migration: drop unused VMStateField.start

On 10/20/2016 03:25 PM, Halil Pasic wrote: > diff --git a/migration/vmstate.c b/migration/vmstate.c > index fc29acf..8767e40 100644 > --- a/migration/vmstate.c > +++ b/migration/vmstate.c > @@ -66,10 +66,10 @@ static void *vmstate_base_addr(void *opaque, VMStateField >

Re: [Qemu-devel] [virtio-dev] RE: [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification

On 01/17/2017 03:49 AM, Gonglei (Arei) wrote: > Hi Halil, > >> >> On 01/16/2017 01:43 PM, Gonglei (Arei) wrote: >>> Hi Michael and others, >>> >>> I'd like to redefine struct virtio_crypto_op_data_req is as below: >>> >>> struct virtio_crypto_op_data_req { >>> struct virtio_crypto_op_header

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification

> Thanks, > -Gonglei > > >> -Original Message- >> From: Gonglei (Arei) >> Sent: Saturday, January 14, 2017 9:21 AM >> To: 'Michael S. Tsirkin' >> Cc: Halil Pasic; qemu-devel@nongnu.org; virtio-...@lists.oasis-open.org; >> Huang

Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification

On 01/04/2017 11:10 AM, Gonglei (Arei) wrote: > Hi all, > > I attach the diff files between v14 and v15 for better review. > Hi, only had a quick look. Will try to come back to this later. > diff --git a/virtio-crypto.tex b/virtio-crypto.tex > index 9f7faf0..884ee95 100644 > ---

Re: [Qemu-devel] [PATCH] error: error_setg_errno(): errno gets preserved

On 01/09/2017 03:50 PM, Eric Blake wrote: > On 07/29/2016 08:38 AM, Halil Pasic wrote: >> >> >> On 07/28/2016 11:03 PM, Eric Blake wrote: >>> On 07/28/2016 09:29 AM, Halil Pasic wrote: >>> >>>>> You mean va_start, not start_va. And actual

[Qemu-devel] [PATCH v2 1/1] virtio: fix vq->inuse recalc after migr

C99 guarantees max ring size < UINT_MAX but does not guarantee max ring size < INT_MAX. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Fixes: bccdef6b ("virtio: recalculate vq->inuse after migration") CC: qemu-sta...@nongnu.org --- v1 -> v2: * Reworded comment expl

Re: [Qemu-devel] [PATCH] virtio: fix vring->inuse recalc after migr

On 12/16/2016 05:12 PM, Stefan Hajnoczi wrote: >> You are not the first one complaining, so the sentence is definitively >> bad. What disturbs me regarding your formulation is that we do not use >> uint16_t to represent neither the ring size nor inuse. >> >> How about "Since max ring size <

Re: [Qemu-devel] [RFC PATCH v2 6/8] migration/vmstate: split up vmstate_base_addr

On 12/15/2016 02:29 PM, Dr. David Alan Gilbert wrote: >> +vmstate_handle_alloc(first_elem, field, opaque); >> +if (field->flags & VMS_POINTER) { >> +first_elem = *(void **)first_elem; >> +assert(first_elem); >> +} >>

Re: [Qemu-devel] [PATCH] virtio: fix vring->inuse recalc after migr

On 12/16/2016 11:25 AM, Stefan Hajnoczi wrote: > On Thu, Dec 15, 2016 at 04:43:30PM +0100, Halil Pasic wrote: >> Correct recalculation of vring->inuse after migration for >> the corner case where the avail_idx has already wrapped >> but used_idx not yet. >> >

Re: [Qemu-devel] commit virtio: recalculate vq->inuse after migration might cause last_avail_idx vs. used_idx failure

On 12/15/2016 02:37 PM, Paolo Bonzini wrote: > > > On 15/12/2016 12:32, Halil Pasic wrote: >> static inline uint16_t vring_avail_idx(VirtQueue *vq) >> { >> hwaddr pa; >> pa = vq->vring.avail + offsetof(VRingAvail, idx); >> vq->sha

[Qemu-devel] [PATCH] virtio: fix vring->inuse recalc after migr

Correct recalculation of vring->inuse after migration for the corner case where the avail_idx has already wrapped but used_idx not yet. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Fixes: bccdef6b ("virtio: recalculate vq->inuse after migration") CC: qemu-sta...@n

Re: [Qemu-devel] commit virtio: recalculate vq->inuse after migration might cause last_avail_idx vs. used_idx failure

On 12/15/2016 11:52 AM, Dr. David Alan Gilbert wrote: >> We got a bugreport with this log for a live migration target. >> >> 2016-12-13T18:59:03.647309Z qemu-system-s390x: VQ 1 size 0x100 < >> last_avail_idx 0x2f76 - used_idx 0x762f > Is this actually an endian problem - 2f76 vs 762f ? > >

[Qemu-devel] commit virtio: recalculate vq->inuse after migration might cause last_avail_idx vs. used_idx failure

We have a migration problem, which is in my opinion caused by a deficiency in how vq->inuse is calculated after the migration (commit bccdef6b "virtio: recalculate vq->inuse after migration" to blame). We got a bugreport with this log for a live migration target. 2016-12-13T18:59:03.647309Z

<    4   5   6   7   8   9   10   11   >