Re: [Qemu-devel] [PATCH v3 0/3] Travis updates

[Michael Tokarev]

31.01.2016 11:43, Alex Bennée wrote:
> Michael Tokarev  writes:
>> 28.01.2016 17:23, Alex Bennée wrote:
>>> Hi,
>>>
>>> The first patch has been reviewed and signed off. Long term I think
>>> it is worth applying but it look like the performance increase it
>>> negligible compared to the old style VM builds at the moment. I
>>> suspect this may be because the new infrastructure is under more load
>>> as more projects have migrated.
>>
>> I'm applying all this to -trivial, but without trying to understand
>> what it is all about, as I don't know travis.
> 
> Maybe we should hold off for now until the later ones have been reviewed
> (David has some comments on 2/3). I guess it was really a question of if
> trivial is the right tree for these patches to go upstream.

Ok, I removed the series from the -trivial patch queue for now.

Thanks,

/mjt

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Gerd Hoffmann]

  Hi,

> And for UUID, I remember Alex had a concern on using it in kernel. 
> Honestly speaking I don't have a good idea here. In Xen side there is a VM ID
> which can be easily used as the index. But for KVM, what would be the best
> identifier to associate with a VM?

The vgpu code doesn't need to associate the vgpu device with a vm in the
first place.  You get all guest address space information from qemu, via
vfio iommu interface.

When qemu does't use kvm (tcg mode), things should still work fine.
Using vfio-based vgpu devices with non-qemu apps (some kind of test
suite for example) should work fine too.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v2] ES1370: QOMify

[Michael Tokarev]

Sorry I replied to the wrong email.  I actually applied this one :)

/mjt

Re: [Qemu-devel] [PATCH v2] ES1370: QOMify

[Cao jin]

Thanks mjt:)

On 02/02/2016 04:00 PM, Michael Tokarev wrote:

Sorry I replied to the wrong email.  I actually applied this one :)

/mjt





--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [PATCH 0/2] CCID QOMify

[Cao jin]

Hi mjt,

I guess these two are suitable for trivial too;) but I forget to cc 
trivial at first...


On 02/01/2016 02:53 PM, Cao jin wrote:

As each commit says

Cao jin (2):
   Emulated CCID card: QOMify
   Passthru CCID card: QOMify

  hw/usb/ccid-card-emulated.c | 20 +---
  hw/usb/ccid-card-passthru.c | 10 --
  hw/usb/ccid.h   |  8 
  3 files changed, 21 insertions(+), 17 deletions(-)



--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Neo Jia]

On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > And for UUID, I remember Alex had a concern on using it in kernel. 
> > Honestly speaking I don't have a good idea here. In Xen side there is a VM 
> > ID
> > which can be easily used as the index. But for KVM, what would be the best
> > identifier to associate with a VM?
> 
> The vgpu code doesn't need to associate the vgpu device with a vm in the
> first place.  You get all guest address space information from qemu, via
> vfio iommu interface.
> 
> When qemu does't use kvm (tcg mode), things should still work fine.
> Using vfio-based vgpu devices with non-qemu apps (some kind of test
> suite for example) should work fine too.

Hi Gerd and Kevin,

I thought Alex had agreed with the UUID as long as it is not tied with VM,
probably it is just his comment gets lost in our previous long email thread.

Thanks,
Neo

> 
> cheers,
>   Gerd
> 

Re: [Qemu-devel] [PATCH 1/2] Emulated CCID card: QOMify

[Michael Tokarev]

01.02.2016 09:53, Cao jin wrote:
> Signed-off-by: Cao jin 
> ---
>  hw/usb/ccid-card-emulated.c | 20 +---
>  hw/usb/ccid.h   |  4 
>  2 files changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/usb/ccid-card-emulated.c b/hw/usb/ccid-card-emulated.c
> index 869a63c..0b05260 100644
> --- a/hw/usb/ccid-card-emulated.c
> +++ b/hw/usb/ccid-card-emulated.c
> @@ -42,8 +42,6 @@ do {\
>  } \
>  } while (0)
>  
> -#define EMULATED_DEV_NAME "ccid-card-emulated"


> --- a/hw/usb/ccid.h
> +++ b/hw/usb/ccid.h
> +#define TYPE_EMULATED_CCID "ccid-card-emulated"
> +#define EMULATED_CCID_CARD(obj) \
> + OBJECT_CHECK(EmulatedState, (obj), TYPE_EMULATED_CCID)

Why did you move the type definition from .c to .h file?
It is only referenced in .c, no?

Ditto for the second patch in this series.

Thanks,

/mjt

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Tian, Kevin]

> From: Neo Jia [mailto:c...@nvidia.com]
> Sent: Tuesday, February 02, 2016 4:13 PM
> 
> On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote:
> >   Hi,
> >
> > > And for UUID, I remember Alex had a concern on using it in kernel.
> > > Honestly speaking I don't have a good idea here. In Xen side there is a 
> > > VM ID
> > > which can be easily used as the index. But for KVM, what would be the best
> > > identifier to associate with a VM?
> >
> > The vgpu code doesn't need to associate the vgpu device with a vm in the
> > first place.  You get all guest address space information from qemu, via
> > vfio iommu interface.
> >
> > When qemu does't use kvm (tcg mode), things should still work fine.
> > Using vfio-based vgpu devices with non-qemu apps (some kind of test
> > suite for example) should work fine too.
> 
> Hi Gerd and Kevin,
> 
> I thought Alex had agreed with the UUID as long as it is not tied with VM,
> probably it is just his comment gets lost in our previous long email thread.
> 

I think the point is... what is the value to introduce a UUID here? If
what Gerd describes is enough, we can simply invent a vgpu ID which
is returned at vgpu_create, and then used as the index for other
interfaces.

But I still need to think about whether there's value to have a VM
identifier within vgpu core driver, especially regarding to how this
vgpu core driver connects to KVM hypervisor or other hypervisor.
I saw another long thread about that part. Jike has started his 
vacation now. I'll follow up with it tomorrow.

Thanks
Kevin

Re: [Qemu-devel] [PATCH 1/2] Emulated CCID card: QOMify

[Cao jin]

On 02/02/2016 04:15 PM, Michael Tokarev wrote:

01.02.2016 09:53, Cao jin wrote:

Signed-off-by: Cao jin 
---
  hw/usb/ccid-card-emulated.c | 20 +---
  hw/usb/ccid.h   |  4 
  2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/hw/usb/ccid-card-emulated.c b/hw/usb/ccid-card-emulated.c
index 869a63c..0b05260 100644
--- a/hw/usb/ccid-card-emulated.c
+++ b/hw/usb/ccid-card-emulated.c
@@ -42,8 +42,6 @@ do {\
  } \
  } while (0)

-#define EMULATED_DEV_NAME "ccid-card-emulated"




--- a/hw/usb/ccid.h
+++ b/hw/usb/ccid.h
+#define TYPE_EMULATED_CCID "ccid-card-emulated"
+#define EMULATED_CCID_CARD(obj) \
+ OBJECT_CHECK(EmulatedState, (obj), TYPE_EMULATED_CCID)


Why did you move the type definition from .c to .h file?
It is only referenced in .c, no?

Ditto for the second patch in this series.

Thanks,

/mjt



Yes, that type definition is referred only in .c for now, but we are not 
sure about it in the future, for better flexibility, I think put it into 
.h is better. http://wiki.qemu.org/QOMConventions also says:


DO use TYPE_FOO constants, defined in a header if used in other parts of 
code


--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Gerd Hoffmann]

On Di, 2016-02-02 at 00:13 -0800, Neo Jia wrote:
> On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > And for UUID, I remember Alex had a concern on using it in kernel. 
> > > Honestly speaking I don't have a good idea here. In Xen side there is a 
> > > VM ID
> > > which can be easily used as the index. But for KVM, what would be the best
> > > identifier to associate with a VM?
> > 
> > The vgpu code doesn't need to associate the vgpu device with a vm in the
> > first place.  You get all guest address space information from qemu, via
> > vfio iommu interface.
> > 
> > When qemu does't use kvm (tcg mode), things should still work fine.
> > Using vfio-based vgpu devices with non-qemu apps (some kind of test
> > suite for example) should work fine too.
> 
> Hi Gerd and Kevin,
> 
> I thought Alex had agreed with the UUID as long as it is not tied with VM,
> probably it is just his comment gets lost in our previous long email thread.

As long as it isn't tied to a VM it is fine indeed.  We'll need names
for the devices, and using a uuid certainly is one option.  Could also
be a simple "vgpu${index}".  A more descriptive name such as
"nvidia-grid-${index}" or "igd-skl-${index}".  Or just a free-form
string where the driver can fill whatever it wants (including a uuid).

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/2] Emulated CCID card: QOMify

[Michael Tokarev]

02.02.2016 11:25, Cao jin wrote:
> On 02/02/2016 04:15 PM, Michael Tokarev wrote:
>> Why did you move the type definition from .c to .h file?
>> It is only referenced in .c, no?
[]
> Yes, that type definition is referred only in .c for now, but we are not sure 
> about it in the future, for better flexibility, I think put it into .h is 
> better. http://wiki.qemu.org/QOMConventions also says:
> 
> DO use TYPE_FOO constants, defined in a header if used in other parts of code

The last words in this sentense makes sense, I think:
"if used in other parts of the code".

So I read it as 2-part suggestion:

1) use TYPE_foo constants instead of "literals", and
2) define them in a header file if used elsewhere too.

The "future flexibility" is, in my opinion, questionable.
If we'll use them in the future, we can always move the
#define to the header file.  For now, there's no need
to clutter the heade more, but there's a good reason
to use the #define in the "home" .c file where this
device is implemented, in all places where the device
name is referenced.

At least that's how I read this (somewhat ambiguous)
suggestion in the wiki.

Thanks,

/mjt

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Neo Jia]

On Tue, Feb 02, 2016 at 08:18:44AM +, Tian, Kevin wrote:
> > From: Neo Jia [mailto:c...@nvidia.com]
> > Sent: Tuesday, February 02, 2016 4:13 PM
> > 
> > On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote:
> > >   Hi,
> > >
> > > > And for UUID, I remember Alex had a concern on using it in kernel.
> > > > Honestly speaking I don't have a good idea here. In Xen side there is a 
> > > > VM ID
> > > > which can be easily used as the index. But for KVM, what would be the 
> > > > best
> > > > identifier to associate with a VM?
> > >
> > > The vgpu code doesn't need to associate the vgpu device with a vm in the
> > > first place.  You get all guest address space information from qemu, via
> > > vfio iommu interface.
> > >
> > > When qemu does't use kvm (tcg mode), things should still work fine.
> > > Using vfio-based vgpu devices with non-qemu apps (some kind of test
> > > suite for example) should work fine too.
> > 
> > Hi Gerd and Kevin,
> > 
> > I thought Alex had agreed with the UUID as long as it is not tied with VM,
> > probably it is just his comment gets lost in our previous long email thread.
> > 
> 
> I think the point is... what is the value to introduce a UUID here? If
> what Gerd describes is enough, we can simply invent a vgpu ID which
> is returned at vgpu_create, and then used as the index for other
> interfaces.
> 

Hi Kevin,

It can just be a plain UUID, and the meaning of the UUID is up to upper layer 
SW, for
example with libvirt, you can create a new "vgpu group" object representing a
list of vgpu device. so the UUID will be the input on vgpu_create instead of
return value.

For the TCG mode, this should just work as long as libvirt can create the proper
internal objects there plus other vfio iommu interface Gerd has called out,
although the vector->kvm_interrupt part might need some tweaks.

Thanks,
Neo

> But I still need to think about whether there's value to have a VM
> identifier within vgpu core driver, especially regarding to how this
> vgpu core driver connects to KVM hypervisor or other hypervisor.
> I saw another long thread about that part. Jike has started his 
> vacation now. I'll follow up with it tomorrow.
> 
> Thanks
> Kevin

Re: [Qemu-devel] [PATCH v2 1/8] ivshmem: no need for opaque argument

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 3/8] ivshmem-test: leak fixes

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> Add a cleanup_vm() function to free QPCIDevice & QPCIBus when cleaning
> up the IVState.
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 5/8] ivshmem-test: test both msi & irq cases

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> Recent commit 660c97ee introduced a regression in irq case, make
> sure this code path is also tested.
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 7/8] ivshmem: use a single eventfd callback, get rid of CharDriver

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> Simplify the interrupt handling by having a single callback on irq&msi
> cases. Remove usage of CharDriver, replace it with
> qemu_set_fd_handler(). Use event_notifier_test_and_clear() to read the
> eventfd.
>
> Before this patch, ivshmem writes the first byte received to
> s->intrstatus. But ivshmem_device_spec.txt says "The status register is
> set to 1 when an interrupt occurs."

Suggest to add: Fortunately, the byte usually comes from another ivshmem
device, and those always write 1.

> After this commit, follows the
> specification, set to 1 when an interrupt occurs.
>
> Signed-off-by: Marc-André Lureau 

Acked-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 6/8] ivshmem: generalize ivshmem_setup_interrupts

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> Call ivshmem_setup_interrupts() with or without MSI, always allocate
> msi_vectors that is going to be used in all case in the following patch.
>
> Signed-off-by: Marc-André Lureau 
> ---
>  hw/misc/ivshmem.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> index 5029789..c601a8a 100644
> --- a/hw/misc/ivshmem.c
> +++ b/hw/misc/ivshmem.c
> @@ -769,18 +769,25 @@ static void ivshmem_reset(DeviceState *d)
>  ivshmem_use_msix(s);
>  }
>  
> -static int ivshmem_setup_msi(IVShmemState * s)
> +static int ivshmem_setup_interrupts(IVShmemState *s)
>  {
> -if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
> -return -1;
> +/* allocate QEMU callback data for receiving interrupts */
> +if (s->vectors > 0) {
> +s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
> +if (!s->msi_vectors) {

Can't happen; s->vectors * sizeof(MSIVector) != 0.

> +return -1;
> +}
>  }
>  
> -IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
> +if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
> +if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
> +return -1;
> +}
>  
> -/* allocate QEMU char devices for receiving interrupts */
> -s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
> +IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
> +ivshmem_use_msix(s);
> +}
>  
> -ivshmem_use_msix(s);
>  return 0;
>  }
>  
> @@ -947,9 +954,8 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
> **errp)
>  IVSHMEM_DPRINTF("using shared memory server (socket = %s)\n",
>  s->server_chr->filename);
>  
> -if (ivshmem_has_feature(s, IVSHMEM_MSI) &&
> -ivshmem_setup_msi(s)) {
> -error_setg(errp, "msix initialization failed");
> +if (ivshmem_setup_interrupts(s) < 0) {
> +error_setg(errp, "failed to initialize interrupts");
>  return;
>  }

With the useless conditional dropped:
Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 4/8] libqos: remove some leaks

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> qpci_device_find() returns allocated data, don't leak it.
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 8/8] char: remove qemu_chr_open_eventfd

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> Broken since d0d7708ba29cbc, since the backend is NULL.
>
> And now no longer needed by ivshmem.
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [PATCH v2 0/8] ivshmem: test msi=off, fix regressions, remove CharDriver

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> This is a ivshmem series with various bits:
> - add a test for msi=off regression (the fix is included in the series
>   but was sent separatly to cc -stable)
> - get rid of CharDriver usage for eventfd & fix regression introduced
>   by d0d7708ba by Daniel Berrange
> - fix some test leaks
> - simplify event callback
>
> v1->v2: after Markus Armbruster review,
> - add a few comments to commit messages
> - fix !msi with nvectors==0 regression
> - comment in commit message that the status register is set to 1 when
>   an interrupt occurs, following the ivshmem specification
> - found out that getting rid of CharDriver also fixed regression from
>   d0d7708ba
> - rebase

The two nits I found seem harmless enough to me to sneak into the pull
request rather than post a full v3 first.  Use your judgement.

Thanks!

Re: [Qemu-devel] [PATCH 4/8] libqos: remove some leaks

[Markus Armbruster]

Markus Armbruster  writes:

> Marc-André Lureau  writes:
>
>> Hi
>>
>> On Fri, Jan 29, 2016 at 4:43 PM, Markus Armbruster  wrote:
>>> The existing users pass a func that saves dev, and free the saved dev
>>> later.  Works as long as we call func() at most once.  If multiple
>>> devices match, all but the last one are leaked.  Can this happen?
>>
>> It is the responsability of the func() callback to deal with multiple
>> matches.
>
> If that's the case, and multiple devices can match, then the callbacks
> are all broken.
>
>>  I don't think this needs to change.
>
> If you mean to say that you don't have to fix it in this series: yes,
> but it still needs fixing.  If you don't want to fix it, consider adding
> a FIXME comment.

I'll have some ivshmem work coming up, and will try to remember to
include a fix for this.

[...]

Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Gerd Hoffmann]

  Hi,

> > I'd have qemu copy the data on 0xfc write then, so things continue to
> > work without updating seabios.  So, the firmware has to allocate space,
> > reserve it etc.,  and programming the 0xfc register.  Qemu has to make
> > sure the opregion appears at the address written by the firmware, by
> > whatever method it prefers.
> 
> Yup. It's Qemu's responsibility to expose opregion content. 
> 
> btw, prefer to do copying here. It's pointless to allow write from guest
> side. One write example is SWSCI mailbox, thru which gfx driver can
> trigger some SCI event to communicate with BIOS (specifically ACPI
> methods here), mostly for some monitor operations. However it's 
> not a right thing for guest to trigger host SCI and thus kick host 
> ACPI methods.

Thanks.

So, question again how we do that best.  Option one being the mmap way,
i.e. basically what the patches posted by alex are doing.  Option two
being the fw_cfg way, i.e. place a opregion copy in fw_cfg and have
seabios not only set 0xfc, but also store the opregion there by copying
from fw_cfg.

Advantage of option one is that we'll keep the option to do things in a
different way in the future, without breaking the guest/qemu interface.

Disadvantage is that it'll cause hugepage mappings to be splitted.

Hmm.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/2] Emulated CCID card: QOMify

[Cao jin]

On 02/02/2016 04:30 PM, Michael Tokarev wrote:

02.02.2016 11:25, Cao jin wrote:

On 02/02/2016 04:15 PM, Michael Tokarev wrote:

Why did you move the type definition from .c to .h file?
It is only referenced in .c, no?

[]

Yes, that type definition is referred only in .c for now, but we are not sure 
about it in the future, for better flexibility, I think put it into .h is 
better. http://wiki.qemu.org/QOMConventions also says:

DO use TYPE_FOO constants, defined in a header if used in other parts of code


The last words in this sentense makes sense, I think:
"if used in other parts of the code".

So I read it as 2-part suggestion:

1) use TYPE_foo constants instead of "literals", and
2) define them in a header file if used elsewhere too.

The "future flexibility" is, in my opinion, questionable.
If we'll use them in the future, we can always move the
#define to the header file.  For now, there's no need
to clutter the heade more, but there's a good reason
to use the #define in the "home" .c file where this
device is implemented, in all places where the device
name is referenced.

At least that's how I read this (somewhat ambiguous)
suggestion in the wiki.

Thanks,

/mjt



leave it where it was is also fine by me, it is not late to move it to 
header file when it is certainly to be used in other parts. I will 
update it:)


--
Yours Sincerely,

Cao jin

Re: [Qemu-devel] [PATCH v10 23/25] qapi: Drop unused error argument for list and implicit struct

[Markus Armbruster]

Eric Blake  writes:

> On 02/01/2016 06:07 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> No backend was setting an error when ending an implicit struct,
>>> or when iterating a list.
>> 
>> Perhaps "when ending the visit of a list or implicit struct, or when
>> moving to the next list node" would be more precise.  If you like it, I
>> can do that on commit.

Done.

>>>Make the callers a bit easier to follow
>>> by making this a part of the contract, and removing the errp
>>> argument - callers can then unconditionally end an object as
>>> part of cleanup without having to think about whether a second
>>> error is dominated by a first, because there is no second error.
>>>
>>> A later patch will then tackle the larger task of splitting
>>> visit_end_struct(), which can indeed set an error (and that
>>> cleanup will also have the side-effect of removing the use of
>>> error_abort added here).
>
> Oh, while you're touching this up, the last half of this sentence is now
> stale (since the addition of &error_abort was split out into 22/25
> instead); I'd just delete the entire parenthetical, ending with "indeed
> set an error."

Done.

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Kirti Wankhede]

On 2/2/2016 1:12 PM, Tian, Kevin wrote:

From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
Sent: Tuesday, February 02, 2016 9:48 AM

Resending this mail again, somehow my previous mail didn't reached every
to everyone's inbox.

On 2/2/2016 3:16 AM, Kirti Wankhede wrote:

Design for vGPU Driver:
Main purpose of vGPU driver is to provide a common interface for vGPU
management that can be used by differnt GPU drivers.


Thanks for composing this design which is a good start.



This module would provide a generic interface to create the device, add
it to vGPU bus, add device to IOMMU group and then add it to vfio group.

High Level block diagram:


+--+vgpu_register_driver()+---+
| __init() +->+   |
|  |  |   |
|  +<-+vgpu.ko|
| vfio_vgpu.ko |   probe()/remove()   |   |
|  |+-+   +-+
+--+| +---+---+ |
  | ^ |
  | callback| |
  | +---++|
  | |vgpu_register_device()   |
  | |||
  +---^-+-++-+--+-+
  | nvidia.ko ||  i915.ko   |
  |   |||
  +---+++

vGPU driver provides two types of registration interfaces:


Looks you missed callbacks which vgpu.ko provides to vfio_vgpu.ko,
e.g. to retrieve basic region/resource info, etc...



Basic region info or resource info would come from GPU driver. So 
retrieving such info should be the part of GPU driver interface. Like I 
mentioned we need to enhance these interfaces during development as and 
when we find it useful.
vfio_vgpu.ko gets dev pointer from which it can reach to vgpu_device 
structure and then it can use GPU driver interface directly to retrieve 
such information from GPU driver.


This RFC is to focus more on different modules and its structures, how 
those modules would be inter-linked with each other and have a flexible 
design to keep the scope for enhancements.


We have identified three modules:

* vgpu.ko - vGPU core driver that provide registration interface for GPU 
driver and vGPU VFIO  driver, responsible for creating vGPU devices and 
providing management interface for vGPU devices.
* vfio_vgpu.ko - vGPU VFIO driver for vGPU device, provides VFIO 
interface that is used by QEMU.
* vfio_iommu_type1_vgpu.ko - IOMMU TYPE1 driver supporting the IOMMU 
TYPE1 v1 and v2 interface.


The above block diagram gives an overview how vgpu.ko, vfio_vgpu.ko and 
GPU drivers would be inter-linked with each other.




Also for GPU driver interfaces, better to identify the caller. E.g. it's
easy to understand life-cycle management would come from sysfs
by mgmt. stack like libvirt. What about @read and @write? what's
the connection between this vgpu core driver and specific hypervisor?
etc. Better to connect all necessary dots so we can refine all
necessary requirements on this proposal.



read and write calls are for PCI CFG space amd MMIO space read/write. 
Read/write access request from QEMU is passed to GPU driver through GPU 
driver interface.



[...]


2. GPU driver interface

/**
   * struct gpu_device_ops - Structure to be registered for each physical
GPU to
   * register the device to vgpu module.
   *
   * @owner:  The module owner.
   * @vgpu_supported_config: Called to get information about supported
   *   vgpu types.
   *  @dev : pci device structure of physical GPU.
   *  @config: should return string listing supported
   *  config
   *  Returns integer: success (0) or error (< 0)
   * @vgpu_create:Called to allocate basic resouces in graphics
   *  driver for a particular vgpu.
   *  @dev: physical pci device structure on which vgpu
   *should be created
   *  @uuid: uuid for which VM it is intended to
   *  @instance: vgpu instance in that VM
   *  @vgpu_id: This represents the type of vgpu to be
   *created
   *  Returns integer: success (0) or error (< 0)


Specifically for Intel GVT-g we didn't hard partition resource among vGPUs.
Instead we allow user to accurately control how many physical resources
are allocated to a vGPU. So this interface should be extensible to allow
vendor 

Re: [Qemu-devel] [PATCH 00/16] aio: first part of aio_context_acquire/release pushdown

[Paolo Bonzini]

On 15/01/2016 16:12, Paolo Bonzini wrote:
> This is the infrastructure part of the aio_context_acquire/release pushdown,
> which in turn is the first step towards a real multiqueue block layer in
> QEMU.  The next step is to touch all the drivers and move calls to the
> aio_context_acquire/release functions from aio-*.c to the drivers.  This
> will be done in a separate patch series.
> 
> While the inserted lines are a lot, more than half of it are in documentation
> and formal models of the code, as well as in the implementation of the new
> "lockcnt" synchronization primitive.  The code is also very heavily commented.
> 
> The first four patches are new, as the issue they fix was found after posting
> the previous patch.  Everything else is more or less the same as before.

Ping?

Paolo

Re: [Qemu-devel] [PATCH v4 0/3] don't use NVDIMM for balooning

[Denis V. Lunev]

On 01/28/2016 09:51 AM, Vladimir Sementsov-Ogievskiy wrote:

v4:
  0001: Reviewed-by: Eric Blake 
  second patch is splitted to 0002 and 0003
  0002: Add 'type' field instead of 'balloonable' to PCDIMMDeviceInfo
  0003: chec 'type' instead of 'balloonable'

v3:
 - do not use additional class variable

NVDIMM for now is planned to use as a backing store for DAX filesystem
in the guest and thus this memory is excluded from guest memory
management and LRUs.

In this case libvirt running QEMU along with configured balloon almost
immediately inflates balloon and effectively kill the guest as
qemu counts nvdimm as part of the ram.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Denis V. Lunev 
CC: Stefan Hajnoczi 
CC: Xiao Guangrong 
CC: "Michael S. Tsirkin" 
CC: Igor Mammedov 
CC: Eric Blake 
CC: Markus Armbruster 

Vladimir Sementsov-Ogievskiy (3):
   move get_current_ram_size to virtio-balloon.c
   pcdimm: add 'type' field to PCDIMMDeviceInfo
   balloon: don't use NVDIMM for ballooning

  hw/mem/pc-dimm.c| 27 +--
  hw/virtio/virtio-balloon.c  | 29 +
  include/exec/cpu-common.h   |  1 -
  qapi-schema.json|  5 -
  stubs/qmp_pc_dimm_device_list.c |  5 -
  5 files changed, 34 insertions(+), 33 deletions(-)


ping

Re: [Qemu-devel] [PATCH 0/2] fixes for bdrv_invalidate_cache

[Denis V. Lunev]

On 01/20/2016 10:12 AM, Denis V. Lunev wrote:

Signed-off-by: Denis V. Lunev 
CC: Kevin Wolf 
CC: Paolo Bonzini 


guys?

Re: [Qemu-devel] [PATCH v10 00/25] qapi visitor cleanups part 1 (post-introspection cleanups subset E)

[Markus Armbruster]

Markus Armbruster  writes:

> Eric Blake  writes:
>
>> Based on qemu.git master. No pending prerequisites
>>
>> Also available as a tag at this location:
>> git fetch git://repo.or.cz/qemu/ericb.git qapi-cleanupv10e
>>
>> and will soon be part of my branch with the rest of the v5 series, at:
>> http://repo.or.cz/qemu/ericb.git/shortlog/refs/heads/qapi
>>
>> v10 notes:
>> This is patches 1-20 of v9; 21-37 of that series will come later,
>> but this half was relatively clean and should be ready to merge.
>> Plus, this half includes the argument reordering, which touches
>> a lot of the tree, so getting it in sooner rather than later will
>> minimize rebase churn.  A couple patches were split differently
>> or retitled.  Reviewed-by was kept on patches that didn't change
>> in content (even if the content was split across different patch
>> boundaries).
>>
>> Most of the work here was addressing Markus' review comments,
>> or rebasing later patches on top of earlier changes.
>
> I found one harmless rebase mistake, and got a few suggestions on commit
> messages, nothing that can't be touched up on commit.
>
> With the harmless rebase mistake cleaned up, series
> Reviewed-by: Markus Armbruster 
>
> [...]

Applied to qapi-next with these nits addressed.

Marc-André, Eric dropped a few of your R-bys.  I'll wait a few days in
case you'd like to put them back.

Re: [Qemu-devel] [PATCH v4 7/7] mips/kvm: Support MSA in MIPS KVM guests

[Leon Alrae]

Hi James,

On 18/12/15 10:46, James Hogan wrote:
> @@ -611,17 +664,51 @@ static int kvm_mips_get_fpu_registers(CPUState *cs)
>  restore_flush_mode(env);
>  }
>  
> -/* Floating point registers */
> -for (i = 0; i < 32; ++i) {
> -if (env->CP0_Status & (1 << CP0St_FR)) {
> -err = kvm_mips_get_one_ureg64(cs, KVM_REG_MIPS_FPR_64(i),
> -  &env->active_fpu.fpr[i].d);
> -} else {
> -err = kvm_mips_get_one_ureg(cs, KVM_REG_MIPS_FPR_32(i),
> -  
> &env->active_fpu.fpr[i].w[FP_ENDIAN_IDX]);
> +/*
> + * FPU register state is a subset of MSA vector state, so don't save 
> FPU
> + * registers if we're emulating a CPU with MSA.
> + */
> +if (!(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
> +/* Floating point registers */
> +for (i = 0; i < 32; ++i) {
> +if (env->CP0_Status & (1 << CP0St_FR)) {
> +err = kvm_mips_get_one_ureg64(cs, KVM_REG_MIPS_FPR_64(i),
> +  &env->active_fpu.fpr[i].d);
> +} else {
> +err = kvm_mips_get_one_ureg(cs, KVM_REG_MIPS_FPR_32(i),
> +
> &env->active_fpu.fpr[i].w[FP_ENDIAN_IDX]);
> +}
> +if (err < 0) {
> +DPRINTF("%s: Failed to get FPR%u (%d)\n", __func__, i, 
> err);
> +ret = err;
> +}
>  }
> +}
> +}
> +
> +/* Only get MSA state if we're emulating a CPU with MSA */
> +if (env->CP0_Config3 & (1 << CP0C3_MSAP)) {
> +/* MSA Control Registers */
> +err = kvm_mips_get_one_reg(cs, KVM_REG_MIPS_MSA_IR,
> +   &env->msair);
> +if (err < 0) {
> +DPRINTF("%s: Failed to get MSA_IR (%d)\n", __func__, err);
> +ret = err;
> +}
> +err = kvm_mips_get_one_reg(cs, KVM_REG_MIPS_MSA_CSR,
> +   &env->active_tc.msacsr);
> +if (err < 0) {
> +DPRINTF("%s: Failed to get MSA_CSR (%d)\n", __func__, err);
> +ret = err;
> +}

Shouldn't MSA's float_status (i.e. msa_fp_status) be restored to reflect
MSACSR?

Thanks,
Leon

> +/* Vector registers (includes FP registers) */
> +for (i = 0; i < 32; ++i) {
> +/* Big endian MSA not supported by QEMU yet anyway */
> +err = kvm_mips_get_one_reg64(cs, KVM_REG_MIPS_VEC_128(i),
> + env->active_fpu.fpr[i].wr.d);
>  if (err < 0) {
> -DPRINTF("%s: Failed to get FPR%u (%d)\n", __func__, i, err);
> +DPRINTF("%s: Failed to get VEC%u (%d)\n", __func__, i, err);
>  ret = err;
>  }
>  }
> 

Re: [Qemu-devel] [PATCH v19 3/9] pc: add a Virtual Machine Generation ID device

[Igor Mammedov]

On Sun, 31 Jan 2016 18:22:13 +0200
"Michael S. Tsirkin"  wrote:

> On Fri, Jan 29, 2016 at 12:13:59PM +0100, Igor Mammedov wrote:
> > On Thu, 28 Jan 2016 14:59:25 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Thu, Jan 28, 2016 at 01:03:16PM +0100, Igor Mammedov wrote:  
> > > > On Thu, 28 Jan 2016 13:13:04 +0200
> > > > "Michael S. Tsirkin"  wrote:
> > > > 
> > > > > On Thu, Jan 28, 2016 at 11:54:25AM +0100, Igor Mammedov wrote:
> > > > > > Based on Microsoft's specifications (paper can be
> > > > > > downloaded from http://go.microsoft.com/fwlink/?LinkId=260709,
> > > > > > easily found by "Virtual Machine Generation ID" keywords),
> > > > > > add a PCI device with corresponding description in
> > > > > > SSDT ACPI table.
> > > > > > 
> > > > > > The GUID is set using "vmgenid.guid" property or
> > > > > > a corresponding HMP/QMP command.
> > > > > > 
> > > > > > Example of using vmgenid device:
> > > > > >  -device vmgenid,id=FOO,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"
> > > > > > 
> > > > > > 'vmgenid' device initialization flow is as following:
> > > > > >  1. vmgenid has RAM BAR registered with size of GUID buffer
> > > > > >  2. BIOS initializes PCI devices and it maps BAR in PCI hole
> > > > > >  3. BIOS reads ACPI tables from QEMU, at that moment tables
> > > > > > are generated with \_SB.VMGI.ADDR constant pointing to
> > > > > > GPA where BIOS's mapped vmgenid's BAR earlier
> > > > > > 
> > > > > > Note:
> > > > > > This implementation uses PCI class 0x0500 code for vmgenid device,
> > > > > > that is marked as NO_DRV in Windows's machine.inf.
> > > > > > Testing various Windows versions showed that, OS
> > > > > > doesn't touch nor checks for resource conflicts
> > > > > > for such PCI devices.
> > > > > > There was concern that during PCI rebalancing, OS
> > > > > > could reprogram the BAR at other place, which would
> > > > > > leave VGEN.ADDR pointing to the old (no more valid)
> > > > > > address.
> > > > > > However testing showed that Windows does rebalancing
> > > > > > only for PCI device that have a driver attached
> > > > > > and completely ignores NO_DRV class of devices.
> > > > > > Which in turn creates a problem where OS could remap
> > > > > > one of PCI devices(with driver) over BAR used by
> > > > > > a driver-less PCI device.
> > > > > > Statically declaring used memory range as VGEN._CRS
> > > > > > makes OS to honor resource reservation and an ignored
> > > > > > BAR range is not longer touched during PCI rebalancing.
> > > > > > 
> > > > > > Signed-off-by: Gal Hammer 
> > > > > > Signed-off-by: Igor Mammedov   
> > > > > 
> > > > > It's an interesting hack, but this needs some thought. BIOS has no 
> > > > > idea
> > > > > this BAR is special and can not be rebalanced, so it might put the BAR
> > > > > in the middle of the range, in effect fragmenting it.
> > > > yep that's the only drawback in PCI approach.
> > > > 
> > > > > Really I think something like V12 just rewritten using the new APIs
> > > > > (probably with something like build_append_named_dword that I 
> > > > > suggested)
> > > > > would be much a simpler way to implement this device, given
> > > > > the weird API limitations.
> > > > We went over stating drawbacks of both approaches several times 
> > > > and that's where I strongly disagree with using v12 AML patching
> > > > approach for reasons stated in those discussions.
> > > 
> > > Yes, IIRC you dislike the need to allocate an IO range to pass address
> > > to host, and to have costom code to migrate the address.  
> > allocating IO ports is fine by me but I'm against using bios_linker (ACPI)
> > approach for task at hand,
> > let me enumerate one more time the issues that make me dislike it so much
> > (in order where most disliked ones go the first):
> > 
> > 1. over-engineered for the task at hand, 
> >for device to become initialized guest OS has to execute AML,
> >so init chain looks like:
> >  QEMU -> BIOS (patch AML) -> OS (AML write buf address to IO port) ->
> >  QEMU (update buf address)
> >it's hell to debug when something doesn't work right in this chain  
> 
> Well this is not very different from e.g. virtio.
> If it's just AML that worries you, we could teach BIOS/EFI a new command
> to give some addresses after linking back to QEMU. Would this address
> this issue?
it would make it marginally better (especially from tests pov)
though it won't fix other issues.

> 
> 
> >even if there isn't any memory corruption that incorrect AML patching
> >could introduce.
> >As result of complexity patches are hard to review since one has
> >to remember/relearn all details how bios_linker in QEMU and BIOS works,
> >hence chance of regression is very high.
> >Dynamically patched AML also introduces its own share of AML
> >code that has to deal with dynamic buff address value.
> >For an example:
> >  "nvdimm acpi: add _CRS" https://patchwork.ozlab

Re: [Qemu-devel] [PATCH v4 05/10] qemu-io: allow specifying image as a set of options args

[Daniel P. Berrange]

On Wed, Jan 27, 2016 at 03:26:51PM +0100, Kevin Wolf wrote:
> Am 26.01.2016 um 14:34 hat Daniel P. Berrange geschrieben:
> > -if ((argc - optind) == 1) {
> > +if (imageOpts) {
> > +char *file;
> > +qopts = qemu_opts_parse_noisily(&file_opts, argv[optind], false);
> > +if (!qopts) {
> > +exit(1);
> > +}
> > +if (opts) {
> > +error_report("--image-opts and -f are mutually exclusive");
> > +exit(1);
> > +}
> > +file = g_strdup(qemu_opt_get(qopts, "file"));
> > +qemu_opt_unset(qopts, "file");
> 
> I'm not sure if special casing "file" is a good idea. I think you're
> doing it in order to support something that looks like -drive, but it's
> not the same anyway - all of the options that are parsed in drive_new()
> or blockdev_init() aren't supported.
> 
> We could change things so that qemu-io actually goes through
> drive_new() or blockdev_init(), at the cost of forbidding node
> references for the "file" options like -drive unfortunately does. Or we
> can require that you use actual bdrv_open() options and specify
> file.filename=... for raw-posix.
> 
> But I would like to avoid creating a new type of option parsing with yet
> another behaviour.

Mostly this special casing of 'file' was based on my confusion /
misunderstanding of the recommended best API usage around bdrv_open.
I thought I was being compatible with -drive from the system emulators
by doing this, but you point out I'm not actually doing it properly.

Lets just keep this simple and use bdrv_open() options explicitly
since IIUC that looks like the "best practice" approach these days


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file

[Gerd Hoffmann]

On Mo, 2016-02-01 at 09:35 +0100, Laszlo Ersek wrote:
> Gerd,
> 
> On 02/01/16 06:57, vladislav.vovche...@sk.com wrote:
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: 27 January 2016 02:21
> >> To: qemu-devel@nongnu.org
> >> Cc: Keith Busch; Kevin Wolf; open list:nvme; Gonglei; Vladislav Vovchenko
> >> SFS; Feng Tian; Gerd Hoffmann; Kevin O'Connor
> >> Subject: [PATCH] nvme: generate OpenFirmware device path in the
> >> "bootorder" fw_cfg file
> 
> [snip]
> 
> > Tested-by: Vladislav Vovchenko 
> 
> Can you please pick up this patch? (You handled the precursor patch,
> commit 33739c712982.)
> 
> This one has A-b's from Gonglei and Keith, and a T-b from Vladislav.
> (Thanks for those, guys!)

Yep.  The fw_cfg dma linuxboot patch is ready too, so I'll go prepare a
fw_cfg pull requests with them.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v2 6/8] ivshmem: generalize ivshmem_setup_interrupts

[Marc-André Lureau]

Hi

- Original Message -
> marcandre.lur...@redhat.com writes:
> 
> > From: Marc-André Lureau 
> >
> > Call ivshmem_setup_interrupts() with or without MSI, always allocate
> > msi_vectors that is going to be used in all case in the following patch.
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  hw/misc/ivshmem.c | 26 --
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> > index 5029789..c601a8a 100644
> > --- a/hw/misc/ivshmem.c
> > +++ b/hw/misc/ivshmem.c
> > @@ -769,18 +769,25 @@ static void ivshmem_reset(DeviceState *d)
> >  ivshmem_use_msix(s);
> >  }
> >  
> > -static int ivshmem_setup_msi(IVShmemState * s)
> > +static int ivshmem_setup_interrupts(IVShmemState *s)
> >  {
> > -if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
> > -return -1;
> > +/* allocate QEMU callback data for receiving interrupts */
> > +if (s->vectors > 0) {
> > +s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
> > +if (!s->msi_vectors) {
> 
> Can't happen; s->vectors * sizeof(MSIVector) != 0.

It can't happen on allocation failure?

> > +return -1;
> > +}
> >  }
> >  
> > -IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
> > +if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
> > +if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
> > +return -1;
> > +}
> >  
> > -/* allocate QEMU char devices for receiving interrupts */
> > -s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
> > +IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
> > +ivshmem_use_msix(s);
> > +}
> >  
> > -ivshmem_use_msix(s);
> >  return 0;
> >  }
> >  
> > @@ -947,9 +954,8 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error
> > **errp)
> >  IVSHMEM_DPRINTF("using shared memory server (socket = %s)\n",
> >  s->server_chr->filename);
> >  
> > -if (ivshmem_has_feature(s, IVSHMEM_MSI) &&
> > -ivshmem_setup_msi(s)) {
> > -error_setg(errp, "msix initialization failed");
> > +if (ivshmem_setup_interrupts(s) < 0) {
> > +error_setg(errp, "failed to initialize interrupts");
> >  return;
> >  }
> 
> With the useless conditional dropped:
> Reviewed-by: Markus Armbruster 
> 

Re: [Qemu-devel] [PULL 00/40] ppc-for-2.6 queue 20160201

[Peter Maydell]

On 1 February 2016 at 02:30, David Gibson  wrote:
> The following changes since commit 0430891ce162b986c6e02a7729a942ecd2a32ca4:
>
>   hw: Clean up includes (2016-01-29 15:07:25 +)
>
> are available in the git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.6-20160201
>
> for you to fetch changes up to d1277156b5d3df6d75d138a7eec6ff80934cdcec:
>
>   target-ppc: mcrfs should always update FEX/VX and only clear exception bits 
> (2016-02-01 13:27:01 +1100)
>
>
> I hope I've managed to finally iron out the problems in this series.
> I've fixed the clang build problem from the 20160129 request and
> checked build on a 32-bit host.  I've also added the mcrfs fix on top.
>
>
> 
> ppc patch queue for 2016-02-01
>
> Currently accumulated patches for target-ppc, pseries machine type and
> related devices.
>   * Cleanup of error handling code in spapr
>   * A number of fixes for Macintosh devices for the benefit of MacOS 9 and X
>   * Remove some abuses of the RTAS memory access functions in spapr
>   * Fixes for the gdbstub (and monitor debug) for VMX and VSX extensions.
>   * Fix pseries machine hotplug memory under TCG
>   * Clean up and extend handling of multiple page sizes with 64-bit hash MMUs
>   * Fix to the TCG implementation of mcrfs
>
> 

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH v4 02/10] qemu-img: add support for --object command line arg

[Daniel P. Berrange]

On Wed, Jan 27, 2016 at 02:26:53PM +0100, Kevin Wolf wrote:
> Am 26.01.2016 um 14:34 hat Daniel P. Berrange geschrieben:
> > Allow creation of user creatable object types with qemu-img
> > via a new --object command line arg. This will be used to supply
> > passwords and/or encryption keys to the various block driver
> > backends via the recently added 'secret' object type.
> > 
> >  # printf letmein > mypasswd.txt
> >  # qemu-img info --object secret,id=sec0,file=mypasswd.txt \
> >   ...other info args...
> > 
> > Signed-off-by: Daniel P. Berrange 
> 
> > diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
> > index 9567774..5bb1de7 100644
> > --- a/qemu-img-cmds.hx
> > +++ b/qemu-img-cmds.hx
> > @@ -10,68 +10,68 @@ STEXI
> >  ETEXI
> >  
> >  DEF("check", img_check,
> > -"check [-q] [-f fmt] [--output=ofmt] [-r [leaks | all]] [-T src_cache] 
> > filename")
> > +"check [-q] [--object objectdef] [-f fmt] [--output=ofmt] [-r [leaks | 
> > all]] [-T src_cache] filename")
> >  STEXI
> > -@item check [-q] [-f @var{fmt}] [--output=@var{ofmt}] [-r [leaks | all]] 
> > [-T @var{src_cache}] @var{filename}
> > +@item check [--object objectdef] [-q] [-f @var{fmt}] [--output=@var{ofmt}] 
> > [-r [leaks | all]] [-T @var{src_cache}] @var{filename}
> >  ETEXI
> 
> s/objectdef/@var{objectdef}/ (in each command)

Ok, will fix.

> > @@ -94,6 +98,10 @@ static void QEMU_NORETURN help(void)
> > "\n"
> > "Command parameters:\n"
> > "  'filename' is a disk image filename\n"
> > +   "  'objectdef' is a QEMU user creatable object definition. See 
> > the @code{qemu(1)}\n"
> > +   "manual page for a description of the object properties. 
> > The common object\n"
> > +   "type that it makes sense to define is the @code{secret} 
> > object, which is used\n"
> > +   "to supply passwords and/or encryption keys.\n"
> > "  'fmt' is the disk image format. It is guessed automatically 
> > in most cases\n"
> > "  'cache' is the cache mode used to write the output disk 
> > image, the valid\n"
> > "options are: 'none', 'writeback' (default, except for 
> > convert), 'writethrough',\n"
> 
> This one in contrast is printed literally on stdout, so using @code{} is
> not a great idea.

Opps, yes.

> >  static int GCC_FMT_ATTR(2, 3) qprintf(bool quiet, const char *fmt, ...)
> >  {
> >  int ret = 0;
> > @@ -273,9 +309,17 @@ static int img_create(int argc, char **argv)
> >  char *options = NULL;
> >  Error *local_err = NULL;
> >  bool quiet = false;
> > +QemuOpts *opts;
> 
> There are places where we declare variables only used by a specific
> option locally with a new block after the case label. This could be
> another one for which it is appropriate - it's not used after the option
> parsing any more (and it can't be used there because it may still be
> uninitialised).

Ok, will put the decl inside the switch case that uses it.

> > -c = getopt(argc, argv, "F:b:f:he6o:q");
> > +int option_index = 0;
> > +static const struct option long_options[] = {
> > +{"help", no_argument, 0, 'h'},
> > +{"object", required_argument, 0, OPTION_OBJECT},
> > +{0, 0, 0, 0}
> > +};
> > +c = getopt_long(argc, argv, "F:b:f:he6o:q",
> > +long_options, &option_index);
> >  if (c == -1) {
> >  break;
> >  }
> > @@ -317,6 +361,13 @@ static int img_create(int argc, char **argv)
> >  case 'q':
> >  quiet = true;
> >  break;
> > +case OPTION_OBJECT:
> > +opts = qemu_opts_parse_noisily(qemu_find_opts("object"),
> > +   optarg, true);
> 
> Any reason for using qemu_add_opts() to register the opts list and then
> finding it again by name instead of just using &qemu_object_opts here?

No reason at all really, other than copying the pattern from vl.c.
I'll change to use &qemu_object_opts instead.

> 
> > +if (!opts) {
> > +exit(1);
> > +}
> 
> You seem to introduce a lot of exit(1) calls even where the surrounding
> code prefers return 1.
> 
> Also, for other patches Eric has been asking to use EXIT_FAILURE instead
> of 1 in new code, and I think that makes sense, too.

For added fun several img_XXX commands are slightly different. I'll go
through and make each one consistent with surrounding code, either a
return, or a goto as applicable.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH] target-mips: Stop using uint_fast*_t types in r4k_tlb_t struct

[Leon Alrae]

On 25/01/16 17:40, Peter Maydell wrote:
> The r4k_tlb_t structure uses the uint_fast*_t types. Most of these
> uses are in bitfields and are thus pointless, because the bitfield
> itself specifies the width of the type; just use 'unsigned int'
> instead. (On glibc uint_fast16_t is defined as either 32 or 64 bits,
> so we know the code is not reliant on it being exactly 16 bits.)
> There is also one use of uint_fast8_t, which we replace with uint8_t,
> because both are exactly 8 bits on glibc and this is the only
> place outside the softfloat code which uses an int_fast*_t type.
> 
> Signed-off-by: Peter Maydell 
> ---
> I'm going to have a go at getting rid of the int_fast16_t usage
> in the softfloat code too, but in the meantime this is an
> independent cleanup.
> 
>  target-mips/cpu.h | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)

Applied to target-mips tree, thanks.

Leon

Re: [Qemu-devel] [PULL 00/17] Net patches

[Peter Maydell]

On 2 February 2016 at 02:36, Jason Wang  wrote:
> The following changes since commit 0430891ce162b986c6e02a7729a942ecd2a32ca4:
>
>   hw: Clean up includes (2016-01-29 15:07:25 +)
>
> are available in the git repository at:
>
>   https://github.com/jasowang/qemu.git tags/net-pull-request
>
> for you to fetch changes up to e8a7a1a574ed6728422959c8aa79ca584cdd1d4d:
>
>   net/filter: Fix the output information for command 'info network' 
> (2016-02-02 10:21:28 +0800)
>
> 
>
> Major changes for net:
>
> - preparation for ipv6 support in slirp
> - fix tx infinite loops of e1000
> - fix cadence_gem buffer overflow
> - rx netfilter were gone in reverse for future complex netfilter setups

Hi. I'm afraid this failed to build on w32:

In file included from /home/petmay01/linaro/qemu-for-merges/slirp/slirp.h:146,
 from /home/petmay01/linaro/qemu-for-merges/stubs/slirp.c:2:
/home/petmay01/linaro/qemu-for-merges/slirp/udp.h:79: error: expected
declaration specifiers or ‘...’ before ‘sa_family_t’
In file included from /home/petmay01/linaro/qemu-for-merges/stubs/slirp.c:2:
/home/petmay01/linaro/qemu-for-merges/slirp/slirp.h:330: error:
expected declaration specifiers or ‘...’ before ‘sa_family_t’

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA version

[Gerd Hoffmann]

  Hi,

>  %.img: %.o
> - $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -Ttext 0 -e _start -s -o $@ 
> $<,"  Building $(TARGET_DIR)$@")
> + $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -m elf_i386 -Ttext 0 -e 
> _start -s -o $@ $<,"  Building $(TARGET_DIR)$@")

Hmm, that breaks the windows cross build:

make: Entering directory `/home/kraxel/projects/qemu/build-win32'
  Building optionrom/linuxboot_dma.img
i686-w64-mingw32-ld: unrecognised emulation mode: elf_i386
Supported emulations: i386pe
make[1]: *** [linuxboot_dma.img] Error 1

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v19 3/9] pc: add a Virtual Machine Generation ID device

[Michael S. Tsirkin]

On Tue, Feb 02, 2016 at 10:59:53AM +0100, Igor Mammedov wrote:
> On Sun, 31 Jan 2016 18:22:13 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > On Fri, Jan 29, 2016 at 12:13:59PM +0100, Igor Mammedov wrote:
> > > On Thu, 28 Jan 2016 14:59:25 +0200
> > > "Michael S. Tsirkin"  wrote:
> > >   
> > > > On Thu, Jan 28, 2016 at 01:03:16PM +0100, Igor Mammedov wrote:  
> > > > > On Thu, 28 Jan 2016 13:13:04 +0200
> > > > > "Michael S. Tsirkin"  wrote:
> > > > > 
> > > > > > On Thu, Jan 28, 2016 at 11:54:25AM +0100, Igor Mammedov wrote:
> > > > > > > Based on Microsoft's specifications (paper can be
> > > > > > > downloaded from http://go.microsoft.com/fwlink/?LinkId=260709,
> > > > > > > easily found by "Virtual Machine Generation ID" keywords),
> > > > > > > add a PCI device with corresponding description in
> > > > > > > SSDT ACPI table.
> > > > > > > 
> > > > > > > The GUID is set using "vmgenid.guid" property or
> > > > > > > a corresponding HMP/QMP command.
> > > > > > > 
> > > > > > > Example of using vmgenid device:
> > > > > > >  -device 
> > > > > > > vmgenid,id=FOO,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"
> > > > > > > 
> > > > > > > 'vmgenid' device initialization flow is as following:
> > > > > > >  1. vmgenid has RAM BAR registered with size of GUID buffer
> > > > > > >  2. BIOS initializes PCI devices and it maps BAR in PCI hole
> > > > > > >  3. BIOS reads ACPI tables from QEMU, at that moment tables
> > > > > > > are generated with \_SB.VMGI.ADDR constant pointing to
> > > > > > > GPA where BIOS's mapped vmgenid's BAR earlier
> > > > > > > 
> > > > > > > Note:
> > > > > > > This implementation uses PCI class 0x0500 code for vmgenid device,
> > > > > > > that is marked as NO_DRV in Windows's machine.inf.
> > > > > > > Testing various Windows versions showed that, OS
> > > > > > > doesn't touch nor checks for resource conflicts
> > > > > > > for such PCI devices.
> > > > > > > There was concern that during PCI rebalancing, OS
> > > > > > > could reprogram the BAR at other place, which would
> > > > > > > leave VGEN.ADDR pointing to the old (no more valid)
> > > > > > > address.
> > > > > > > However testing showed that Windows does rebalancing
> > > > > > > only for PCI device that have a driver attached
> > > > > > > and completely ignores NO_DRV class of devices.
> > > > > > > Which in turn creates a problem where OS could remap
> > > > > > > one of PCI devices(with driver) over BAR used by
> > > > > > > a driver-less PCI device.
> > > > > > > Statically declaring used memory range as VGEN._CRS
> > > > > > > makes OS to honor resource reservation and an ignored
> > > > > > > BAR range is not longer touched during PCI rebalancing.
> > > > > > > 
> > > > > > > Signed-off-by: Gal Hammer 
> > > > > > > Signed-off-by: Igor Mammedov   
> > > > > > 
> > > > > > It's an interesting hack, but this needs some thought. BIOS has no 
> > > > > > idea
> > > > > > this BAR is special and can not be rebalanced, so it might put the 
> > > > > > BAR
> > > > > > in the middle of the range, in effect fragmenting it.
> > > > > yep that's the only drawback in PCI approach.
> > > > > 
> > > > > > Really I think something like V12 just rewritten using the new APIs
> > > > > > (probably with something like build_append_named_dword that I 
> > > > > > suggested)
> > > > > > would be much a simpler way to implement this device, given
> > > > > > the weird API limitations.
> > > > > We went over stating drawbacks of both approaches several times 
> > > > > and that's where I strongly disagree with using v12 AML patching
> > > > > approach for reasons stated in those discussions.
> > > > 
> > > > Yes, IIRC you dislike the need to allocate an IO range to pass address
> > > > to host, and to have costom code to migrate the address.  
> > > allocating IO ports is fine by me but I'm against using bios_linker (ACPI)
> > > approach for task at hand,
> > > let me enumerate one more time the issues that make me dislike it so much
> > > (in order where most disliked ones go the first):
> > > 
> > > 1. over-engineered for the task at hand, 
> > >for device to become initialized guest OS has to execute AML,
> > >so init chain looks like:
> > >  QEMU -> BIOS (patch AML) -> OS (AML write buf address to IO port) ->
> > >  QEMU (update buf address)
> > >it's hell to debug when something doesn't work right in this chain  
> > 
> > Well this is not very different from e.g. virtio.
> > If it's just AML that worries you, we could teach BIOS/EFI a new command
> > to give some addresses after linking back to QEMU. Would this address
> > this issue?
> it would make it marginally better (especially from tests pov)
> though it won't fix other issues.
> 
> > 
> > 
> > >even if there isn't any memory corruption that incorrect AML patching
> > >could introduce.
> > >As result of complexity patches are hard to review since one has
> > >to remember/relearn all details how bios_linke

Re: [Qemu-devel] [PATCH v2 0/5] KVM: Hyper-V VMBus hypercalls

[Andrey Smetanin]

ping

On 01/21/2016 05:01 PM, Andrey Smetanin wrote:

The patch implements userspace exit 'KVM_EXIT_HYPERV'
for Hyper-V VMBus hypercalls(postmsg, signalevent)
to handle these hypercalls by QEMU.

Changes v2:
* use KVM_EXIT_HYPERV for hypercalls

Signed-off-by: Andrey Smetanin 
Reviewed-by: Roman Kagan 
CC: Gleb Natapov 
CC: Paolo Bonzini 
CC: Joerg Roedel 
CC: "K. Y. Srinivasan" 
CC: Haiyang Zhang 
CC: Roman Kagan 
CC: Denis V. Lunev 
CC: qemu-devel@nongnu.org

Andrey Smetanin (5):
   kvm/x86: Rename Hyper-V long spin wait hypercall
   drivers/hv: Move VMBus hypercall codes into Hyper-V UAPI header
   kvm/x86: Pass return code of kvm_emulate_hypercall
   kvm/x86: Reject Hyper-V hypercall continuation
   kvm/x86: Hyper-V VMBus hypercall userspace exit

  Documentation/virtual/kvm/api.txt  |  6 ++
  arch/x86/include/uapi/asm/hyperv.h |  4 +++-
  arch/x86/kvm/hyperv.c  | 40 +-
  arch/x86/kvm/hyperv.h  |  1 +
  arch/x86/kvm/svm.c |  3 +--
  arch/x86/kvm/vmx.c |  3 +--
  arch/x86/kvm/x86.c |  5 +
  drivers/hv/hv.c|  4 ++--
  drivers/hv/hyperv_vmbus.h  |  6 --
  include/uapi/linux/kvm.h   |  6 ++
  10 files changed, 56 insertions(+), 22 deletions(-)

Re: [Qemu-devel] [PATCH v3 1/2] build: [linux-user] Rename "syscall.h" to "target_syscall.h" in target directories

[Peter Maydell]

On 1 February 2016 at 18:38, Lluís Vilanova  wrote:
> This fixes double-definitions in linux-user builds when using the UST
> tracing backend (which indirectly includes the system's "syscall.h").
>
> Signed-off-by: Lluís Vilanova 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4 03/10] qemu-nbd: add support for --object command line arg

[Daniel P. Berrange]

On Wed, Jan 27, 2016 at 02:57:51PM +0100, Kevin Wolf wrote:
> Am 26.01.2016 um 14:34 hat Daniel P. Berrange geschrieben:
> > Allow creation of user creatable object types with qemu-nbd
> > via a new --object command line arg. This will be used to supply
> > passwords and/or encryption keys to the various block driver
> > backends via the recently added 'secret' object type.
> > 
> >  # printf letmein > mypasswd.txt
> >  # qemu-nbd --object secret,id=sec0,file=mypasswd.txt \
> >   ...other nbd args...
> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >  qemu-nbd.c| 54 ++
> >  qemu-nbd.texi |  6 ++
> >  2 files changed, 60 insertions(+)
> > 
> > diff --git a/qemu-nbd.c b/qemu-nbd.c
> > index ede4a54..8e5d36c 100644
> > --- a/qemu-nbd.c
> > +++ b/qemu-nbd.c
> > @@ -23,9 +23,12 @@
> >  #include "qemu/main-loop.h"
> >  #include "qemu/sockets.h"
> >  #include "qemu/error-report.h"
> > +#include "qemu/config-file.h"
> >  #include "block/snapshot.h"
> >  #include "qapi/util.h"
> >  #include "qapi/qmp/qstring.h"
> > +#include "qapi/opts-visitor.h"
> > +#include "qom/object_interfaces.h"
> >  
> >  #include 
> >  #include 
> > @@ -44,6 +47,7 @@
> >  #define QEMU_NBD_OPT_AIO   2
> >  #define QEMU_NBD_OPT_DISCARD   3
> >  #define QEMU_NBD_OPT_DETECT_ZEROES 4
> > +#define QEMU_NBD_OPT_OBJECT5
> >  
> >  static NBDExport *exp;
> >  static int verbose;
> > @@ -77,6 +81,9 @@ static void usage(const char *name)
> >  "  -o, --offset=OFFSET   offset into the image\n"
> >  "  -P, --partition=NUM   only expose partition NUM\n"
> >  "\n"
> > +"General purpose options:\n"
> > +"  --object type,id=ID,...   define an object such as 'secret' for 
> > providing\n"
> > +"passwords and/or encryption keys\n"
> >  #ifdef __linux__
> >  "Kernel NBD client support:\n"
> >  "  -c, --connect=DEV connect FILE to the local NBD device DEV\n"
> > @@ -374,6 +381,35 @@ static SocketAddress *nbd_build_socket_address(const 
> > char *sockpath,
> >  }
> >  
> >  
> > +static QemuOptsList qemu_object_opts = {
> > +.name = "object",
> > +.implied_opt_name = "qom-type",
> > +.head = QTAILQ_HEAD_INITIALIZER(qemu_object_opts.head),
> > +.desc = {
> > +{ }
> > +},
> > +};
> > +
> > +static int object_create(void *opaque, QemuOpts *opts, Error **errp)
> > +{
> > +Error *err = NULL;
> > +OptsVisitor *ov;
> > +QDict *pdict;
> > +
> > +ov = opts_visitor_new(opts);
> > +pdict = qemu_opts_to_qdict(opts, NULL);
> > +
> > +user_creatable_add(pdict, opts_get_visitor(ov), &err);
> > +opts_visitor_cleanup(ov);
> > +QDECREF(pdict);
> > +
> > +if (err) {
> > +error_propagate(errp, err);
> > +return -1;
> > +}
> > +return 0;
> > +}
> 
> Hm... This looks very similar to the same function in qemu-img.c. And
> actually, vl.c is a bit different, but not too much either. Wouldn't it
> make sense to share this code?
> 
> Also, now that I compared this to vl.c, there seem to be two differences
> compared to the tools: Support for filtering (the tools don't seem to
> need this; passing NULL as the callback could skip it) and an additional
> obj_unref(obj).

Ok, I'll push more of this into qom/object_interfaces.c to allow
more sharing.

> I don't understand much of QOM, so I don't know what the obj_unref() is
> for, but I'm wondering whether we need to do the same in the tools. Can
> you explain?

Yes, we ought to have the obj_unref too from a technical correctness
POV, even though its harmless since we need the object around forever
anyway.

> > @@ -436,6 +474,8 @@ int main(int argc, char **argv)
> >  memset(&sa_sigterm, 0, sizeof(sa_sigterm));
> >  sa_sigterm.sa_handler = termsig_handler;
> >  sigaction(SIGTERM, &sa_sigterm, NULL);
> > +module_call_init(MODULE_INIT_QOM);
> > +qemu_add_opts(&qemu_object_opts);
> 
> Like in qemu-img, I'd prefer directly using the pointer.

Yes, will fix

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v4 07/10] qemu-img: allow specifying image as a set of options args

[Daniel P. Berrange]

On Wed, Jan 27, 2016 at 03:30:29PM +0100, Kevin Wolf wrote:
> Am 26.01.2016 um 14:34 hat Daniel P. Berrange geschrieben:
> > Currently qemu-img allows an image filename to be passed on the
> > command line, but unless using the JSON format, it does not have
> > a way to set any options except the format eg
> > 
> >qemu-img info https://127.0.0.1/images/centos7.iso
> > 
> > This adds a --image-opts arg that indicates that the positional
> > filename should be interpreted as a full option string, not
> > just a filename.
> > 
> >qemu-img info --source 
> > driver=http,url=https://127.0.0.1/images,sslverify=off
> > 
> > This flag is mutually exclusive with the '-f' / '-F' flags.
> > 
> > Signed-off-by: Daniel P. Berrange 
> 
> > @@ -633,7 +671,20 @@ static int img_check(int argc, char **argv)
> >  return 1;
> >  }
> >  
> > -blk = img_open("image", filename, fmt, flags, true, quiet);
> > +if (image_opts) {
> > +if (fmt) {
> > +error_report("--image-opts and --format are mutually 
> > exclusive");
> > +exit(1);
> > +}
> > +opts = qemu_opts_parse_noisily(qemu_find_opts("source"),
> > +   filename, true);
> > +if (!opts) {
> > +exit(1);
> > +}
> > +blk = img_open_opts("image", opts, flags);
> > +} else {
> > +blk = img_open_file("image", filename, fmt, flags, true, quiet);
> > +}
> 
> This block is duplicated everywhere. Can you make it a function so that
> it stays a single line in each of the callers?

Yes, I've done that and its much nicer now

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [SeaBIOS] [RFC PATCH] fw/pci: Add support for mapping Intel IGD OpRegion via QEMU

[Laszlo Ersek]

On 02/02/16 05:15, Alex Williamson wrote:
> The proposed IGD OpRegion support in QEMU via vfio maps the host
> OpRegion into VM system memory at the address written to the ASL
> Storage register (0xFC).  The OpRegion contains a 16-byte signature
> followed by a 4-byte size field.  Therefore SeaBIOS can allocate a
> buffer of the typical size (8KB), this results in a matching e820
> reserved entry for the range, then write the buffer address to the ASL
> Storage register, blinking the OpRegion into the VM address space.  At
> that point SeaBIOS can validate the signature and size and remap if
> necessary.  If the OpRegion is larger than 8KB, this would result in
> any conflicting ranges being temporarily mapped with the OpRegion,
> which probably needs further discussion on what that could break.
> Other options might be to use the same algorithm with an obscenely
> sized initial buffer to make sure we do not overlap, always
> re-allocating the proper sized buffer, or perhaps we could pass the
> OpRegion itself or information about the OpRegion through fw_cfg.
> 
> With the posted kernel series[1] and QEMU series[2] (on top of Gerd's
> IGD patches[3]), this makes the OpRegion available to the VM and
> tracing shows that the guest driver does access it.
> 
> [1] https://lkml.org/lkml/2016/2/1/884
> [2] https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg00202.html
> [3] https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg00244.html
> 
> Signed-off-by: Alex Williamson 
> ---
>  src/fw/pciinit.c |   50 ++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> index c31c2fa..4f3251e 100644
> --- a/src/fw/pciinit.c
> +++ b/src/fw/pciinit.c
> @@ -257,6 +257,52 @@ static void ich9_smbus_setup(struct pci_device *dev, 
> void *arg)
>  pci_config_writeb(bdf, ICH9_SMB_HOSTC, ICH9_SMB_HOSTC_HST_EN);
>  }
>  
> +static void intel_igd_opregion_setup(struct pci_device *dev, void *arg)
> +{
> +u16 bdf = dev->bdf;
> +u32 orig;
> +void *opregion;
> +int size = 8;
> +
> +if (!CONFIG_QEMU)
> +return;
> +
> +orig = pci_config_readl(bdf, 0xFC);
> +
> +realloc:
> +opregion = malloc_high(size * 1024);
> +if (!opregion) {
> +warn_noalloc();
> +return;
> +}
> +
> +/*
> + * QEMU maps the OpRegion into system memory at the address written here,
> + * this overlaps our malloc, which marks the range e820 reserved.
> + */
> +pci_config_writel(bdf, 0xFC, cpu_to_le32((u32)opregion));
> +
> +if (memcmp(opregion, "IntelGraphicsMem", 16)) {
> +pci_config_writel(bdf, 0xFC, orig);
> +free(opregion);
> +return; /* the opregion didn't magically appear, not supported */
> +}
> +
> +if (size == le32_to_cpu(*(u32 *)(opregion + 16))) {
> +dprintf(1, "Intel IGD OpRegion enabled on %02x:%02x.%x\n",
> +pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), 
> pci_bdf_to_fn(bdf));
> +return; /* success! */
> +}
> +
> +pci_config_writel(bdf, 0xFC, orig);
> +free(opregion);
> +
> +if (size == 8) { /* try once more with a new size */
> +size = le32_to_cpu(*(u32 *)(opregion + 16));
> +goto realloc;

Is this idiomatic SeaBIOS coding style?

How about "for (;;)" -- the code has many instances -- and reworking
this last branch accordingly?

(Apologies, not a very important comment.)

Thanks
Laszlo

> +}
> +}
> +
>  static const struct pci_device_id pci_device_tbl[] = {
>  /* PIIX3/PIIX4 PCI to ISA bridge */
>  PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0,
> @@ -290,6 +336,10 @@ static const struct pci_device_id pci_device_tbl[] = {
>  PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0017, 0xff00, apple_macio_setup),
>  PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0022, 0xff00, apple_macio_setup),
>  
> +/* Intel IGD OpRegion setup */
> +PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA,
> + intel_igd_opregion_setup),
> +
>  PCI_DEVICE_END,
>  };
>  
> 
> 
> ___
> SeaBIOS mailing list
> seab...@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
> 

Re: [Qemu-devel] [libvirt] ARM KVM GICv3 Support

[Christoffer Dall]

On Fri, Jan 22, 2016 at 02:44:32PM +, Daniel P. Berrange wrote:
> On Wed, Jan 06, 2016 at 01:30:16PM +, Peter Maydell wrote:
> > On 6 January 2016 at 12:49, Andrea Bolognani  wrote:
> > > That's correct, having a QMP command that lists the values gic-version
> > > can have on the current host would be just great.
> > >
> > > If we had that, we could validate the GIC version chosen for a guest,
> > > and expose it in the capabilities XML so that higher-level tools can
> > > provide a list of choices to the user.
> > >
> > > Please note that this QMP command would have to work regardless of the
> > > machine type selected on QEMU's command line, because libvirt always
> > > runs a QEMU binary with '-M none' when probing its capabilities.
> > 
> > On the other hand, if you don't tell us the machine type you care
> > about then we can't tell you:
> >  (a) "this machine type doesn't support setting this property at all"
> >  (which applies to machines like vexpress-a15 which you can use with
> >  KVM on 32-bit hosts, and of course also to all the non-KVM models)
> 
> We have just recently merged support for registering properties against
> classes instead of object instances. There is also a proposed command
> to allow querying the list of properties against a class
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04348.html
> 
> So if we now update the machine types to register their properties against
> the class instead of object, then we can query what properties are present
> against each machine type, while still using '-M none'.
> 
> >  (b) "this machine type only supports GIC versions X and Y even if the
> >   host supports more" (this is currently only hypothetical, though,
> >   since we only have the property on 'virt'. it would only happen
> >   if in the future we needed something other than '2' or '3' or
> >   'host' I think.)
> 
> Our introspection support in QOM only allows us to say that a property
> is a particular type (int / enum / str / whatever). We don't have any
> way to expose info about what subset of possible values for a type are
> permitted. So I don't see any near term way to inform apps that the
> gic property accepts values x, y and but not z.
> 
> IMHO, we shouldn't try to overthink this. Libvirt can query the host
> to find out what GIC versions are supported and default to using the
> most recent version, on the basis that people are likely to have a
> matching QEMU. We can just rely on QEMU to report error if we pass
> it a version it doesn't support and not try to pre-emptively check
> before launch. The key is just getting the default right IMHO.
> 
This sounds fine to me.

However, not being familiar with the internals of libvirt I really can't
just what the right implementation approach here is.

As I understand we need to either:

  1) Add a QMP command that lets you ask for -M virt, if GIC version X
 is supported

  2) Just implement something in libvirt that checks what the kernel
 supports directly via the well-defined KVM interface and chooses
 the highest supported version per default.

To me it sounds like we should just go ahead with (2) and document
somehwere that if you get an error, you need to either manually change
the gic version setting in your VM definition file or upgrade QEMU.

Can someone with libvirt authority please advice whether (1) or (2) is
what we need to do?

Thanks,
-Christoffer

Re: [Qemu-devel] [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[David Woodhouse]

On Tue, 2016-02-02 at 06:42 +, Tian, Kevin wrote:
> > From: Kay, Allen M
> > Sent: Tuesday, February 02, 2016 8:04 AM
> > > 
> > > David notes in the latter commit above:
> > > 
> > > "We should be able to successfully assign graphics devices to guests too, 
> > > as
> > > long as the initial handling of stolen memory is reconfigured 
> > > appropriately."
> > > 
> > > What code is supposed to be doing that reconfiguration when a device is
> > > assigned?  Clearly we don't have it yet, making assignment of these 
> > > devices
> > > very unsafe.  It seems like vfio or IOMMU code  in the kernel needs device
> > > specific code to clear these settings to make it safe for userspace, then
> > > perhaps VM BIOS support to reallocate.  Is there any consistency across 
> > > IGD
> > > revisions for doing this?  Is there a spec?
> > > Thanks,

I haven't ever successfully assigned an IGD device to a VM myself, but
my understanding was that it *has* been done. So when the code was
changed to prevent assignment of devices afflicted by RMRRs (except USB
where we know it's OK), I just added the integrated graphics to that
same exception as USB, to preserve the status quo ante.

> I don't think stolen memory should be handled explicitly. If yes, it should be
> listed as a RMRR region so general RMRR setup will cover it. But as Allen
> pointed out, the whole RMRR becomes unnecessary if we target only secondary
> device for IGD.

Perhaps the best option is *not* to have special cases in the IOMMU
code for "those devices which can safely be assigned despite RMRRs".

Instead, let's let the device driver — or whatever — tell the IOMMU
code when it's *stopped* the firmware from (ab)using the device's DMA
facilities.

So when the USB code does the handoff thing to quiesce the firmware's
access to USB and take over in the OS, it would call the IOMMU function
to revoke the RMRR for the USB controller.

And if/when the graphics driver resets its device into a state where
it's no longer accessing stolen memory and can be assigned to a VM, it
can also call that 'RMRR revoke' function.

Likewise, if we teach device drivers to cancel whatever abominations
the HP firmware tends to set up behind the OS's back on other PCI
devices, we can cancel the RMRRs for those too.

Then the IOMMU code has a simple choice and no special cases — we can
assign a device iff it has no active RMRR.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH v2 6/8] ivshmem: generalize ivshmem_setup_interrupts

[Markus Armbruster]

Marc-André Lureau  writes:

> Hi
>
> - Original Message -
>> marcandre.lur...@redhat.com writes:
>> 
>> > From: Marc-André Lureau 
>> >
>> > Call ivshmem_setup_interrupts() with or without MSI, always allocate
>> > msi_vectors that is going to be used in all case in the following patch.
>> >
>> > Signed-off-by: Marc-André Lureau 
>> > ---
>> >  hw/misc/ivshmem.c | 26 --
>> >  1 file changed, 16 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
>> > index 5029789..c601a8a 100644
>> > --- a/hw/misc/ivshmem.c
>> > +++ b/hw/misc/ivshmem.c
>> > @@ -769,18 +769,25 @@ static void ivshmem_reset(DeviceState *d)
>> >  ivshmem_use_msix(s);
>> >  }
>> >  
>> > -static int ivshmem_setup_msi(IVShmemState * s)
>> > +static int ivshmem_setup_interrupts(IVShmemState *s)
>> >  {
>> > -if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
>> > -return -1;
>> > +/* allocate QEMU callback data for receiving interrupts */
>> > +if (s->vectors > 0) {
>> > +s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
>> > +if (!s->msi_vectors) {
>> 
>> Can't happen; s->vectors * sizeof(MSIVector) != 0.
>
> It can't happen on allocation failure?

Nope.

Compare g_malloc0() and g_try_malloc0() at
https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html

We generally use the "try" variants only for memory allocations that can
execute during operation and can be "big".

Re: [Qemu-devel] [PATCH v2 6/8] ivshmem: generalize ivshmem_setup_interrupts

[Marc-André Lureau]

Hi

- Original Message -
> Marc-André Lureau  writes:
> 
> > Hi
> >
> > - Original Message -
> >> marcandre.lur...@redhat.com writes:
> >> 
> >> > From: Marc-André Lureau 
> >> >
> >> > Call ivshmem_setup_interrupts() with or without MSI, always allocate
> >> > msi_vectors that is going to be used in all case in the following patch.
> >> >
> >> > Signed-off-by: Marc-André Lureau 
> >> > ---
> >> >  hw/misc/ivshmem.c | 26 --
> >> >  1 file changed, 16 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> >> > index 5029789..c601a8a 100644
> >> > --- a/hw/misc/ivshmem.c
> >> > +++ b/hw/misc/ivshmem.c
> >> > @@ -769,18 +769,25 @@ static void ivshmem_reset(DeviceState *d)
> >> >  ivshmem_use_msix(s);
> >> >  }
> >> >  
> >> > -static int ivshmem_setup_msi(IVShmemState * s)
> >> > +static int ivshmem_setup_interrupts(IVShmemState *s)
> >> >  {
> >> > -if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
> >> > -return -1;
> >> > +/* allocate QEMU callback data for receiving interrupts */
> >> > +if (s->vectors > 0) {
> >> > +s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
> >> > +if (!s->msi_vectors) {
> >> 
> >> Can't happen; s->vectors * sizeof(MSIVector) != 0.
> >
> > It can't happen on allocation failure?
> 
> Nope.
> 
> Compare g_malloc0() and g_try_malloc0() at
> https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html
> 
> We generally use the "try" variants only for memory allocations that can
> execute during operation and can be "big".

oops, that was too obvious ;)

thanks

Re: [Qemu-devel] [PATCH v4] Add optionrom compatible with fw_cfg DMA version

[Gerd Hoffmann]

On Di, 2016-02-02 at 12:06 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >  %.img: %.o
> > -   $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -Ttext 0 -e _start -s -o $@ 
> > $<,"  Building $(TARGET_DIR)$@")
> > +   $(call quiet-command,$(LD) $(LDFLAGS_NOPIE) -m elf_i386 -Ttext 0 -e 
> > _start -s -o $@ $<,"  Building $(TARGET_DIR)$@")
> 
> Hmm, that breaks the windows cross build:
> 
> make: Entering directory `/home/kraxel/projects/qemu/build-win32'
>   Building optionrom/linuxboot_dma.img
> i686-w64-mingw32-ld: unrecognised emulation mode: elf_i386
> Supported emulations: i386pe
> make[1]: *** [linuxboot_dma.img] Error 1

Testing shows two more problems:

(1) initrd loading is broken, kernel complains it finds only gibberish:

[0.934582] Unpacking initramfs...
[1.166983] Initramfs unpacking failed: junk in compressed archive
[1.168458] Freeing initrd memory: 32812k freed

(2) going back to non-dma boot via -M pc-$old doesn't work, appearently
fw_cfg dma is enabled even for old machine types.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] hw/pci: ensure that only PCI/PCIe bridges can be attached to pxb/pxb-pcie devices

[Marcel Apfelbaum]

On 01/19/2016 10:04 AM, Marcel Apfelbaum wrote:

On 01/18/2016 08:16 PM, Laszlo Ersek wrote:

On 01/18/16 19:08, Peter Maydell wrote:

On 18 January 2016 at 15:27, Marcel Apfelbaum  wrote:

PCI devices can't be plugged directly into PCI extra root bridges
because their resources can't be computed by firmware before the ACPI
tables are loaded.

Signed-off-by: Marcel Apfelbaum 
---

Hi,

This patch follows the discussion:
https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01484.html


Is it definitely the case that no current working command lines plug
PCI devices directly into these things (including on platforms that
don't have anything to do with ACPI at all) ?


Hi,

The PXB devices can work only on ACPI based platforms, but currently work only 
on PC Machines.
So for other platforms are out of the scope.

I understand the issue in putting it generic PCI code, but:
  - Non ACPI platforms (implemented in QEMU) do not support extra PCI host 
bridges (at least yet)
  - Even when extra host bridges will be supported, there are are several ways 
to implement it
and most of them will not require their pxbs to have a parent_device. The 
presence of a parent device
is a pretty solid lead that is a "snooping bridge" and as far as I know is 
only typical for the existing solution.

Now the explanation of the issue we want to solve:
  - pxb (PCI expander bridge) - it already has an internal bridge, using
-device pxb,bus80,id=pxb1 -device e1000,bus=pxb1
will land the device on a built-in pci bridge.
- An incorrect command-line will result in a non working device without the 
proposed patch.
  - pxb-pcie (PCIe Root Complex) - it does not have an internal bridge and 
trying to use:
 -device pxb-pcie,bus80,id=pxb1 -device e1000,bus=pxb1
will fail.

This patch ensures non of that can happen.

Last word:
I did consider another option, adding a "bridges-only" property (defaulted to 
false) to PCIBus class
and leverage the fact that the pxb internal buses derive from it(and it can be 
set to true).

Then we can simply check PCI_BUS_CLASS(bus)->bridges-only but it seemed a 
little odd since we
don't have that limitation on the real world.
I am not against it, if it is preferred I'll submit a new patch.


Ping. Can we merge this patch?

Thanks,
Marcel






No clue about "pxb-pcie", but re: "pxb", the documentation and examples
by Marcel (see: "docs/pci_expander_bridge.txt") will certainly continue
working, with this patch place. And, that text file is authoritative for
pxb, since Marcel (et al) wrote the code directly for the purposes
described in the txt.


and that reminds me I need to update the doc for pxb-pcie, thanks Laszlo!
Marcel




(But I'll let Marcel answer too! :))

Thanks
Laszlo

Re: [Qemu-devel] [PATCH v4 0/3] target-arm: Add a few more S2 MMU input checks

[Peter Maydell]

On 27 January 2016 at 22:16, Edgar E. Iglesias  wrote:
> From: "Edgar E. Iglesias" 
>
> This adds the inputsize > pamax check and also fixes the
> startlevel checks to apply to the 64bit translations.
>
> Comments welcome!

Thanks, applied to target-arm.next.

-- PMM

Re: [Qemu-devel] [libvirt] ARM KVM GICv3 Support

[Daniel P. Berrange]

On Tue, Feb 02, 2016 at 12:49:33PM +0100, Christoffer Dall wrote:
> On Fri, Jan 22, 2016 at 02:44:32PM +, Daniel P. Berrange wrote:
> > On Wed, Jan 06, 2016 at 01:30:16PM +, Peter Maydell wrote:
> > > On 6 January 2016 at 12:49, Andrea Bolognani  wrote:
> > > > That's correct, having a QMP command that lists the values gic-version
> > > > can have on the current host would be just great.
> > > >
> > > > If we had that, we could validate the GIC version chosen for a guest,
> > > > and expose it in the capabilities XML so that higher-level tools can
> > > > provide a list of choices to the user.
> > > >
> > > > Please note that this QMP command would have to work regardless of the
> > > > machine type selected on QEMU's command line, because libvirt always
> > > > runs a QEMU binary with '-M none' when probing its capabilities.
> > > 
> > > On the other hand, if you don't tell us the machine type you care
> > > about then we can't tell you:
> > >  (a) "this machine type doesn't support setting this property at all"
> > >  (which applies to machines like vexpress-a15 which you can use with
> > >  KVM on 32-bit hosts, and of course also to all the non-KVM models)
> > 
> > We have just recently merged support for registering properties against
> > classes instead of object instances. There is also a proposed command
> > to allow querying the list of properties against a class
> > 
> >   https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04348.html
> > 
> > So if we now update the machine types to register their properties against
> > the class instead of object, then we can query what properties are present
> > against each machine type, while still using '-M none'.
> > 
> > >  (b) "this machine type only supports GIC versions X and Y even if the
> > >   host supports more" (this is currently only hypothetical, though,
> > >   since we only have the property on 'virt'. it would only happen
> > >   if in the future we needed something other than '2' or '3' or
> > >   'host' I think.)
> > 
> > Our introspection support in QOM only allows us to say that a property
> > is a particular type (int / enum / str / whatever). We don't have any
> > way to expose info about what subset of possible values for a type are
> > permitted. So I don't see any near term way to inform apps that the
> > gic property accepts values x, y and but not z.
> > 
> > IMHO, we shouldn't try to overthink this. Libvirt can query the host
> > to find out what GIC versions are supported and default to using the
> > most recent version, on the basis that people are likely to have a
> > matching QEMU. We can just rely on QEMU to report error if we pass
> > it a version it doesn't support and not try to pre-emptively check
> > before launch. The key is just getting the default right IMHO.
> > 
> This sounds fine to me.
> 
> However, not being familiar with the internals of libvirt I really can't
> just what the right implementation approach here is.
> 
> As I understand we need to either:
> 
>   1) Add a QMP command that lets you ask for -M virt, if GIC version X
>  is supported
> 
>   2) Just implement something in libvirt that checks what the kernel
>  supports directly via the well-defined KVM interface and chooses
>  the highest supported version per default.
> 
> To me it sounds like we should just go ahead with (2) and document
> somehwere that if you get an error, you need to either manually change
> the gic version setting in your VM definition file or upgrade QEMU.
> 
> Can someone with libvirt authority please advice whether (1) or (2) is
> what we need to do?

IMHO we should just go for 2.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH v3 1/2] cpu: Add callback to check architectural watchpoint match

[Peter Maydell]

On 31 January 2016 at 16:15, Sergey Fedorov  wrote:
> When QEMU watchpoint matches, that is not definitely an architectural
> watchpoint match yet. If it is a stop-before-access watchpoint then that
> is hardly possible to ignore it after throwing a TCG exception.
>
> A special callback is introduced to check for architectural watchpoint
> match before raising a TCG exception.
>
> Signed-off-by: Sergey Fedorov 

This looks OK to me, but there's one QOM CPU style question
I'd like Andreas's view on.

> @@ -2024,6 +2024,7 @@ static const MemoryRegionOps notdirty_mem_ops = {
>  static void check_watchpoint(int offset, int len, MemTxAttrs attrs, int 
> flags)
>  {
>  CPUState *cpu = current_cpu;
> +CPUClass *cc = CPU_GET_CLASS(cpu);
>  CPUArchState *env = cpu->env_ptr;
>  target_ulong pc, cs_base;
>  target_ulong vaddr;
> @@ -2049,6 +2050,11 @@ static void check_watchpoint(int offset, int len, 
> MemTxAttrs attrs, int flags)
>  wp->hitaddr = vaddr;
>  wp->hitattrs = attrs;
>  if (!cpu->watchpoint_hit) {
> +if (wp->flags & BP_CPU &&
> +!cc->debug_check_watchpoint(cpu, wp)) {

At least some of the QOM CPU methods have wrapper functions
(eg cpu_set_pc(), cpu_unaligned_access()) that just bundle up
the CPU_GET_CLASS and method invocation). Should new methods
like the debug_check_watchpoint() introduced by this patch have
that kind of wrapper function, or is it optional?

(There also seems to be a mix of "implement default/common
behaviour in a common method implementation" vs "implement
it in the wrapper function if the method pointer is NULL".
I think the former, as done in this patch, is probably nicer
but again would defer to Andreas.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH v12 24/36] cpu: Convert CpuInfo into flat union

[James Hogan]

Hi Eric,

On 18 November 2015 at 08:52, Eric Blake  wrote:
> +# An enumeration of cpu types that enable additional information during
> +# @query-cpus.
> +#
> +# Since: 2.6
> +##
> +{ 'enum': 'CpuInfoArch',
> +  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
> +

...

> +##
> +# @CpuInfo:
> +#
> +# Information about a virtual CPU
> +#
> +# Since: 0.14.0
> +##
> +{ 'union': 'CpuInfo', 'base': 'CpuInfoBase', 'discriminator': 'arch',
> +  'data': { 'x86': 'CpuInfoX86',
> +'sparc': 'CpuInfoSparc',
> +'ppc': 'CpuInfoPpc',
> +'mips': 'CpuInfoMips',

This is causing compilation issues on MIPS, because gcc bizarrely
defines mips=1:

$ mips-img-linux-gnu-gcc -dM -E - value->u.sparc->pc = env->pc;
info->value->u.sparc->npc = env->npc;
#elif defined(TARGET_MIPS)
-info->value->arch = CPU_INFO_ARCH_MIPS;
-info->value->u.mips = g_new0(CpuInfoMIPS, 1);
-info->value->u.mips->PC = env->active_tc.PC;
+info->value->arch = CPU_INFO_ARCH_MIPSARCH;
+info->value->u.mipsarch = g_new0(CpuInfoMIPS, 1);
+info->value->u.mipsarch->PC = env->active_tc.PC;
#elif defined(TARGET_TRICORE)
info->value->arch = CPU_INFO_ARCH_TRICORE;
info->value->u.tricore = g_new0(CpuInfoTricore, 1);
diff --git a/hmp.c b/hmp.c
index 54f2620690b1..e4cba874352e 100644
--- a/hmp.c
+++ b/hmp.c
@@ -321,8 +321,8 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)
monitor_printf(mon, " pc=0x%016" PRIx64, cpu->value->u.sparc->pc);
monitor_printf(mon, " npc=0x%016" PRIx64, cpu->value->u.sparc->npc);
break;
-case CPU_INFO_ARCH_MIPS:
-monitor_printf(mon, " PC=0x%016" PRIx64, cpu->value->u.mips->PC);
+case CPU_INFO_ARCH_MIPSARCH:
+monitor_printf(mon, " PC=0x%016" PRIx64,
cpu->value->u.mipsarch->PC);
break;
case CPU_INFO_ARCH_TRICORE:
monitor_printf(mon, " PC=0x%016" PRIx64, cpu->value->u.tricore->PC);
diff --git a/qapi-schema.json b/qapi-schema.json
index 8d04897922ec..c72e0615e074 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -750,7 +750,7 @@
# Since: 2.6
##
{ 'enum': 'CpuInfoArch',
-  'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
+  'data': ['x86', 'sparc', 'ppc', 'mipsarch', 'tricore', 'other' ] }

##
# @CpuInfoBase:
@@ -791,7 +791,7 @@
  'data': { 'x86': 'CpuInfoX86',
'sparc': 'CpuInfoSPARC',
'ppc': 'CpuInfoPPC',
-'mips': 'CpuInfoMIPS',
+'mipsarch': 'CpuInfoMIPS',
'tricore': 'CpuInfoTricore',
'other': 'CpuInfoOther' } }

Cheers
James

Re: [Qemu-devel] [PATCH v3 0/4] Netfilter: Add each netdev a default filter

[Hailiang Zhang]

Hi Hongyang,

On 2016/2/2 11:11, Yang Hongyang wrote:

If we have to add a default filter, then I have a suggestion only
for this series:
1. Add a nop filter. filter-nop.c


I'm not quite sure if we really need to add a new type 'nop' filter,
because it is only a special case for buffer-filter, where
the process of releasing packets is not controlled by the timer.
(Maybe we can use this to distinguish if the buffer-filter is default or not.
If a buffer-filter is not attached with a timer, then it could be considered as
the default filter)


2. Add a "default-filter=xxx" property to -netdev, if not specified,
default to nop.



Hmm, yes, Jason also suggested that, export an option for the netdev
to control the type of default filter. I have added a 'TODO' tag in
patch 4, we will do that in the future.

Thanks,
Hailiang



On 02/01/2016 08:01 PM, zhanghailiang wrote:

This series is a prerequisite for COLO, here we add each netdev
a default buffer filter, it is disabled by default, and has
no side effect for delivering packets in net layer.

Note: this series is based on patch
 '[PATCH v2] net/filter: Fix the output information for command 'info 
network'

v3:
  - Drop patch '[PATCH RFC v2 2/5] vl: Make object_create() public'
  - Use object_new_with_props() instead of object_create() (Daniel)
v2:
  - Drop the patch net/filter: prevent the default filter to be deleted' (Jason)
  - Re-implement netdev_add_filter() by re-using object_object() (Jason)
  - Send patch 'net/filter: Fix the output information for command 'info
network' as an independent one. (Jason)

zhanghailiang (4):
   net/filter: Add a 'status' property for filter object
   net/filter: Introduce a helper to add a filter to the netdev
   filter-buffer: Accept zero interval
   net/filter: Add a default filter to each netdev

  include/net/filter.h | 12 
  net/filter-buffer.c  | 10 ---
  net/filter.c | 79 
  net/net.c| 23 +++
  4 files changed, 114 insertions(+), 10 deletions(-)

Re: [Qemu-devel] [PATCH v4 7/7] mips/kvm: Support MSA in MIPS KVM guests

[James Hogan]

Hi Leon,

On Tue, Feb 02, 2016 at 09:58:46AM +, Leon Alrae wrote:
> Hi James,
> 
> On 18/12/15 10:46, James Hogan wrote:
> > @@ -611,17 +664,51 @@ static int kvm_mips_get_fpu_registers(CPUState *cs)
> >  restore_flush_mode(env);
> >  }
> >  
> > -/* Floating point registers */
> > -for (i = 0; i < 32; ++i) {
> > -if (env->CP0_Status & (1 << CP0St_FR)) {
> > -err = kvm_mips_get_one_ureg64(cs, KVM_REG_MIPS_FPR_64(i),
> > -  &env->active_fpu.fpr[i].d);
> > -} else {
> > -err = kvm_mips_get_one_ureg(cs, KVM_REG_MIPS_FPR_32(i),
> > -  
> > &env->active_fpu.fpr[i].w[FP_ENDIAN_IDX]);
> > +/*
> > + * FPU register state is a subset of MSA vector state, so don't 
> > save FPU
> > + * registers if we're emulating a CPU with MSA.
> > + */
> > +if (!(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
> > +/* Floating point registers */
> > +for (i = 0; i < 32; ++i) {
> > +if (env->CP0_Status & (1 << CP0St_FR)) {
> > +err = kvm_mips_get_one_ureg64(cs, 
> > KVM_REG_MIPS_FPR_64(i),
> > +  
> > &env->active_fpu.fpr[i].d);
> > +} else {
> > +err = kvm_mips_get_one_ureg(cs, KVM_REG_MIPS_FPR_32(i),
> > +
> > &env->active_fpu.fpr[i].w[FP_ENDIAN_IDX]);
> > +}
> > +if (err < 0) {
> > +DPRINTF("%s: Failed to get FPR%u (%d)\n", __func__, i, 
> > err);
> > +ret = err;
> > +}
> >  }
> > +}
> > +}
> > +
> > +/* Only get MSA state if we're emulating a CPU with MSA */
> > +if (env->CP0_Config3 & (1 << CP0C3_MSAP)) {
> > +/* MSA Control Registers */
> > +err = kvm_mips_get_one_reg(cs, KVM_REG_MIPS_MSA_IR,
> > +   &env->msair);
> > +if (err < 0) {
> > +DPRINTF("%s: Failed to get MSA_IR (%d)\n", __func__, err);
> > +ret = err;
> > +}
> > +err = kvm_mips_get_one_reg(cs, KVM_REG_MIPS_MSA_CSR,
> > +   &env->active_tc.msacsr);
> > +if (err < 0) {
> > +DPRINTF("%s: Failed to get MSA_CSR (%d)\n", __func__, err);
> > +ret = err;
> > +}
> 
> Shouldn't MSA's float_status (i.e. msa_fp_status) be restored to reflect
> MSACSR?

Yes, it probably should. Good spot!

I can use restore_msa_fp_status(env); here, and actually the FP one
above (in previous patch) can change to restore_fp_status(env); too,
since it does the same thing.

I've rebased and resolved the uint64 thing too, would you like a resend?

Thanks
James


signature.asc
Description: Digital signature

[Qemu-devel] [PULL 1/8] ivshmem: no need for opaque argument

[marcandre . lureau]

From: Marc-André Lureau 

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 hw/misc/ivshmem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index d5c89ae..358df24 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -350,11 +350,11 @@ static void ivshmem_vector_poll(PCIDevice *dev,
 }
 }
 
-static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier 
*n,
+static CharDriverState* create_eventfd_chr_device(IVShmemState *s,
+  EventNotifier *n,
   int vector)
 {
 /* create a event character device based on the passed eventfd */
-IVShmemState *s = opaque;
 PCIDevice *pdev = PCI_DEVICE(s);
 int eventfd = event_notifier_get_fd(n);
 CharDriverState *chr;
-- 
2.5.0

[Qemu-devel] [PULL 0/8] Ivshmem patches

[marcandre . lureau]

From: Marc-André Lureau 

The following changes since commit 10ae9d76388e3f4a31f6a1475b5e2d1f28404a10:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160201' into 
staging (2016-02-02 09:13:10 +)

are available in the git repository at:

  g...@github.com:elmarco/qemu.git tags/ivshmem-pull-request

for you to fetch changes up to 6db262557260129883c5aa47d47556f4075a3e5c:

  char: remove qemu_chr_open_eventfd (2016-02-02 13:28:58 +0100)





Marc-André Lureau (8):
  ivshmem: no need for opaque argument
  ivshmem: remove redundant assignment, fix crash with msi=off
  ivshmem-test: leak fixes
  libqos: remove some leaks
  ivshmem-test: test both msi & irq cases
  ivshmem: generalize ivshmem_setup_interrupts
  ivshmem: use a single eventfd callback, get rid of CharDriver
  char: remove qemu_chr_open_eventfd

 hw/misc/ivshmem.c | 81 +++
 include/sysemu/char.h |  3 --
 qemu-char.c   | 13 -
 tests/ivshmem-test.c  | 81 ++-
 tests/libqos/pci.c|  2 ++
 5 files changed, 86 insertions(+), 94 deletions(-)

-- 
2.5.0

[Qemu-devel] [PULL 5/8] ivshmem-test: test both msi & irq cases

[marcandre . lureau]

From: Marc-André Lureau 

Recent commit 660c97ee introduced a regression in irq case, make
sure this code path is also tested.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 tests/ivshmem-test.c | 53 
 1 file changed, 37 insertions(+), 16 deletions(-)

diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
index d544d5e..705fece 100644
--- a/tests/ivshmem-test.c
+++ b/tests/ivshmem-test.c
@@ -277,18 +277,18 @@ static void *server_thread(void *data)
 return NULL;
 }
 
-static void setup_vm_with_server(IVState *s, int nvectors)
+static void setup_vm_with_server(IVState *s, int nvectors, bool msi)
 {
 char *cmd = g_strdup_printf("-chardev socket,id=chr0,path=%s,nowait "
-"-device 
ivshmem,size=1M,chardev=chr0,vectors=%d",
-tmpserver, nvectors);
+"-device 
ivshmem,size=1M,chardev=chr0,vectors=%d,msi=%s",
+tmpserver, nvectors, msi ? "true" : "false");
 
-setup_vm_cmd(s, cmd, true);
+setup_vm_cmd(s, cmd, msi);
 
 g_free(cmd);
 }
 
-static void test_ivshmem_server(void)
+static void test_ivshmem_server(bool msi)
 {
 IVState state1, state2, *s1, *s2;
 ServerThread thread;
@@ -306,9 +306,9 @@ static void test_ivshmem_server(void)
 ret = ivshmem_server_start(&server);
 g_assert_cmpint(ret, ==, 0);
 
-setup_vm_with_server(&state1, nvectors);
+setup_vm_with_server(&state1, nvectors, msi);
 s1 = &state1;
-setup_vm_with_server(&state2, nvectors);
+setup_vm_with_server(&state2, nvectors, msi);
 s2 = &state2;
 
 g_assert_cmpuint(in_reg(s1, IVPOSITION), ==, 0x);
@@ -338,27 +338,37 @@ static void test_ivshmem_server(void)
 g_assert_cmpuint(vm1, !=, vm2);
 
 global_qtest = s1->qtest;
-ret = qpci_msix_table_size(s1->dev);
-g_assert_cmpuint(ret, ==, nvectors);
+if (msi) {
+ret = qpci_msix_table_size(s1->dev);
+g_assert_cmpuint(ret, ==, nvectors);
+}
 
 /* ping vm2 -> vm1 */
-ret = qpci_msix_pending(s1->dev, 0);
-g_assert_cmpuint(ret, ==, 0);
+if (msi) {
+ret = qpci_msix_pending(s1->dev, 0);
+g_assert_cmpuint(ret, ==, 0);
+} else {
+out_reg(s1, INTRSTATUS, 0);
+}
 out_reg(s2, DOORBELL, vm1 << 16);
 do {
 g_usleep(1);
-ret = qpci_msix_pending(s1->dev, 0);
+ret = msi ? qpci_msix_pending(s1->dev, 0) : in_reg(s1, INTRSTATUS);
 } while (ret == 0 && g_get_monotonic_time() < end_time);
 g_assert_cmpuint(ret, !=, 0);
 
 /* ping vm1 -> vm2 */
 global_qtest = s2->qtest;
-ret = qpci_msix_pending(s2->dev, 0);
-g_assert_cmpuint(ret, ==, 0);
+if (msi) {
+ret = qpci_msix_pending(s2->dev, 0);
+g_assert_cmpuint(ret, ==, 0);
+} else {
+out_reg(s2, INTRSTATUS, 0);
+}
 out_reg(s1, DOORBELL, vm2 << 16);
 do {
 g_usleep(1);
-ret = qpci_msix_pending(s2->dev, 0);
+ret = msi ? qpci_msix_pending(s2->dev, 0) : in_reg(s2, INTRSTATUS);
 } while (ret == 0 && g_get_monotonic_time() < end_time);
 g_assert_cmpuint(ret, !=, 0);
 
@@ -376,6 +386,16 @@ static void test_ivshmem_server(void)
 close(thread.pipe[0]);
 }
 
+static void test_ivshmem_server_msi(void)
+{
+test_ivshmem_server(true);
+}
+
+static void test_ivshmem_server_irq(void)
+{
+test_ivshmem_server(false);
+}
+
 #define PCI_SLOT_HP 0x06
 
 static void test_ivshmem_hotplug(void)
@@ -489,7 +509,8 @@ int main(int argc, char **argv)
 qtest_add_func("/ivshmem/memdev", test_ivshmem_memdev);
 if (g_test_slow()) {
 qtest_add_func("/ivshmem/pair", test_ivshmem_pair);
-qtest_add_func("/ivshmem/server", test_ivshmem_server);
+qtest_add_func("/ivshmem/server-msi", test_ivshmem_server_msi);
+qtest_add_func("/ivshmem/server-irq", test_ivshmem_server_irq);
 }
 
 ret = g_test_run();
-- 
2.5.0

[Qemu-devel] [PULL 6/8] ivshmem: generalize ivshmem_setup_interrupts

[marcandre . lureau]

From: Marc-André Lureau 

Call ivshmem_setup_interrupts() with or without MSI, always allocate
msi_vectors that is going to be used in all case in the following patch.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 hw/misc/ivshmem.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 5029789..5f33149 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -769,18 +769,20 @@ static void ivshmem_reset(DeviceState *d)
 ivshmem_use_msix(s);
 }
 
-static int ivshmem_setup_msi(IVShmemState * s)
+static int ivshmem_setup_interrupts(IVShmemState *s)
 {
-if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
-return -1;
-}
+/* allocate QEMU callback data for receiving interrupts */
+s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
 
-IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
+if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
+if (msix_init_exclusive_bar(PCI_DEVICE(s), s->vectors, 1)) {
+return -1;
+}
 
-/* allocate QEMU char devices for receiving interrupts */
-s->msi_vectors = g_malloc0(s->vectors * sizeof(MSIVector));
+IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
+ivshmem_use_msix(s);
+}
 
-ivshmem_use_msix(s);
 return 0;
 }
 
@@ -947,9 +949,8 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 IVSHMEM_DPRINTF("using shared memory server (socket = %s)\n",
 s->server_chr->filename);
 
-if (ivshmem_has_feature(s, IVSHMEM_MSI) &&
-ivshmem_setup_msi(s)) {
-error_setg(errp, "msix initialization failed");
+if (ivshmem_setup_interrupts(s) < 0) {
+error_setg(errp, "failed to initialize interrupts");
 return;
 }
 
-- 
2.5.0

[Qemu-devel] [PULL 4/8] libqos: remove some leaks

[marcandre . lureau]

From: Marc-André Lureau 

qpci_device_find() returns allocated data, don't leak it.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 tests/libqos/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c
index 4e630c2..80b1a21 100644
--- a/tests/libqos/pci.c
+++ b/tests/libqos/pci.c
@@ -34,11 +34,13 @@ void qpci_device_foreach(QPCIBus *bus, int vendor_id, int 
device_id,
 
 if (vendor_id != -1 &&
 qpci_config_readw(dev, PCI_VENDOR_ID) != vendor_id) {
+g_free(dev);
 continue;
 }
 
 if (device_id != -1 &&
 qpci_config_readw(dev, PCI_DEVICE_ID) != device_id) {
+g_free(dev);
 continue;
 }
 
-- 
2.5.0

[Qemu-devel] [PULL 3/8] ivshmem-test: leak fixes

[marcandre . lureau]

From: Marc-André Lureau 

Add a cleanup_vm() function to free QPCIDevice & QPCIBus when cleaning
up the IVState.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 tests/ivshmem-test.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
index 03c7b96..d544d5e 100644
--- a/tests/ivshmem-test.c
+++ b/tests/ivshmem-test.c
@@ -34,12 +34,10 @@ static void save_fn(QPCIDevice *dev, int devfn, void *data)
 *pdev = dev;
 }
 
-static QPCIDevice *get_device(void)
+static QPCIDevice *get_device(QPCIBus *pcibus)
 {
 QPCIDevice *dev;
-QPCIBus *pcibus;
 
-pcibus = qpci_init_pc();
 dev = NULL;
 qpci_device_foreach(pcibus, 0x1af4, 0x1110, save_fn, &dev);
 g_assert(dev != NULL);
@@ -50,6 +48,7 @@ static QPCIDevice *get_device(void)
 typedef struct _IVState {
 QTestState *qtest;
 void *reg_base, *mem_base;
+QPCIBus *pcibus;
 QPCIDevice *dev;
 } IVState;
 
@@ -100,13 +99,20 @@ static inline void out_reg(IVState *s, enum Reg reg, 
unsigned v)
 global_qtest = qtest;
 }
 
+static void cleanup_vm(IVState *s)
+{
+g_free(s->dev);
+qpci_free_pc(s->pcibus);
+qtest_quit(s->qtest);
+}
+
 static void setup_vm_cmd(IVState *s, const char *cmd, bool msix)
 {
 uint64_t barsize;
 
 s->qtest = qtest_start(cmd);
-
-s->dev = get_device();
+s->pcibus = qpci_init_pc();
+s->dev = get_device(s->pcibus);
 
 /* FIXME: other bar order fails, mappings changes */
 s->mem_base = qpci_iomap(s->dev, 2, &barsize);
@@ -173,7 +179,7 @@ static void test_ivshmem_single(void)
 g_assert_cmpuint(data[i], ==, i);
 }
 
-qtest_quit(s->qtest);
+cleanup_vm(s);
 }
 
 static void test_ivshmem_pair(void)
@@ -218,8 +224,8 @@ static void test_ivshmem_pair(void)
 g_assert_cmpuint(data[i], ==, 0x44);
 }
 
-qtest_quit(s1->qtest);
-qtest_quit(s2->qtest);
+cleanup_vm(s1);
+cleanup_vm(s2);
 g_free(data);
 }
 
@@ -356,8 +362,8 @@ static void test_ivshmem_server(void)
 } while (ret == 0 && g_get_monotonic_time() < end_time);
 g_assert_cmpuint(ret, !=, 0);
 
-qtest_quit(s2->qtest);
-qtest_quit(s1->qtest);
+cleanup_vm(s2);
+cleanup_vm(s1);
 
 if (qemu_write_full(thread.pipe[1], "q", 1) != 1) {
 g_error("qemu_write_full: %s", g_strerror(errno));
@@ -395,7 +401,7 @@ static void test_ivshmem_memdev(void)
 setup_vm_cmd(&state, "-object memory-backend-ram,size=1M,id=mb1"
  " -device ivshmem,x-memdev=mb1", false);
 
-qtest_quit(state.qtest);
+cleanup_vm(&state);
 }
 
 static void cleanup(void)
-- 
2.5.0

[Qemu-devel] [PULL 7/8] ivshmem: use a single eventfd callback, get rid of CharDriver

[marcandre . lureau]

From: Marc-André Lureau 

Simplify the interrupt handling by having a single callback on irq&msi
cases. Remove usage of CharDriver, replace it with
qemu_set_fd_handler(). Use event_notifier_test_and_clear() to read the
eventfd.

Before this patch, ivshmem writes the first byte received to
s->intrstatus. But ivshmem_device_spec.txt says "The status register is
set to 1 when an interrupt occurs." Fortunately, the byte usually comes
from another ivshmem device, and those always write 1.

After this commit, follows the specification, set to 1 when an interrupt
occurs.

Signed-off-by: Marc-André Lureau 
Acked-by: Markus Armbruster 
---
 hw/misc/ivshmem.c | 55 ++-
 1 file changed, 18 insertions(+), 37 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 5f33149..48b7a34 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -263,15 +263,6 @@ static const MemoryRegionOps ivshmem_mmio_ops = {
 },
 };
 
-static void ivshmem_receive(void *opaque, const uint8_t *buf, int size)
-{
-IVShmemState *s = opaque;
-
-IVSHMEM_DPRINTF("ivshmem_receive 0x%02x size: %d\n", *buf, size);
-
-ivshmem_IntrStatus_write(s, *buf);
-}
-
 static int ivshmem_can_receive(void * opaque)
 {
 return sizeof(int64_t);
@@ -282,15 +273,24 @@ static void ivshmem_event(void *opaque, int event)
 IVSHMEM_DPRINTF("ivshmem_event %d\n", event);
 }
 
-static void fake_irqfd(void *opaque, const uint8_t *buf, int size) {
-
+static void ivshmem_vector_notify(void *opaque)
+{
 MSIVector *entry = opaque;
 PCIDevice *pdev = entry->pdev;
 IVShmemState *s = IVSHMEM(pdev);
 int vector = entry - s->msi_vectors;
+EventNotifier *n = &s->peers[s->vm_id].eventfds[vector];
+
+if (!event_notifier_test_and_clear(n)) {
+return;
+}
 
 IVSHMEM_DPRINTF("interrupt on vector %p %d\n", pdev, vector);
-msix_notify(pdev, vector);
+if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
+msix_notify(pdev, vector);
+} else {
+ivshmem_IntrStatus_write(s, 1);
+}
 }
 
 static int ivshmem_vector_unmask(PCIDevice *dev, unsigned vector,
@@ -350,35 +350,16 @@ static void ivshmem_vector_poll(PCIDevice *dev,
 }
 }
 
-static CharDriverState* create_eventfd_chr_device(IVShmemState *s,
-  EventNotifier *n,
-  int vector)
+static void watch_vector_notifier(IVShmemState *s, EventNotifier *n,
+ int vector)
 {
-/* create a event character device based on the passed eventfd */
 int eventfd = event_notifier_get_fd(n);
-CharDriverState *chr;
-
-chr = qemu_chr_open_eventfd(eventfd);
-
-if (chr == NULL) {
-error_report("creating chardriver for eventfd %d failed", eventfd);
-return NULL;
-}
-qemu_chr_fe_claim_no_fail(chr);
 
 /* if MSI is supported we need multiple interrupts */
-if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
-s->msi_vectors[vector].pdev = PCI_DEVICE(s);
-
-qemu_chr_add_handlers(chr, ivshmem_can_receive, fake_irqfd,
-  ivshmem_event, &s->msi_vectors[vector]);
-} else {
-qemu_chr_add_handlers(chr, ivshmem_can_receive, ivshmem_receive,
-  ivshmem_event, s);
-}
-
-return chr;
+s->msi_vectors[vector].pdev = PCI_DEVICE(s);
 
+qemu_set_fd_handler(eventfd, ivshmem_vector_notify,
+NULL, &s->msi_vectors[vector]);
 }
 
 static int check_shm_size(IVShmemState *s, int fd, Error **errp)
@@ -588,7 +569,7 @@ static void setup_interrupt(IVShmemState *s, int vector)
 
 if (!with_irqfd) {
 IVSHMEM_DPRINTF("with eventfd");
-s->eventfd_chr[vector] = create_eventfd_chr_device(s, n, vector);
+watch_vector_notifier(s, n, vector);
 } else if (msix_enabled(pdev)) {
 IVSHMEM_DPRINTF("with irqfd");
 if (ivshmem_add_kvm_msi_virq(s, vector) < 0) {
-- 
2.5.0

[Qemu-devel] [PULL 2/8] ivshmem: remove redundant assignment, fix crash with msi=off

[marcandre . lureau]

From: Marc-André Lureau 

Fix crash when msi=false introduced in 660c97ee (msi_vectors is NULL in
this case)

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 hw/misc/ivshmem.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 358df24..5029789 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -355,12 +355,9 @@ static CharDriverState* 
create_eventfd_chr_device(IVShmemState *s,
   int vector)
 {
 /* create a event character device based on the passed eventfd */
-PCIDevice *pdev = PCI_DEVICE(s);
 int eventfd = event_notifier_get_fd(n);
 CharDriverState *chr;
 
-s->msi_vectors[vector].pdev = pdev;
-
 chr = qemu_chr_open_eventfd(eventfd);
 
 if (chr == NULL) {
-- 
2.5.0

[Qemu-devel] [PULL 8/8] char: remove qemu_chr_open_eventfd

[marcandre . lureau]

From: Marc-André Lureau 

Broken since d0d7708ba29cbc, since the backend is NULL.

And now no longer needed by ivshmem.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Markus Armbruster 
---
 include/sysemu/char.h |  3 ---
 qemu-char.c   | 13 -
 2 files changed, 16 deletions(-)

diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index 598dd2b..e035d1c 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -360,9 +360,6 @@ void register_char_driver(const char *name, 
ChardevBackendKind kind,
 CharDriverState *(*create)(const char *id, ChardevBackend *backend,
ChardevReturn *ret, Error **errp));
 
-/* add an eventfd to the qemu devices that are polled */
-CharDriverState *qemu_chr_open_eventfd(int eventfd);
-
 extern int term_escape_char;
 
 CharDriverState *qemu_char_get_next_serial(void);
diff --git a/qemu-char.c b/qemu-char.c
index ca53e8c..1605b30 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2838,19 +2838,6 @@ static int tcp_chr_sync_read(CharDriverState *chr, const 
uint8_t *buf, int len)
 return size;
 }
 
-#ifndef _WIN32
-CharDriverState *qemu_chr_open_eventfd(int eventfd)
-{
-CharDriverState *chr = qemu_chr_open_fd(eventfd, eventfd, NULL, NULL);
-
-if (chr) {
-chr->avail_connections = 1;
-}
-
-return chr;
-}
-#endif
-
 static void tcp_chr_connect(void *opaque)
 {
 CharDriverState *chr = opaque;
-- 
2.5.0

Re: [Qemu-devel] [PATCH v2 2/5] qapi: switch x-input-send-event from console to device+head

[Markus Armbruster]

Gerd Hoffmann  writes:

> Use display device qdev id and head number instead of console index to
> specify the QemuConsole.  This makes things consistent with input
> devices (for input routing) and vnc server configuration, which both use
> display and head too.
>
> Signed-off-by: Gerd Hoffmann 
> Reviewed-by: Daniel P. Berrange 
> ---
>  qapi-schema.json | 32 +---
>  qmp-commands.hx  | 17 +
>  ui/input.c   | 15 ++-
>  3 files changed, 36 insertions(+), 28 deletions(-)
>
[...]
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index db072a6..9925fc1 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -4614,8 +4614,9 @@ Send input event to guest.
>  
>  Arguments:
>  
> -- "console": console index. (json-int, optional)
> -- "events": list of input events.
> +- "device": display device (json-str, optional)

Missed this in v1, sorry: json-string

> +- "head": display head (json-int, optional)
> +- "events": list of input events
>  
>  The consoles are visible in the qom tree, under
>  /backend/console[$index]. They have a device link and head property, so
[...]

[Qemu-devel] [PULL 0/1] nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file

[Gerd Hoffmann]

  Hi,

Here comes fwcfg patch queue, a bit shorter than planned as I've ran
into issues while verifying linuxboot_dma fw_cfg patches.

please pull,
  Gerd

The following changes since commit 10ae9d76388e3f4a31f6a1475b5e2d1f28404a10:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160201' into 
staging (2016-02-02 09:13:10 +)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-fwcfg-20160202-1

for you to fetch changes up to a907ec52cc1aefc820768b6e341b56f8f3caaca7:

  nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file 
(2016-02-02 12:45:01 +0100)


nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file


Laszlo Ersek (1):
  nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file

 hw/block/nvme.c | 42 +-
 1 file changed, 5 insertions(+), 37 deletions(-)

Re: [Qemu-devel] [PATCH v2 1/5] console: add & use qemu_console_lookup_by_device_name

[Markus Armbruster]

With the trivial doc fix in PATCH 2, series
Reviewed-by: Markus Armbruster 

[Qemu-devel] [PATCH v5 00/10] Make qemu-img/qemu-nbd/qemu-io CLI more flexible

[Daniel P. Berrange]

This series of patches expands the syntax of the qemu-img,
qemu-nbd and qemu-io commands to make them more flexible.

  v0: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg04365.html
  v1: https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04014.html
  v2: https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04354.html
  v3: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg03381.html
  v4: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04984.html

First all three gain a --object parameter, which allows
instantiation of user creatable object types. The immediate
use case is to allow for creation of the 'secret' object
type to pass passwords for curl, iscsi and rbd drivers.
For qemu-nbd this will also be needed to create TLS
certificates for encryption support.

Then all three gain a '--image-opts' parameter which causes
the positional filenames to be interepreted as option strings
rather tha nplain filenames. This avoids the need to use the
JSON syntax, or to add custom CLI args for each block backend
option that exists. The immediate use case is to allow the
user to specify the ID of the 'secret' object they just created.

Finally, there are a few small cleanup patches

The first 4 patches in this series are a pre-requisite for
3 other series

 - Support for TLS in NBD
 - Support for secrets for passwd auth in curl, rbd, iscsi
   (fixes a CVE issue in libvirt)
 - Support for LUKS encryption passwords

Changed in v5:

 - Move more common object creation code into qom/ (Kevin)
 - Add missing @var{} syntax in CLI help definition (Kevin)
 - Declare QemuOpts closer to time of use (Kevin)
 - Directly reference registered opts instead of calling
   qemu_find_opts (Kevin)
 - Use consistent exit/return/goto pattern in qemu-img (Kevin)
 - Remove special casing of 'file' in QemuOpts handling
   for bdrv_open (Kevin)
 - Split file file opening code out into separate method
   (Kevin)

Changed in v4:

 - Fix error reporting when object_create fails

Changed in v3:

 - Rebase to resolve with conflicts against recently
   merged code
 - Remove use of errx()

Changed in v2:

 - Share more common code in qom/object_interfaces.c to
   avoid duplicating so much of 'object_create' in each
   command
 - Remove previously added '--source optstring' parameter
   which replaced the positional filenames, in favour of
   keeping the positional filenames but using a --image-opts
   boolean arg to change their interpretation
 - Added docs for --image-opts to qemu-img man page
 - Use printf instead of echo -n in examples
 - Line wrap help string based on user terminal width not
   source code width
 - Update qemu-nbd/qemu-io to use constants for options
 - Update qemu-nbd to avoid overlapping option values

Daniel P. Berrange (10):
  qom: add helpers for UserCreatable object types
  qemu-img: add support for --object command line arg
  qemu-nbd: add support for --object command line arg
  qemu-io: add support for --object command line arg
  qemu-io: allow specifying image as a set of options args
  qemu-nbd: allow specifying image as a set of options args
  qemu-img: allow specifying image as a set of options args
  qemu-nbd: don't overlap long option values with short options
  qemu-nbd: use no_argument/required_argument constants
  qemu-io: use no_argument/required_argument constants

 hmp.c   |  52 +
 include/monitor/monitor.h   |   3 -
 include/qom/object_interfaces.h |  92 +
 qemu-img-cmds.hx|  44 ++--
 qemu-img.c  | 433 +---
 qemu-img.texi   |  14 ++
 qemu-io.c   |  92 +++--
 qemu-nbd.c  | 127 +---
 qemu-nbd.texi   |   6 +
 qmp.c   |  76 +--
 qom/object_interfaces.c | 180 +
 vl.c|  66 +-
 12 files changed, 916 insertions(+), 269 deletions(-)

-- 
2.5.0

[Qemu-devel] [PATCH v5 05/10] qemu-io: allow specifying image as a set of options args

[Daniel P. Berrange]

Currently qemu-io allows an image filename to be passed on the
command line, but unless using the JSON format, it does not have
a way to set any options except the format eg

 qemu-io https://127.0.0.1/images/centos7.iso
 qemu-io /home/berrange/demo.qcow2

This adds a --image-opts arg that indicates that the positional
filename should be interpreted as a full option string, not
just a filename.

 qemu-io --image-opts driver=https,url=https://127.0.0.1/images,sslverify=off
 qemu-io --image-opts driver=file,filename=/home/berrange/demo.qcow2

This flag is mutually exclusive with the '-f' flag.

Signed-off-by: Daniel P. Berrange 
---
 qemu-io.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/qemu-io.c b/qemu-io.c
index 65a28e4..3544fd7 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -366,6 +366,7 @@ static void reenable_tty_echo(void)
 
 enum {
 OPTION_OBJECT = 256,
+OPTION_IMAGE_OPTS = 257,
 };
 
 static QemuOptsList qemu_object_opts = {
@@ -378,6 +379,16 @@ static QemuOptsList qemu_object_opts = {
 };
 
 
+static QemuOptsList file_opts = {
+.name = "file",
+.implied_opt_name = "file",
+.head = QTAILQ_HEAD_INITIALIZER(file_opts.head),
+.desc = {
+/* no elements => accept any params */
+{ /* end of list */ }
+},
+};
+
 int main(int argc, char **argv)
 {
 int readonly = 0;
@@ -397,6 +408,7 @@ int main(int argc, char **argv)
 { "cache", 1, NULL, 't' },
 { "trace", 1, NULL, 'T' },
 { "object", 1, NULL, OPTION_OBJECT },
+{ "image-opts", 0, NULL, OPTION_IMAGE_OPTS },
 { NULL, 0, NULL, 0 }
 };
 int c;
@@ -404,6 +416,7 @@ int main(int argc, char **argv)
 int flags = BDRV_O_UNMAP;
 Error *local_error = NULL;
 QDict *opts = NULL;
+bool imageOpts = false;
 
 #ifdef CONFIG_POSIX
 signal(SIGPIPE, SIG_IGN);
@@ -473,6 +486,9 @@ int main(int argc, char **argv)
 exit(1);
 }
 }   break;
+case OPTION_IMAGE_OPTS:
+imageOpts = true;
+break;
 default:
 usage(progname);
 exit(1);
@@ -515,7 +531,20 @@ int main(int argc, char **argv)
 flags |= BDRV_O_RDWR;
 }
 
-if ((argc - optind) == 1) {
+if (imageOpts) {
+QemuOpts *qopts;
+qopts = qemu_opts_parse_noisily(&file_opts, argv[optind], false);
+if (!qopts) {
+exit(1);
+}
+if (opts) {
+error_report("--image-opts and -f are mutually exclusive");
+exit(1);
+}
+opts = qemu_opts_to_qdict(qopts, NULL);
+qemu_opts_reset(&file_opts);
+openfile(NULL, flags, opts);
+} else if ((argc - optind) == 1) {
 openfile(argv[optind], flags, opts);
 }
 command_loop();
-- 
2.5.0

[Qemu-devel] [PATCH v5 01/10] qom: add helpers for UserCreatable object types

[Daniel P. Berrange]

The QMP monitor code has two helper methods object_add
and qmp_object_del that are called from several places
in the code (QMP, HMP and main emulator startup).

The HMP and main emulator startup code also share
further logic that extracts the qom-type & id
values from a qdict.

We soon need to use this logic from qemu-img, qemu-io
and qemu-nbd too, but don't want those to depend on
the monitor, nor do we want to duplicate the code.

To avoid this, move some code out of qmp.c and hmp.c
adding new methods to qom/object_interfaces.c

 - user_creatable_add - takes a QDict holding a full
   object definition & instantiates it
 - user_creatable_add_type - takes an ID, type name,
   and QDict holding object properties & instantiates
   it
 - user_creatable_add_opts - takes a QemuOpts holding
   a full object definition & instantiates it
 - user_creatable_add_opts_foreach - variant on
   user_creatable_add_opts which can be directly used
   in conjunction with qemu_opts_foreach.
 - user_creatable_del - takes an ID and deletes the
   corresponding object

The existing code is updated to use these new methods.

Signed-off-by: Daniel P. Berrange 
---
 hmp.c   |  52 +++-
 include/monitor/monitor.h   |   3 -
 include/qom/object_interfaces.h |  92 
 qmp.c   |  76 ++---
 qom/object_interfaces.c | 180 
 vl.c|  66 ++-
 6 files changed, 296 insertions(+), 173 deletions(-)

diff --git a/hmp.c b/hmp.c
index 54f2620..95930b0 100644
--- a/hmp.c
+++ b/hmp.c
@@ -29,6 +29,7 @@
 #include "qapi/string-output-visitor.h"
 #include "qapi/util.h"
 #include "qapi-visit.h"
+#include "qom/object_interfaces.h"
 #include "ui/console.h"
 #include "block/qapi.h"
 #include "qemu-io.h"
@@ -1652,58 +1653,27 @@ void hmp_netdev_del(Monitor *mon, const QDict *qdict)
 void hmp_object_add(Monitor *mon, const QDict *qdict)
 {
 Error *err = NULL;
-Error *err_end = NULL;
 QemuOpts *opts;
-char *type = NULL;
-char *id = NULL;
-void *dummy = NULL;
 OptsVisitor *ov;
-QDict *pdict;
+Object *obj = NULL;
 
 opts = qemu_opts_from_qdict(qemu_find_opts("object"), qdict, &err);
 if (err) {
-goto out;
+hmp_handle_error(mon, &err);
+return;
 }
 
 ov = opts_visitor_new(opts);
-pdict = qdict_clone_shallow(qdict);
-
-visit_start_struct(opts_get_visitor(ov), &dummy, NULL, NULL, 0, &err);
-if (err) {
-goto out_clean;
-}
-
-qdict_del(pdict, "qom-type");
-visit_type_str(opts_get_visitor(ov), &type, "qom-type", &err);
-if (err) {
-goto out_end;
-}
+obj = user_creatable_add(qdict, opts_get_visitor(ov), &err);
+opts_visitor_cleanup(ov);
+qemu_opts_del(opts);
 
-qdict_del(pdict, "id");
-visit_type_str(opts_get_visitor(ov), &id, "id", &err);
 if (err) {
-goto out_end;
+hmp_handle_error(mon, &err);
 }
-
-object_add(type, id, pdict, opts_get_visitor(ov), &err);
-
-out_end:
-visit_end_struct(opts_get_visitor(ov), &err_end);
-if (!err && err_end) {
-qmp_object_del(id, NULL);
+if (obj) {
+object_unref(obj);
 }
-error_propagate(&err, err_end);
-out_clean:
-opts_visitor_cleanup(ov);
-
-QDECREF(pdict);
-qemu_opts_del(opts);
-g_free(id);
-g_free(type);
-g_free(dummy);
-
-out:
-hmp_handle_error(mon, &err);
 }
 
 void hmp_getfd(Monitor *mon, const QDict *qdict)
@@ -1933,7 +1903,7 @@ void hmp_object_del(Monitor *mon, const QDict *qdict)
 const char *id = qdict_get_str(qdict, "id");
 Error *err = NULL;
 
-qmp_object_del(id, &err);
+user_creatable_del(id, &err);
 hmp_handle_error(mon, &err);
 }
 
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 91b95ae..aa0f373 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -43,9 +43,6 @@ void monitor_read_command(Monitor *mon, int show_prompt);
 int monitor_read_password(Monitor *mon, ReadLineFunc *readline_func,
   void *opaque);
 
-void object_add(const char *type, const char *id, const QDict *qdict,
-Visitor *v, Error **errp);
-
 AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
 bool has_opaque, const char *opaque,
 Error **errp);
diff --git a/include/qom/object_interfaces.h b/include/qom/object_interfaces.h
index 283ae0d..f50e404 100644
--- a/include/qom/object_interfaces.h
+++ b/include/qom/object_interfaces.h
@@ -2,6 +2,8 @@
 #define OBJECT_INTERFACES_H
 
 #include "qom/object.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/visitor.h"
 
 #define TYPE_USER_CREATABLE "user-creatable"
 
@@ -72,4 +74,94 @@ void user_creatable_complete(Object *obj, Error **errp);
  * from implements USER_CREATABLE interface.
  */
 bool user_creatable_can_be_deleted(

[Qemu-devel] [PULL 1/1] nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file

[Gerd Hoffmann]

From: Laszlo Ersek 

Background on QEMU boot indices
---

Normally, the "bootindex" property is configured for bootable devices
with:

  DEVICE_instance_init()
device_add_bootindex_property(..., "bootindex", ...)
  object_property_add(..., device_get_bootindex,
  device_set_bootindex, ...)

and when the bootindex is set on the QEMU command line, with

  -device DEVICE,...,bootindex=N

the setter that was configured above is invoked:

  device_set_bootindex()
/* parse boot index */
visit_type_int32()

/* verify unicity */
check_boot_index()

/* store parsed boot index */
...

/* insert device path to boot order */
add_boot_device_path()

In the last step, add_boot_device_path() ensures that an OpenFirmware
device path will show up in the "bootorder" fw_cfg file, at a position
corresponding to the device's boot index. Thus guest firmware (SeaBIOS and
OVMF) can try to boot off the device with the right priority.

NVMe boot index
---

In QEMU commit 33739c712982,

  nvma: ide: add bootindex to qom property

the following generic setters / getters:
- device_set_bootindex()
- device_get_bootindex()

were open-coded for NVMe, under the names
- nvme_set_bootindex()
- nvme_get_bootindex()

Plus nvme_instance_init() was added to configure the "bootindex" property
manually, designating the open-coded getter & setter, rather than calling
device_add_bootindex_property().

Crucially, nvme_set_bootindex() avoided the final add_boot_device_path()
call. This fact is spelled out in the message of commit 33739c712982, and
it was presumably the entire reason for all of the code duplication.

Now, Vladislav filed an RFE for OVMF
; OVMF should boot off NVMe
devices. It is simple to build edk2's existent NvmExpressDxe driver into
OVMF, but the boot order matching logic in OVMF can only handle NVMe if
the "bootorder" fw_cfg file includes such devices.

Therefore this patch converts the NVMe device model to
device_set_bootindex() all the way.

Device paths


device_set_bootindex() accepts an optional parameter called "suffix". When
present, it is expected to take the form of an OpenFirmware device path
node, and it gets appended as last node to the otherwise auto-generated
OFW path.

For NVMe, the auto-generated part is

  /pci@i0cf8/pci8086,5845@6[,1]
   ^ ^^  ^
   | |PCI slot and (present when nonzero)
   | |function of the NVMe controller, both hex
   | "driver name" component, built from PCI vendor & device IDs
   PCI root at system bus port, PIO

to which here we append the suffix

  /namespace@1,0
 ^ ^
 | big endian (MSB at lowest address) numeric interpretation
 | of the 64-bit IEEE Extended Unique Identifier, aka EUI-64,
 | hex
 32-bit NVMe namespace identifier, aka NSID, hex

resulting in the OFW device path

  /pci@i0cf8/pci8086,5845@6[,1]/namespace@1,0

The reason for including the NSID and the EUI-64 is that an NVMe device
can in theory produce several different namespaces (distinguished by
NSID). Additionally, each of those may (optionally) have an EUI-64 value.

For now, QEMU only provides namespace 1.

Furthermore, QEMU doesn't even represent the EUI-64 as a standalone field;
it is embedded (and left unused) inside the "NvmeIdNs.res30" array, at the
last eight bytes. (Which is fine, since EUI-64 can be left zero-filled if
unsupported by the device.)

Based on the above, we set the "unit address" part of the last
("namespace") node to fixed "1,0".

OVMF will then map the above OFW device path to the following UEFI device
path fragment, for boot order processing:

  PciRoot(0x0)/Pci(0x6,0x1)/NVMe(0x1,00-00-00-00-00-00-00-00)
  ^^   ^^^   ^
  ||   |||   octets of the EUI-64 in address order
  ||   ||NSID
  ||   |NVMe namespace messaging device path node
  |PCI slot and function
  PCI root bridge

Cc: Keith Busch  (supporter:nvme)
Cc: Kevin Wolf  (supporter:Block layer core)
Cc: qemu-bl...@nongnu.org (open list:nvme)
Cc: Gonglei 
Cc: Vladislav Vovchenko 
Cc: Feng Tian 
Cc: Gerd Hoffmann 
Cc: Kevin O'Connor 
Signed-off-by: Laszlo Ersek 
Acked-by: Gonglei 
Acked-by: Keith Busch 
Tested-by: Vladislav Vovchenko 
Message-id: 1453850483-27511-1-git-send-email-ler...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 hw/block/nvme.c | 42 +-
 1 file changed, 5 insertions(+), 37 deletions(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index a5fedb2..c68b625 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -916,45 +916,13 @@ static void nvme_class_init(ObjectClass *oc, void *data)
 dc->vmsd = &nvme_vmstate;
 }
 
-static void nvme_get_bootindex(Object *obj, Visitor *v, void *opaque,

[Qemu-devel] [PATCH v5 08/10] qemu-nbd: don't overlap long option values with short options

[Daniel P. Berrange]

When defining values for long options, the normal practice is
to start numbering from 256, to avoid overlap with the range
of valid values for short options.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 qemu-nbd.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index ee91e47..026cf86 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -42,12 +42,12 @@
 #include 
 
 #define SOCKET_PATH"/var/lock/qemu-nbd-%s"
-#define QEMU_NBD_OPT_CACHE 1
-#define QEMU_NBD_OPT_AIO   2
-#define QEMU_NBD_OPT_DISCARD   3
-#define QEMU_NBD_OPT_DETECT_ZEROES 4
-#define QEMU_NBD_OPT_OBJECT5
-#define QEMU_NBD_OPT_IMAGE_OPTS6
+#define QEMU_NBD_OPT_CACHE 256
+#define QEMU_NBD_OPT_AIO   257
+#define QEMU_NBD_OPT_DISCARD   258
+#define QEMU_NBD_OPT_DETECT_ZEROES 259
+#define QEMU_NBD_OPT_OBJECT260
+#define QEMU_NBD_OPT_IMAGE_OPTS261
 
 static NBDExport *exp;
 static int verbose;
-- 
2.5.0

[Qemu-devel] [PATCH v5 02/10] qemu-img: add support for --object command line arg

[Daniel P. Berrange]

Allow creation of user creatable object types with qemu-img
via a new --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.

 # printf letmein > mypasswd.txt
 # qemu-img info --object secret,id=sec0,file=mypasswd.txt \
  ...other info args...

Signed-off-by: Daniel P. Berrange 
---
 qemu-img-cmds.hx |  44 -
 qemu-img.c   | 269 +--
 qemu-img.texi|   8 ++
 3 files changed, 291 insertions(+), 30 deletions(-)

diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 9567774..0eaf307 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -10,68 +10,68 @@ STEXI
 ETEXI
 
 DEF("check", img_check,
-"check [-q] [-f fmt] [--output=ofmt] [-r [leaks | all]] [-T src_cache] 
filename")
+"check [-q] [--object objectdef] [-f fmt] [--output=ofmt] [-r [leaks | 
all]] [-T src_cache] filename")
 STEXI
-@item check [-q] [-f @var{fmt}] [--output=@var{ofmt}] [-r [leaks | all]] [-T 
@var{src_cache}] @var{filename}
+@item check [--object @var{objectdef}] [-q] [-f @var{fmt}] 
[--output=@var{ofmt}] [-r [leaks | all]] [-T @var{src_cache}] @var{filename}
 ETEXI
 
 DEF("create", img_create,
-"create [-q] [-f fmt] [-o options] filename [size]")
+"create [-q] [--object objectdef] [-f fmt] [-o options] filename [size]")
 STEXI
-@item create [-q] [-f @var{fmt}] [-o @var{options}] @var{filename} [@var{size}]
+@item create [--object @var{objectdef}] [-q] [-f @var{fmt}] [-o @var{options}] 
@var{filename} [@var{size}]
 ETEXI
 
 DEF("commit", img_commit,
-"commit [-q] [-f fmt] [-t cache] [-b base] [-d] [-p] filename")
+"commit [-q] [--object objectdef] [-f fmt] [-t cache] [-b base] [-d] [-p] 
filename")
 STEXI
-@item commit [-q] [-f @var{fmt}] [-t @var{cache}] [-b @var{base}] [-d] [-p] 
@var{filename}
+@item commit [--object @var{objectdef}] [-q] [-f @var{fmt}] [-t @var{cache}] 
[-b @var{base}] [-d] [-p] @var{filename}
 ETEXI
 
 DEF("compare", img_compare,
-"compare [-f fmt] [-F fmt] [-T src_cache] [-p] [-q] [-s] filename1 
filename2")
+"compare [--object objectdef] [-f fmt] [-F fmt] [-T src_cache] [-p] [-q] 
[-s] filename1 filename2")
 STEXI
-@item compare [-f @var{fmt}] [-F @var{fmt}] [-T @var{src_cache}] [-p] [-q] 
[-s] @var{filename1} @var{filename2}
+@item compare [--object @var{objectdef}] [-f @var{fmt}] [-F @var{fmt}] [-T 
@var{src_cache}] [-p] [-q] [-s] @var{filename1} @var{filename2}
 ETEXI
 
 DEF("convert", img_convert,
-"convert [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O 
output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S 
sparse_size] filename [filename2 [...]] output_filename")
+"convert [--object objectdef] [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T 
src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l 
snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename")
 STEXI
-@item convert [-c] [-p] [-q] [-n] [-f @var{fmt}] [-t @var{cache}] [-T 
@var{src_cache}] [-O @var{output_fmt}] [-o @var{options}] [-s 
@var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S @var{sparse_size}] 
@var{filename} [@var{filename2} [...]] @var{output_filename}
+@item convert [--object @var{objectdef}] [-c] [-p] [-q] [-n] [-f @var{fmt}] 
[-t @var{cache}] [-T @var{src_cache}] [-O @var{output_fmt}] [-o @var{options}] 
[-s @var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S @var{sparse_size}] 
@var{filename} [@var{filename2} [...]] @var{output_filename}
 ETEXI
 
 DEF("info", img_info,
-"info [-f fmt] [--output=ofmt] [--backing-chain] filename")
+"info [--object objectdef] [-f fmt] [--output=ofmt] [--backing-chain] 
filename")
 STEXI
-@item info [-f @var{fmt}] [--output=@var{ofmt}] [--backing-chain] 
@var{filename}
+@item info [--object @var{objectdef}] [-f @var{fmt}] [--output=@var{ofmt}] 
[--backing-chain] @var{filename}
 ETEXI
 
 DEF("map", img_map,
-"map [-f fmt] [--output=ofmt] filename")
+"map [--object objectdef] [-f fmt] [--output=ofmt] filename")
 STEXI
-@item map [-f @var{fmt}] [--output=@var{ofmt}] @var{filename}
+@item map [--object @var{objectdef}] [-f @var{fmt}] [--output=@var{ofmt}] 
@var{filename}
 ETEXI
 
 DEF("snapshot", img_snapshot,
-"snapshot [-q] [-l | -a snapshot | -c snapshot | -d snapshot] filename")
+"snapshot [--object objectdef] [-q] [-l | -a snapshot | -c snapshot | -d 
snapshot] filename")
 STEXI
-@item snapshot [-q] [-l | -a @var{snapshot} | -c @var{snapshot} | -d 
@var{snapshot}] @var{filename}
+@item snapshot [--object @var{objectdef}] [-q] [-l | -a @var{snapshot} | -c 
@var{snapshot} | -d @var{snapshot}] @var{filename}
 ETEXI
 
 DEF("rebase", img_rebase,
-"rebase [-q] [-f fmt] [-t cache] [-T src_cache] [-p] [-u] -b backing_file 
[-F backing_fmt] filename")
+"rebase [--object objectdef] [-q] [-f fmt] [-t cache] [-T src_cache] [-p] 
[-u] -b backing_file [-F backing_fmt] filename")
 STEXI
-@item re

[Qemu-devel] [PATCH v5 06/10] qemu-nbd: allow specifying image as a set of options args

[Daniel P. Berrange]

Currently qemu-nbd allows an image filename to be passed on the
command line, but unless using the JSON format, it does not have
a way to set any options except the format eg

   qemu-nbd https://127.0.0.1/images/centos7.iso
   qemu-nbd /home/berrange/demo.qcow2

This adds a --image-opts arg that indicates that the positional
filename should be interpreted as a full option string, not
just a filename.

   qemu-nbd --image-opts driver=https,url=https://127.0.0.1/images,sslverify=off
   qemu-nbd --image-opts driver=file,filename=/home/berrange/demo.qcow2

This flag is mutually exclusive with the '-f' flag.

Signed-off-by: Daniel P. Berrange 
---
 qemu-nbd.c | 42 +-
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index 0e019c1..ee91e47 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -47,6 +47,7 @@
 #define QEMU_NBD_OPT_DISCARD   3
 #define QEMU_NBD_OPT_DETECT_ZEROES 4
 #define QEMU_NBD_OPT_OBJECT5
+#define QEMU_NBD_OPT_IMAGE_OPTS6
 
 static NBDExport *exp;
 static int verbose;
@@ -380,6 +381,16 @@ static SocketAddress *nbd_build_socket_address(const char 
*sockpath,
 }
 
 
+static QemuOptsList file_opts = {
+.name = "file",
+.implied_opt_name = "file",
+.head = QTAILQ_HEAD_INITIALIZER(file_opts.head),
+.desc = {
+/* no elements => accept any params */
+{ /* end of list */ }
+},
+};
+
 static QemuOptsList qemu_object_opts = {
 .name = "object",
 .implied_opt_name = "qom-type",
@@ -428,6 +439,7 @@ int main(int argc, char **argv)
 { "persistent", 0, NULL, 't' },
 { "verbose", 0, NULL, 'v' },
 { "object", 1, NULL, QEMU_NBD_OPT_OBJECT },
+{ "image-opts", 0, NULL, QEMU_NBD_OPT_IMAGE_OPTS },
 { NULL, 0, NULL, 0 }
 };
 int ch;
@@ -445,6 +457,7 @@ int main(int argc, char **argv)
 Error *local_err = NULL;
 BlockdevDetectZeroesOptions detect_zeroes = 
BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF;
 QDict *options = NULL;
+bool imageOpts = false;
 
 /* The client thread uses SIGTERM to interrupt the server.  A signal
  * handler ensures that "qemu-nbd -v -c" exits with a nice status code.
@@ -618,6 +631,9 @@ int main(int argc, char **argv)
 exit(EXIT_FAILURE);
 }
 }   break;
+case QEMU_NBD_OPT_IMAGE_OPTS:
+imageOpts = true;
+break;
 }
 }
 
@@ -724,13 +740,29 @@ int main(int argc, char **argv)
 bdrv_init();
 atexit(bdrv_close_all);
 
-if (fmt) {
-options = qdict_new();
-qdict_put(options, "driver", qstring_from_str(fmt));
+srcpath = argv[optind];
+if (imageOpts) {
+QemuOpts *opts;
+if (fmt) {
+error_report("--image-opts and -f are mutually exclusive");
+exit(EXIT_FAILURE);
+}
+opts = qemu_opts_parse_noisily(&file_opts, srcpath, true);
+if (!opts) {
+qemu_opts_reset(&file_opts);
+exit(EXIT_FAILURE);
+}
+options = qemu_opts_to_qdict(opts, NULL);
+qemu_opts_reset(&file_opts);
+blk = blk_new_open("hda", NULL, NULL, options, flags, &local_err);
+} else {
+if (fmt) {
+options = qdict_new();
+qdict_put(options, "driver", qstring_from_str(fmt));
+}
+blk = blk_new_open("hda", srcpath, NULL, options, flags, &local_err);
 }
 
-srcpath = argv[optind];
-blk = blk_new_open("hda", srcpath, NULL, options, flags, &local_err);
 if (!blk) {
 error_reportf_err(local_err, "Failed to blk_new_open '%s': ",
   argv[optind]);
-- 
2.5.0

[Qemu-devel] [PATCH v5 09/10] qemu-nbd: use no_argument/required_argument constants

[Daniel P. Berrange]

When declaring the 'struct option' array, use the standard
constants no_argument/required_argument, instead of magic
values 0 and 1.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 qemu-nbd.c | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index 026cf86..54d579c 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -417,29 +417,30 @@ int main(int argc, char **argv)
 const char *sn_id_or_name = NULL;
 const char *sopt = "hVb:o:p:rsnP:c:dvk:e:f:tl:";
 struct option lopt[] = {
-{ "help", 0, NULL, 'h' },
-{ "version", 0, NULL, 'V' },
-{ "bind", 1, NULL, 'b' },
-{ "port", 1, NULL, 'p' },
-{ "socket", 1, NULL, 'k' },
-{ "offset", 1, NULL, 'o' },
-{ "read-only", 0, NULL, 'r' },
-{ "partition", 1, NULL, 'P' },
-{ "connect", 1, NULL, 'c' },
-{ "disconnect", 0, NULL, 'd' },
-{ "snapshot", 0, NULL, 's' },
-{ "load-snapshot", 1, NULL, 'l' },
-{ "nocache", 0, NULL, 'n' },
-{ "cache", 1, NULL, QEMU_NBD_OPT_CACHE },
-{ "aio", 1, NULL, QEMU_NBD_OPT_AIO },
-{ "discard", 1, NULL, QEMU_NBD_OPT_DISCARD },
-{ "detect-zeroes", 1, NULL, QEMU_NBD_OPT_DETECT_ZEROES },
-{ "shared", 1, NULL, 'e' },
-{ "format", 1, NULL, 'f' },
-{ "persistent", 0, NULL, 't' },
-{ "verbose", 0, NULL, 'v' },
-{ "object", 1, NULL, QEMU_NBD_OPT_OBJECT },
-{ "image-opts", 0, NULL, QEMU_NBD_OPT_IMAGE_OPTS },
+{ "help", no_argument, NULL, 'h' },
+{ "version", no_argument, NULL, 'V' },
+{ "bind", required_argument, NULL, 'b' },
+{ "port", required_argument, NULL, 'p' },
+{ "socket", required_argument, NULL, 'k' },
+{ "offset", required_argument, NULL, 'o' },
+{ "read-only", no_argument, NULL, 'r' },
+{ "partition", required_argument, NULL, 'P' },
+{ "connect", required_argument, NULL, 'c' },
+{ "disconnect", no_argument, NULL, 'd' },
+{ "snapshot", no_argument, NULL, 's' },
+{ "load-snapshot", required_argument, NULL, 'l' },
+{ "nocache", no_argument, NULL, 'n' },
+{ "cache", required_argument, NULL, QEMU_NBD_OPT_CACHE },
+{ "aio", required_argument, NULL, QEMU_NBD_OPT_AIO },
+{ "discard", required_argument, NULL, QEMU_NBD_OPT_DISCARD },
+{ "detect-zeroes", required_argument, NULL,
+  QEMU_NBD_OPT_DETECT_ZEROES },
+{ "shared", required_argument, NULL, 'e' },
+{ "format", required_argument, NULL, 'f' },
+{ "persistent", no_argument, NULL, 't' },
+{ "verbose", no_argument, NULL, 'v' },
+{ "object", required_argument, NULL, QEMU_NBD_OPT_OBJECT },
+{ "image-opts", no_argument, NULL, QEMU_NBD_OPT_IMAGE_OPTS },
 { NULL, 0, NULL, 0 }
 };
 int ch;
-- 
2.5.0

[Qemu-devel] [PATCH v5 10/10] qemu-io: use no_argument/required_argument constants

[Daniel P. Berrange]

When declaring the 'struct option' array, use the standard
constants no_argument/required_argument, instead of magic
values 0 and 1.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 qemu-io.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/qemu-io.c b/qemu-io.c
index 3544fd7..d94dad1 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -394,21 +394,21 @@ int main(int argc, char **argv)
 int readonly = 0;
 const char *sopt = "hVc:d:f:rsnmgkt:T:";
 const struct option lopt[] = {
-{ "help", 0, NULL, 'h' },
-{ "version", 0, NULL, 'V' },
-{ "offset", 1, NULL, 'o' },
-{ "cmd", 1, NULL, 'c' },
-{ "format", 1, NULL, 'f' },
-{ "read-only", 0, NULL, 'r' },
-{ "snapshot", 0, NULL, 's' },
-{ "nocache", 0, NULL, 'n' },
-{ "misalign", 0, NULL, 'm' },
-{ "native-aio", 0, NULL, 'k' },
-{ "discard", 1, NULL, 'd' },
-{ "cache", 1, NULL, 't' },
-{ "trace", 1, NULL, 'T' },
-{ "object", 1, NULL, OPTION_OBJECT },
-{ "image-opts", 0, NULL, OPTION_IMAGE_OPTS },
+{ "help", no_argument, NULL, 'h' },
+{ "version", no_argument, NULL, 'V' },
+{ "offset", required_argument, NULL, 'o' },
+{ "cmd", required_argument, NULL, 'c' },
+{ "format", required_argument, NULL, 'f' },
+{ "read-only", no_argument, NULL, 'r' },
+{ "snapshot", no_argument, NULL, 's' },
+{ "nocache", no_argument, NULL, 'n' },
+{ "misalign", no_argument, NULL, 'm' },
+{ "native-aio", no_argument, NULL, 'k' },
+{ "discard", required_argument, NULL, 'd' },
+{ "cache", required_argument, NULL, 't' },
+{ "trace", required_argument, NULL, 'T' },
+{ "object", required_argument, NULL, OPTION_OBJECT },
+{ "image-opts", no_argument, NULL, OPTION_IMAGE_OPTS },
 { NULL, 0, NULL, 0 }
 };
 int c;
-- 
2.5.0

[Qemu-devel] [PATCH v5 03/10] qemu-nbd: add support for --object command line arg

[Daniel P. Berrange]

Allow creation of user creatable object types with qemu-nbd
via a new --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.

 # printf letmein > mypasswd.txt
 # qemu-nbd --object secret,id=sec0,file=mypasswd.txt \
  ...other nbd args...

Signed-off-by: Daniel P. Berrange 
---
 qemu-nbd.c| 34 ++
 qemu-nbd.texi |  6 ++
 2 files changed, 40 insertions(+)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index ede4a54..0e019c1 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -23,9 +23,11 @@
 #include "qemu/main-loop.h"
 #include "qemu/sockets.h"
 #include "qemu/error-report.h"
+#include "qemu/config-file.h"
 #include "block/snapshot.h"
 #include "qapi/util.h"
 #include "qapi/qmp/qstring.h"
+#include "qom/object_interfaces.h"
 
 #include 
 #include 
@@ -44,6 +46,7 @@
 #define QEMU_NBD_OPT_AIO   2
 #define QEMU_NBD_OPT_DISCARD   3
 #define QEMU_NBD_OPT_DETECT_ZEROES 4
+#define QEMU_NBD_OPT_OBJECT5
 
 static NBDExport *exp;
 static int verbose;
@@ -77,6 +80,9 @@ static void usage(const char *name)
 "  -o, --offset=OFFSET   offset into the image\n"
 "  -P, --partition=NUM   only expose partition NUM\n"
 "\n"
+"General purpose options:\n"
+"  --object type,id=ID,...   define an object such as 'secret' for providing\n"
+"passwords and/or encryption keys\n"
 #ifdef __linux__
 "Kernel NBD client support:\n"
 "  -c, --connect=DEV connect FILE to the local NBD device DEV\n"
@@ -374,6 +380,16 @@ static SocketAddress *nbd_build_socket_address(const char 
*sockpath,
 }
 
 
+static QemuOptsList qemu_object_opts = {
+.name = "object",
+.implied_opt_name = "qom-type",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_object_opts.head),
+.desc = {
+{ }
+},
+};
+
+
 int main(int argc, char **argv)
 {
 BlockBackend *blk;
@@ -411,6 +427,7 @@ int main(int argc, char **argv)
 { "format", 1, NULL, 'f' },
 { "persistent", 0, NULL, 't' },
 { "verbose", 0, NULL, 'v' },
+{ "object", 1, NULL, QEMU_NBD_OPT_OBJECT },
 { NULL, 0, NULL, 0 }
 };
 int ch;
@@ -436,6 +453,8 @@ int main(int argc, char **argv)
 memset(&sa_sigterm, 0, sizeof(sa_sigterm));
 sa_sigterm.sa_handler = termsig_handler;
 sigaction(SIGTERM, &sa_sigterm, NULL);
+module_call_init(MODULE_INIT_QOM);
+qemu_add_opts(&qemu_object_opts);
 qemu_init_exec_dir(argv[0]);
 
 while ((ch = getopt_long(argc, argv, sopt, lopt, &opt_ind)) != -1) {
@@ -591,6 +610,14 @@ int main(int argc, char **argv)
 case '?':
 error_report("Try `%s --help' for more information.", argv[0]);
 exit(EXIT_FAILURE);
+case QEMU_NBD_OPT_OBJECT: {
+QemuOpts *opts;
+opts = qemu_opts_parse_noisily(&qemu_object_opts,
+   optarg, true);
+if (!opts) {
+exit(EXIT_FAILURE);
+}
+}   break;
 }
 }
 
@@ -600,6 +627,13 @@ int main(int argc, char **argv)
 exit(EXIT_FAILURE);
 }
 
+if (qemu_opts_foreach(&qemu_object_opts,
+  user_creatable_add_opts_foreach,
+  NULL, &local_err)) {
+error_report_err(local_err);
+exit(EXIT_FAILURE);
+}
+
 if (disconnect) {
 fd = open(argv[optind], O_RDWR);
 if (fd < 0) {
diff --git a/qemu-nbd.texi b/qemu-nbd.texi
index 46fd483..9f9daca 100644
--- a/qemu-nbd.texi
+++ b/qemu-nbd.texi
@@ -14,6 +14,12 @@ Export QEMU disk image using NBD protocol.
 @table @option
 @item @var{filename}
  is a disk image filename
+@item --object type,id=@var{id},...props...
+  define a new instance of the @var{type} object class identified by @var{id}.
+  See the @code{qemu(1)} manual page for full details of the properties
+  supported. The common object type that it makes sense to define is the
+  @code{secret} object, which is used to supply passwords and/or encryption
+  keys.
 @item -p, --port=@var{port}
   port to listen on (default @samp{10809})
 @item -o, --offset=@var{offset}
-- 
2.5.0

[Qemu-devel] [PATCH v5 07/10] qemu-img: allow specifying image as a set of options args

[Daniel P. Berrange]

Currently qemu-img allows an image filename to be passed on the
command line, but unless using the JSON format, it does not have
a way to set any options except the format eg

   qemu-img info https://127.0.0.1/images/centos7.iso

This adds a --image-opts arg that indicates that the positional
filename should be interpreted as a full option string, not
just a filename.

   qemu-img info --image-opts 
driver=https,url=https://127.0.0.1/images,sslverify=off

This flag is mutually exclusive with the '-f' / '-F' flags.

Signed-off-by: Daniel P. Berrange 
---
 qemu-img-cmds.hx |  44 +++
 qemu-img.c   | 164 +++
 qemu-img.texi|   6 ++
 3 files changed, 170 insertions(+), 44 deletions(-)

diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 0eaf307..e7cded6 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -10,68 +10,68 @@ STEXI
 ETEXI
 
 DEF("check", img_check,
-"check [-q] [--object objectdef] [-f fmt] [--output=ofmt] [-r [leaks | 
all]] [-T src_cache] filename")
+"check [-q] [--object objectdef] [--image-opts] [-f fmt] [--output=ofmt] 
[-r [leaks | all]] [-T src_cache] filename")
 STEXI
-@item check [--object @var{objectdef}] [-q] [-f @var{fmt}] 
[--output=@var{ofmt}] [-r [leaks | all]] [-T @var{src_cache}] @var{filename}
+@item check [--object @var{objectdef}] [--image-opts] [-q] [-f @var{fmt}] 
[--output=@var{ofmt}] [-r [leaks | all]] [-T @var{src_cache}] @var{filename}
 ETEXI
 
 DEF("create", img_create,
-"create [-q] [--object objectdef] [-f fmt] [-o options] filename [size]")
+"create [-q] [--object objectdef] [--image-opts] [-f fmt] [-o options] 
filename [size]")
 STEXI
-@item create [--object @var{objectdef}] [-q] [-f @var{fmt}] [-o @var{options}] 
@var{filename} [@var{size}]
+@item create [--object @var{objectdef}] [--image-opts] [-q] [-f @var{fmt}] [-o 
@var{options}] @var{filename} [@var{size}]
 ETEXI
 
 DEF("commit", img_commit,
-"commit [-q] [--object objectdef] [-f fmt] [-t cache] [-b base] [-d] [-p] 
filename")
+"commit [-q] [--object objectdef] [--image-opts] [-f fmt] [-t cache] [-b 
base] [-d] [-p] filename")
 STEXI
-@item commit [--object @var{objectdef}] [-q] [-f @var{fmt}] [-t @var{cache}] 
[-b @var{base}] [-d] [-p] @var{filename}
+@item commit [--object @var{objectdef}] [--image-opts] [-q] [-f @var{fmt}] [-t 
@var{cache}] [-b @var{base}] [-d] [-p] @var{filename}
 ETEXI
 
 DEF("compare", img_compare,
-"compare [--object objectdef] [-f fmt] [-F fmt] [-T src_cache] [-p] [-q] 
[-s] filename1 filename2")
+"compare [--object objectdef] [--image-opts] [-f fmt] [-F fmt] [-T 
src_cache] [-p] [-q] [-s] filename1 filename2")
 STEXI
-@item compare [--object @var{objectdef}] [-f @var{fmt}] [-F @var{fmt}] [-T 
@var{src_cache}] [-p] [-q] [-s] @var{filename1} @var{filename2}
+@item compare [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] [-F 
@var{fmt}] [-T @var{src_cache}] [-p] [-q] [-s] @var{filename1} @var{filename2}
 ETEXI
 
 DEF("convert", img_convert,
-"convert [--object objectdef] [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T 
src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l 
snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename")
+"convert [--object objectdef] [--image-opts] [-c] [-p] [-q] [-n] [-f fmt] 
[-t cache] [-T src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] 
[-l snapshot_param] [-S sparse_size] filename [filename2 [...]] 
output_filename")
 STEXI
-@item convert [--object @var{objectdef}] [-c] [-p] [-q] [-n] [-f @var{fmt}] 
[-t @var{cache}] [-T @var{src_cache}] [-O @var{output_fmt}] [-o @var{options}] 
[-s @var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S @var{sparse_size}] 
@var{filename} [@var{filename2} [...]] @var{output_filename}
+@item convert [--object @var{objectdef}] [--image-opts] [-c] [-p] [-q] [-n] 
[-f @var{fmt}] [-t @var{cache}] [-T @var{src_cache}] [-O @var{output_fmt}] [-o 
@var{options}] [-s @var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S 
@var{sparse_size}] @var{filename} [@var{filename2} [...]] @var{output_filename}
 ETEXI
 
 DEF("info", img_info,
-"info [--object objectdef] [-f fmt] [--output=ofmt] [--backing-chain] 
filename")
+"info [--object objectdef] [--image-opts] [-f fmt] [--output=ofmt] 
[--backing-chain] filename")
 STEXI
-@item info [--object @var{objectdef}] [-f @var{fmt}] [--output=@var{ofmt}] 
[--backing-chain] @var{filename}
+@item info [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] 
[--output=@var{ofmt}] [--backing-chain] @var{filename}
 ETEXI
 
 DEF("map", img_map,
-"map [--object objectdef] [-f fmt] [--output=ofmt] filename")
+"map [--object objectdef] [--image-opts] [-f fmt] [--output=ofmt] 
filename")
 STEXI
-@item map [--object @var{objectdef}] [-f @var{fmt}] [--output=@var{ofmt}] 
@var{filename}
+@item map [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] 
[--output=@var{ofmt}] @var{filename}
 ETEXI
 
 DEF("snapshot", im

[Qemu-devel] [PATCH v5 04/10] qemu-io: add support for --object command line arg

[Daniel P. Berrange]

Allow creation of user creatable object types with qemu-io
via a new --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.

 # printf letmein > mypasswd.txt
 # qemu-io --object secret,id=sec0,file=mypasswd.txt \
  ...other args...

Signed-off-by: Daniel P. Berrange 
---
 qemu-io.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/qemu-io.c b/qemu-io.c
index d593f19..65a28e4 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -18,6 +18,7 @@
 #include "qemu/config-file.h"
 #include "qemu/readline.h"
 #include "qapi/qmp/qstring.h"
+#include "qom/object_interfaces.h"
 #include "sysemu/block-backend.h"
 #include "block/block_int.h"
 #include "trace/control.h"
@@ -200,6 +201,8 @@ static void usage(const char *name)
 "Usage: %s [-h] [-V] [-rsnm] [-f FMT] [-c STRING] ... [file]\n"
 "QEMU Disk exerciser\n"
 "\n"
+"  --object OBJECTDEF   define an object such as 'secret' for\n"
+"   passwords and/or encryption keys\n"
 "  -c, --cmd STRING execute command with its arguments\n"
 "   from the given string\n"
 "  -f, --format FMT specifies the block driver to use\n"
@@ -361,6 +364,20 @@ static void reenable_tty_echo(void)
 qemu_set_tty_echo(STDIN_FILENO, true);
 }
 
+enum {
+OPTION_OBJECT = 256,
+};
+
+static QemuOptsList qemu_object_opts = {
+.name = "object",
+.implied_opt_name = "qom-type",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_object_opts.head),
+.desc = {
+{ }
+},
+};
+
+
 int main(int argc, char **argv)
 {
 int readonly = 0;
@@ -379,6 +396,7 @@ int main(int argc, char **argv)
 { "discard", 1, NULL, 'd' },
 { "cache", 1, NULL, 't' },
 { "trace", 1, NULL, 'T' },
+{ "object", 1, NULL, OPTION_OBJECT },
 { NULL, 0, NULL, 0 }
 };
 int c;
@@ -394,6 +412,8 @@ int main(int argc, char **argv)
 progname = basename(argv[0]);
 qemu_init_exec_dir(argv[0]);
 
+module_call_init(MODULE_INIT_QOM);
+qemu_add_opts(&qemu_object_opts);
 bdrv_init();
 
 while ((c = getopt_long(argc, argv, sopt, lopt, &opt_index)) != -1) {
@@ -445,6 +465,14 @@ int main(int argc, char **argv)
 case 'h':
 usage(progname);
 exit(0);
+case OPTION_OBJECT: {
+QemuOpts *qopts = NULL;
+qopts = qemu_opts_parse_noisily(&qemu_object_opts,
+optarg, true);
+if (!qopts) {
+exit(1);
+}
+}   break;
 default:
 usage(progname);
 exit(1);
@@ -461,6 +489,13 @@ int main(int argc, char **argv)
 exit(1);
 }
 
+if (qemu_opts_foreach(&qemu_object_opts,
+  user_creatable_add_opts_foreach,
+  NULL, &local_error)) {
+error_report_err(local_error);
+exit(1);
+}
+
 /* initialize commands */
 qemuio_add_command(&quit_cmd);
 qemuio_add_command(&open_cmd);
-- 
2.5.0

Re: [Qemu-devel] [libvirt] ARM KVM GICv3 Support

[Andrew Jones]

On Tue, Feb 02, 2016 at 12:10:10PM +, Daniel P. Berrange wrote:
> On Tue, Feb 02, 2016 at 12:49:33PM +0100, Christoffer Dall wrote:
> > On Fri, Jan 22, 2016 at 02:44:32PM +, Daniel P. Berrange wrote:
> > > On Wed, Jan 06, 2016 at 01:30:16PM +, Peter Maydell wrote:
> > > > On 6 January 2016 at 12:49, Andrea Bolognani  
> > > > wrote:
> > > > > That's correct, having a QMP command that lists the values gic-version
> > > > > can have on the current host would be just great.
> > > > >
> > > > > If we had that, we could validate the GIC version chosen for a guest,
> > > > > and expose it in the capabilities XML so that higher-level tools can
> > > > > provide a list of choices to the user.
> > > > >
> > > > > Please note that this QMP command would have to work regardless of the
> > > > > machine type selected on QEMU's command line, because libvirt always
> > > > > runs a QEMU binary with '-M none' when probing its capabilities.
> > > > 
> > > > On the other hand, if you don't tell us the machine type you care
> > > > about then we can't tell you:
> > > >  (a) "this machine type doesn't support setting this property at all"
> > > >  (which applies to machines like vexpress-a15 which you can use with
> > > >  KVM on 32-bit hosts, and of course also to all the non-KVM models)
> > > 
> > > We have just recently merged support for registering properties against
> > > classes instead of object instances. There is also a proposed command
> > > to allow querying the list of properties against a class
> > > 
> > >   https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04348.html
> > > 
> > > So if we now update the machine types to register their properties against
> > > the class instead of object, then we can query what properties are present
> > > against each machine type, while still using '-M none'.
> > > 
> > > >  (b) "this machine type only supports GIC versions X and Y even if the
> > > >   host supports more" (this is currently only hypothetical, though,
> > > >   since we only have the property on 'virt'. it would only happen
> > > >   if in the future we needed something other than '2' or '3' or
> > > >   'host' I think.)
> > > 
> > > Our introspection support in QOM only allows us to say that a property
> > > is a particular type (int / enum / str / whatever). We don't have any
> > > way to expose info about what subset of possible values for a type are
> > > permitted. So I don't see any near term way to inform apps that the
> > > gic property accepts values x, y and but not z.

This actually doesn't matter for the v2 vs. v3 case. The gic-version property
doesn't exist at all for v2-only QEMU. Although maybe the gic-version property
should be reworked. Instead of gic-version=, we could create
one boolean property per version supported, i.e. gicv2, gicv3, gicv4...

> > > 
> > > IMHO, we shouldn't try to overthink this. Libvirt can query the host
> > > to find out what GIC versions are supported and default to using the
> > > most recent version, on the basis that people are likely to have a
> > > matching QEMU. We can just rely on QEMU to report error if we pass
> > > it a version it doesn't support and not try to pre-emptively check
> > > before launch. The key is just getting the default right IMHO.
> > > 
> > This sounds fine to me.
> > 
> > However, not being familiar with the internals of libvirt I really can't
> > just what the right implementation approach here is.
> > 
> > As I understand we need to either:
> > 
> >   1) Add a QMP command that lets you ask for -M virt, if GIC version X
> >  is supported
> > 
> >   2) Just implement something in libvirt that checks what the kernel
> >  supports directly via the well-defined KVM interface and chooses
> >  the highest supported version per default.
> > 
> > To me it sounds like we should just go ahead with (2) and document
> > somehwere that if you get an error, you need to either manually change
> > the gic version setting in your VM definition file or upgrade QEMU.
> > 
> > Can someone with libvirt authority please advice whether (1) or (2) is
> > what we need to do?
> 
> IMHO we should just go for 2.

I'm not familiar enough with libvirt, nor the use of QMP, to really argue
one way or another, but I find it a bit strange that we'd prefer libvirt
to query two entities over one. And, why should the libvirt installed on
a particular host prefer gicv3 as the default, just because KVM supports
it, even when QEMU does not? The default will fail every time until QEMU
is upgraded, which may not be necessary/desired. Finally, I thought we
were trying to get away from relying on QEMU's error messages to make any
sort of decisions.

I don't know what else libvirt queries directly from KVM, but IMO, it
should be a long-term goal to stop doing it, not add to more. Besides
libvirt then properly selecting defaults that both KVM and QEMU support,
it would allow /dev/kvm to have QEMU-only selinux labels applied.

[Qemu-devel] [PULL 1/1] audio: Clean up includes

[Gerd Hoffmann]

From: Peter Maydell 

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes.

Signed-off-by: Peter Maydell 
Message-id: 1453138432-8324-1-git-send-email-peter.mayd...@linaro.org
Signed-off-by: Gerd Hoffmann 
---
 audio/alsaaudio.c  | 1 +
 audio/audio.c  | 1 +
 audio/audio_pt_int.c   | 1 +
 audio/audio_win_int.c  | 1 +
 audio/coreaudio.c  | 2 +-
 audio/dsoundaudio.c| 1 +
 audio/mixeng.c | 1 +
 audio/noaudio.c| 1 +
 audio/ossaudio.c   | 3 +--
 audio/paaudio.c| 1 +
 audio/sdlaudio.c   | 1 +
 audio/spiceaudio.c | 1 +
 audio/wavaudio.c   | 1 +
 audio/wavcapture.c | 1 +
 hw/audio/ac97.c| 1 +
 hw/audio/adlib.c   | 1 +
 hw/audio/cs4231.c  | 1 +
 hw/audio/cs4231a.c | 1 +
 hw/audio/es1370.c  | 1 +
 hw/audio/fmopl.c   | 5 +
 hw/audio/gus.c | 1 +
 hw/audio/gusemu_hal.c  | 1 +
 hw/audio/gusemu_mixer.c| 1 +
 hw/audio/hda-codec.c   | 1 +
 hw/audio/intel-hda.c   | 1 +
 hw/audio/lm4549.c  | 2 +-
 hw/audio/marvell_88w8618.c | 1 +
 hw/audio/milkymist-ac97.c  | 1 +
 hw/audio/pcspk.c   | 1 +
 hw/audio/pl041.c   | 1 +
 hw/audio/sb16.c| 1 +
 hw/audio/wm8750.c  | 1 +
 32 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 6315b2d..3652a7b 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -21,6 +21,7 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+#include "qemu/osdep.h"
 #include 
 #include "qemu-common.h"
 #include "qemu/main-loop.h"
diff --git a/audio/audio.c b/audio/audio.c
index a0fc8b3..e841532 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -21,6 +21,7 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+#include "qemu/osdep.h"
 #include "hw/hw.h"
 #include "audio.h"
 #include "monitor/monitor.h"
diff --git a/audio/audio_pt_int.c b/audio/audio_pt_int.c
index 9a9c306..21ff9c5 100644
--- a/audio/audio_pt_int.c
+++ b/audio/audio_pt_int.c
@@ -1,3 +1,4 @@
+#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "audio.h"
 
diff --git a/audio/audio_win_int.c b/audio/audio_win_int.c
index e132405..698 100644
--- a/audio/audio_win_int.c
+++ b/audio/audio_win_int.c
@@ -1,5 +1,6 @@
 /* public domain */
 
+#include "qemu/osdep.h"
 #include "qemu-common.h"
 
 #define AUDIO_CAP "win-int"
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 7150604..d4ad224 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -22,8 +22,8 @@
  * THE SOFTWARE.
  */
 
+#include "qemu/osdep.h"
 #include 
-#include  /* strerror */
 #include /* pthread_X */
 
 #include "qemu-common.h"
diff --git a/audio/dsoundaudio.c b/audio/dsoundaudio.c
index e9472c1..516846e 100644
--- a/audio/dsoundaudio.c
+++ b/audio/dsoundaudio.c
@@ -26,6 +26,7 @@
  * SEAL 1.07 by Carlos 'pel' Hasan was used as documentation
  */
 
+#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "audio.h"
 
diff --git a/audio/mixeng.c b/audio/mixeng.c
index 0e4976f..981b97a 100644
--- a/audio/mixeng.c
+++ b/audio/mixeng.c
@@ -22,6 +22,7 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "audio.h"
 
diff --git a/audio/noaudio.c b/audio/noaudio.c
index 50db1f3..09588b9 100644
--- a/audio/noaudio.c
+++ b/audio/noaudio.c
@@ -21,6 +21,7 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "audio.h"
 #include "qemu/timer.h"
diff --git a/audio/ossaudio.c b/audio/ossaudio.c
index 7dbe333..349e9dd 100644
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -21,9 +21,8 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
-#include 
+#include "qemu/osdep.h"
 #include 
-#include 
 #include 
 #include 
 #include "qemu-common.h"
diff --git a/audio/paaudio.c b/audio/paaudio.c
index fea6071..57678e7 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -1,4 +1,5 @@
 /* public domain */
+#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "audio.h"
 
diff --git a/audio/sdlaudio.c b/audio/sdlaudio.c
index 1140f2e..db69fe1 100644
--- a/audio/sdlaudio.c
+++ b/audio/sdlaudio.c
@@ -21,6 +21,7 @@
  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  * THE SOFTWARE.
  */
+#include "qemu/osdep.h"
 #include 
 #include 
 #include "qemu-common.h"
diff --git a/audio/spiceaudio.c b/audio/spiceaudio.c
index 42ae4a4..297fd41 100644
--- a/audio/spiceaudio.c
+++ b/audio/spiceaudio.c
@@ -17,6 +17,7 @@
  * along with this program; if not, see 

Re: [Qemu-devel] [PATCH 1/4] usb: make USBDevice->attached bool

[Markus Armbruster]

Gerd Hoffmann  writes:

> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Markus Armbruster 

[Qemu-devel] [PULL 0/1] audio: Clean up includes

[Gerd Hoffmann]

  Hi,

Audio queue, also pretty short ...

please pull,
  Gerd

The following changes since commit 10ae9d76388e3f4a31f6a1475b5e2d1f28404a10:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160201' into 
staging (2016-02-02 09:13:10 +)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-audio-20160202-1

for you to fetch changes up to 6086a565b0efe3eb66c5bf65a715a2c84425e47f:

  audio: Clean up includes (2016-02-02 13:57:31 +0100)


audio: Clean up includes


Peter Maydell (1):
  audio: Clean up includes

 audio/alsaaudio.c  | 1 +
 audio/audio.c  | 1 +
 audio/audio_pt_int.c   | 1 +
 audio/audio_win_int.c  | 1 +
 audio/coreaudio.c  | 2 +-
 audio/dsoundaudio.c| 1 +
 audio/mixeng.c | 1 +
 audio/noaudio.c| 1 +
 audio/ossaudio.c   | 3 +--
 audio/paaudio.c| 1 +
 audio/sdlaudio.c   | 1 +
 audio/spiceaudio.c | 1 +
 audio/wavaudio.c   | 1 +
 audio/wavcapture.c | 1 +
 hw/audio/ac97.c| 1 +
 hw/audio/adlib.c   | 1 +
 hw/audio/cs4231.c  | 1 +
 hw/audio/cs4231a.c | 1 +
 hw/audio/es1370.c  | 1 +
 hw/audio/fmopl.c   | 5 +
 hw/audio/gus.c | 1 +
 hw/audio/gusemu_hal.c  | 1 +
 hw/audio/gusemu_mixer.c| 1 +
 hw/audio/hda-codec.c   | 1 +
 hw/audio/intel-hda.c   | 1 +
 hw/audio/lm4549.c  | 2 +-
 hw/audio/marvell_88w8618.c | 1 +
 hw/audio/milkymist-ac97.c  | 1 +
 hw/audio/pcspk.c   | 1 +
 hw/audio/pl041.c   | 1 +
 hw/audio/sb16.c| 1 +
 hw/audio/wm8750.c  | 1 +
 32 files changed, 32 insertions(+), 8 deletions(-)

[Qemu-devel] [PULL 2/2] sdl: shorten the GUI refresh interval when mouse or keyboard is active

[Gerd Hoffmann]

From: Jindřich Makovička 

Signed-off-by: Jindřich Makovička 
Signed-off-by: Gerd Hoffmann 
---
 include/ui/sdl2.h |  1 +
 ui/sdl.c  | 22 ++
 ui/sdl2.c | 23 +++
 3 files changed, 46 insertions(+)

diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index b7ac38f..3f0b57b 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -19,6 +19,7 @@ struct sdl2_console {
 int hidden;
 int opengl;
 int updates;
+int idle_counter;
 SDL_GLContext winctx;
 #ifdef CONFIG_OPENGL
 ConsoleGLState *gls;
diff --git a/ui/sdl.c b/ui/sdl.c
index c837436..f215fe1 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -60,6 +60,11 @@ static SDL_Cursor *guest_sprite = NULL;
 static SDL_PixelFormat host_format;
 static int scaling_active = 0;
 static Notifier mouse_mode_notifier;
+static int idle_counter;
+
+#define SDL_REFRESH_INTERVAL_BUSY 10
+#define SDL_MAX_IDLE_COUNT (2 * GUI_REFRESH_INTERVAL_DEFAULT \
+/ SDL_REFRESH_INTERVAL_BUSY + 1)
 
 #if 0
 #define DEBUG_SDL
@@ -802,6 +807,7 @@ static void handle_activation(SDL_Event *ev)
 static void sdl_refresh(DisplayChangeListener *dcl)
 {
 SDL_Event ev1, *ev = &ev1;
+int idle = 1;
 
 if (last_vm_running != runstate_is_running()) {
 last_vm_running = runstate_is_running();
@@ -817,9 +823,11 @@ static void sdl_refresh(DisplayChangeListener *dcl)
 sdl_update(dcl, 0, 0, real_screen->w, real_screen->h);
 break;
 case SDL_KEYDOWN:
+idle = 0;
 handle_keydown(ev);
 break;
 case SDL_KEYUP:
+idle = 0;
 handle_keyup(ev);
 break;
 case SDL_QUIT:
@@ -829,10 +837,12 @@ static void sdl_refresh(DisplayChangeListener *dcl)
 }
 break;
 case SDL_MOUSEMOTION:
+idle = 0;
 handle_mousemotion(ev);
 break;
 case SDL_MOUSEBUTTONDOWN:
 case SDL_MOUSEBUTTONUP:
+idle = 0;
 handle_mousebutton(ev);
 break;
 case SDL_ACTIVEEVENT:
@@ -847,6 +857,18 @@ static void sdl_refresh(DisplayChangeListener *dcl)
 break;
 }
 }
+
+if (idle) {
+if (idle_counter < SDL_MAX_IDLE_COUNT) {
+idle_counter++;
+if (idle_counter >= SDL_MAX_IDLE_COUNT) {
+dcl->update_interval = GUI_REFRESH_INTERVAL_DEFAULT;
+}
+}
+} else {
+idle_counter = 0;
+dcl->update_interval = SDL_REFRESH_INTERVAL_BUSY;
+}
 }
 
 static void sdl_mouse_warp(DisplayChangeListener *dcl,
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 46270f4..c0a76d7 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -49,6 +49,10 @@ static int guest_x, guest_y;
 static SDL_Cursor *guest_sprite;
 static Notifier mouse_mode_notifier;
 
+#define SDL2_REFRESH_INTERVAL_BUSY 10
+#define SDL2_MAX_IDLE_COUNT (2 * GUI_REFRESH_INTERVAL_DEFAULT \
+ / SDL2_REFRESH_INTERVAL_BUSY + 1)
+
 static void sdl_update_caption(struct sdl2_console *scon);
 
 static struct sdl2_console *get_scon_from_window(uint32_t window_id)
@@ -578,6 +582,7 @@ static void handle_windowevent(SDL_Event *ev)
 void sdl2_poll_events(struct sdl2_console *scon)
 {
 SDL_Event ev1, *ev = &ev1;
+int idle = 1;
 
 if (scon->last_vm_running != runstate_is_running()) {
 scon->last_vm_running = runstate_is_running();
@@ -587,12 +592,15 @@ void sdl2_poll_events(struct sdl2_console *scon)
 while (SDL_PollEvent(ev)) {
 switch (ev->type) {
 case SDL_KEYDOWN:
+idle = 0;
 handle_keydown(ev);
 break;
 case SDL_KEYUP:
+idle = 0;
 handle_keyup(ev);
 break;
 case SDL_TEXTINPUT:
+idle = 0;
 handle_textinput(ev);
 break;
 case SDL_QUIT:
@@ -602,13 +610,16 @@ void sdl2_poll_events(struct sdl2_console *scon)
 }
 break;
 case SDL_MOUSEMOTION:
+idle = 0;
 handle_mousemotion(ev);
 break;
 case SDL_MOUSEBUTTONDOWN:
 case SDL_MOUSEBUTTONUP:
+idle = 0;
 handle_mousebutton(ev);
 break;
 case SDL_MOUSEWHEEL:
+idle = 0;
 handle_mousewheel(ev);
 break;
 case SDL_WINDOWEVENT:
@@ -618,6 +629,18 @@ void sdl2_poll_events(struct sdl2_console *scon)
 break;
 }
 }
+
+if (idle) {
+if (scon->idle_counter < SDL2_MAX_IDLE_COUNT) {
+scon->idle_counter++;
+if (scon->idle_counter >= SDL2_MAX_IDLE_COUNT) {
+scon->dcl.update_interval = GUI_REFRESH_INTERVAL_DEFAULT;
+}
+}
+} else {
+scon->idle_counter = 0;
+scon->dcl.update_interval = SDL2_REFRESH_INTERVAL_BUSY;
+}
 }
 
 static void sdl_mouse_warp(DisplayChangeListener *dcl,
-- 
1.8.3.1

[Qemu-devel] [PULL 1/2] gtk: use qemu_chr_alloc() to allocate CharDriverState

[Gerd Hoffmann]

From: "Daniel P. Berrange" 

The gd_vc_handler() callback is using g_malloc0() to
allocate the CharDriverState struct. As a result the
logfd field is getting initialized to 0, instead of
-1 when no logfile is requested.

The result is that when running

 $ qemu-system-i386 -nodefaults -chardev vc,id=mon0 -mon chardev=mon0

qemu duplicates all monitor output to stdout as well
as the GTK window.

Not using qemu_chr_alloc() was already a bug, but harmless
until this commit

  commit d0d7708ba29cbcc343364a46bff981e0ff88366f
  Author: Daniel P. Berrange 
  Date:   Mon Jan 11 12:44:41 2016 +

qemu-char: add logfile facility to all chardev backends

which exposed the problem as a behaviour regression

Reported-by: Hervé Poussineau 
Signed-off-by: Daniel P. Berrange 
Reviewed-by: Eric Blake 
Tested-by: Hervé Poussineau 
Message-id: 1453377386-10190-1-git-send-email-berra...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/gtk.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index ce7018e..c8dbd5c 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1598,11 +1598,16 @@ static void gd_vc_chr_set_echo(CharDriverState *chr, 
bool echo)
 static int nb_vcs;
 static CharDriverState *vcs[MAX_VCS];
 
-static CharDriverState *gd_vc_handler(ChardevVC *unused, Error **errp)
+static CharDriverState *gd_vc_handler(ChardevVC *vc, Error **errp)
 {
+ChardevCommon *common = qapi_ChardevVC_base(vc);
 CharDriverState *chr;
 
-chr = g_malloc0(sizeof(*chr));
+chr = qemu_chr_alloc(common, errp);
+if (!chr) {
+return NULL;
+}
+
 chr->chr_write = gd_vc_chr_write;
 chr->chr_set_echo = gd_vc_chr_set_echo;
 
-- 
1.8.3.1

[Qemu-devel] [PULL 0/2] ui: gtk vc fix, adaptive sdl refresh.

[Gerd Hoffmann]

  Hi,

Two ui patches, for gtk and sdl.

please pull,
  Gerd

The following changes since commit 10ae9d76388e3f4a31f6a1475b5e2d1f28404a10:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160201' into 
staging (2016-02-02 09:13:10 +)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-ui-20160202-1

for you to fetch changes up to 56bdd4b69aa10bec274b1e812685bcf44dcb0c72:

  sdl: shorten the GUI refresh interval when mouse or keyboard is active 
(2016-02-02 14:05:07 +0100)


ui: gtk vc fix, adaptive sdl refresh.


Daniel P. Berrange (1):
  gtk: use qemu_chr_alloc() to allocate CharDriverState

Jindřich Makovička (1):
  sdl: shorten the GUI refresh interval when mouse or keyboard is active

 include/ui/sdl2.h |  1 +
 ui/gtk.c  |  9 +++--
 ui/sdl.c  | 22 ++
 ui/sdl2.c | 23 +++
 4 files changed, 53 insertions(+), 2 deletions(-)

[Qemu-devel] [PULL v1 0/3] Misc fixes for crypto/ code

[Daniel P. Berrange]

The following changes since commit 0430891ce162b986c6e02a7729a942ecd2a32ca4:

  hw: Clean up includes (2016-01-29 15:07:25 +)

are available in the git repository at:

  git://github.com/berrange/qemu tags/pull-qcrypto-next-2016-02-02-1

for you to fetch changes up to c0377a7cc6cb46aba295b744d237aeed94087ac0:

  crypto: ensure qcrypto_hash_digest_len is always defined (2016-02-02 13:02:56 
+)


Merge qcrypto-next 2016/2/2 v1



Daniel P. Berrange (3):
  crypto: fix description of @errp parameter initialization
  crypto: register properties against the class instead of object
  crypto: ensure qcrypto_hash_digest_len is always defined

 crypto/hash.c   | 30 +--
 crypto/secret.c | 60 -
 crypto/tlscreds.c   | 36 +++
 crypto/tlscredsanon.c   | 16 
 crypto/tlscredsx509.c   | 26 ++--
 include/crypto/cipher.h |  8 +++---
 include/crypto/hash.h   | 12 -
 include/crypto/tlssession.h |  8 +++---
 8 files changed, 97 insertions(+), 99 deletions(-)

-- 
2.5.0

[Qemu-devel] [PULL v1 3/3] crypto: ensure qcrypto_hash_digest_len is always defined

[Daniel P. Berrange]

The qcrypto_hash_digest_len method was accidentally inside
a CONFIG_GNUTLS_HASH block, even though it doesn't depend
on gnutls. Re-arrange it to be unconditionally defined.

Reviewed-by: Fam Zheng 
Signed-off-by: Daniel P. Berrange 
---
 crypto/hash.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/crypto/hash.c b/crypto/hash.c
index 33324b6..4a8c0ca 100644
--- a/crypto/hash.c
+++ b/crypto/hash.c
@@ -24,12 +24,8 @@
 #ifdef CONFIG_GNUTLS_HASH
 #include 
 #include 
+#endif
 
-static int qcrypto_hash_alg_map[QCRYPTO_HASH_ALG__MAX] = {
-[QCRYPTO_HASH_ALG_MD5] = GNUTLS_DIG_MD5,
-[QCRYPTO_HASH_ALG_SHA1] = GNUTLS_DIG_SHA1,
-[QCRYPTO_HASH_ALG_SHA256] = GNUTLS_DIG_SHA256,
-};
 
 static size_t qcrypto_hash_alg_size[QCRYPTO_HASH_ALG__MAX] = {
 [QCRYPTO_HASH_ALG_MD5] = 16,
@@ -37,14 +33,6 @@ static size_t qcrypto_hash_alg_size[QCRYPTO_HASH_ALG__MAX] = 
{
 [QCRYPTO_HASH_ALG_SHA256] = 32,
 };
 
-gboolean qcrypto_hash_supports(QCryptoHashAlgorithm alg)
-{
-if (alg < G_N_ELEMENTS(qcrypto_hash_alg_map)) {
-return true;
-}
-return false;
-}
-
 size_t qcrypto_hash_digest_len(QCryptoHashAlgorithm alg)
 {
 if (alg >= G_N_ELEMENTS(qcrypto_hash_alg_size)) {
@@ -54,6 +42,22 @@ size_t qcrypto_hash_digest_len(QCryptoHashAlgorithm alg)
 }
 
 
+#ifdef CONFIG_GNUTLS_HASH
+static int qcrypto_hash_alg_map[QCRYPTO_HASH_ALG__MAX] = {
+[QCRYPTO_HASH_ALG_MD5] = GNUTLS_DIG_MD5,
+[QCRYPTO_HASH_ALG_SHA1] = GNUTLS_DIG_SHA1,
+[QCRYPTO_HASH_ALG_SHA256] = GNUTLS_DIG_SHA256,
+};
+
+gboolean qcrypto_hash_supports(QCryptoHashAlgorithm alg)
+{
+if (alg < G_N_ELEMENTS(qcrypto_hash_alg_map)) {
+return true;
+}
+return false;
+}
+
+
 int qcrypto_hash_bytesv(QCryptoHashAlgorithm alg,
 const struct iovec *iov,
 size_t niov,
-- 
2.5.0

[Qemu-devel] [PULL v1 1/3] crypto: fix description of @errp parameter initialization

[Daniel P. Berrange]

The "Error **errp" parameters must be NULL initialized
not uninitialized.

Signed-off-by: Daniel P. Berrange 
---
 include/crypto/cipher.h |  8 
 include/crypto/hash.h   | 12 ++--
 include/crypto/tlssession.h |  8 
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/crypto/cipher.h b/include/crypto/cipher.h
index a812803..f90ac79 100644
--- a/include/crypto/cipher.h
+++ b/include/crypto/cipher.h
@@ -138,7 +138,7 @@ size_t qcrypto_cipher_get_iv_len(QCryptoCipherAlgorithm alg,
  * @mode: the cipher usage mode
  * @key: the private key bytes
  * @nkey: the length of @key
- * @errp: pointer to an uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Creates a new cipher object for encrypting/decrypting
  * data with the algorithm @alg in the usage mode @mode.
@@ -174,7 +174,7 @@ void qcrypto_cipher_free(QCryptoCipher *cipher);
  * @in: buffer holding the plain text input data
  * @out: buffer to fill with the cipher text output data
  * @len: the length of @in and @out buffers
- * @errp: pointer to an uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Encrypts the plain text stored in @in, filling
  * @out with the resulting ciphered text. Both the
@@ -196,7 +196,7 @@ int qcrypto_cipher_encrypt(QCryptoCipher *cipher,
  * @in: buffer holding the cipher text input data
  * @out: buffer to fill with the plain text output data
  * @len: the length of @in and @out buffers
- * @errp: pointer to an uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Decrypts the cipher text stored in @in, filling
  * @out with the resulting plain text. Both the
@@ -216,7 +216,7 @@ int qcrypto_cipher_decrypt(QCryptoCipher *cipher,
  * @cipher: the cipher object
  * @iv: the initialization vector bytes
  * @niv: the length of @iv
- * @errpr: pointer to an uninitialized error object
+ * @errpr: pointer to a NULL-initialized error object
  *
  * If the @cipher object is setup to use a mode that requires
  * initialization vectors, this sets the initialization vector
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 41822c0..5e8d9a1 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -55,7 +55,7 @@ size_t qcrypto_hash_digest_len(QCryptoHashAlgorithm alg);
  * @niov: the length of @iov
  * @result: pointer to hold output hash
  * @resultlen: pointer to hold length of @result
- * @errp: pointer to uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Computes the hash across all the memory regions
  * present in @iov. The @result pointer will be
@@ -80,7 +80,7 @@ int qcrypto_hash_bytesv(QCryptoHashAlgorithm alg,
  * @len: the length of @buf
  * @result: pointer to hold output hash
  * @resultlen: pointer to hold length of @result
- * @errp: pointer to uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Computes the hash across all the memory region
  * @buf of length @len. The @result pointer will be
@@ -104,7 +104,7 @@ int qcrypto_hash_bytes(QCryptoHashAlgorithm alg,
  * @iov: the array of memory regions to hash
  * @niov: the length of @iov
  * @digest: pointer to hold output hash
- * @errp: pointer to uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Computes the hash across all the memory regions
  * present in @iov. The @digest pointer will be
@@ -127,7 +127,7 @@ int qcrypto_hash_digestv(QCryptoHashAlgorithm alg,
  * @buf: the memory region to hash
  * @len: the length of @buf
  * @digest: pointer to hold output hash
- * @errp: pointer to uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Computes the hash across all the memory region
  * @buf of length @len. The @digest pointer will be
@@ -150,7 +150,7 @@ int qcrypto_hash_digest(QCryptoHashAlgorithm alg,
  * @iov: the array of memory regions to hash
  * @niov: the length of @iov
  * @base64: pointer to hold output hash
- * @errp: pointer to uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Computes the hash across all the memory regions
  * present in @iov. The @base64 pointer will be
@@ -173,7 +173,7 @@ int qcrypto_hash_base64v(QCryptoHashAlgorithm alg,
  * @buf: the memory region to hash
  * @len: the length of @buf
  * @base64: pointer to hold output hash
- * @errp: pointer to uninitialized error object
+ * @errp: pointer to a NULL-initialized error object
  *
  * Computes the hash across all the memory region
  * @buf of length @len. The @base64 pointer will be
diff --git a/include/crypto/tlssession.h b/include/crypto/tlssession.h
index d356a8d..c1bad9e 100644
--- a/include/crypto/tlssession.h
+++ b/include/crypto/tlssession.h
@@ -114,7 +114,7 @@ typedef struct QCryptoTLSSession QCryptoTLSSession;
  * @hostname: optional hostname to validate
  * @aclname: optional ACL to validate peer credentials against
  

[Qemu-devel] [PULL v1 2/3] crypto: register properties against the class instead of object

[Daniel P. Berrange]

This converts the tlscredsx509, tlscredsanon and secret objects
to register their properties against the class rather than object.

Signed-off-by: Daniel P. Berrange 
---
 crypto/secret.c   | 60 +++
 crypto/tlscreds.c | 36 ++-
 crypto/tlscredsanon.c | 16 +-
 crypto/tlscredsx509.c | 26 +++---
 4 files changed, 66 insertions(+), 72 deletions(-)

diff --git a/crypto/secret.c b/crypto/secret.c
index 90592c0..be736f2 100644
--- a/crypto/secret.c
+++ b/crypto/secret.c
@@ -353,38 +353,6 @@ qcrypto_secret_complete(UserCreatable *uc, Error **errp)
 
 
 static void
-qcrypto_secret_init(Object *obj)
-{
-object_property_add_bool(obj, "loaded",
- qcrypto_secret_prop_get_loaded,
- qcrypto_secret_prop_set_loaded,
- NULL);
-object_property_add_enum(obj, "format",
- "QCryptoSecretFormat",
- QCryptoSecretFormat_lookup,
- qcrypto_secret_prop_get_format,
- qcrypto_secret_prop_set_format,
- NULL);
-object_property_add_str(obj, "data",
-qcrypto_secret_prop_get_data,
-qcrypto_secret_prop_set_data,
-NULL);
-object_property_add_str(obj, "file",
-qcrypto_secret_prop_get_file,
-qcrypto_secret_prop_set_file,
-NULL);
-object_property_add_str(obj, "keyid",
-qcrypto_secret_prop_get_keyid,
-qcrypto_secret_prop_set_keyid,
-NULL);
-object_property_add_str(obj, "iv",
-qcrypto_secret_prop_get_iv,
-qcrypto_secret_prop_set_iv,
-NULL);
-}
-
-
-static void
 qcrypto_secret_finalize(Object *obj)
 {
 QCryptoSecret *secret = QCRYPTO_SECRET(obj);
@@ -402,6 +370,33 @@ qcrypto_secret_class_init(ObjectClass *oc, void *data)
 UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
 
 ucc->complete = qcrypto_secret_complete;
+
+object_class_property_add_bool(oc, "loaded",
+   qcrypto_secret_prop_get_loaded,
+   qcrypto_secret_prop_set_loaded,
+   NULL);
+object_class_property_add_enum(oc, "format",
+   "QCryptoSecretFormat",
+   QCryptoSecretFormat_lookup,
+   qcrypto_secret_prop_get_format,
+   qcrypto_secret_prop_set_format,
+   NULL);
+object_class_property_add_str(oc, "data",
+  qcrypto_secret_prop_get_data,
+  qcrypto_secret_prop_set_data,
+  NULL);
+object_class_property_add_str(oc, "file",
+  qcrypto_secret_prop_get_file,
+  qcrypto_secret_prop_set_file,
+  NULL);
+object_class_property_add_str(oc, "keyid",
+  qcrypto_secret_prop_get_keyid,
+  qcrypto_secret_prop_set_keyid,
+  NULL);
+object_class_property_add_str(oc, "iv",
+  qcrypto_secret_prop_get_iv,
+  qcrypto_secret_prop_set_iv,
+  NULL);
 }
 
 
@@ -493,7 +488,6 @@ static const TypeInfo qcrypto_secret_info = {
 .parent = TYPE_OBJECT,
 .name = TYPE_QCRYPTO_SECRET,
 .instance_size = sizeof(QCryptoSecret),
-.instance_init = qcrypto_secret_init,
 .instance_finalize = qcrypto_secret_finalize,
 .class_size = sizeof(QCryptoSecretClass),
 .class_init = qcrypto_secret_class_init,
diff --git a/crypto/tlscreds.c b/crypto/tlscreds.c
index 38bb671..fc99589 100644
--- a/crypto/tlscreds.c
+++ b/crypto/tlscreds.c
@@ -199,26 +199,31 @@ qcrypto_tls_creds_prop_get_endpoint(Object *obj,
 
 
 static void
+qcrypto_tls_creds_class_init(ObjectClass *oc, void *data)
+{
+object_class_property_add_bool(oc, "verify-peer",
+   qcrypto_tls_creds_prop_get_verify,
+   qcrypto_tls_creds_prop_set_verify,
+   NULL);
+object_class_property_add_str(oc, "dir",
+  qcrypto_tls_creds_prop_get_dir,
+  qcrypto_tls_creds_prop_set_dir,
+  NULL);
+object_class_property_add_enum(oc, "endpoint",
+   "QCryptoTLSCredsEndpoint",
+

Re: [Qemu-devel] [libvirt] ARM KVM GICv3 Support

[Peter Maydell]

On 2 February 2016 at 12:59, Andrew Jones  wrote:
> This actually doesn't matter for the v2 vs. v3 case. The gic-version property
> doesn't exist at all for v2-only QEMU. Although maybe the gic-version property
> should be reworked. Instead of gic-version=, we could 
> create
> one boolean property per version supported, i.e. gicv2, gicv3, gicv4...

QEMU 2.5 released with the gic-version property, so we can't just drop
it now; that would break users' command lines. We'd need a strong
argument for why it's worth adding new properties that duplicate
the legacy syntax.

thanks
- PMM

Re: [Qemu-devel] [PATCH 1/2] block: fix assert in qcow2_get_specific_info

[Paolo Bonzini]

On 20/01/2016 08:12, Denis V. Lunev wrote:
> There is a possibility to hit assert qcow2_get_specific_info that
> s->qcow_version is undefined. This happens when VM in starting from
> suspended state, i.e. it processes incoming migration, and in the same
> time 'info block' is called.
> 
> The problem is that in the qcow2_invalidate_cache closes and the image
> and memsets BDRVQcowState in the middle.
> 
> The patch moves processing of qcow2_get_specific_info into coroutine
> context and ensures that qcow2_invalidate_cache and qcow2_get_specific_info
> can not run simultaneosly.

I'm sitting next to Kevin :) and this is not a qcow2 bug.

The problem is that qcow2_invalidate_cache is being called in coroutine
context.  The process_incoming_migration_co code starting with
bdrv_invalidate_cache_all should be moved out of the coroutine and into
the main loop.  You can use a bottom half to get out of coroutine context.

The result should be a much simpler patch, too.

Thanks, and sorry for the delay.  I saw qcow2 in the title and assumed
it was something I knew nothing about. :)

Paolo

[Qemu-devel] [PULL 2/2] ehci: update irq on reset

[Gerd Hoffmann]

After clearing the status register we also have to update the irq line
status.  Otherwise a irq which happends to be pending at reset time
causes a interrupt storm.  And the guest can't stop as the status
register doesn't indicate any pending interrupt.

Both NetBSD and FreeBSD hang on shutdown because of that.

Cc: qemu-sta...@nongnu.org
Reported-by: Andrey Korolyov 
Signed-off-by: Gerd Hoffmann 
Message-id: 1453203884-4125-1-git-send-email-kra...@redhat.com
---
 hw/usb/hcd-ehci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 93601d9..1b50601 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -866,6 +866,7 @@ void ehci_reset(void *opaque)
 s->usbsts = USBSTS_HALT;
 s->usbsts_pending = 0;
 s->usbsts_frindex = 0;
+ehci_update_irq(s);
 
 s->astate = EST_INACTIVE;
 s->pstate = EST_INACTIVE;
-- 
1.8.3.1

[Qemu-devel] [PULL 0/2] usb: two ehci fixes.

[Gerd Hoffmann]

  Hi,

Here is the usb patch queue with two ehci fixes.

please pull,
  Gerd

The following changes since commit 10ae9d76388e3f4a31f6a1475b5e2d1f28404a10:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.6-20160201' into 
staging (2016-02-02 09:13:10 +)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-usb-20160202-1

for you to fetch changes up to 5a8660741a8aa19fbf8a5e8a2b3aac88664f4e66:

  ehci: update irq on reset (2016-02-02 14:11:01 +0100)


usb: two ehci fixes.


Gerd Hoffmann (1):
  ehci: update irq on reset

Prasad J Pandit (1):
  usb: check page select value while processing iTD

 hw/usb/hcd-ehci.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

[Qemu-devel] [PULL 1/2] usb: check page select value while processing iTD

[Gerd Hoffmann]

From: Prasad J Pandit 

While processing isochronous transfer descriptors(iTD), the page
select(PG) field value could lead to an OOB read access. Add
check to avoid it.

Reported-by: Qinghao Tang 
Signed-off-by: Prasad J Pandit 
Message-id: 1453233406-12165-1-git-send-email-ppan...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 hw/usb/hcd-ehci.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index ab00268..93601d9 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -1405,21 +1405,23 @@ static int ehci_process_itd(EHCIState *ehci,
 if (itd->transact[i] & ITD_XACT_ACTIVE) {
 pg   = get_field(itd->transact[i], ITD_XACT_PGSEL);
 off  = itd->transact[i] & ITD_XACT_OFFSET_MASK;
-ptr1 = (itd->bufptr[pg] & ITD_BUFPTR_MASK);
-ptr2 = (itd->bufptr[pg+1] & ITD_BUFPTR_MASK);
 len  = get_field(itd->transact[i], ITD_XACT_LENGTH);
 
 if (len > max * mult) {
 len = max * mult;
 }
-
-if (len > BUFF_SIZE) {
+if (len > BUFF_SIZE || pg > 6) {
 return -1;
 }
 
+ptr1 = (itd->bufptr[pg] & ITD_BUFPTR_MASK);
 qemu_sglist_init(&ehci->isgl, ehci->device, 2, ehci->as);
 if (off + len > 4096) {
 /* transfer crosses page border */
+if (pg == 6) {
+return -1;  /* avoid page pg + 1 */
+}
+ptr2 = (itd->bufptr[pg + 1] & ITD_BUFPTR_MASK);
 uint32_t len2 = off + len - 4096;
 uint32_t len1 = len - len2;
 qemu_sglist_add(&ehci->isgl, ptr1 + off, len1);
-- 
1.8.3.1

[Qemu-devel] vl.c:main_loop() non-blocking TCG optimization still useful?

[Stefan Hajnoczi]

Hi Jan,
In 2011 the following patch was merged to optimize I/O vs vcpu scheduling:

commit c9f711a5d31e22dac932c1c01e9c0f97caff0988
Author: Jan Kiszka 
Date:   Mon Aug 22 17:46:02 2011 +0200

Poll main loop after I/O events were received

This was back in the days of CONFIG_IOTHREAD.  Things have changed
quite a bit since then.

Do you think the last_io/non-blocking trick is still needed today in TCG?

Thanks,
Stefan

Re: [Qemu-devel] [PATCH 2/4] usb: add attached property

[Markus Armbruster]

Suggest to say

usb: Add QOM property "attached"

The quotes make more obvious that "attached" is a property name, not an
adjective tacked to property.

Gerd Hoffmann  writes:

> USB devices in attached state are visible to the guest.

If I read the code correctly:

* ->attached is true between usb_device_attach() and usb_device_detach()

* Attach and detach is automatic on realize and unrealize, but a device
  can choose to suppress attach on realize, by unsetting ->auto_attach,
  and manage attach/detach itself.

* A detached device is wired up normally in QOM, but the USB core treats
  it as not plugged into its USB port.

Correct?

>  This patch adds
> a QOM property for this.  Write access is opt-in per device.  Some
> devices manage attached state automatically (usb-host, usb-serial), so

Full list of devices unsetting ->auto_attach: dev-serial.c dev-storage.c
host-libusb.c redirect.c.

dev-storage.c does it only for encrypted media without a key, but that
should go away with Dan's "Support LUKS encryption in block devices", so
I guess neglecting to mention it here is okay.

Suggest to add usb-redir to your list.

> we can't enable write access universally but have to do it on a case by
> case base.

Suggest to add: So far, no device opts in.

>
> Signed-off-by: Gerd Hoffmann 

Patch looks good.

Re: [Qemu-devel] [PATCH 3/4] usb-bot: hotplug support

[Markus Armbruster]

Gerd Hoffmann  writes:

> This patch marks usb-bot as hot-pluggable device, makes attached
> property settable and turns off auto-attach in case the device
> was hotplugged.
>
> Hot-plugging a usb-bot device with one or more scsi devices can be
> done this way now:
>
>   (1) device-add usb-bot,id=foo
>   (2) device-add scsi-{hd,cd},bus=foo.0,lun=0
>   (2b) optionally add more devices (luns 0 ... 15).
>   (3) qom-set foo.attached = true

This isn't exactly pretty, but it beats no hot plug.

A general solution for hot plugging composite devices could perhaps be
prettier, but I'm not aware of any recent work in the area.  Andreas,
Paolo?

> Signed-off-by: Gerd Hoffmann 

Assuming we want this because we can't have a general solution now:

Reviewed-by: Markus Armbruster