Re: [Xen-devel] [PATCH v2] aarch64: advertise the GIC system register interface

2017-11-07 Thread Peter Maydell
On 7 November 2017 at 17:57, Stefano Stabellini <sstabell...@kernel.org> wrote:
> On Tue, 7 Nov 2017, Peter Maydell wrote:
>> I thought about this on the cycle into work this morning, and I
>> think that rather than require every board that uses gicv3
>> to set a property on the CPU, we should change the definition
>> of the id_aa64pfr0 register so that rather than being ARM_CP_CONST
>> it has a readfn, and then at runtime we can get that readfn to
>> add in the right bit if env->gicv3state is non-null.
>>
>> I'll put together a patch this afternoon.
>
> Great, please CC me when you do, I'll help you test the patch.

http://patchwork.ozlabs.org/patch/835300/ -- should already be
in your inbox somewhere...

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2] aarch64: advertise the GIC system register interface

2017-11-07 Thread Peter Maydell
On 6 November 2017 at 22:16, Stefano Stabellini  wrote:
> When QEMU emulates a GICv3, it needs to advertise the presence of the
> system register interface, which is done via id_aa64pfr0.
>
> To do that, and at the same time to avoid advertising the presence of
> the system register interface when it is actually not available, set a
> boolean property in machvirt_init. Check on the boolean property from
> register_cp_regs_for_features and set id_aa64pfr0 accordingly.
>
> Signed-off-by: Stefano Stabellini 
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 9e18b41..369d36b 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1401,6 +1401,9 @@ static void machvirt_init(MachineState *machine)
>  object_property_set_link(cpuobj, OBJECT(secure_sysmem),
>   "secure-memory", _abort);
>  }
> +if (vms->gic_version == 3) {
> +object_property_set_bool(cpuobj, true, "gicv3-sysregs", NULL);
> +}
>
>  object_property_set_bool(cpuobj, true, "realized", NULL);
>  object_unref(cpuobj);

I thought about this on the cycle into work this morning, and I
think that rather than require every board that uses gicv3
to set a property on the CPU, we should change the definition
of the id_aa64pfr0 register so that rather than being ARM_CP_CONST
it has a readfn, and then at runtime we can get that readfn to
add in the right bit if env->gicv3state is non-null.

I'll put together a patch this afternoon.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events

2017-11-02 Thread Peter Maydell
On 2 November 2017 at 17:18, Liang Yan  wrote:
> New tigervnc changes the way to send long pressed key,
> from "down up down up ..." to "down down ... up", it only
> affects xen pv console mode. I send a patch to latest
> kernel side, but it may have a fix in qemu backend for
> back compatible becase guest VMs may use very old kernel.
> This patch inserts an up event after each regular key down
> event to simulate an auto-repeat key event for xen keyboard
> frontend driver.
>
> Signed-off-by: Liang Yan 
> ---
> v2:
> - exclude extended key
> - change log comment
>
>  hw/display/xenfb.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 8e2547ac05..1bc5b41ab7 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -292,6 +292,11 @@ static void xenfb_key_event(void *opaque, int scancode)
>  }
>  trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
>  xenfb_send_key(xenfb, down, scancode2linux[scancode]);
> +
> +/* insert an up event for regular down key event */
> +if (down && !xenfb->extended) {
> +xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
> +}
>  }

This doesn't look to me like the right place to fix this bug.
The xenfb key event handler is just one QEMU keyboard backend
(in a setup where there are many possible sources of keyboard
events: vnc, gtk, SDL, cocoa UI frontends; and many possible
sinks: xenfb's key handling, ps2 keyboard emulator, etc etc).

We need to be clear in our definition of generic QEMU key
events how key repeat is supposed to be handled, and then
every consumer and every producer needs to follow that.
In the specific case of the vnc UI frontend, we need to
also look at what the VNC protocol specifies for key repeat.
That then tells us whether the bug to be fixed is in QEMU,
or in a particular VNC client.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

2017-10-31 Thread Peter Maydell
On 31 October 2017 at 18:51, Stefano Stabellini <sstabell...@kernel.org> wrote:
> On Tue, 31 Oct 2017, Peter Maydell wrote:
>> On 31 October 2017 at 17:01, Stefano Stabellini <sstabell...@kernel.org> 
>> wrote:
>> > Fixing QEMU is harder than I expected. Would it be possible to update
>> > id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?
>>
>> At that point we've already called register_cp_regs_for_features(),
>> which is where we read cpu->id_aa64pfr0 when we're creating the
>> cpreg. So if you change it after that it's too late. But that
>> function is called at CPU realize time, which is before we've
>> created the GIC object...
>
> What about something along the lines of
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 9e18b41..0851071 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1401,6 +1400,10 @@ static void machvirt_init(MachineState *machine)
>  object_property_set_link(cpuobj, OBJECT(secure_sysmem),
>   "secure-memory", _abort);
>  }
> +if (vms->gic_version == 3) {
> +ARMCPU *cpu = ARM_CPU(cpuobj);
> +cpu->id_aa64pfr0 |= 0x0100;
> +}
>
>  object_property_set_bool(cpuobj, true, "realized", NULL);
>  object_unref(cpuobj);

Definitely not -- the virt board should not be poking about inside the
internals of the CPU object.

The slightly cleaned up version of this idea is that you give the
CPU an object property for "claim the GICv3 registers exist in the
ID registers" and have virt.c set it. That feels like an ugly
workaround for something we really ought not to have to tell the
board about at all, though.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

2017-10-31 Thread Peter Maydell
On 31 October 2017 at 17:01, Stefano Stabellini  wrote:
> Fixing QEMU is harder than I expected. Would it be possible to update
> id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?

At that point we've already called register_cp_regs_for_features(),
which is where we read cpu->id_aa64pfr0 when we're creating the
cpreg. So if you change it after that it's too late. But that
function is called at CPU realize time, which is before we've
created the GIC object...

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

2017-10-31 Thread Peter Maydell
On 19 October 2017 at 15:46, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 18 October 2017 at 01:10, Stefano Stabellini <sstabell...@kernel.org> 
> wrote:
>> Advertise the presence of the GIC system register interface (1<<24)
>> according to H9.248 of the ARM ARM.
>>
>> This patch allows Xen to boot on QEMU aarch64.
>>
>> Signed-off-by: Stefano Stabellini <sstabell...@kernel.org>
>>
>> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
>> index 670c07a..a451763 100644
>> --- a/target/arm/cpu64.c
>> +++ b/target/arm/cpu64.c
>> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj)
>>  cpu->id_isar3 = 0x01112131;
>>  cpu->id_isar4 = 0x00011142;
>>  cpu->id_isar5 = 0x00011121;
>> -cpu->id_aa64pfr0 = 0x;
>> +cpu->id_aa64pfr0 = 0x0100;
>>  cpu->id_aa64dfr0 = 0x10305106;
>>  cpu->pmceid0 = 0x;
>>  cpu->pmceid1 = 0x;
>> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj)
>>  cpu->id_isar3 = 0x01112131;
>>  cpu->id_isar4 = 0x00011142;
>>  cpu->id_isar5 = 0x00011121;
>> -cpu->id_aa64pfr0 = 0x;
>> +cpu->id_aa64pfr0 = 0x0100;
>>  cpu->id_aa64dfr0 = 0x10305106;
>>  cpu->id_aa64isar0 = 0x00011120;
>>  cpu->id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */
>
> Whoops -- we missed this when we added the GICv3 support, because
> Linux doesn't check it.
>
> Applied to target-arm.next, thanks.

Unfortunately I've just noticed that this breaks booting Linux
in the "not using gicv3" case. This is because we don't actually
define the GICv3 cpu interface registers unless the board
instantiates a GICv3. We mustn't advertise the GICv3 sysregs
in the ID register unless we actually have them.

Not sure how best to fix this -- it's a consequence of the
design decision we made to have the sysregs implementation
be in the gicv3 code. There's no useful feature bit in the CPU
to hang this off either, it's an effect of whether the board
model happens to wire up a gicv3 or not. So we can only figure
this out fairly late on (probably at CPU reset time), which
is a bit tedious for getting ID reg values right.

In the meantime I've dropped this patch from target-arm.next.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/3] xen-20171026-tag

2017-10-28 Thread Peter Maydell
On 26 October 2017 at 23:59, Stefano Stabellini  wrote:
> The following changes since commit 325a084c1ebccb265a3c8f1dd092ffbbfb448a00:
>
>   Merge remote-tracking branch 
> 'remotes/stefanberger/tags/pull-tpm-2017-10-24-1' into staging (2017-10-26 
> 09:20:11 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20171026-tag
>
> for you to fetch changes up to 7cdcca725b6bfc96634c15e3f74ae4b148cf9c40:
>
>   xen: Log errno rather than return value (2017-10-26 14:26:48 -0700)
>
> 
> Xen 2017/10/26
>
> 
> Juergen Gross (2):
>   xen: add a global indicator for grant copy being available
>   xen: dont try setting max grants multiple times
>
> Ross Lagerwall (1):
>   xen: Log errno rather than return value

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

2017-10-19 Thread Peter Maydell
On 18 October 2017 at 01:10, Stefano Stabellini  wrote:
> Advertise the presence of the GIC system register interface (1<<24)
> according to H9.248 of the ARM ARM.
>
> This patch allows Xen to boot on QEMU aarch64.
>
> Signed-off-by: Stefano Stabellini 
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 670c07a..a451763 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj)
>  cpu->id_isar3 = 0x01112131;
>  cpu->id_isar4 = 0x00011142;
>  cpu->id_isar5 = 0x00011121;
> -cpu->id_aa64pfr0 = 0x;
> +cpu->id_aa64pfr0 = 0x0100;
>  cpu->id_aa64dfr0 = 0x10305106;
>  cpu->pmceid0 = 0x;
>  cpu->pmceid1 = 0x;
> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj)
>  cpu->id_isar3 = 0x01112131;
>  cpu->id_isar4 = 0x00011142;
>  cpu->id_isar5 = 0x00011121;
> -cpu->id_aa64pfr0 = 0x;
> +cpu->id_aa64pfr0 = 0x0100;
>  cpu->id_aa64dfr0 = 0x10305106;
>  cpu->id_aa64isar0 = 0x00011120;
>  cpu->id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */

Whoops -- we missed this when we added the GICv3 support, because
Linux doesn't check it.

Applied to target-arm.next, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

2017-10-06 Thread Peter Maydell
On 4 October 2017 at 17:18, Ian Jackson  wrote:
> This allows the caller to specify a uid and gid to use, even if there
> is no corresponding password entry.  This will be useful in certain
> Xen configurations.
>
> Signed-off-by: Ian Jackson 
> ---


> @@ -166,17 +187,19 @@ void os_parse_cmd_args(int index, const char *optarg)
>
>  static void change_process_uid(void)
>  {
> -if (user_pwd) {
> -if (setgid(user_pwd->pw_gid) < 0) {
> +if (user_pwd || user_uid != (uid_t)-1) {
> +if (setgid(user_pwd ? user_pwd->pw_gid : user_gid) < 0) {
>  fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);

If you're changing the gid we pass to setgid() I think you should
also change the value we tell the user we tried to use in the
error message, or it could be rather confusing.

>  exit(1);
>  }
> -if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
> +if ((user_pwd
> + ? initgroups(user_pwd->pw_name, user_pwd->pw_gid)
> + : setgroups(1, _gid)) < 0) {
>  fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
>  user_pwd->pw_name, user_pwd->pw_gid);

...and here we might claim we failed initgroups() when we actually
failed setgroups().

>  exit(1);
>  }
> -if (setuid(user_pwd->pw_uid) < 0) {
> +if (setuid(user_pwd ? user_pwd->pw_uid : user_gid) < 0) {
>  fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid);

This error message should be updated too.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-arm] [Qemu-devel] [PATCH v1 1/8] Replace all occurances of __FUNCTION__ with __func__

2017-09-27 Thread Peter Maydell
On 26 September 2017 at 06:32, Eric Blake  wrote:
> On 09/25/2017 07:08 PM, Alistair Francis wrote:
>> diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
>> index 58005b6619..32687afced 100644
>> --- a/hw/arm/nseries.c
>> +++ b/hw/arm/nseries.c
>> @@ -463,7 +463,7 @@ static uint32_t mipid_txrx(void *opaque, uint32_t cmd, 
>> int len)
>>  uint8_t ret;
>>
>>  if (len > 9) {
>> -hw_error("%s: FIXME: bad SPI word width %i\n", __FUNCTION__, len);
>> +hw_error("%s: FIXME: bad SPI word width %i\n", __func__, len);
>
> Not this patch's problem, but it would probably be simpler if hw_error()
> were a macro that automatically prefixed __func__, rather than making
> every caller have to supply it themselves.

I'm not sure there's a great deal of benefit to that change, because
use of hw_error() in new code is rarely correct (it does an abort()
so it should never be used for guest-triggered conditions, which is
about the only time that you might be interested in a guest register
dump rather than just asserting). Most of its existing uses are in
crufty old device models.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] xen-20170920-tag

2017-09-21 Thread Peter Maydell
On 21 September 2017 at 03:21, Stefano Stabellini
 wrote:
> The following changes since commit b62b7ed0fc9c58e373b8946c9bd2e193be98dae6:
>
>   Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging 
> (2017-09-20 20:33:48 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170920-tag
>
> for you to fetch changes up to a8036336609d2e184fc3543a4c439c0ba7d7f3a2:
>
>   xen/pt: allow QEMU to request MSI unmasking at bind time (2017-09-20 
> 19:05:27 -0700)
>
> 
> Xen 2017/09/20
>
> 
> Olaf Hering (1):
>   xen-disk: use g_new0 to fix build
>
> Roger Pau Monne (1):
>   xen/pt: allow QEMU to request MSI unmasking at bind time
>
>  hw/block/xen_disk.c |  2 +-
>  hw/xen/xen_pt.h |  1 +
>  hw/xen/xen_pt_config_init.c | 20 ++--
>  hw/xen/xen_pt_msi.c | 13 ++---
>  4 files changed, 30 insertions(+), 6 deletions(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH v2] xen-disk: use g_new0 to fix build

2017-07-28 Thread Peter Maydell
On 28 July 2017 at 21:49, Philippe Mathieu-Daudé  wrote:
> Hi Olaf,
>
> On 07/28/2017 10:11 AM, Olaf Hering wrote:
>>
>> g_malloc0_n is available since glib-2.24. To allow build with older glib
>> versions use the generic g_new0, which is already used in many other
>> places in the code.
>
>
> Can you provide information about which distrib/release/version/[packages?]
> you used? So we might add the same setup in QEMU continuous integration
> system.

I do have a build system with our oldest supported glib
version (it's my OSX box), and I have a feeling one of the
patchew centos configs does this too, but I guess neither
of them have the Xen headers to enable the Xen code,
which is why this one slipped through.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.10 0/2] please pull xen-20170721-tag

2017-07-24 Thread Peter Maydell
On 22 July 2017 at 01:45, Stefano Stabellini  wrote:
> The following changes since commit 91939262ffcd3c85ea6a4793d3029326eea1d649:
>
>   configure: Drop ancient Solaris 9 and earlier support (2017-07-21 15:04:05 
> +0100)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170721-tag
>
> for you to fetch changes up to 7fb394ad8a7c4609cefa2136dec16cf65d028f40:
>
>   xen-mapcache: Fix the bug when overlapping emulated DMA operations may 
> cause inconsistency in guest memory mappings (2017-07-21 17:37:06 -0700)
>
> 
> Xen 2017/07/21
>
> 
> Alexey G (1):
>   xen-mapcache: Fix the bug when overlapping emulated DMA operations may 
> cause inconsistency in guest memory mappings
>
> Igor Druzhinin (1):
>   xen: fix compilation on 32-bit hosts
>
>  hw/i386/xen/xen-mapcache.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.0 0/7] please pull xen-20170718-tag

2017-07-19 Thread Peter Maydell
On 18 July 2017 at 23:20, Stefano Stabellini <sstabell...@kernel.org> wrote:
> The following changes since commit f9dada2baabb639feb988b3a564df7a06d214e18:
>
>   Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into 
> staging (2017-07-18 20:29:36 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170718-tag
>
> for you to fetch changes up to 331b5189d756d431b1d18ae7097527ba3d3ea809:
>
>   xen: don't use xenstore to save/restore physmap anymore (2017-07-18 
> 14:16:52 -0700)
>
> 
> Xen 2017/07/18
>
> 
> Igor Druzhinin (4):
>   xen: move physmap saving into a separate function
>   xen/mapcache: add an ability to create dummy mappings
>   xen/mapcache: introduce xen_replace_cache_entry()
>   xen: don't use xenstore to save/restore physmap anymore
>
> Peter Maydell (1):
>   xen_pt_msi.c: Check for xen_host_pci_get_* failures in 
> xen_pt_msix_init()
>
> Stefano Stabellini (1):
>   xen-platform: separate unplugging of NVMe disks
>
> Xiong Zhang (1):
>   hw/xen: Set emu_mask for igd_opregion register

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/3] please pull xen-20170707-tag

2017-07-10 Thread Peter Maydell
On 7 July 2017 at 19:29, Stefano Stabellini  wrote:
> The following changes since commit b11365867568ba954de667a0bfe0945b8f78d6bd:
>
>   Merge remote-tracking branch 'remotes/borntraeger/tags/s390x-20170706' into 
> staging (2017-07-06 11:42:59 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170707-tag
>
> for you to fetch changes up to 4daf62594d13dfca2ce3a74dd3bddee5f54d7127:
>
>   xen/pt: Fixup addr validation in xen_pt_pci_config_access_check (2017-07-07 
> 11:13:10 -0700)
>
> 
> Xen 2017/07/07
>
> 
> Anoob Soman (1):
>   xen/pt: Fixup addr validation in xen_pt_pci_config_access_check
>
> Ross Lagerwall (1):
>   xen-platform: Cleanup network infrastructure when emulated NICs are 
> unplugged
>
> Stefano Stabellini (1):
>   xenfb: remove xen_init_display "temporary" hack
>
>  hw/display/xenfb.c   | 81 
> ++--
>  hw/i386/xen/xen_platform.c   | 11 ++
>  hw/xen/xen_pt.c  |  2 +-
>  hw/xenpv/xen_machine_pv.c|  3 --
>  include/hw/xen/xen_backend.h |  2 --
>  5 files changed, 30 insertions(+), 69 deletions(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


[Xen-devel] [PATCH] xen_pt_msi.c: Check for xen_host_pci_get_* failures in xen_pt_msix_init()

2017-07-09 Thread Peter Maydell
Check the return status of the xen_host_pci_get_* functions we call in
xen_pt_msix_init(), and fail device init if the reads failed rather than
ploughing ahead. (Spotted by Coverity: CID 777338.)

Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
---
Disclaimer: compile tested only!

The only other Xen-related Coverity issue outstanding is that
we don't check the return value of net_hub_id_for_client() in
xen_config_dev_nic(), but that's too complicated for me to figure
out what the right thing to do is (or if it's even a bug at all).
---
 hw/xen/xen_pt_msi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 62add0639f..ff9a79f5d2 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -535,7 +535,11 @@ int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t 
base)
 return -1;
 }
 
-xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, );
+rc = xen_host_pci_get_word(hd, base + PCI_MSIX_FLAGS, );
+if (rc) {
+XEN_PT_ERR(d, "Failed to read PCI_MSIX_FLAGS field\n");
+return rc;
+}
 total_entries = control & PCI_MSIX_FLAGS_QSIZE;
 total_entries += 1;
 
@@ -554,7 +558,11 @@ int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t 
base)
+ XC_PAGE_SIZE - 1)
   & XC_PAGE_MASK);
 
-xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, _off);
+rc = xen_host_pci_get_long(hd, base + PCI_MSIX_TABLE, _off);
+if (rc) {
+XEN_PT_ERR(d, "Failed to read PCI_MSIX_TABLE field\n");
+goto error_out;
+}
 bar_index = msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
 table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
 msix->table_base = s->real_device.io_regions[bar_index].base_addr;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH 0/3] please pull xen-20170627-tag

2017-06-29 Thread Peter Maydell
On 27 June 2017 at 23:04, Stefano Stabellini  wrote:
> The following changes since commit 577caa2672ccde7352fda3ef17e44993de862f0e:
>
>   Merge remote-tracking branch 
> 'remotes/edgar/tags/edgar/mmio-exec-v2.for-upstream' into staging (2017-06-27 
> 16:56:55 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170627-tag
>
> for you to fetch changes up to 3284fad7283596033cb810b4788fd1bb43312dbd:
>
>   xen-disk: add support for multi-page shared rings (2017-06-27 15:01:56 
> -0700)
>
> 
> Xen 2017/06/27
>
> 
> Paul Durrant (2):
>   xen-disk: only advertize feature-persistent if grant copy is not 
> available
>   xen-disk: add support for multi-page shared rings
>
> Stefano Stabellini (1):
>   xen/disk: don't leak stack data via response ring
>
>  hw/block/xen_disk.c | 184 
> +---
>  1 file changed, 133 insertions(+), 51 deletions(-)


Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] Getting rid of xen_init_display() (and its dubious call into main_loop_wait())

2017-06-28 Thread Peter Maydell
On 28 June 2017 at 01:06, Stefano Stabellini <sstabell...@kernel.org> wrote:
> On Tue, 27 Jun 2017, Peter Maydell wrote:
>> So, there is exactly one caller of main_loop_wait() in the tree that
>> passes it 'true' as an argument. That caller is in xen_init_display()
>> in hw/dispaly/xenfb.c. The function was added in 2009 with the comment
>> "FIXME/TODO: Kill this. Temporary needed while DisplayState
>> reorganization is in flight."
>>
>> I'd like to think that we've now completed whatever reorg that was,
>> 8 years on, so can we now get rid of this function? It definitely
>> seems very dubious to have a display init function with a busy loop
>> and a call into main_loop_wait()...
>
> LOL, you gotta love "temporary fixes". I am happy to see it wasn't me
> that added it ;-)
>
> I think the following should do the trick.

Thanks!

> ---
>
> xenfb: remove xen_init_display "temporary" hack
>
> Initialize xenfb properly, as all other backends, from its own
> "initialise" function.
>
> Signed-off-by: Stefano Stabellini <sstabell...@kernel.org>
>
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index e76c0d8..873e51f 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -71,7 +71,6 @@ struct XenFB {
>  int   fbpages;
>  int   feature_update;
>  int   bug_trigger;
> -int   have_console;
>  int   do_resize;
>
>  struct {
> @@ -80,6 +79,7 @@ struct XenFB {
>  int   up_count;
>  int   up_fullscreen;
>  };
> +static const GraphicHwOps xenfb_ops;
>
>  /*  */
>
> @@ -855,6 +855,8 @@ static int fb_init(struct XenDevice *xendev)
>  static int fb_initialise(struct XenDevice *xendev)
>  {
>  struct XenFB *fb = container_of(xendev, struct XenFB, c.xendev);
> +struct XenDevice *xin;
> +struct XenInput *in;
>  struct xenfb_page *fb_page;
>  int videoram;
>  int rc;
> @@ -877,16 +879,12 @@ static int fb_initialise(struct XenDevice *xendev)
>  if (rc != 0)
> return rc;
>
> -#if 0  /* handled in xen_init_display() for now */
> -if (!fb->have_console) {
> -fb->c.ds = graphic_console_init(xenfb_update,
> -xenfb_invalidate,
> -NULL,
> -NULL,
> -fb);
> -fb->have_console = 1;
> -}
> -#endif
> +fb->c.con = graphic_console_init(NULL, 0, _ops, fb);
> +
> +xin = xen_pv_find_xendev("vkbd", xen_domid, 0);
> +in = container_of(xin, struct XenInput, c.xendev);
> +in->c.con = fb->c.con;

Won't this crash if xen_pv_find_xendev() returned NULL?
Or are we guaranteed that that can't happen here?

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/21] Please pull xen-20170421-v2-tag for 2.10

2017-04-26 Thread Peter Maydell
On 25 April 2017 at 19:34, Stefano Stabellini  wrote:
> Added a fix for the clang build, see
> alpine.DEB.2.10.1704251014320.2875@sstabellini-ThinkPad-X260
>
>
> The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059:
>
>   Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git 
> tags/xen-20170421-v2-tag
>
> for you to fetch changes up to 28b99f473bda682385da944b0404aedbe11ea0dc:
>
>   move xen-mapcache.c to hw/i386/xen/ (2017-04-25 11:04:34 -0700)
>
> 
> Xen 2017/04/21 + fix
>

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

2017-04-24 Thread Peter Maydell
On 24 April 2017 at 22:25, Stefano Stabellini  wrote:
> diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
> new file mode 100644
> index 000..18f0ec0
> --- /dev/null
> +++ b/hw/9pfs/xen-9pfs.h
> @@ -0,0 +1,14 @@
> +/*
> + * Xen 9p backend
> + *
> + * Copyright Aporeto 2017
> + *
> + * Authors:
> + *  Stefano Stabellini 
> + *
> + */

Trivial file, but I prefer it if we have a brief license
statement in every file, just to be clear (it might
accumulate more code later).

> +
> +#include 
> +#include "hw/xen/io/ring.h"
> +
> +DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);

Is it worth a comment to dissuade people from thinking they can
inline the file back into xen-9p-backend.c ?

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

2017-04-24 Thread Peter Maydell
On 21 April 2017 at 21:14, Stefano Stabellini  wrote:
> The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059:
>
>   Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170421-tag
>
> for you to fetch changes up to b0d48550a2d10f0fa8c30a7cc3ff5a1cbda8d4c4:
>
>   move xen-mapcache.c to hw/i386/xen/ (2017-04-21 12:41:29 -0700)
>
> 
> Xen 2017/04/21
>
> 

Hi; I'm afraid this doesn't build with clang:


  CC  hw/9pfs/xen-9p-backend.o
/home/petmay01/linaro/qemu-for-merges/hw/9pfs/xen-9p-backend.c:21:1:
error: unused fun
ction 'xen_9pfs_get_ring_ptr' [-Werror,-Wunused-function]
DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
^
/home/petmay01/linaro/qemu-for-merges/include/hw/xen/io/ring.h:469:79:
note: expanded
from macro 'DEFINE_XEN_FLEX_RING_AND_INTF'
};\
  ^
/home/petmay01/linaro/qemu-for-merges/include/hw/xen/io/ring.h:387:30:
note: expanded from macro '\
DEFINE_XEN_FLEX_RING'
static inline unsigned char *name##_get_ring_ptr(unsigned char *buf,  \
 ^
:151:1: note: expanded from here
xen_9pfs_get_ring_ptr
^
/home/petmay01/linaro/qemu-for-merges/hw/9pfs/xen-9p-backend.c:21:1:
error: unused function 'xen_9pfs_write_packet'
[-Werror,-Wunused-function]
/home/petmay01/linaro/qemu-for-merges/include/hw/xen/io/ring.h:469:79:
note: expanded from macro 'DEFINE_XEN_FLEX_RING_AND_INTF'
};\
  ^
/home/petmay01/linaro/qemu-for-merges/include/hw/xen/io/ring.h:412:20:
note: expanded from macro '\
DEFINE_XEN_FLEX_RING'
static inline void name##_write_packet(unsigned char *buf,\
   ^
:155:1: note: expanded from here
xen_9pfs_write_packet
^
2 errors generated.
/home/petmay01/linaro/qemu-for-merges/rules.mak:69: recipe for target
'hw/9pfs/xen-9p-backend.o' failed


Clang requires that functions, even inline functions, defined in .c files
must be used.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] tags/xen-20170228-tag

2017-03-01 Thread Peter Maydell
On 28 February 2017 at 19:15, Stefano Stabellini  wrote:
> The following changes since commit 7d1730b7d9d8272a13245adfc9b0405e5a4bd0c2:
>
>   Merge remote-tracking branch 'remotes/mjt/tags/trivial-patches-fetch' into 
> staging (2017-02-28 16:22:41 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170228-tag
>
> for you to fetch changes up to daa33c52153df48ef0a7d06013f8ca6f24eff92f:
>
>   Add a new qmp command to do checkpoint, query xen replication status 
> (2017-02-28 11:02:12 -0800)
>
> 
> Xen 2017/02/28
>
> 
> Zhang Chen (2):
>   Add a new qmp command to start/stop replication
>   Add a new qmp command to do checkpoint, query xen replication status
>

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/5] xen-20170202

2017-02-03 Thread Peter Maydell
On 2 February 2017 at 18:35, Stefano Stabellini  wrote:
> The following changes since commit 3aca12f841fcd6f3a7477076dad0d564360500de:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20170127' into staging (2017-01-27 
> 16:59:17 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170202
>
> for you to fetch changes up to e9dcbc86d614018923e26e31319b0a54c9e5abac:
>
>   xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev() 
> (2017-02-02 10:23:53 -0800)
>
> 
> Xen 2017/02/02
>
> 
> Anthony PERARD (1):
>   MAINTAINERS: Update xen-devel mailing list address
>
> Juergen Gross (1):
>   xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()
>
> Paul Durrant (3):
>   xen-platform: re-structure unplug_disks
>   xen-platform: add support for unplugging NVMe disks...
>   xen-platform: add missing disk unplug option

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2] xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()

2017-02-01 Thread Peter Maydell
On 1 February 2017 at 19:37, Stefano Stabellini  wrote:
> Hi Peter,
>
> do you think this is acceptable?

The set of operations here is basically what I suggested
in review of v1, so I think it is the right thing.
OTOH this is a bit of an odd corner of the QOM model
so it might be worth doing some testing to make sure
the reference counts are doing what you (I) expect and
that the object does get correctly freed both in the
error-handling path here and when the device is
unplugged via xen_pv_del_xendev().

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

2017-01-30 Thread Peter Maydell
On 30 January 2017 at 15:14, Juergen Gross  wrote:
> The error exits of xen_pv_find_xendev() free the new xen-device via
> g_free() which is wrong.
>
> As the xen-device has been initialized as qdev it must be removed
> via qdev_unplug().
>
> This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
> ("xen: create qdev for each backend device").
>
> Reported-by: Roger Pau Monné 
> Tested-by: Roger Pau Monné 
> Signed-off-by: Juergen Gross 
> ---
>  hw/xen/xen_backend.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index d119004..030772b 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -145,7 +145,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
> *type, int dom, int dev,
>  xendev->evtchndev = xenevtchn_open(NULL, 0);
>  if (xendev->evtchndev == NULL) {
>  xen_pv_printf(NULL, 0, "can't open evtchn device\n");
> -g_free(xendev);
> +qdev_unplug(>qdev, NULL);
>  return NULL;
>  }
>  fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> @@ -155,7 +155,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
> *type, int dom, int dev,
>  if (xendev->gnttabdev == NULL) {
>  xen_pv_printf(NULL, 0, "can't open gnttab device\n");
>  xenevtchn_close(xendev->evtchndev);
> -g_free(xendev);
> +qdev_unplug(>qdev, NULL);
>  return NULL;
>  }
>  } else {

I think this will leak memory (and that we're already leaking
memory), because the code is creating the xendev with
xendev = g_malloc0(ops->size);
object_initialize(>qdev, ops->size, TYPE_XENBACKEND);

This is saying "I own and am responsible for freeing the memory
that the device object lives in". If you want the object system
to handle freeing the memory for you when the reference count
goes to zero, then you need to create it with
   xendev = object_new()
which we can't do here because we're allocating ops->size bytes
rather than just the size of the object type.

Two options I think:
 (1) have your code do
OBJECT(xendev)->free = g_free;
 after the object_initialize (to tell the object system how
to free this object)
 (2) call both qdev_unplug and g_free

I think (1) is better because it will definitely work even
if the qdev bus system is holding on to an object reference
after it returns from qdev_unplug() for some reason, and
it will also mean we free the memory when we do a
qdev_unplug in xen_pv_del_xendev(), rather than leaking it.

Side note: Using DEVICE(xendev) is better QOM style than
>qdev.

(The weirdness with doing a g_malloc0(ops->size) appears
to be because Xen backends have their own setup for saying
"allocate this many bytes for my data", rather than having
XenBlkDev, XenConsole, etc be QOM subclasses of XenDevice.
Presumably that code all predates QEMU's QOMification.)

We also do OBJECT(thing)->free = something in hw/core/sysbus.c;
maybe we should have a function to abstract this away?
Not sure.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

2017-01-26 Thread Peter Maydell
On 26 January 2017 at 20:47, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 26 January 2017 at 19:36, Stefano Stabellini <sstabell...@kernel.org> 
> wrote:
>> It should be just a matter of replacing qdev_init_nofail with something
>> that can fail. I couldn't find a regular qdev_init that can return
>> error, so maybe we would need to add it.
>
> That's just
> object_property_set_bool(OBJECT(whatever), true, "realized", );
>
> ie "please realize the device".

(PS watch out for ownership refcounting issues depending on what
you did with parenting the device: you likely want to object_unparent()
and then object_unref() the thing in the error-exit path. See
qdev_device_add() for some example code, maybe.)

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

2017-01-26 Thread Peter Maydell
On 26 January 2017 at 19:36, Stefano Stabellini  wrote:
> It should be just a matter of replacing qdev_init_nofail with something
> that can fail. I couldn't find a regular qdev_init that can return
> error, so maybe we would need to add it.

That's just
object_property_set_bool(OBJECT(whatever), true, "realized", );

ie "please realize the device".

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH] hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()

2016-11-02 Thread Peter Maydell
On 2 November 2016 at 17:34, Stefano Stabellini  wrote:
> On Wed, 2 Nov 2016, Thomas Huth wrote:
>> Olaf Hering reported a build failure due to an undefined reference
>> to 'qemu_log_vprintf'. Explicitely including qemu/log.h seems to
>> fix the issue.
>>
>> Signed-off-by: Thomas Huth 
>
> The fix makes sense:
>
> Acked-by: Stefano Stabellini 
>
> However I was unable to reproduce the build failure, so I would like a
> confirmation from Olaf that the fix is working.

If you configure with the (default) simple trace
backend then trace.h will pull in qemu/log.h
(and in this case trace.h comes in via xen_common.h).
But if you're using a different backend then it won't
bring in that header, and you'll get the build failure.

This is a fairly common "breaks but only with
some trace backends" compile failure, but I'm
not sure how best to try to make it more robust
(or at least into a 'fails-everywhere' bug).

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 00/13] xen-20161028-tag

2016-10-31 Thread Peter Maydell
On 29 October 2016 at 02:10, Stefano Stabellini  wrote:
> The following changes since commit 5b2ecabaeabc17f032197246c4846b9ba95ba8a6:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20161028-1' into 
> staging (2016-10-28 17:59:04 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161028-tag
>
> for you to fetch changes up to 71981364b6152e63d0f3098fcdf8b884fa9ffa50:
>
>   xen: Rename xen_be_del_xendev (2016-10-28 17:54:49 -0700)
>
> 
> Xen 2016/10/28
>
> 
> Emil Condrea (13):
>   xen: Fix coding style errors
>   xen: Fix coding style warnings
>   xen: Create a new file xen_pvdev.c
>   xen: Move xenstore_update to xen_pvdev.c
>   xen: Move evtchn functions to xen_pvdev.c
>   xen: Prepare xendev qtail to be shared with frontends
>   xen: Move xenstore cleanup and mkdir functions
>   xen: Rename xen_be_printf to xen_pv_printf
>   xen: Rename xen_be_unbind_evtchn
>   xen: Rename xen_be_send_notify
>   xen: Rename xen_be_evtchn_event
>   xen: Rename xen_be_find_xendev
>   xen: Rename xen_be_del_xendev
>

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/3] tags/xen-20161021-tag

2016-10-24 Thread Peter Maydell
On 21 October 2016 at 21:06, Stefano Stabellini  wrote:
> The following changes since commit b49e452fe994f8fbcd22bf5a87b79a2355481318:
>
>   Merge remote-tracking branch 'remotes/riku/tags/pull-linux-user-20160921' 
> into staging (2016-10-21 13:49:58 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161021-tag
>
> for you to fetch changes up to 35132016dc1c27de2b1354b161df6cc22f3ac5bf:
>
>   xen_platform: SUSE xenlinux unplug for emulated PCI (2016-10-21 12:11:38 
> -0700)
>
> 
> Xen 2016/10/21
>
> 
> Olaf Hering (2):
>   xen_platform: unplug also SCSI disks
>   xen_platform: SUSE xenlinux unplug for emulated PCI
>
> Stefano Stabellini (1):
>   xen-usb: do not reference PAGE_SIZE

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/1] tags/xen-20160927-tag

2016-09-28 Thread Peter Maydell
On 27 September 2016 at 18:36, Stefano Stabellini
 wrote:
> The following changes since commit 25930ed60aad49f1fdd7de05272317c86ce1275b:
>
>   Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into 
> staging (2016-09-27 23:10:12 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160927-tag
>
> for you to fetch changes up to b6eb9b45f7307638ff166401721ae6d0401e1d67:
>
>   qdisk - hw/block/xen_disk: grant copy implementation (2016-09-27 18:18:55 
> -0700)
>
> 
> Xen 2016/09/27
>
> 
> Paulina Szubarczyk (1):
>   qdisk - hw/block/xen_disk: grant copy implementation
>
>  configure   |  55 
>  hw/block/xen_disk.c | 153 
> ++--
>  include/hw/xen/xen_common.h |  14 
>  3 files changed, 217 insertions(+), 5 deletions(-)


Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/1] xen-20160905

2016-09-06 Thread Peter Maydell
On 5 September 2016 at 20:02, Stefano Stabellini  wrote:
> The following changes since commit 12d2c4184c5ab60be3428b2bdea5ae66e8d5d960:
>
>   Update version for v2.7.0-rc5 release (2016-08-30 20:39:45 +0100)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160905
>
> for you to fetch changes up to 4ada797b05a52ac824a710c67216b37739026a64:
>
>   xen: use native disk xenbus protocol if possible (2016-08-30 15:01:01 -0700)
>
> 
> Xen 2016/09/05
>
> 
> Juergen Gross (1):
>   xen: use native disk xenbus protocol if possible

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] xen-20160812-tag-2

2016-08-15 Thread Peter Maydell
On 13 August 2016 at 00:42, Stefano Stabellini  wrote:
> The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51:
>
>   Merge remote-tracking branch 
> 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 
> 17:53:35 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag-2
>
> for you to fetch changes up to b7665c6027c972c23668ee74b878b5c617218514:
>
>   xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
> 16:38:30 -0700)
>
> 
> Xen 2016/08/12, fixed commit message
>
> 
> Cao jin (1):
>   Xen: fix converity warning of xen_pt_config_init()
>
> Paul Durrant (1):
>   xen: handle inbound migration of VMs without ioreq server pages

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] xen-20160804-tag

2016-08-05 Thread Peter Maydell
On 4 August 2016 at 18:44, Stefano Stabellini  wrote:
> The following changes since commit 09704e6ded83fa0bec14baf32f800f6512156ca0:
>
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
> staging (2016-08-04 10:24:27 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160804-tag
>
> for you to fetch changes up to 0968c91ce00f42487fb11de5da38e53b5dc6bc7f:
>
>   Xen PCI passthrough: fix passthrough failure when no interrupt pin 
> (2016-08-04 10:42:48 -0700)
>
> 
> Xen 2016/08/04
>
> 
> Bruce Rogers (1):
>   Xen PCI passthrough: fix passthrough failure when no interrupt pin

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/3] xen-20160622-tag

2016-06-23 Thread Peter Maydell
On 22 June 2016 at 12:47, Stefano Stabellini  wrote:
> The following changes since commit 6f1d2d1c5ad20d464705b17318cb7ca495f8078a:
>
>   Merge remote-tracking branch 'remotes/stsquad/tags/pull-travis-20160621-1' 
> into staging (2016-06-21 15:19:58 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160622-tag
>
> for you to fetch changes up to 25f8f6b4c295940ae5d83c19509353afc1dbc9a4:
>
>   xen: move xen_sysdev to xen_backend.c (2016-06-22 11:28:42 +0100)
>
> 
> xen-20160622

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] xen-20160614-tag

2016-06-14 Thread Peter Maydell
On 14 June 2016 at 16:04, Stefano Stabellini <sstabell...@kernel.org> wrote:
> The following changes since commit 55e5c3a2d2433bd2e1e635a7ba395f1c70341794:
>
>   Merge remote-tracking branch 
> 'remotes/berrange/tags/qcrypto-next-2016-06-13-v1' into staging (2016-06-13 
> 13:05:02 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160614-tag
>
> for you to fetch changes up to b1b23e5bbfb66d9401e2c2b0646fb721d94a3f83:
>
>   xen: Clean up includes (2016-06-14 15:37:43 +0100)
>
> 
> Xen 2016/06/14
>
> 
> Jan Beulich (1):
>   xen/blkif: avoid double access to any shared ring request fields
>
> Peter Maydell (1):
>   xen: Clean up includes
>
>  hw/block/xen_blkif.h | 12 ++--
>  hw/block/xen_disk.c  |  2 ++
>  hw/usb/xen-usb.c |  5 +
>  include/hw/xen/xen.h |  1 -
>  4 files changed, 9 insertions(+), 11 deletions(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] xen: Clean up includes

2016-06-14 Thread Peter Maydell
On 14 June 2016 at 15:37, Stefano Stabellini  wrote:
> I didn't lose it, I thought you had already committed it as
> 21cbfe5f37aaa3a13d3af28454e762c05be67429, but I realize now that
> although they have the same commit message, they are not the same patch.
>
> I was wondering how it got upstream given that I didn't send a pull
> request for it. Mystery solved. Next time it might be good to avoid
> having multiple patches touching similar code with exactly the same
> commit description.

Mmm, unfortunate side effect of the commit message being automatically
created by the clean-includes script.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] xen: Clean up includes

2016-06-14 Thread Peter Maydell
On 30 May 2016 at 16:54, Stefano Stabellini <sstabell...@kernel.org> wrote:
> On Tue, 24 May 2016, Peter Maydell wrote:
>> 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 <peter.mayd...@linaro.org>
>
> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org>
>
> Added to my queue

Hi; did this patch get lost? You've done a xen pullreq since
this but this patch wasn't in it.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] xen-20160613-tag

2016-06-13 Thread Peter Maydell
On 13 June 2016 at 11:54, Stefano Stabellini  wrote:
> The following changes since commit a93c1bdf0bd4689287094ddb2aae3dc907da3535:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20160610-1' into 
> staging (2016-06-10 15:47:17 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160613-tag
>
> for you to fetch changes up to 88c16567d2cd23da328787187910b013ee43ebca:
>
>   Introduce "xen-load-devices-state" (2016-06-13 11:50:53 +0100)
>
> 
> Xen 2016/06/13
>
> 

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [PATCH] xen: Clean up includes

2016-05-24 Thread 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 <peter.mayd...@linaro.org>
---
 hw/usb/xen-usb.c | 5 +
 include/hw/xen/xen.h | 1 -
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 664df04..8fa47ed 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -19,13 +19,10 @@
  *  GNU GPL, version 2 or (at your option) any later version.
  */
 
+#include "qemu/osdep.h"
 #include 
-#include 
-#include 
 #include 
-#include 
 
-#include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "qemu/config-file.h"
 #include "hw/sysbus.h"
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 6365483..b2cd992 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -8,7 +8,6 @@
  */
 
 #include "qemu-common.h"
-#include "qemu/typedefs.h"
 #include "exec/cpu-common.h"
 #include "hw/irq.h"
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.6 0/1] tags/xen-2016-04-20

2016-04-20 Thread Peter Maydell
On 20 April 2016 at 12:14, Stefano Stabellini  wrote:
> The following changes since commit 42bb626f7ebc9197d2943b897a99e127315275ab:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2016-04-12 09:34:52 +0100)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2016-04-20
>
> for you to fetch changes up to 4df26e88ee2f23c01418630368e87b719ed06b75:
>
>   xenfb: use the correct condition to avoid excessive looping (2016-04-12 
> 10:16:08 -0700)
>
> 
> Xen 2016/04/20
>
> 
> Wei Liu (1):
>   xenfb: use the correct condition to avoid excessive looping
>
>  hw/display/xenfb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH] Xen: update MAINTAINERS info

2016-03-31 Thread Peter Maydell
On 29 March 2016 at 11:02, Stefano Stabellini
 wrote:
> Add Anthony Perard as Xen co-maintainer.
> Update my email address.
>
> Signed-off-by: Stefano Stabellini 
> Acked-by: Anthony Perard 
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index afbe845..66abde8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -278,7 +278,8 @@ Guest CPU Cores (Xen):
>  --
>
>  X86
> -M: Stefano Stabellini 
> +M: Stefano Stabellini 
> +M: Anthony Perard 
>  L: xen-de...@lists.xensource.com
>  S: Supported
>  F: xen-*

Applied to master, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/5] tags/xen-2016-02-12

2016-02-12 Thread Peter Maydell
On 12 February 2016 at 17:30, Stefano Stabellini
 wrote:
> The following changes since commit f075c89f0a9cb31daf38892371d2822177505706:
>
>   Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' 
> into staging (2016-02-09 17:56:46 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2016-02-12
>
> for you to fetch changes up to 47d3df2387ed6927732584ffa4159c26d9f4dee8:
>
>   xen: Drop __XEN_LATEST_INTERFACE_VERSION__ checks from prior to Xen 4.2 
> (2016-02-10 12:01:32 +)
>
> 
> Xen 2016-02-12
>
> 
> Ian Campbell (5):
>   xen: drop support for Xen 4.1 and older.
>   xen: drop xen_xc_hvm_inject_msi wrapper
>   xen: drop XenXC and associated interface wrappers
>   xen: move xenforeignmemory compat layer into common place
>   xen: Drop __XEN_LATEST_INTERFACE_VERSION__ checks from prior to Xen 4.2

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH 1/5] xen: drop support for Xen 4.1 and older.

2016-02-09 Thread Peter Maydell
On 9 February 2016 at 16:17, Ian Campbell  wrote:
> Xen 4.2 become unsupported upstream in 09/2105 (see
> http://wiki.xen.org/wiki/Xen_Release_Features)

"2015" if you have to do a respin or the person committing
to their subtree wants to fix it up...

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] qemu-upstream compile failure in intel_iommu.c:vtd_context_device_invalidate

2016-01-28 Thread Peter Maydell
On 28 January 2016 at 08:45, Paolo Bonzini  wrote:
>
>
> On 27/01/2016 19:23, Olaf Hering wrote:
>>
>> xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c: In function 
>> ‘vtd_context_device_invalidate’:
>> xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c:911:46: error: ‘mask’ may 
>> be used uninitialized in this function [-Werror=maybe-uninitialized]
>>  if (vtd_as && ((devfn_it & mask) == (devfn & mask))) {
>>   ^
>> It works with -O2. From the code flow its clear that mask is always
>> initialized. Looks like gcc 5.2.1 does no proper diagnostic at -O1.
>> What should be done with such issues, are they fixed in the code?
>
> It's probably simplest to add a
>
> default:
> abort();
>
> to the switch statement above.

glib provides a g_assert_not_reached() for this purpose, which is slightly
more self-documenting.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/8] xen-20160126

2016-01-26 Thread Peter Maydell
On 26 January 2016 at 15:51, Stefano Stabellini
 wrote:
> The following changes since commit 1535a6d699487740b490369e44f9ca8d305463cd:
>
>   Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into 
> staging (2016-01-26 09:16:07 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160126
>
> for you to fetch changes up to f4297d663d92844f87aeb6ea762244167490dadb:
>
>   xen: make it possible to build without the Xen PV domain builder 
> (2016-01-26 15:03:38 +)
>
> 
> Xen 2016/01/26
>
> 
> Ian Campbell (8):
>   xen_console: correctly cleanup primary console on teardown.
>   xen: Switch to libxenevtchn interface for compat shims.
>   xen: Switch to libxengnttab interface for compat shims.
>   xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
>   xen: Switch uses of xc_map_foreign_{pages,bulk} to use 
> libxenforeignmemory API.
>   xen: Use stable library interfaces when they are available.
>   xen: domainbuild: reopen libxenctrl interface after forking for domain 
> watcher.
>   xen: make it possible to build without the Xen PV domain builder

Hi. It looks like you forgot to add your Signed-off-by: line as the maintainer
to these patches; can I ask you to fix that and resend the pull, please?
(You can just resend the cover letter.)

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL] xen-20160126-2

2016-01-26 Thread Peter Maydell
On 26 January 2016 at 17:21, Stefano Stabellini
 wrote:
> The following changes since commit 1535a6d699487740b490369e44f9ca8d305463cd:
>
>   Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into 
> staging (2016-01-26 09:16:07 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160126-2
>
> for you to fetch changes up to 64a7ad6fe3d8500119d83e0af830e0e45e83499a:
>
>   xen: make it possible to build without the Xen PV domain builder 
> (2016-01-26 17:19:44 +)
>
> 
> Xen 2016/01/26 with Signed-off-by lines.

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/11] xen-20160121

2016-01-21 Thread Peter Maydell
On 21 January 2016 at 17:01, Stefano Stabellini
 wrote:
> The following changes since commit 17c8a2197888bac8ec0256b16919b721c76c5e62:
>
>   Merge remote-tracking branch 'remotes/armbru/tags/pull-error-2016-01-13' 
> into staging (2016-01-14 13:07:38 +)
>
> are available in the git repository at:
>
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160121
>
> for you to fetch changes up to 5a11d0f7549e24a10e178a9dc8ff5e698031d9a6:
>
>   Xen PCI passthru: convert to realize() (2016-01-21 16:45:54 +)
>
> 
> Xen 2016/01/21

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/4] xen-2015-12-22

2015-12-23 Thread Peter Maydell
On 22 December 2015 at 16:20, Stefano Stabellini
 wrote:
> The following changes since commit c3626ca7df027dabf0568284360a23faf18f0884:
>
>   Update version for v2.5.0-rc3 release (2015-12-07 17:47:40 +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-12-22
>
> for you to fetch changes up to fc3e493bc8e96ef4bf7ae4f035f43cb39382c936:
>
>   xen_disk: treat "vhd" as "vpc" (2015-12-11 17:02:37 +)
>
> 
> Xen 2015/12/22
>
> 
> Jan Beulich (3):
>   xen/MSI-X: latch MSI-X table writes
>   xen/MSI-X: really enforce alignment
>   xen/pass-through: correctly deal with RW1C bits
>
> Stefano Stabellini (1):
>   xen_disk: treat "vhd" as "vpc"

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] xsa155

2015-12-18 Thread Peter Maydell
On 18 December 2015 at 15:17, Stefano Stabellini
 wrote:
> The following changes since commit 18f49881cf8359e89396aac12f5d3cf3f8a632ba:
>
>   configure: Fix shell syntax to placate OpenBSD's pdksh (2015-12-18 13:32:49 
> +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xsa155
>
> for you to fetch changes up to 7ea11bf376aea4bf8340eb363de9777c7f93e556:
>
>   xenfb: avoid reading twice the same fields from the shared page (2015-12-18 
> 15:10:09 +)
>
>
> It would be great if they were backported to the QEMU stable trees too.
>
>
> 
> XSA-155 fixes
>
> 
> Stefano Stabellini (2):
>   xen/blkif: Avoid double access to src->nr_segments
>   xenfb: avoid reading twice the same fields from the shared page

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/1] tags/xen-2015-12-11

2015-12-11 Thread Peter Maydell
On 11 December 2015 at 17:01, Stefano Stabellini
<stefano.stabell...@eu.citrix.com> wrote:
> On Fri, 11 Dec 2015, Peter Maydell wrote:
>> On 11 December 2015 at 16:52, Stefano Stabellini
>> <stefano.stabell...@eu.citrix.com> wrote:
>> If this was intended for 2.5 you have missed the boat.
>
> I sent it because it is a bug fix, but waiting for 2.6 also makes
> sense. I'll resend after the release.

For future releases I recommend listing things you're
hoping to get into 2.5 on the wiki's Planning page.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/1] tags/xen-2015-12-11

2015-12-11 Thread Peter Maydell
On 11 December 2015 at 16:52, Stefano Stabellini
 wrote:
> The following changes since commit 6e0abc251dd4f8eba1f53656dfede12e5840e83b:
>
>   blockdev: Mark {insert, remove}-medium experimental (2015-12-11 15:39:29 
> +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-12-11
>
> for you to fetch changes up to 73e72322d336e1a5c5fb32e8cc2310c2ad62d79b:
>
>   xen_disk: treat "vhd" as "vpc" (2015-12-11 16:49:42 +)
>
> 
> Xen 2015/12/11
>
> 
> Stefano Stabellini (1):
>   xen_disk: treat "vhd" as "vpc"
>
>  hw/block/xen_disk.c |3 +++
>  1 file changed, 3 insertions(+)

If this was intended for 2.5 you have missed the boat.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.5 0/2] xen-20151125

2015-11-25 Thread Peter Maydell
On 25 November 2015 at 11:22, Stefano Stabellini
 wrote:
> The following changes since commit 8337c6cbc37c6b2184f41bab3eaff47d5e68012a:
>
>   Update version for v2.5.0-rc0 release (2015-11-13 17:10:36 +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20151125
>
> for you to fetch changes up to 22037db38ccfe497bd13a94edead6657781b9b37:
>
>   xen_disk: Remove ioreq.postsync (2015-11-25 11:04:55 +)
>
> 
> Xen 2015/11/25
>
> 
> Alberto Garcia (1):
>   xen_disk: Remove ioreq.postsync
>
> Roger Pau Monne (1):
>   xen: fix usage of xc_domain_create in domain builder

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-10 Thread Peter Maydell
On 10 September 2015 at 02:21, Chen, Tiejun  wrote:
> On 9/10/2015 12:10 AM, Stefano Stabellini wrote:
>> I found another issue introduced by the gfx passthrough series on
>> Windows:
>>
>> ../hw/pci-host/piix.o: In function `host_pci_config_read':
>> /root/qemu/hw/pci-host/piix.c:778: undefined reference to `_pread'
>>
>> It is introduced by:
>>
>> commit fdb70721ba0496a767137e5505dd27627d19c4a8
>> Author: Tiejun Chen 
>> Date:   Wed Jul 15 13:37:43 2015 +0800
>>
>>  piix: create host bridge to passthrough
>>
>>
>> You might have to replace the pread call with lseek and read.
>>
>
> This is also surprising to me. Just see xen_host_pci_config_() inside
> /hw/xen/xen-host-pci-device.c, there are so many this pread usage(). So I
> really don't understand what's difference between these two files.

xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
was set by configure. That won't be the case on OSX or Windows, where
the Xen headers don't exist.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-10 Thread Peter Maydell
On 10 September 2015 at 02:12, Chen, Tiejun <tiejun.c...@intel.com> wrote:
> On 9/9/2015 9:06 PM, Stefano Stabellini wrote:
>>
>> On Tue, 8 Sep 2015, Peter Maydell wrote:
>>>
>>> On 8 September 2015 at 18:21, Stefano Stabellini
>>> <stefano.stabell...@eu.citrix.com> wrote:
>>> > The following changes since commit
>>> > 8611280505119e296757a60711a881341603fa5a:
>>> >
>>> >   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
>>> >
>>> > are available in the git repository at:
>>> >
>>> >   git://xenbits.xen.org/people/sstabellini/qemu-dm.git
>>> > tags/xen-2015-09-08-tag
>>> >
>>> > for you to fetch changes up to
>>> > ba2250ad148997b1352aba976aac66b55410e7e4:
>>> >
>>> >   xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.
>>> > (2015-09-08 15:21:56 +)
>>> >
>>> > 
>>> > Xen branch xen-2015-09-08
>>> >
>>> > 
>>>
>>> Hi. I'm afraid this fails to build on OSX (and probably Windows too,
>>> though that build hasn't run yet):
>>>
>>>   CCi386-softmmu/hw/i386/pci-assign-load-rom.o
>>> /Users/pm215/src/qemu/hw/i386/pci-assign-load-rom.c:6:10: fatal error:
>>>   'sys/io.h' file not found
>>> #include 
>>>  ^
>>>   CCalpha-softmmu/hw/alpha/pci.o
>>> 1 error generated.
>>
>>
>> Tiejun,
>>
>> this is caused by 33d33242b7d802e6c994f3d56ecba96a66465dc3,
>> "hw/pci-assign: split pci-assign.c". Could you please double-check
>> non-Linux builds?
>
>
> Its interesting.
>
> As you see this short log, "hw/pci-assign: split pci-assign.c", so this
> means I just extract something from the original hw/i386/kvm/pci-assign.c,
> and here so I just keep those original head files residing
> hw/i386/kvm/pci-assign.c, and I didn't introduce anything new.

hw/i386/kvm/pci-assign.c is only built if configure set CONFIG_KVM,
which it won't do on Windows or OSX builds.

It sounds like your patch has incorrectly moved code out of files
which are compiled only if KVM is present, or only if we're doing
Xen PCI passthrough, and into compiled-for-everything files.

> So its very probably that you still can't compile successfully even without
> my commit on OSX/Windows, right?

OSX and Windows build fine on master at the moment; I check this
for every pull request.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 00/29] xen-2015-09-10-tag

2015-09-10 Thread Peter Maydell
On 10 September 2015 at 18:15, Stefano Stabellini
 wrote:
> The following changes since commit 8611280505119e296757a60711a881341603fa5a:
>
>   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-09-10-tag
>
> for you to fetch changes up to cae99f1d779a6e2c8721ce2dd80bafdbf0abe7a0:
>
>   xen/pt: Don't slurp wholesale the PCI configuration registers (2015-09-10 
> 16:47:28 +)
>
> 
> xen-2015-09-10
>

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-09 Thread Peter Maydell
On 9 September 2015 at 14:06, Stefano Stabellini
 wrote:
> Speak about build environments, Peter, would you care to share your
> scripts and setup so that I can run similar tests in the future on my
> own?  I have no OSX machines so I tried to do a Windows
> cross-compile, following http://wiki.qemu.org/Hosts/W32 on Debian 7, but
> I failed very early with an "ERROR: zlib check failed".

My build scripts are at
https://git.linaro.org/people/peter.maydell/misc-scripts.git
(in particular pull-buildtest runs the test and remake-merge-builds
does the one-time configure-each-build-tree setup.) But they're really
just doing a make/make check. I don't have scripts for getting the
cross-compile environment set up in the first place, I'm afraid.

Your error message means you're missing the zlib cross library.
Fedora provides packaged versions of all the cross libs, but for
Debian you have to download them from the upstream websites and
stick them in a directory somewhere.

My (Ubuntu-based) instructions from last time somebody asked:
https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00688.html

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-09 Thread Peter Maydell
On 9 September 2015 at 17:10, Stefano Stabellini
 wrote:
> I found another issue introduced by the gfx passthrough series on
> Windows:
>
> ../hw/pci-host/piix.o: In function `host_pci_config_read':
> /root/qemu/hw/pci-host/piix.c:778: undefined reference to `_pread'
>
> It is introduced by:
>
> commit fdb70721ba0496a767137e5505dd27627d19c4a8
> Author: Tiejun Chen 
> Date:   Wed Jul 15 13:37:43 2015 +0800
>
> piix: create host bridge to passthrough
>
>
> You might have to replace the pread call with lseek and read.

Will passthrough even work on Windows and OSX hosts?
Consider whether we should be building this code on those
hosts at all...

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-08 Thread Peter Maydell
On 8 September 2015 at 18:21, Stefano Stabellini
 wrote:
> The following changes since commit 8611280505119e296757a60711a881341603fa5a:
>
>   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-09-08-tag
>
> for you to fetch changes up to ba2250ad148997b1352aba976aac66b55410e7e4:
>
>   xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings. 
> (2015-09-08 15:21:56 +)
>
> 
> Xen branch xen-2015-09-08
>
> 

Hi. I'm afraid this fails to build on OSX (and probably Windows too,
though that build hasn't run yet):

  CCi386-softmmu/hw/i386/pci-assign-load-rom.o
/Users/pm215/src/qemu/hw/i386/pci-assign-load-rom.c:6:10: fatal error:
  'sys/io.h' file not found
#include 
 ^
  CCalpha-softmmu/hw/alpha/pci.o
1 error generated.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.4 0/1] cve-2015-5166-tag

2015-08-04 Thread Peter Maydell
On 3 August 2015 at 15:32, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit 2a3612ccc1fa9cea77bd193afbfe21c77e7e91ef:

   Merge remote-tracking branch 
 'remotes/stefanha/tags/rtl8139-cplus-tx-input-validation-pull-request' into 
 staging (2015-08-03 13:09:10 +0100)

 are available in the git repository at:


   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/cve-2015-5166-tag

 for you to fetch changes up to 6cd387833d05e8ad31829d97e474dc420625aed9:

   Fix release_drive on unplugged devices (pci_piix3_xen_ide_unplug) 
 (2015-08-03 14:27:12 +)

 
 cve-2015-5166

 
 Stefano Stabellini (1):
   Fix release_drive on unplugged devices (pci_piix3_xen_ide_unplug)

  hw/ide/piix.c |7 +++
  1 file changed, 7 insertions(+)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.4 0/2] Fix migration on Xen

2015-08-03 Thread Peter Maydell
On 3 August 2015 at 17:19, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit f60c87154ac722c528fd5582f7137914a93c5eec:

   configure: Drop vnc-ws feature from help text (2015-08-03 15:32:17 +0100)

 are available in the git repository at:

   git://xenbits.xen.org/people/sstabellini/qemu-dm.git 
 tags/xen-migration-2.4-tag

 for you to fetch changes up to 8c6dc68f4cff9eef870497a19a5373dde9dbdcc2:

   migration: Fix regression for xenfv and pc,accel=xen machine. (2015-08-03 
 16:13:40 +)

 
 xen-migration-2.4

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH] Fix the compatibility typedef of ioservid_t to match the Xen headers

2015-07-08 Thread Peter Maydell
On 8 July 2015 at 15:06, Michael S. Tsirkin m...@redhat.com wrote:
 On Tue, Jul 07, 2015 at 02:32:38PM +0100, Paul Durrant wrote:
 There is a mismatch between the definition of ioservid_t in
 xen_common.h and the definition in the Xen publix headers. This patch
 corrects the definition in xen_common.h.

 Signed-off-by: Paul Durrant paul.durr...@citrix.com
 Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com

 Tested-by: Michael S. Tsirkin m...@redhat.com


Applied to master, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/5] xen-220615

2015-06-23 Thread Peter Maydell
On 23 June 2015 at 11:30, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Tue, 23 Jun 2015, Peter Maydell wrote:
 I'm afraid I can't apply this -- this revert commit is missing a 
 signed-off-by
 line. Can you respin, please?

 I thought that being a straight revert, didn't need a SOB line.
 xen-220615-2 is the tag with SOB line on the last commit:

 git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-220615-2

xen/pass-through: fold host PCI command register writes
only has Jan's signoff, not yours too... (apologies for not
noticing that first time around.)

I have a bit in my pull-request-creation script that automatically
checks that every commit has my signoff, to avoid this kind of
mistake:
https://git.linaro.org/people/peter.maydell/misc-scripts.git/blob/HEAD:/make-pullreq#l98

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/5] xen-220615

2015-06-23 Thread Peter Maydell
On 23 June 2015 at 17:19, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Tue, 23 Jun 2015, Peter Maydell wrote:
 I have a bit in my pull-request-creation script that automatically
 checks that every commit has my signoff, to avoid this kind of
 mistake:
 https://git.linaro.org/people/peter.maydell/misc-scripts.git/blob/HEAD:/make-pullreq#l98

 Sorry. I noticed that this is the second time that I make this mistake.
 Part of the problem is that in other communities (Linux, Xen Project),
 maintainers are not required to add their SOB if they don't modify the
 patch.

Interesting. I thought QEMU's process on this was basically the same
as Linux's, which says things like
The Signed-off-by: tag indicates that the signer was involved in
 the development of the patch, or that he/she was in the patch's
 delivery path.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n394

which I take to mean that submaintainers add s-o-b lines.

 Here is my third try:

 git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-220615-3

Applied this version, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH 0/11] Xen PCI Passthrough security fixes

2015-06-02 Thread Peter Maydell
On 2 June 2015 at 16:32, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 On Tue, 2 Jun 2015, Stefano Stabellini wrote:
 Hi all,

 the following is a collection of QEMU security fixes for PCI Passthrough
 on Xen. Non-Xen usages of QEMU are unaffected.

 Although the CVEs have already been made public, given the large amount
 of changes, I decided not to send a pull request without giving a chance
 to the QEMU community to comment on the patches first.

 Peter convinced me to send out a pull request immediately. If anybody
 has any comments on the patches, we can still fix them up later or even
 revert them if that becomes necessary.

For the record, the rationale is:
 * fixes for CVEs will have been reviewed during the nondisclosure period
 * getting security fixes into master in a timely fashion is important
 * having the patches in upstream master be different from the ones
   advertised with the CVE can cause confusion about which are correct
 * if there are any problems with the CVE fixes (stylistic or otherwise)
   we can correct them with followup patches

Our workflow/process for handling security issues is not set in
stone (indeed it's evolving a bit at the moment), so comments/suggestions
welcome.

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/11] Xen PCI Passthrough security fixes

2015-06-02 Thread Peter Maydell
On 2 June 2015 at 16:39, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit 3fc827d591679f3e262b9d1f8b34528eabfca8c0:

   target-arm: Correct check for non-EL3 (2015-06-02 13:22:29 +0100)

 are available in the git repository at:

   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-15-06-02

 for you to fetch changes up to c25bbf1545a53ac051f9e51d4140e397660c10ae:

   xen/pt: unknown PCI config space fields should be read-only (2015-06-02 
 15:07:01 +)

 
 Jan Beulich (11):
   xen: properly gate host writes of modified PCI CFG contents
   xen: don't allow guest to control MSI mask register
   xen/MSI-X: limit error messages
   xen/MSI: don't open-code pass-through of enable bit modifications
   xen/pt: consolidate PM capability emu_mask
   xen/pt: correctly handle PM status bit
   xen/pt: split out calculation of throughable mask in PCI config space 
 handling
   xen/pt: mark all PCIe capability bits read-only
   xen/pt: mark reserved bits in PCI config space fields
   xen/pt: add a few PCI config space field descriptions
   xen/pt: unknown PCI config space fields should be read-only

  hw/pci/msi.c|4 -
  hw/xen/xen_pt.c |   51 +-
  hw/xen/xen_pt.h |7 +-
  hw/xen/xen_pt_config_init.c |  235 
 ---
  hw/xen/xen_pt_msi.c |   12 ++-
  include/hw/pci/pci_regs.h   |2 +
  6 files changed, 217 insertions(+), 94 deletions(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/1] Xen tree 2015-01-26

2015-01-26 Thread Peter Maydell
On 26 January 2015 at 12:00, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit b3a4755a67a52aa7297eb8927b482d09dabdefec:

   Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150122-1' into 
 staging (2015-01-22 12:14:19 +)

 are available in the git repository at:


   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2015-01-26

 for you to fetch changes up to d01a5a3fe19645f3cdea1566f0e518ea2152a029:

   fix QEMU build on Xen/ARM (2015-01-26 11:56:33 +)

 
 Stefano Stabellini (1):
   fix QEMU build on Xen/ARM

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/4] Xen tree 2015-01-20

2015-01-20 Thread Peter Maydell
On 20 January 2015 at 11:19, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit 74acb99737dbedd86654d660c0c20815139a873c:

   Merge remote-tracking branch 'remotes/kraxel/tags/pull-console-20150119-1' 
 into staging (2015-01-19 13:37:05 +)

 are available in the git repository at:


   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2015-01-20

 for you to fetch changes up to 085bde8e8f9bd4fb06e010810991b26aba795fb2:

   xen: add a lock for the mapcache (2015-01-20 11:09:54 +)

 

I'm afraid I can't apply this -- three out of four patches are missing
your signed-off-by as maintainer.

You might like to add something to your pre-submission checking scripts
to catch this error; eg the script fragment I suggested in
http://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg02134.html

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL v2 0/4] Xen tree 2015-01-20 v2

2015-01-20 Thread Peter Maydell
On 20 January 2015 at 14:27, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit 74acb99737dbedd86654d660c0c20815139a873c:

   Merge remote-tracking branch 'remotes/kraxel/tags/pull-console-20150119-1' 
 into staging (2015-01-19 13:37:05 +)

 are available in the git repository at:


   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2015-01-20-v2

 for you to fetch changes up to 86a6a9bf551ffa183880480b37c5836d3916687a:

   xen: add a lock for the mapcache (2015-01-20 14:24:17 +)

 
 Paolo Bonzini (2):
   xen: do not use __-named variables in mapcache
   xen: add a lock for the mapcache

 Paul Durrant (2):
   Add device listener interface
   Xen: Use the ioreq-server API when available

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL 0/2] Xen tree 2015-01-13

2015-01-13 Thread Peter Maydell
On 13 January 2015 at 18:24, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit 7d5ad15d17f26dd4f9ff5f3491828bc34e74f28c:

   Merge remote-tracking branch 'remotes/stefanha/tags/net-pull-request' into 
 staging (2015-01-12 11:13:24 +)

 are available in the git repository at:


   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2015-01-13

 for you to fetch changes up to c1d322e6048796296555dd36fdd102d7fa2f50bf:

   xen-hvm: increase maxmem before calling xc_domain_populate_physmap 
 (2015-01-13 18:05:52 +)

 
 Liang Li (1):
   xen-pt: Fix PCI devices re-attach failed

 Stefano Stabellini (1):
   xen-hvm: increase maxmem before calling xc_domain_populate_physmap

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] introduce virtqueue_unmap_sg

2014-11-25 Thread Peter Maydell
On 25 November 2014 at 14:43, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 Introduce a function to unmap an sg previously mapped with
 virtqueue_map_sg.

 Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
 CC: jasow...@redhat.com
 CC: we...@cn.fujitsu.com
 CC: m...@redhat.com
 CC: pbonz...@redhat.com
 ---
  hw/virtio/virtio.c |   22 ++
  include/hw/virtio/virtio.h |2 ++
  2 files changed, 24 insertions(+)

 diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
 index 3e4b70c..2621ae6 100644
 --- a/hw/virtio/virtio.c
 +++ b/hw/virtio/virtio.c
 @@ -446,6 +446,28 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr,
  }
  }

 +void virtqueue_unmap_sg(const struct iovec *sg, size_t num_sg,
 +int is_write, unsigned int len)
 +{
 +unsigned int i;
 +unsigned int offset;
 +
 +if (num_sg  VIRTQUEUE_MAX_SIZE) {
 +error_report(virtio: unmap attempt out of bounds: %zd  %d,
 + num_sg, VIRTQUEUE_MAX_SIZE);
 +exit(1);
 +}
 +
 +offset = 0;
 +for (i = 0; i  num_sg; i++) {
 +size_t size = MIN(len - offset, sg[i].iov_len);
 +
 +cpu_physical_memory_unmap(sg[i].iov_base, sg[i].iov_len, is_write, 
 size);
 +
 +offset += size;
 +}
 +}

It seems rather odd that size and the iov_len fields in
the iovec are size_t but 'len' and 'offset' are only
unsigned int...

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PULL for-2.2 0/2] Xen tree 2014-11-14

2014-11-14 Thread Peter Maydell
On 14 November 2014 11:29, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
 The following changes since commit c52e67924fbdadfa00668248f5c075542943c54c:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
 staging (2014-11-13 15:44:16 +)

 are available in the git repository at:


   git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2014-11-14

 for you to fetch changes up to 2f01dfacb56bc7a0d4639adc9dff9aae131e6216:

   xen_disk: fix unmapping of persistent grants (2014-11-14 11:12:38 +)

 
 Igor Mammedov (1):
   pc: piix4_pm: init legacy PCI hotplug when running on Xen

 Roger Pau Monne (1):
   xen_disk: fix unmapping of persistent grants

  hw/acpi/piix4.c |4 +++
  hw/block/xen_disk.c |   72 
 ++-
  hw/i386/pc_piix.c   |   11 
  3 files changed, 70 insertions(+), 17 deletions(-)

Applied, thanks.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel