Re: [Qemu-devel] [PATCH 2/2] pc: memhp: force gaps between DIMM's GPA

On Sun, Sep 27, 2015 at 03:06:24PM +0200, Igor Mammedov wrote: > On Sun, 27 Sep 2015 13:48:21 +0300 > "Michael S. Tsirkin" wrote: > > > On Fri, Sep 25, 2015 at 03:53:12PM +0200, Igor Mammedov wrote: > > > mapping DIMMs non contiguously allows to workaround > > > virtio bug

Re: [Qemu-devel] [PATCH v5 15/21] vhost user: add rarp sending after live migration for legacy guest

On Thu, Sep 24, 2015 at 05:53:05PM -0400, Marc-André Lureau wrote: > Hi > > - Original Message - > > On Thu, Sep 24, 2015 at 6:22 PM, wrote: > > > From: Thibaut Collet > > > > > > A new vhost user message is added to allow QEMU to

Re: [Qemu-devel] [PATCH 2/2] pc: memhp: force gaps between DIMM's GPA

On Sun, 27 Sep 2015 16:11:02 +0300 "Michael S. Tsirkin" wrote: > On Sun, Sep 27, 2015 at 03:06:24PM +0200, Igor Mammedov wrote: > > On Sun, 27 Sep 2015 13:48:21 +0300 > > "Michael S. Tsirkin" wrote: > > > > > On Fri, Sep 25, 2015 at 03:53:12PM +0200, Igor

[Qemu-devel] [PATCH] ui/cocoa.m: fix help menus

Make the help menus actually work. Signed-off-by: John Arbuckle --- ui/cocoa.m | 20 1 files changed, 16 insertions(+), 4 deletions(-) diff --git a/ui/cocoa.m b/ui/cocoa.m index 334e6f6..2c81785 100644 --- a/ui/cocoa.m +++ b/ui/cocoa.m @@

[Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

Cores with and without MMU have system RAM and ROM at different locations. Also with noMMU cores system IO region is accessible through two physical address ranges. Signed-off-by: Max Filippov --- hw/xtensa/xtfpga.c | 49 + 1

[Qemu-devel] [PATCH 1/3] pflash_cfi01: add pflash_cfi01_init

pflash_cfi01_register always registers FLASH to the default system_memory region, which may not always be the right thing. Provide pflash_cfi01_init function that only creates FLASH device and sets its properties, leaving MMIO region registration to its caller. Cc: Kevin Wolf

[Qemu-devel] [PATCH 0/3] target-xtensa: xtfpga: support cores without MMU

Hello, this series adds noMMU memory map to Xtensa XTFPGA board allowing to run uClinux on cores without MMU. Max Filippov (3): pflash_cfi01: add pflash_cfi01_init target-xtensa: xtfpga: attach FLASH to system IO target-xtensa: xtfpga: support noMMU cores hw/block/pflash_cfi01.c | 29

[Qemu-devel] [PATCH 2/3] target-xtensa: xtfpga: attach FLASH to system IO

XTFPGA FLASH is tied to XTFPGA system IO block. It's not very important for systems with MMU where system IO block is visible at single location, but it's important for noMMU systems, where system IO block is accessible through two separate physical address ranges. Map XTFPGA FLASH to system IO

[Qemu-devel] [Bug 1500175] Re: unable to init msix vectors

Oh right, stupid mistake then! Never mind. Thanks for pointing this out. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1500175 Title: unable to init msix vectors Status in QEMU: New Bug

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Sun, Sep 27, 2015 at 8:38 PM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: >> Cores with and without MMU have system RAM and ROM at different locations. >> Also with noMMU cores system IO region is accessible

Re: [Qemu-devel] [PATCH 2/3] target-xtensa: xtfpga: attach FLASH to system IO

On Sun, Sep 27, 2015 at 11:01 AM, Max Filippov wrote: > On Sun, Sep 27, 2015 at 8:42 PM, Peter Crosthwaite > wrote: >> On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: >>> XTFPGA FLASH is tied to XTFPGA system IO block.

Re: [Qemu-devel] [PATCH 1/3] pflash_cfi01: add pflash_cfi01_init

On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: > pflash_cfi01_register always registers FLASH to the default > system_memory region, which may not always be the right thing. > > Provide pflash_cfi01_init function that only creates FLASH device and > sets its properties,

Re: [Qemu-devel] [PATCH v5 15/21] vhost user: add rarp sending after live migration for legacy guest

hi On Sun, Sep 27, 2015 at 5:49 PM, Thibaut Collet wrote: > Maybe a solution like that is clearer ? > > -#define VHOST_USER_PROTOCOL_FEATURE_MASK 0x7ULL > -#define VHOST_USER_PROTOCOL_F_MQ 0 > -#define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 > -#define

[Qemu-devel] [Bug 1492649] Re: QEMU soundhw HDA huge microphone lag

I seem to have this issue too. Using latest 15.04 Ubuntu, qemu and -soundhw all. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1492649 Title: QEMU soundhw HDA huge microphone lag Status in QEMU:

[Qemu-devel] [Bug 1500175] [NEW] unable to init msix vectors

Public bug reported: Using the latest stable (2.4.0.1) and earlier releases (at least down to 2.2.1), I am unable to run a qemu-system-arm virtualization on a Mac OS X Yosemite machine. QEMU was compiled with --enable-sdl. Command line: qemu-system-arm -device virtio-net,netdev=user.0 -drive

Re: [Qemu-devel] [PATCH 2/2] pc: memhp: force gaps between DIMM's GPA

On Sun, Sep 27, 2015 at 04:04:06PM +0200, Igor Mammedov wrote: > On Sun, 27 Sep 2015 16:11:02 +0300 > "Michael S. Tsirkin" wrote: > > > On Sun, Sep 27, 2015 at 03:06:24PM +0200, Igor Mammedov wrote: > > > On Sun, 27 Sep 2015 13:48:21 +0300 > > > "Michael S. Tsirkin"

Re: [Qemu-devel] [PATCH] virtio: Notice when the system doesn't support MSIx at all

Ping^2 -- this is still confusing users, cf bug LP:1500175. thanks -- PMM On 6 July 2015 at 11:38, Peter Maydell wrote: > On 3 July 2015 at 09:22, Mark Cave-Ayland > wrote: >> On 19/05/15 21:29, Richard Henderson wrote: >> >>> And do

Re: [Qemu-devel] [PATCH 2/3] target-xtensa: xtfpga: attach FLASH to system IO

On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: > XTFPGA FLASH is tied to XTFPGA system IO block. It's not very important > for systems with MMU where system IO block is visible at single > location, Are your relying on a matching change in the guest for MMU setup here?

Re: [Qemu-devel] [PATCH 1/3] pflash_cfi01: add pflash_cfi01_init

On Sun, Sep 27, 2015 at 8:25 PM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: >> pflash_cfi01_register always registers FLASH to the default >> system_memory region, which may not always be the right thing. >> >>

Re: [Qemu-devel] [PATCH 2/3] target-xtensa: xtfpga: attach FLASH to system IO

On Sun, Sep 27, 2015 at 8:42 PM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: >> XTFPGA FLASH is tied to XTFPGA system IO block. It's not very important >> for systems with MMU where system IO block is visible at

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Sun, Sep 27, 2015 at 11:13 AM, Max Filippov wrote: > On Sun, Sep 27, 2015 at 8:38 PM, Peter Crosthwaite > wrote: >> On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: >>> Cores with and without MMU have system RAM and ROM

Re: [Qemu-devel] [PATCH 1/3] pflash_cfi01: add pflash_cfi01_init

On Sun, Sep 27, 2015 at 9:32 PM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 10:51 AM, Max Filippov wrote: >> On Sun, Sep 27, 2015 at 8:25 PM, Peter Crosthwaite >> wrote: >>> On Sun, Sep 27, 2015 at 10:16 AM, Max

Re: [Qemu-devel] [PATCH 2/2] pc: memhp: force gaps between DIMM's GPA

On Sun, 27 Sep 2015 13:48:21 +0300 "Michael S. Tsirkin" wrote: > On Fri, Sep 25, 2015 at 03:53:12PM +0200, Igor Mammedov wrote: > > mapping DIMMs non contiguously allows to workaround > > virtio bug reported earlier: > >

[Qemu-devel] [Bug 1500175] Re: unable to init msix vectors

The "unable to init msix vectors" message is just a warning, and is harmless -- it is expected for the ARM boards. (There's a patch around that suppresses the incorrect warning but unfortunately it didn't get into 2.4.) Your actual problem is that you haven't specified either a guest kernel (via

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: > Cores with and without MMU have system RAM and ROM at different locations. > Also with noMMU cores system IO region is accessible through two physical > address ranges. > > Signed-off-by: Max Filippov

Re: [Qemu-devel] [PULL 00/35] TileGX basic instructions

On 9/17/15 06:36, Chen Gang wrote: > > > need analyzing (it is easy, I guess): > > mm: abort (origin has no issue) > pcnt:abort (origin has no issue) > v1addi: abort (origin has no issue) > After fix v1addi insn issue, the 3 abort cases are all fixed. :-)

Re: [Qemu-devel] [PATCH v5 15/21] vhost user: add rarp sending after live migration for legacy guest

Hi On Sun, Sep 27, 2015 at 3:12 PM, Michael S. Tsirkin wrote: > On Thu, Sep 24, 2015 at 05:53:05PM -0400, Marc-André Lureau wrote: >> Hi >> >> - Original Message - >> > On Thu, Sep 24, 2015 at 6:22 PM, wrote: >> > > From: Thibaut Collet

Re: [Qemu-devel] [PULL 23/27] i.MX: Add the i.MX25 PDK platform

On 27 September 2015 at 20:48, Peter Crosthwaite wrote: > On Fri, Sep 4, 2015 at 8:05 AM, Peter Maydell > wrote: >> From: Jean-Christophe Dubois >> >> Tested by booting a minimal Linux system on the emulated platform

Re: [Qemu-devel] [PATCH v2 1/2] target-xtensa: xtfpga: attach FLASH to system IO

On Sun, Sep 27, 2015 at 1:58 PM, Max Filippov wrote: > XTFPGA FLASH is tied to XTFPGA system IO block. It's not very important > for systems with MMU where system IO block is visible at single > location, but it's important for noMMU systems, where system IO block is >

[Qemu-devel] [PATCH v4 0/5] add ACPI node for fw_cfg on pc and arm

New since v3: - rebased to work on top of 87e896ab (introducing pc-*-25 classes), inserting fw_cfg acpi node only for machines >= 2.5. - reintroduce _STA with value 0x0B (bit 2 for u/i visibility turned off to avoid Windows complaining -- thanks Igor for

[Qemu-devel] [PATCH v4 1/5] fw_cfg: expose control register size in fw_cfg.h

Expose the size of the control register (FW_CFG_SIZE, renamed to FW_CFG_CTL_SIZE) in fw_cfg.h. Add comment to fw_cfg_io_realize() pointing out that since the 8-bit data register is always subsumed by the 16-bit control register in the port I/O case, we use the control register width as the *total*

[Qemu-devel] [PATCH v4 3/5] acpi: pc: add fw_cfg device node to ssdt

Add a fw_cfg device node to the ACPI SSDT, on machine types pc-*-2.5 and up. While the guest-side BIOS can't utilize this information (since it has to access the hard-coded fw_cfg device to extract ACPI tables to begin with), having fw_cfg listed in ACPI will help the guest kernel keep a more

[Qemu-devel] [PATCH v4 5/5] fw_cfg: document ACPI device node information

Signed-off-by: Gabriel Somlo --- docs/specs/fw_cfg.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt index bc95404..4d85701 100644 --- a/docs/specs/fw_cfg.txt +++ b/docs/specs/fw_cfg.txt @@ -77,6 +77,15 @@ increasing

[Qemu-devel] [PATCH v4 4/5] acpi: arm: add fw_cfg device node to dsdt

Add a fw_cfg device node to the ACPI DSDT. This is mostly informational, as the authoritative fw_cfg MMIO region(s) are listed in the Device Tree. However, since we are building ACPI tables, we might as well be thorough while at it... Signed-off-by: Gabriel Somlo ---

[Qemu-devel] [PATCH v4 2/5] pc: fw_cfg: move ioport base constant to pc.h

Move BIOS_CFG_IOPORT define from pc.c to pc.h, and rename it to FW_CFG_IO_BASE. Signed-off-by: Gabriel Somlo --- hw/i386/pc.c | 5 ++--- include/hw/i386/pc.h | 2 ++ 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index

Re: [Qemu-devel] [PULL 23/27] i.MX: Add the i.MX25 PDK platform

On Fri, Sep 4, 2015 at 8:05 AM, Peter Maydell wrote: > From: Jean-Christophe Dubois > > Tested by booting a minimal Linux system on the emulated platform > Tested by booting the Xvisor hypervisor on the emulated platform > > Signed-off-by:

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Mon, Sep 28, 2015 at 12:28 AM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 12:01 PM, Max Filippov wrote: >> On Sun, Sep 27, 2015 at 9:43 PM, Peter Crosthwaite >> wrote: >>> On Sun, Sep 27, 2015 at 11:13 AM,

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Sun, Sep 27, 2015 at 2:48 PM, Max Filippov wrote: > On Mon, Sep 28, 2015 at 12:28 AM, Peter Crosthwaite > wrote: >> On Sun, Sep 27, 2015 at 12:01 PM, Max Filippov wrote: >>> On Sun, Sep 27, 2015 at 9:43 PM, Peter Crosthwaite

[Qemu-devel] [PATCH v2 1/2] target-xtensa: xtfpga: attach FLASH to system IO

XTFPGA FLASH is tied to XTFPGA system IO block. It's not very important for systems with MMU where system IO block is visible at single location, but it's important for noMMU systems, where system IO block is accessible through two separate physical address ranges. Map XTFPGA FLASH to system IO

[Qemu-devel] [PATCH v2 2/2] target-xtensa: xtfpga: support noMMU cores

Cores with and without MMU have system RAM and ROM at different locations. Also with noMMU cores system IO region is accessible through two physical address ranges. Signed-off-by: Max Filippov --- Changes v1->v2: - replace bool mmu with enum; - decide if system IO alias is

[Qemu-devel] [PATCH v2 0/2] target-xtensa: xtfpga: support cores without MMU

Hello, this series adds noMMU memory map to Xtensa XTFPGA board allowing to run uClinux on cores without MMU. Changes v1->v2: - drop patch 1; - create and initialize XTFPGA FLASH device in hw/xtensa/xtfpga.c with series of qdev_prop_set_*; - replace bool mmu with enum; - decide if system IO

Re: [Qemu-devel] [PATCH v2 1/2] target-xtensa: xtfpga: attach FLASH to system IO

On Mon, Sep 28, 2015 at 12:34 AM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 1:58 PM, Max Filippov wrote: >> +qdev_prop_set_uint16(dev, "id0", 0x00); >> +qdev_prop_set_uint16(dev, "id1", 0x00); >> +qdev_prop_set_uint16(dev,

[Qemu-devel] [Bug 1500175] Re: unable to init msix vectors

No problem -- QEMU is unfortunately not as clear as it perhaps could be about what happens in this situation. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Sun, Sep 27, 2015 at 12:01 PM, Max Filippov wrote: > On Sun, Sep 27, 2015 at 9:43 PM, Peter Crosthwaite > wrote: >> On Sun, Sep 27, 2015 at 11:13 AM, Max Filippov wrote: >>> On Sun, Sep 27, 2015 at 8:38 PM, Peter Crosthwaite

[Qemu-devel] ARM CPU affinities

Hi Peter, I am looking at this: static void arm_cpu_initfn(Object *obj) { ... Aff1 = cs->cpu_index / ARM_CPUS_PER_CLUSTER; Aff0 = cs->cpu_index % ARM_CPUS_PER_CLUSTER; cpu->mp_affinity = (Aff1 << ARM_AFF1_SHIFT) | Aff0; Should we push this up to the machine model? I am trying

Re: [Qemu-devel] feature idea: allow user to run custom scripts

On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell wrote: > On 27 September 2015 at 04:39, Programmingkid > wrote: >> Would you be open to a feature that allows the user to select >> and run a custom file that has commands in it that would run >>

Re: [Qemu-devel] [PATCH 3/3] target-xtensa: xtfpga: support noMMU cores

On Sun, Sep 27, 2015 at 9:43 PM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 11:13 AM, Max Filippov wrote: >> On Sun, Sep 27, 2015 at 8:38 PM, Peter Crosthwaite >> wrote: >>> On Sun, Sep 27, 2015 at 10:16 AM, Max

Re: [Qemu-devel] [PATCH v5 00/21] vhost-user: add migration support

On Thu, Sep 24, 2015 at 06:22:00PM +0200, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Hi, > > The following series implement shareable log for vhost-user to support > memory tracking during live migration. On qemu-side, the solution is > fairly

Re: [Qemu-devel] [PATCH v5 15/21] vhost user: add rarp sending after live migration for legacy guest

On Sun, Sep 27, 2015 at 5:13 PM, Marc-André Lureau wrote: > Hi > > On Sun, Sep 27, 2015 at 3:12 PM, Michael S. Tsirkin wrote: >> On Thu, Sep 24, 2015 at 05:53:05PM -0400, Marc-André Lureau wrote: >>> Hi >>> >>> - Original Message - >>> > On

Re: [Qemu-devel] [PATCH 1/3] pflash_cfi01: add pflash_cfi01_init

On Sun, Sep 27, 2015 at 10:51 AM, Max Filippov wrote: > On Sun, Sep 27, 2015 at 8:25 PM, Peter Crosthwaite > wrote: >> On Sun, Sep 27, 2015 at 10:16 AM, Max Filippov wrote: >>> pflash_cfi01_register always registers FLASH to

Re: [Qemu-devel] [PATCH] block: disable I/O limits at the beginning of bdrv_close()

On Fri, 09/25 16:31, Alberto Garcia wrote: > On Fri 25 Sep 2015 04:22:26 PM CEST, Eric Blake wrote: > > >> Disabling I/O limits from a BDS also drains all pending throttled > >> requests, so it should be done at the beginning of bdrv_close() with > >> the rest of the bdrv_drain() calls before the

Re: [Qemu-devel] feature idea: allow user to run custom scripts

On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote: > On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell > wrote: >> On 27 September 2015 at 04:39, Programmingkid >> wrote: >>> Would you be open to a feature that allows the user to select

Re: [Qemu-devel] feature idea: allow user to run custom scripts

Quoting Programmingkid (2015-09-27 20:49:24) > > On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote: > > > On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell > > wrote: > >> On 27 September 2015 at 04:39, Programmingkid > >> wrote: > >>>

[Qemu-devel] [PATCH 2/3] block: mirror - split out part of mirror_run()

This is code relocation, to pull the part of mirror_run() that calls mirror_iteration out into a separate function. Signed-off-by: Jeff Cody --- block/mirror.c | 206 ++--- 1 file changed, 110 insertions(+), 96 deletions(-)

[Qemu-devel] [PATCH 1/3] block: allow creation of detached dirty bitmaps

This allows the creation of detached dirty bitmaps, so that the block driver dirty bitmaps can be used without inserting the bitmap into the dirty bitmap list for a BDS. To free a bitmap that was created "detached = true", call bdrv_release_dirty_bitmap() with the BlockDriverState argument as

[Qemu-devel] [PATCH 0/3] block: mirror - Write zeroes for unallocated sectors if no zero init

When doing a block mirror to a target that does not support zero init (e.g. host device and raw format), unallocated sectors on the source may lead to a corrupted target image. Unallocated sectors are skipped over during block mirror (the dirty bitmap is only loaded with allocated sectors), so

Re: [Qemu-devel] [PATCH V7 2/2] sdhci: Split sdhci.h for public and internal device usage

Hi Peter, > -Original Message- > From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] > Sent: Saturday, September 26, 2015 11:42 PM > To: Sai Pavan Boddu; Peter Maydell > Cc: qemu-devel@nongnu.org Developers; Alistair Francis; Edgar Iglesias; Sai > Pavan Boddu > Subject: Re: [PATCH

[Qemu-devel] [PATCH] e1000: use alias for default model

Instead of using a new type for default model (82540em), using an alias for this to avoid bit duplication. Cc: Markus Armbruster Signed-off-by: Jason Wang --- hw/net/e1000.c | 8 +--- qdev-monitor.c | 1 + 2 files changed, 2 insertions(+), 7

Re: [Qemu-devel] [PATCH v11 02/12] init/cleanup of netfilter object

On 09/28/2015 01:47 PM, Jason Wang wrote: On 09/25/2015 10:10 PM, Markus Armbruster wrote: Jason Wang writes: On 09/24/2015 07:52 PM, Markus Armbruster wrote: Yang Hongyang writes: On 09/24/2015 04:41 PM, Markus Armbruster wrote: Yang

[Qemu-devel] [Bug 1500265] [NEW] nested 9p filesystem with security_model=mapped-xattr

Public bug reported: I do not know whether this is a bug or a feature request, but on a 9p virtfs with security_model=mapped-xattr, access to extended attributes starting with "user.virtfs" coming from the guest seem to be silently ignored. Would it not be more correct to use some sort of

[Qemu-devel] [Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

After looking at the code, it seems that disabling the user.virtfs namespace was the intended behaviour. I have created a patch implementing nesting instead of disabling. I do not know if this is the right way to do it, but I did some limited testing and it seemed ok. ** Patch added:

Re: [Qemu-devel] feature idea: allow user to run custom scripts

On Sep 27, 2015, at 10:30 PM, Michael Roth wrote: > Quoting Programmingkid (2015-09-27 20:49:24) >> >> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote: >> >>> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell >>> wrote: On 27 September 2015 at 04:39,

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

On 9/22/2015 12:03 AM, Stefano Stabellini wrote: It is going to be in QEMU 2.5 and qemu-xen 4.7. Thanks for your reply. Do we have any possibility of just merging this series into qemu-xen 4.6? We really want to support IGD passthrough on xen 4.6 if possible :) Thanks Tiejun On Mon, 21

Re: [Qemu-devel] [PATCH 2/2] pc: memhp: force gaps between DIMM's GPA

On Sun, Sep 27, 2015 at 04:04:06PM +0200, Igor Mammedov wrote: > On Sun, 27 Sep 2015 16:11:02 +0300 > "Michael S. Tsirkin" wrote: > > > On Sun, Sep 27, 2015 at 03:06:24PM +0200, Igor Mammedov wrote: > > > On Sun, 27 Sep 2015 13:48:21 +0300 > > > "Michael S. Tsirkin"

[Qemu-devel] [PATCH 3/3] block: mirror - zero unallocated target sectors when zero init not present

During mirror, if the target device does not have support zero initialization, a mirror may result in a corrupt image. For instance, on mirror to a host device with format = raw, whatever random data is on the target device will still be there for unallocated sectors. This is because during the

[Qemu-devel] [PATCH v8 2/2] sdhci: Split sdhci.h for public and internal device usage

Split sdhci.h into pubilc version (i.e include/hw/sd/sdhci.h) and internal version (i.e hw/sd/sdhci-interna.h) based on register declarations and object declaration. Signed-off-by: Sai Pavan Boddu Reviewed-by: Alistair Francis Reviewed-by: Peter

[Qemu-devel] [PATCH v8 1/2] sd.h: Move sd.h to include/hw/sd/

Create a sd directory under include/hw/ and move sd.h to same. Signed-off-by: Sai Pavan Boddu Reviewed-by: Alistair Francis Reviewed-by: Peter Crosthwaite --- Changes for V8: None Changes for V7: None Changes

Re: [Qemu-devel] [PATCH v11 02/12] init/cleanup of netfilter object

On 09/25/2015 10:10 PM, Markus Armbruster wrote: > Jason Wang writes: > >> On 09/24/2015 07:52 PM, Markus Armbruster wrote: >>> Yang Hongyang writes: >>> On 09/24/2015 04:41 PM, Markus Armbruster wrote: > Yang Hongyang

[Qemu-devel] [PATCH] target-tilegx: Let v1addi call its own implementation

From: Chen Gang Original implementation let v1addi instruction call v1cmpeqi. It will cause gcc testsuite fail: the relate test is for mm instruction, tilegx qemu implement mm instruction correctly, but its 'v1addi' causes test abort. Signed-off-by: Chen Gang

Re: [Qemu-devel] Triggering two arm processors from same interrupt (A9 and M3)

W dniu 26.09.2015 o 19:46, Peter Crosthwaite pisze: On Sat, Sep 26, 2015 at 9:08 AM, Peter Maydell wrote: On 26 September 2015 at 01:54, mar.krzeminski wrote: Hello again, My next question is still related with M3 and A9 board what I

[Qemu-devel] [RFC/PATCH] monitor/ppc: Access all SPRs from the monitor

We already have a table with all supported SPRs along with their names, so let's use that rather than a duplicate table that is perpetually out of sync in the monitor code. This adds a new monitor hook target_extra_monitor_def() which is called if nothing is found is the normal table. We still

[Qemu-devel] qemu-system-alpha -nographic does not work

git master clone from 09/27/2015, 8:07 git rev-parse HEAD 9e071429e649346c14b2dc76902f84f8352d2333 if i try to start qemu-system-alpha with option -nographic while installing debian lenny 5.0.10 for alpha i get this output and qemu hangs - without using -nographic debian is fully installable

Re: [Qemu-devel] [PATCH v4 1/1] intel_iommu: Add support for translation for devices behind bridges

On Sat, Sep 26, 2015 at 08:09:56AM +0200, Knut Omang wrote: > - Use a hash table indexed on bus pointers to store information about buses > instead of using the bus numbers. > Bus pointers are stored in a new VTDBus struct together with the vector > of device address space pointers indexed

[Qemu-devel] [PATCH repost 0/4] add mitigation against buffer overflows

Multiple places in QEMU map guest memory, then access it directly. Unfortunately since we are using C, there's always a chance that we'll miss a bounds check when we do this. This has a potential to corrupt QEMU memory. As a mitigation strategy against such exploits, allocate a page in HVA space

Re: [Qemu-devel] feature idea: allow user to run custom scripts

On 27 September 2015 at 04:39, Programmingkid wrote: > Would you be open to a feature that allows the user to select > and run a custom file that has commands in it that would run > in the monitor? Sounds like a VM management layer feature. -- PMM

[Qemu-devel] [PATCH repost 2/4] oslib: allocate PROT_NONE pages on top of RAM

This inserts a read and write protected page between RAM and QEMU memory. This makes it harder to exploit QEMU bugs resulting from buffer overflows in devices using variants of cpu_physical_memory_map, dma_memory_map etc. Signed-off-by: Michael S. Tsirkin --- util/oslib-posix.c

[Qemu-devel] [PATCH repost 4/4] exec: factor out duplicate mmap code

Anonymous and file-backed RAM allocation are now almost exactly the same. Reduce code duplication by moving RAM mmap code out of oslib-posix.c and exec.c. Signed-off-by: Michael S. Tsirkin --- include/qemu/mmap-alloc.h | 10 + exec.c| 47

[Qemu-devel] [PATCH repost 1/4] oslib: rework anonimous RAM allocation

At the moment we first allocate RAM, sometimes more than necessary for alignment reasons. We then free the extra RAM. Rework this to avoid the temporary allocation: reserve the range by mapping it with PROT_NONE, then use just the necessary range with MAP_FIXED. Signed-off-by: Michael S.

[Qemu-devel] [PATCH repost 3/4] exec: allocate PROT_NONE pages on top of RAM

This inserts a read and write protected page between RAM and QEMU memory, for file-backend RAM. This makes it harder to exploit QEMU bugs resulting from buffer overflows in devices using variants of cpu_physical_memory_map, dma_memory_map etc. Signed-off-by: Michael S. Tsirkin

Re: [Qemu-devel] [PATCH 2/2] pc: memhp: force gaps between DIMM's GPA

On Fri, Sep 25, 2015 at 03:53:12PM +0200, Igor Mammedov wrote: > mapping DIMMs non contiguously allows to workaround > virtio bug reported earlier: > http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg00522.html > in this case guest kernel doesn't allocate buffers > that can cross DIMM