Re: [Qemu-devel] [PATCH] pc: limit 64 bit hole to 2G by default

[Andreas Färber]

Hi,

Am 24.07.2013 08:01, schrieb Michael S. Tsirkin:
> It turns out that some 32 bit windows guests crash
> if 64 bit PCI hole size is >2G.
> Limit it to 2G for piix and q35 by default,
> add properties to let management override the hole size.
> 
> Examples:
> -global i440FX-pcihost.pci_hole64_size=137438953472
> 
> -global q35-pcihost.pci_hole64_size=137438953472
> 
> Reported-by: Igor Mammedov ,
> Signed-off-by: Michael S. Tsirkin 
> ---
>  hw/i386/pc.c  | 35 ---
>  hw/i386/pc_piix.c | 14 +-
>  hw/pci-host/piix.c| 42 ++
>  hw/pci-host/q35.c | 29 +
>  include/hw/i386/pc.h  |  7 +--
>  include/hw/pci-host/q35.h |  1 +
>  6 files changed, 78 insertions(+), 50 deletions(-)
[...]
> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index 7fb2fb1..963b3d8 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -40,6 +41,7 @@
>  
>  typedef struct I440FXState {
>  PCIHostState parent_obj;
> +uint64_t pci_hole64_size;
>  } I440FXState;
>  
>  #define PIIX_NUM_PIC_IRQS   16  /* i8259 * 2 */
> @@ -234,9 +236,9 @@ static PCIBus *i440fx_common_init(const char *device_name,
>hwaddr pci_hole_start,
>hwaddr pci_hole_size,
>hwaddr pci_hole64_start,
> -  hwaddr pci_hole64_size,
>MemoryRegion *pci_address_space,
> -  MemoryRegion *ram_memory)
> +  MemoryRegion *ram_memory,
> +  PcGuestInfo *guest_info)
>  {
>  DeviceState *dev;
>  PCIBus *b;
> @@ -245,15 +247,31 @@ static PCIBus *i440fx_common_init(const char 
> *device_name,
>  PIIX3State *piix3;
>  PCII440FXState *f;
>  unsigned i;
> +I440FXState *i440fx;
>  
>  dev = qdev_create(NULL, "i440FX-pcihost");
>  s = PCI_HOST_BRIDGE(dev);
> +i440fx = OBJECT_CHECK(I440FXState, dev, "i440FX-pcihost");

If we're lacking a macro for this, please define one. E.g.:
#define TYPE_I440FX "i440FX-pcihost"
#define I440FX(obj) OBJECT_CHECK(I440FXState, (obj), TYPE_I440FX)
above I440FXState.

i440fx = I440FX(dev);

So far was unused due to PCI_HOST_BRIDGE(), I guess.

>  b = pci_bus_new(dev, NULL, pci_address_space,
>  address_space_io, 0, TYPE_PCI_BUS);
>  s->bus = b;
>  object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), 
> NULL);
>  qdev_init_nofail(dev);
>  
> +if (guest_info) {
> +/* Set PCI window size the way seabios has always done it. */
> +/* Power of 2 so bios can cover it with a single MTRR */
> +if (ram_size <= 0x8000)
> +guest_info->pci_info.w32.begin = 0x8000;
> +else if (ram_size <= 0xc000)
> +guest_info->pci_info.w32.begin = 0xc000;
> +else
> +guest_info->pci_info.w32.begin = 0xe000;
> +
> +pc_init_pci_info(&guest_info->pci_info,
> + pci_hole64_start, i440fx->pci_hole64_size);
> +}
> +
>  d = pci_create_simple(b, 0, device_name);
>  *pi440fx_state = I440FX_PCI_DEVICE(d);
>  f = *pi440fx_state;
> @@ -265,8 +283,8 @@ static PCIBus *i440fx_common_init(const char *device_name,
>  memory_region_add_subregion(f->system_memory, pci_hole_start, 
> &f->pci_hole);
>  memory_region_init_alias(&f->pci_hole_64bit, OBJECT(d), "pci-hole64",
>   f->pci_address_space,
> - pci_hole64_start, pci_hole64_size);
> -if (pci_hole64_size) {
> + pci_hole64_start, i440fx->pci_hole64_size);
> +if (i440fx->pci_hole64_size) {
>  memory_region_add_subregion(f->system_memory, pci_hole64_start,
>  &f->pci_hole_64bit);
>  }
> @@ -322,8 +340,8 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int 
> *piix3_devfn,
>  hwaddr pci_hole_start,
>  hwaddr pci_hole_size,
>  hwaddr pci_hole64_start,
> -hwaddr pci_hole64_size,
> -MemoryRegion *pci_memory, MemoryRegion *ram_memory)
> +MemoryRegion *pci_memory, MemoryRegion *ram_memory,
> +PcGuestInfo *guest_info)
>  
>  {
>  PCIBus *b;
> @@ -332,8 +350,9 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int 
> *piix3_devfn,
> piix3_devfn, isa_bus, pic,
> address_space_mem, address_space_io, ram_size,
> pci_hole_start, pci_hole_size,
> -   pci_hole64_start, pci_hole64_size,
> -   pci_memory, ram_memory);
> +   pci_hole64_start,
> +

Re: [Qemu-devel] trim in windows guest witch virtio

[Paolo Bonzini]

Il 24/07/2013 02:53, Libaiqing ha scritto:
> Hi paolo,
> 
> I test window guest with ide device with the following config,trim with 
> ide drive failed.
> 
>  1 The host fs is ext4 with discard option: 
>/dev/sdb1 on /home/sdb type ext4 (rw,relatime,discard,data=ordered)
>  
>  2 qemu config : ide drive with discard open
> x86_64-softmmu/qemu-system-x86_64 -enable-kvm -name win7 -M pc-0.15 -m 1024 
> -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2  -drive 
> file=/home/win7_base.qcow2,if=ide,index=0,format=qcow2,id=ad  -drive 
> file=/home/sdb/raw.img,if=ide,index=1,format=raw,id=hd,discard=on  -monitor 
> stdio   -vga qxl  -vnc :1 -device usb-tablet,id=input0

TRIM is supported only on "-M pc-1.5" and "-M pc".

>  3 In win7 guest,init drive d,fill it with files,then shift+del files
> 
>  4 The file /home/sdb/raw.img does not become small,when listing with -s 
> option.
> 
>  It seems that the windows ntfs does not send trim to ide controller. No 
> IDE_DMA_TRIM request received.

Note that this may not happen immediately.  NTFS may send TRIM later.

>  Is there any config wrong?
> 
>  Btw,I found the info from the URL: 
> http://msdn.microsoft.com/en-us/library/windows/desktop/hh848053(v=vs.85).aspx
>  Qemu can do the same thing like hyper-v with windows guest?

I don't know, I never tested it with Windows guests.  It looks like
Windows 8 would not need a filter driver to do TRIM on SCSI disks (you
could try with megasas, so that you do not need a driver for the HBA).

Paolo

Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

[Paolo Bonzini]

Il 24/07/2013 03:28, liu ping fan ha scritto:
> On Tue, Jul 23, 2013 at 6:30 PM, Paolo Bonzini  wrote:
>> > Il 23/07/2013 04:53, liu ping fan ha scritto:
>>> >> The scenior I can figure out is if adopting timeout of poll, then when
>>> >> changing the deadline, we need to invoke poll, and set the new
>>> >> timeout, right?
>> >
>> > Yes, you need to call aio_notify so that poll is reinvoked.
>> >
> I try to list the difference between alarm_timer and timeout of poll.
> It includes thread-affinity, resolution and easy-use.
> 
> Most of all,  thread-affinity
> The main issue with alarm timer is the affinity of timer_t with
> threads. For linux, SIGEV_THREAD_ID has been supported for a very long
> time and we already associate the signal with the specified thread. So
> the only issue is left for other unix, we can emulate the affinity by
> using SIGEV_THREAD and repost the event to the specified thread.
> As to timeout of poll, it has the affinity of threads.
> 
> Resolution:
> alarm_timer provides higher resolution, but do we care about it?

With ppoll, is this true or just hearsay?

(Without ppoll, indeed setitimer has 1 us resolution while poll has 1
ms; too bad that select has other problems, because select has also 1 us
resolution).

Paolo

> easy-use:
> The reset of the deadline as mentioned.
> 
> Finally, I admit timeout of poll will save large chunk of platform-related 
> code.

[Qemu-devel] [PATCH] pc: limit 64 bit hole to 2G by default

[Michael S. Tsirkin]

It turns out that some 32 bit windows guests crash
if 64 bit PCI hole size is >2G.
Limit it to 2G for piix and q35 by default,
add properties to let management override the hole size.

Examples:
-global i440FX-pcihost.pci_hole64_size=137438953472

-global q35-pcihost.pci_hole64_size=137438953472

Reported-by: Igor Mammedov ,
Signed-off-by: Michael S. Tsirkin 
---
 hw/i386/pc.c  | 35 ---
 hw/i386/pc_piix.c | 14 +-
 hw/pci-host/piix.c| 42 ++
 hw/pci-host/q35.c | 29 +
 include/hw/i386/pc.h  |  7 +--
 include/hw/pci-host/q35.h |  1 +
 6 files changed, 78 insertions(+), 50 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a7c578f..9cc0fda 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1072,27 +1072,32 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t 
below_4g_mem_size,
 memset(&guest_info->found_cpus, 0, sizeof guest_info->found_cpus);
 qemu_for_each_cpu(pc_set_cpu_guest_info, guest_info);
 
-guest_info->pci_info.w32.end = IO_APIC_DEFAULT_ADDRESS;
-if (sizeof(hwaddr) == 4) {
-guest_info->pci_info.w64.begin = 0;
-guest_info->pci_info.w64.end = 0;
-} else {
+guest_info_state->machine_done.notify = pc_guest_info_machine_done;
+qemu_add_machine_init_done_notifier(&guest_info_state->machine_done);
+return guest_info;
+}
+
+void pc_init_pci_info(PcPciInfo *pci_info,
+  uint64_t pci_hole64_start,
+  uint64_t pci_hole64_size)
+{
+pci_info->w32.end = IO_APIC_DEFAULT_ADDRESS;
+
+if (pci_hole64_size & ((0x1 << 30) - 1)) {
+error_report("Invalid value for pci_hole64_size: "
+ "must be a multiple of 1G. Rounding up.");
+}
+pci_hole64_size = ROUND_UP(pci_hole64_size, 0x1ULL << 30);
+
 /*
  * BIOS does not set MTRR entries for the 64 bit window, so no need to
  * align address to power of two.  Align address at 1G, this makes sure
  * it can be exactly covered with a PAT entry even when using huge
  * pages.
  */
-guest_info->pci_info.w64.begin =
-ROUND_UP((0x1ULL << 32) + above_4g_mem_size, 0x1ULL << 30);
-guest_info->pci_info.w64.end = guest_info->pci_info.w64.begin +
-(0x1ULL << 31);
-assert(guest_info->pci_info.w64.begin <= guest_info->pci_info.w64.end);
-}
-
-guest_info_state->machine_done.notify = pc_guest_info_machine_done;
-qemu_add_machine_init_done_notifier(&guest_info_state->machine_done);
-return guest_info;
+pci_info->w64.begin = ROUND_UP(pci_hole64_start, 0x1ULL << 30);
+pci_info->w64.end = pci_info->w64.begin + pci_hole64_size;
+assert(pci_info->w64.begin <= pci_info->w64.end);
 }
 
 void pc_acpi_init(const char *default_dsdt)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 76df42b..da61fa3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -137,15 +137,6 @@ static void pc_init1(MemoryRegion *system_memory,
 
 guest_info->has_pci_info = has_pci_info;
 
-/* Set PCI window size the way seabios has always done it. */
-/* Power of 2 so bios can cover it with a single MTRR */
-if (ram_size <= 0x8000)
-guest_info->pci_info.w32.begin = 0x8000;
-else if (ram_size <= 0xc000)
-guest_info->pci_info.w32.begin = 0xc000;
-else
-guest_info->pci_info.w32.begin = 0xe000;
-
 /* allocate ram and load rom/bios */
 if (!xen_enabled()) {
 fw_cfg = pc_memory_init(system_memory,
@@ -169,10 +160,7 @@ static void pc_init1(MemoryRegion *system_memory,
   below_4g_mem_size,
   0x1ULL - below_4g_mem_size,
   0x1ULL + above_4g_mem_size,
-  (sizeof(hwaddr) == 4
-   ? 0
-   : ((uint64_t)1 << 62)),
-  pci_memory, ram_memory);
+  pci_memory, ram_memory, guest_info);
 } else {
 pci_bus = NULL;
 i440fx_state = NULL;
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 7fb2fb1..963b3d8 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -40,6 +41,7 @@
 
 typedef struct I440FXState {
 PCIHostState parent_obj;
+uint64_t pci_hole64_size;
 } I440FXState;
 
 #define PIIX_NUM_PIC_IRQS   16  /* i8259 * 2 */
@@ -234,9 +236,9 @@ static PCIBus *i440fx_common_init(const char *device_name,
   hwaddr pci_hole_start,
   hwaddr pci_hole_size,
   hwaddr pci_hole64_start,
-  hwaddr pci_hole64_size,
   MemoryRegion *pci_address_space,
-  MemoryR

Re: [Qemu-devel] [PATCH 1/2] prep_pci: set isa_mem_base in the PCI host bridge

[Hervé Poussineau]

Andreas Färber a écrit :

Am 23.07.2013 23:16, schrieb Hervé Poussineau:

Currently, it is done by i82378 device, which shouldn't care of it.

Signed-off-by: Hervé Poussineau 
---
 hw/isa/i82378.c|3 ---
 hw/pci-host/prep.c |2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index b25ed04..de71d81 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -45,7 +45,6 @@ typedef struct I82378State {
 typedef struct PCIi82378State {
 PCIDevice pci_dev;
 uint32_t isa_io_base;
-uint32_t isa_mem_base;
 I82378State state;
 } PCIi82378State;
 
@@ -234,7 +233,6 @@ static int pci_i82378_init(PCIDevice *dev)

 pci_set_long(dev->wmask + PCI_BASE_ADDRESS_0, 0);
 pci_set_long(pci_conf + PCI_BASE_ADDRESS_0, pci->isa_io_base);
 
-isa_mem_base = pci->isa_mem_base;

 isa_bus_new(&dev->qdev, pci_address_space_io(dev));
 
 i82378_init(&dev->qdev, s);

@@ -244,7 +242,6 @@ static int pci_i82378_init(PCIDevice *dev)
 
 static Property i82378_properties[] = {

 DEFINE_PROP_HEX32("iobase", PCIi82378State, isa_io_base, 0x8000),
-DEFINE_PROP_HEX32("membase", PCIi82378State, isa_mem_base, 0xc000),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep.c

index b41d564..d6bcc63 100644
--- a/hw/pci-host/prep.c
+++ b/hw/pci-host/prep.c
@@ -119,6 +119,8 @@ static void raven_pcihost_realizefn(DeviceState *d, Error 
**errp)
 MemoryRegion *address_space_mem = get_system_memory();
 int i;
 
+isa_mem_base = 0xc000;

+
 for (i = 0; i < 4; i++) {
 sysbus_init_irq(dev, &s->irq[i]);
 }


Patch is okay with me, but I wonder what we still need the global
isa_mem_base for? The only users seem to be VGA, adding offsets to it.


Indeed, isa_mem_base should be removed, and PCI bus regions (memory and 
I/O) should be adapted in PCI host.
However, while I have a patch pending, it is not ready yet, so I prefer 
to postpone it past QEMU 1.6.


Hervé

[Qemu-devel] QEMU dynamic call graph

[ammad rehmat]

Hi,

I am trying to port QEMU to a new processor and i want to generate a
dynamic call graph for QEMU. I have tried following tutorial but its not
working.
http://www.ibm.com/developerworks/library/l-graphvis/

Any help regarding generation of qemu dynamic call graph will be
appreciated. I have checked online there are a few tools available but qemu
is such a big piece of software that none of them seems to be working.

-- 
Ammad Rehmat
Research Officer,
Al-Khawarizmi Institute of Computer Science (KICS),
University of Engineering & Technology (UET), Lahore.
+92-323-405-6631

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Alexey Kardashevskiy]

On 07/23/2013 01:28 AM, Alexander Graf wrote:
> Today we generate the device tree once on machine initialization and then
> store the finalized blob in memory to reload it on reset.
> 
> This is bad for 2 reasons. First we potentially waste a bunch of RAM for no
> good reason, as we have all information required to regenerate the device
> tree available anyways.
> 
> The second reason is even more important. On machine init when we generate
> the device tree for the first time, we don't have all of the devices fully
> initialized yet. But the device tree needs to potentially walk devices to
> put information about them into the device tree.


Not fully initialized yet? They are not even created at the machine init
point as far as I can tell, and that was the reason to do for spapr what
you are trying to do for e500 :)


-- 
Alexey

[Qemu-devel] [Solved]FYI//Re: [Question] why x2apic's set by default without host support(on Nehalem CPU).

[Peter Huang(Peng)]

FYI, just for information sharing.

KVM emulated x2apic feature no matter host supports it or not.
You can get the code from arch/x86/kvm/cpuid.c.
kvm_dev_ioctl_get_supported_cpuid ()->do_cpuid_ent()

  /* we support x2apic emulation even if host does not support

 * it since we emulate x2apic in software */

entry->ecx |= F(*X2APIC*);


QEMU will get this feature through kvm_ioctl().

On 2013-07-24 8:48, Peter Huang(Peng) wrote:
> Hi,Jiri
>
> Thanks for replying.
>
> So why VM identified different features from host is due to the hypervisor 
> filtering.
> I will dig into the hypervisor of how it filter features, and update status 
> later.
>
> Thanks again.

Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

[liu ping fan]

On Tue, Jul 23, 2013 at 6:30 PM, Paolo Bonzini  wrote:
> Il 23/07/2013 04:53, liu ping fan ha scritto:
>> The scenior I can figure out is if adopting timeout of poll, then when
>> changing the deadline, we need to invoke poll, and set the new
>> timeout, right?
>
> Yes, you need to call aio_notify so that poll is reinvoked.
>
I try to list the difference between alarm_timer and timeout of poll.
It includes thread-affinity, resolution and easy-use.

Most of all,  thread-affinity
The main issue with alarm timer is the affinity of timer_t with
threads. For linux, SIGEV_THREAD_ID has been supported for a very long
time and we already associate the signal with the specified thread. So
the only issue is left for other unix, we can emulate the affinity by
using SIGEV_THREAD and repost the event to the specified thread.
As to timeout of poll, it has the affinity of threads.

Resolution:
alarm_timer provides higher resolution, but do we care about it?

easy-use:
The reset of the deadline as mentioned.

Finally, I admit timeout of poll will save large chunk of platform-related code.

Thanks and regards,
Pingfan

> Paolo

Re: [Qemu-devel] [PATCH V6 0/3] Implement sync modes for drive-backup.

[Fam Zheng]

On Tue, 07/23 12:55, Ian Main wrote:
> On Tue, Jul 23, 2013 at 01:53:51PM +0200, Stefan Hajnoczi wrote:
> > On Mon, Jul 22, 2013 at 03:09:17PM -0700, Ian Main wrote:
> > > This patch adds sync modes on top of the work that Stefan Hajnoczi has 
> > > done.
> > > 
> > > These patches apply on kevin/block.
> > > 
> > > Hopefully all is in order as this is my first QEMU patch.  Many thanks to
> > > Stephan and Fam Zheng for their help.
> > > 
> > > V2:
> > > 
> > > - No longer poll, instead use qemu_coroutine_yield().
> > > - Use bdrv_co_is_allocated().
> > > - Much better SYNC_MODE_NONE test.
> > > 
> > > V3:
> > > 
> > > - A few style fixes.
> > > - Better commit message explaining how TOP and NONE operate.
> > > - Verified using checkpatch.pl.
> > > 
> > > V4:
> > > 
> > > - Add patch to use the source as a backing hd during backup.
> > > - Add patch to default sync mode none to qcow2.
> > > 
> > > V5:
> > > 
> > > - Fix qcow2 patch.  Forgot to git add final version.
> > > 
> > > V6:
> > > 
> > > - Default to requiring 'format' when mode is absolute-paths.
> > > - Removed one bad hunk that was misapplying.
> > > - Fixed docs, examples and tests to match changes.
> > > - Added tests for format bad/missing.
> > > - Added bdrv_set_in_use() to target.
> > > - Default to qcow2 patch not required.
> > > 
> > > Ian Main (3):
> > >   Implement sync modes for drive-backup.
> > >   Add tests for sync modes 'TOP' and 'NONE'
> > >   Add backing drive while performing backup.
> > > 
> > >  block/backup.c| 107 
> > > +
> > >  blockdev.c|  36 +-
> > >  include/block/block_int.h |   4 +-
> > >  qapi-schema.json  |   4 +-
> > >  qmp-commands.hx   |   2 +
> > >  tests/qemu-iotests/055| 108 
> > > +-
> > >  tests/qemu-iotests/055.out|   4 +-
> > >  tests/qemu-iotests/group  |   2 +-
> > >  tests/qemu-iotests/iotests.py |   5 ++
> > >  9 files changed, 211 insertions(+), 61 deletions(-)
> > 
> > This patch mostly takes care of image fleecing except it does not give
> > the target a device name which can be used by nbd-server-add.
> 
> It's not clear to me how to do that.  I looked through Fams series and
> was hoping to find a clue there but I may have missed it.

In short, my patches added QMP, the device id version of drive-backup:

blockdev-backup device=source-id target=target-id

where it needs the target already there:

(HMP) drive_add ...,backing=source-id"

"backing=source-id" is added there too, it's just the same purpose to
override backing_hd, as you added in block/backup.c

Then we have the target-id to use with NBD.

>  
> > Fam's series tackles the target device name and some of the overlapping
> > problems with your series.
> 
> Yes which is great.
>  
> > The core feature in your series is sync=top|none and that needs to be
> > merged.
> > 
> > Now we need to figure out which patches to take and what must be
> > changed.  Please see the sub-threads on Fam's series.  Perhaps we can
> > reach a consensus there.
> 
> Yes I'm happy to offer whatever help this is.  It does seem like
> applying this is the next logical move however.  Fam could then base his
> patch on top of this one.  At some point soon we need to reconcile
> everything and to me that seems the logical way.  There actually doesn't
> seem to be too much overlap in effort from what I can see.

The overlapping I can see is overriding backing_hd, but I'm not sure
which way will end merged, or both.

> 
> Fam, what do you think?  I'm happy to make changes to make it easier for
> your patchset too.
> 
I think it's fine till now, the hard and unresolved parts are adding
bits to control interface, which is independent on your patches.

Thanks.

-- 
Fam

Re: [Qemu-devel] trim in windows guest witch virtio

[Libaiqing]

Hi paolo,

I test window guest with ide device with the following config,trim with ide 
drive failed.

 1 The host fs is ext4 with discard option: 
   /dev/sdb1 on /home/sdb type ext4 (rw,relatime,discard,data=ordered)
 
 2 qemu config : ide drive with discard open
x86_64-softmmu/qemu-system-x86_64 -enable-kvm -name win7 -M pc-0.15 -m 1024 
-smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2  -drive 
file=/home/win7_base.qcow2,if=ide,index=0,format=qcow2,id=ad  -drive 
file=/home/sdb/raw.img,if=ide,index=1,format=raw,id=hd,discard=on  -monitor 
stdio   -vga qxl  -vnc :1 -device usb-tablet,id=input0
 
 3 In win7 guest,init drive d,fill it with files,then shift+del files

 4 The file /home/sdb/raw.img does not become small,when listing with -s 
option.

 It seems that the windows ntfs does not send trim to ide controller. No 
IDE_DMA_TRIM request received.

 Is there any config wrong?

 Btw,I found the info from the URL: 
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848053(v=vs.85).aspx
 Qemu can do the same thing like hyper-v with windows guest?

Thanks 
baiqing

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, July 23, 2013 2:35 PM
> To: Libaiqing
> Cc: qemu-devel@nongnu.org
> Subject: Re: trim in windows guest witch virtio
> 
> Il 23/07/2013 03:05, Libaiqing ha scritto:
> > Hi paolo,
> > Recently I test trim function,and it works well in linux guest with ext4
> fs.
> >
> > How to test it in windows guest? I got some info like this:
> >   1 windows7 can send discard command when the storage device is
> ssd;
> >   2 find a tool like 'fstrim', 'TRIM' the volume manually.
> 
> I think it only works with IDE and AHCI on Windows.  You need a filter
> driver to send it on SCSI disks.
> 
> Paolo

Re: [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).

[Peter Huang(Peng)]

Hi,Jiri

Thanks for replying.

So why VM identified different features from host is due to the hypervisor 
filtering.
I will dig into the hypervisor of how it filter features, and update status 
later.

Thanks again.


On 2013-07-23 19:27, Jiri Denemark wrote:
> On Tue, Jul 23, 2013 at 10:44:48 +0800, Peter Huang(Peng) wrote:
>>> libvirt's "host-passthrough" uses "-cpu host', and it "-cpu host"
>>> enables every feature that can be enabled on the host.
>> From my test results, I found that even when use host-passthrough mode, VM's
>> cpu features are very different from host, this doesn't match what 
>> host-passthrough
>> mode's explanation.
>>
>> libvirt's option exlanation:
>> With this mode, the CPU visible to the guest should be exactly  the  same as 
>>  the host 
>> CPU even in  the aspects  that libvirt  does not understand.
> The libvirt documentation is what needs to be updated. While
> host-passthrough is asking for a CPU which is as close as possible to
> the real host CPU, there are features that need special handling before
> they can be provided to a guest. And if the hypervisor does not provide
> that handling, it may just filter such feature out. Also if some
> features can be efficiently provided to a guest even though the host CPU
> does not provide them (x2apic is an example of such feature), they may
> be provided to a guest.
>
> Jirka
>

Re: [Qemu-devel] [PATCH v2 01/11] block: replace in_use with refcnt_soft and refcnt_hard

[Fam Zheng]

On Tue, 07/23 15:34, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2013 at 06:32:25PM +0800, Fam Zheng wrote:
> > On Tue, 07/23 11:36, Stefan Hajnoczi wrote:
> > > On Wed, Jul 17, 2013 at 05:42:06PM +0800, Fam Zheng wrote:
> > > > Introduce refcnt_soft (soft reference) and refcnt_hard (hard reference)
> > > > to BlockDriverState, since in_use mechanism cannot provide proper
> > > > management of lifecycle when a BDS is referenced in multiple places
> > > > (e.g. pointed to by another bs's backing_hd while also used as a block
> > > > job device, in the use case of image fleecing).
> > > > 
> > > > The original in_use case is considered a "hard reference" in this patch,
> > > > where the bs is busy and should not be used in other tasks that require
> > > > a hard reference. (However the interface doesn't force this, caller
> > > > still need to call bdrv_in_use() to check by itself.).
> > > > 
> > > > A soft reference is implemented but not used yet. It will be used in
> > > > following patches to manage the lifecycle together with hard reference.
> > > > 
> > > > If bdrv_ref() is called on a BDS, it must be released by exactly the
> > > > same numbers of bdrv_unref() with the same "soft/hard" type, and never
> > > > call bdrv_delete() directly. If the BDS is only used locally (unnamed),
> > > > bdrv_ref/bdrv_unref can be skipped and just use bdrv_delete().
> > > 
> > > It is risky to keep bdrv_delete() public.  I suggest replacing
> > > bdrv_delete() callers with bdrv_unref() and then making bdrv_delete()
> > > static in block.c.
> > > 
> > > This way it is impossible to make the mistake of calling bdrv_delete()
> > > on a BDS which has refcnt > 1.
> > > 
> > > I don't really understand this patch.  There are now two separate
> > > refcounts.  They must both reach 0 for deletion to occur.  I think
> > > you plan to treat the "hard" refcount like the in_use counter (there
> > > should only be 0 or 1 refs) but you don't enforce it.  It seems cleaner
> > > to keep in_use separate: let in_use callers take a refcount and also set
> > > in_use.
> > 
> > OK, I like your ideas, make bdrv_delete private is much cleaner. Will
> > fix in next revision.
> > 
> > I plan to make it like this:
> > 
> > /* soft ref */
> > void bdrv_{ref,unref}(bs)
> > 
> > /* hard ref */
> > bool bdrv_hard_{ref,unref}(bs)
> > 
> > usage:
> > bs = bdrv_new()
> > 
> > ...
> > bdrv_unref(bs)
> > 
> > 
> > or with hard ref:
> > bs = bdrv_new()
> > 
> > 
> > bdrv_hard_ref(bs)
> > ...
> > bdrv_hard_unref(bs)
> > 
> > bdrv_unref(bs)
> > 
> > 
> > The second bdrv_hard_ref call to a bs returns false, caller check the
> > return value.
> 
> Why is hard ref necessary when we already have
> bdrv_in_use()/bdrv_set_in_use()?

Keeping the names of bdrv_in_use() and bdrv_set_in_use() is noting
wrong, if no more than one "hard ref" is enforced. However I think we
should manage lifecycle with both bdrv_ref and bdrv_set_in_use, so name
them both ref sounds consistent: make it clearer to caller both hard ref
(in_use) and soft ref preserve the bs from being released.

-- 
Fam

Re: [Qemu-devel] [PATCH v2 01/16] cpu/a9mpcore: QOM casting cleanup

[Peter Maydell]

On 23 July 2013 03:43, Andreas Färber  wrote:
> From: Andreas Färber 
>
> Introduce type constant and cast macro and enforce its use by
> renaming A9MPPrivState::busdev field to parent_obj.
>
> Reviewed-by: Peter Crosthwaite 
> Signed-off-by: Andreas Färber 

Reviewed-by: Peter Maydell 

-- PMM

Re: [Qemu-devel] [PATCH v2 07/16] timer/arm_mptimer: QOM cast cleanup

[Peter Maydell]

On 23 July 2013 03:43, Andreas Färber  wrote:
> From: Andreas Färber 
>
> Introduce type constant and cast macro and rename
> ARMMPTimerState::busdev to enforce its use.
>
> Signed-off-by: Andreas Färber 

Reviewed-by: Peter Maydell 

-- PMM

Re: [Qemu-devel] [PATCH v2 12/16] cpu/a15mpcore: QOM cast cleanup

[Peter Maydell]

On 23 July 2013 03:43, Andreas Färber  wrote:
> From: Andreas Färber 
>
> Introduce type constant and cast macro and rename A15MPPrivState::busdev
> field to parent_obj to enforce its use.
>
> Prepares for QOM realize.
>
> Signed-off-by: Andreas Färber 

Reviewed-by: Peter Maydell 

-- PMM

[Qemu-devel] [PATCH v8 08/10] qemu-ga: Call Windows VSS requester in fsfreeze command handler

[Tomoki Sekiyama]

Support guest-fsfreeze-freeze and guest-fsfreeze-thaw commands for Windows
guests. When fsfreeze command is issued, it calls the VSS requester to
freeze filesystems and applications. On thaw command, it again tells the VSS
requester to thaw them.

This also adds calling of initialize functions for the VSS requester.

Signed-off-by: Tomoki Sekiyama 
---
 qga/Makefile.objs|1 
 qga/commands-win32.c |   82 ++---
 qga/vss-win32.c  |  141 ++
 qga/vss-win32.h  |   24 +
 4 files changed, 240 insertions(+), 8 deletions(-)
 create mode 100644 qga/vss-win32.c
 create mode 100644 qga/vss-win32.h

diff --git a/qga/Makefile.objs b/qga/Makefile.objs
index 4891732..ae1c28b 100644
--- a/qga/Makefile.objs
+++ b/qga/Makefile.objs
@@ -1,6 +1,7 @@
 qga-obj-y = commands.o guest-agent-command-state.o main.o
 qga-obj-$(CONFIG_POSIX) += commands-posix.o channel-posix.o
 qga-obj-$(CONFIG_WIN32) += commands-win32.o channel-win32.o service-win32.o
+qga-obj-$(CONFIG_WIN32) += vss-win32.o
 qga-obj-y += qapi-generated/qga-qapi-types.o qapi-generated/qga-qapi-visit.o
 qga-obj-y += qapi-generated/qga-qmp-marshal.o
 
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 24e4ad0..7a37f5c 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include "qga/guest-agent-core.h"
+#include "qga/vss-win32.h"
 #include "qga-qmp-commands.h"
 #include "qapi/qmp/qerror.h"
 
@@ -156,27 +157,89 @@ void qmp_guest_file_flush(int64_t handle, Error **err)
  */
 GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error **err)
 {
-error_set(err, QERR_UNSUPPORTED);
-return 0;
+if (!vss_initialized()) {
+error_set(err, QERR_UNSUPPORTED);
+return 0;
+}
+
+if (ga_is_frozen(ga_state)) {
+return GUEST_FSFREEZE_STATUS_FROZEN;
+}
+
+return GUEST_FSFREEZE_STATUS_THAWED;
 }
 
 /*
- * Walk list of mounted file systems in the guest, and freeze the ones which
- * are real local file systems.
+ * Freeze local file systems using Volume Shadow-copy Service.
+ * The frozen state is limited for up to 10 seconds by VSS.
  */
 int64_t qmp_guest_fsfreeze_freeze(Error **err)
 {
-error_set(err, QERR_UNSUPPORTED);
+int i;
+Error *local_err = NULL;
+
+if (!vss_initialized()) {
+error_set(err, QERR_UNSUPPORTED);
+return 0;
+}
+
+slog("guest-fsfreeze called");
+
+/* cannot risk guest agent blocking itself on a write in this state */
+ga_set_frozen(ga_state);
+
+qga_vss_fsfreeze(&i, err, true);
+if (error_is_set(err)) {
+goto error;
+}
+
+return i;
+
+error:
+qmp_guest_fsfreeze_thaw(&local_err);
+if (error_is_set(&local_err)) {
+g_debug("cleanup thaw: %s", error_get_pretty(local_err));
+error_free(local_err);
+}
 return 0;
 }
 
 /*
- * Walk list of frozen file systems in the guest, and thaw them.
+ * Thaw local file systems using Volume Shadow-copy Service.
  */
 int64_t qmp_guest_fsfreeze_thaw(Error **err)
 {
-error_set(err, QERR_UNSUPPORTED);
-return 0;
+int i;
+
+if (!vss_initialized()) {
+error_set(err, QERR_UNSUPPORTED);
+return 0;
+}
+
+qga_vss_fsfreeze(&i, err, false);
+
+ga_unset_frozen(ga_state);
+return i;
+}
+
+static void guest_fsfreeze_cleanup(void)
+{
+Error *err = NULL;
+
+if (!vss_initialized()) {
+return;
+}
+
+if (ga_is_frozen(ga_state) == GUEST_FSFREEZE_STATUS_FROZEN) {
+qmp_guest_fsfreeze_thaw(&err);
+if (err) {
+slog("failed to clean up frozen filesystems: %s",
+ error_get_pretty(err));
+error_free(err);
+}
+}
+
+vss_deinit(true);
 }
 
 /*
@@ -354,4 +417,7 @@ int64_t qmp_guest_set_vcpus(GuestLogicalProcessorList 
*vcpus, Error **errp)
 /* register init/cleanup routines for stateful command groups */
 void ga_command_state_init(GAState *s, GACommandState *cs)
 {
+if (vss_init(true)) {
+ga_command_state_add(cs, NULL, guest_fsfreeze_cleanup);
+}
 }
diff --git a/qga/vss-win32.c b/qga/vss-win32.c
new file mode 100644
index 000..ef5f0df
--- /dev/null
+++ b/qga/vss-win32.c
@@ -0,0 +1,141 @@
+/*
+ * QEMU Guest Agent VSS utility functions
+ *
+ * Copyright Hitachi Data Systems Corp. 2013
+ *
+ * Authors:
+ *  Tomoki Sekiyama   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include 
+#include 
+#include "qga/guest-agent-core.h"
+#include "qga/vss-win32.h"
+#include "qga/vss-win32/requester.h"
+
+#define QGA_VSS_DLL "qga-vss.dll"
+
+static HMODULE provider_lib;
+
+/* Call a function in qga-vss.dll with the specified name */
+static HRESULT call_vss_provider_func(const char *func_name)
+{
+FARPROC WINAPI func;
+
+g_assert(provider_lib);
+
+func = GetProcAddress(provider_lib, func_name);
+if (!func) {
+  

[Qemu-devel] [PATCH v8 09/10] qemu-ga: Install Windows VSS provider on `qemu-ga -s install'

[Tomoki Sekiyama]

Register QGA VSS provider library into Windows when qemu-ga is installed as
Windows service ('-s install' option). It is deregistered when the service
is uninstalled ('-s uninstall' option).

Signed-off-by: Tomoki Sekiyama 
---
 qga/main.c  |   10 +-
 qga/vss-win32.c |   25 +
 qga/vss-win32.h |3 +++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/qga/main.c b/qga/main.c
index 0e04e73..6c746c8 100644
--- a/qga/main.c
+++ b/qga/main.c
@@ -34,6 +34,7 @@
 #include "qemu/bswap.h"
 #ifdef _WIN32
 #include "qga/service-win32.h"
+#include "qga/vss-win32.h"
 #include 
 #endif
 #ifdef __linux__
@@ -1031,8 +1032,15 @@ int main(int argc, char **argv)
 fixed_state_dir = (state_dir == dfl_pathnames.state_dir) ?
   NULL :
   state_dir;
-return ga_install_service(path, log_filepath, fixed_state_dir);
+if (ga_install_vss_provider()) {
+return EXIT_FAILURE;
+}
+if (ga_install_service(path, log_filepath, fixed_state_dir)) {
+return EXIT_FAILURE;
+}
+return 0;
 } else if (strcmp(service, "uninstall") == 0) {
+ga_uninstall_vss_provider();
 return ga_uninstall_service();
 } else {
 printf("Unknown service command.\n");
diff --git a/qga/vss-win32.c b/qga/vss-win32.c
index ef5f0df..7b77a8c 100644
--- a/qga/vss-win32.c
+++ b/qga/vss-win32.c
@@ -119,6 +119,31 @@ bool vss_initialized(void)
 return !!provider_lib;
 }
 
+int ga_install_vss_provider(void)
+{
+HRESULT hr;
+
+if (!vss_init(false)) {
+fprintf(stderr, "Installation of VSS provider is skipped. "
+"fsfreeze will be disabled.\n");
+return 0;
+}
+hr = call_vss_provider_func("COMRegister");
+vss_deinit(false);
+
+return SUCCEEDED(hr) ? 0 : EXIT_FAILURE;
+}
+
+void ga_uninstall_vss_provider(void)
+{
+if (!vss_init(false)) {
+fprintf(stderr, "Removal of VSS provider is skipped.\n");
+return;
+}
+call_vss_provider_func("COMUnregister");
+vss_deinit(false);
+}
+
 /* Call VSS requester and freeze/thaw filesystems and applications */
 void qga_vss_fsfreeze(int *nr_volume, Error **err, bool freeze)
 {
diff --git a/qga/vss-win32.h b/qga/vss-win32.h
index eac669c..db8fbe5 100644
--- a/qga/vss-win32.h
+++ b/qga/vss-win32.h
@@ -19,6 +19,9 @@ bool vss_init(bool init_requester);
 void vss_deinit(bool deinit_requester);
 bool vss_initialized(void);
 
+int ga_install_vss_provider(void);
+void ga_uninstall_vss_provider(void);
+
 void qga_vss_fsfreeze(int *nr_volume, Error **err, bool freeze);
 
 #endif

[Qemu-devel] [PATCH v8 06/10] error: Add error_set_win32 and error_setg_win32

[Tomoki Sekiyama]

These functions help maintaining homogeneous formatting of error messages
with Windows error code and description (generated by
g_win32_error_message()).

Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Michael Roth 
---
 include/qapi/error.h |   13 +
 util/error.c |   35 +++
 2 files changed, 48 insertions(+)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index ffd1cea..7d4c696 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -36,6 +36,15 @@ void error_set(Error **err, ErrorClass err_class, const char 
*fmt, ...) GCC_FMT_
  */
 void error_set_errno(Error **err, int os_error, ErrorClass err_class, const 
char *fmt, ...) GCC_FMT_ATTR(4, 5);
 
+#ifdef _WIN32
+/**
+ * Set an indirect pointer to an error given a ErrorClass value and a
+ * printf-style human message, followed by a g_win32_error_message() string if
+ * @win32_err is not zero.
+ */
+void error_set_win32(Error **err, int win32_err, ErrorClass err_class, const 
char *fmt, ...) GCC_FMT_ATTR(4, 5);
+#endif
+
 /**
  * Same as error_set(), but sets a generic error
  */
@@ -43,6 +52,10 @@ void error_set_errno(Error **err, int os_error, ErrorClass 
err_class, const char
 error_set(err, ERROR_CLASS_GENERIC_ERROR, fmt, ## __VA_ARGS__)
 #define error_setg_errno(err, os_error, fmt, ...) \
 error_set_errno(err, os_error, ERROR_CLASS_GENERIC_ERROR, fmt, ## 
__VA_ARGS__)
+#ifdef _WIN32
+#define error_setg_win32(err, win32_err, fmt, ...) \
+error_set_win32(err, win32_err, ERROR_CLASS_GENERIC_ERROR, fmt, ## 
__VA_ARGS__)
+#endif
 
 /**
  * Helper for open() errors
diff --git a/util/error.c b/util/error.c
index 53b0435..ec0faa6 100644
--- a/util/error.c
+++ b/util/error.c
@@ -76,6 +76,41 @@ void error_setg_file_open(Error **errp, int os_errno, const 
char *filename)
 error_setg_errno(errp, os_errno, "Could not open '%s'", filename);
 }
 
+#ifdef _WIN32
+
+void error_set_win32(Error **errp, int win32_err, ErrorClass err_class,
+ const char *fmt, ...)
+{
+Error *err;
+char *msg1;
+va_list ap;
+
+if (errp == NULL) {
+return;
+}
+assert(*errp == NULL);
+
+err = g_malloc0(sizeof(*err));
+
+va_start(ap, fmt);
+msg1 = g_strdup_vprintf(fmt, ap);
+if (win32_err != 0) {
+char *msg2 = g_win32_error_message(win32_err);
+err->msg = g_strdup_printf("%s: %s (error: %x)", msg1, msg2,
+   (unsigned)win32_err);
+g_free(msg2);
+g_free(msg1);
+} else {
+err->msg = msg1;
+}
+va_end(ap);
+err->err_class = err_class;
+
+*errp = err;
+}
+
+#endif
+
 Error *error_copy(const Error *err)
 {
 Error *err_new;

[Qemu-devel] [PATCH v8 02/10] Add c++ keywords to QAPI helper script

[Tomoki Sekiyama]

Add c++ keywords to avoid errors in compiling with c++ compiler.
This also renames class member of PciDeviceInfo to q_class.

Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Michael Roth 
---
 hmp.c   |2 +-
 hw/pci/pci.c|2 +-
 scripts/qapi.py |   12 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/hmp.c b/hmp.c
index dc4d8d4..0dbc0a6 100644
--- a/hmp.c
+++ b/hmp.c
@@ -524,7 +524,7 @@ static void hmp_info_pci_device(Monitor *mon, const 
PciDeviceInfo *dev)
 if (dev->class_info.has_desc) {
 monitor_printf(mon, "%s", dev->class_info.desc);
 } else {
-monitor_printf(mon, "Class %04" PRId64, dev->class_info.class);
+monitor_printf(mon, "Class %04" PRId64, dev->class_info.q_class);
 }
 
 monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 81cf5a9..3676e45 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1466,7 +1466,7 @@ static PciDeviceInfo *qmp_query_pci_device(PCIDevice 
*dev, PCIBus *bus,
 info->function = PCI_FUNC(dev->devfn);
 
 class = pci_get_word(dev->config + PCI_CLASS_DEVICE);
-info->class_info.class = class;
+info->class_info.q_class = class;
 desc = get_class_desc(class);
 if (desc->desc) {
 info->class_info.has_desc = true;
diff --git a/scripts/qapi.py b/scripts/qapi.py
index baf1321..942bcc2 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -169,9 +169,19 @@ def c_var(name, protect=True):
 # GCC http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/C-Extensions.html
 # excluding _.*
 gcc_words = set(['asm', 'typeof'])
+# C++ ISO/IEC 14882:2003 2.11
+cpp_words = set(['bool', 'catch', 'class', 'const_cast', 'delete',
+ 'dynamic_cast', 'explicit', 'false', 'friend', 'mutable',
+ 'namespace', 'new', 'operator', 'private', 'protected',
+ 'public', 'reinterpret_cast', 'static_cast', 'template',
+ 'this', 'throw', 'true', 'try', 'typeid', 'typename',
+ 'using', 'virtual', 'wchar_t',
+ # alternative representations
+ 'and', 'and_eq', 'bitand', 'bitor', 'compl', 'not',
+ 'not_eq', 'or', 'or_eq', 'xor', 'xor_eq'])
 # namespace pollution:
 polluted_words = set(['unix'])
-if protect and (name in c89_words | c99_words | c11_words | gcc_words | 
polluted_words):
+if protect and (name in c89_words | c99_words | c11_words | gcc_words | 
cpp_words | polluted_words):
 return "q_" + name
 return name.replace('-', '_').lstrip("*")
 

[Qemu-devel] [PATCH v8 10/10] QMP/qemu-ga-client: Make timeout longer for guest-fsfreeze-freeze command

[Tomoki Sekiyama]

guest-fsfreeze-freeze command can take longer than 3 seconds when heavy
disk I/O is running. To avoid unexpected timeout, this changes the timeout
to 60 seconds (timeout of pre-commit phase of VSS).

Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Paolo Bonzini 
Reviewed-by: Laszlo Ersek 
---
 QMP/qemu-ga-client |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/QMP/qemu-ga-client b/QMP/qemu-ga-client
index 46676c3..b5f7e7c 100755
--- a/QMP/qemu-ga-client
+++ b/QMP/qemu-ga-client
@@ -267,7 +267,9 @@ def main(address, cmd, args):
 print('Hint: qemu is not running?')
 sys.exit(1)
 
-if cmd != 'ping':
+if cmd == 'fsfreeze' and args[0] == 'freeze':
+client.sync(60)
+elif cmd != 'ping':
 client.sync()
 
 globals()['_cmd_' + cmd](client, args)

[Qemu-devel] [PATCH v8 05/10] qemu-ga: Add configure options to specify path to Windows/VSS SDK

[Tomoki Sekiyama]

To enable VSS support in qemu-ga for Windows, header files included in
VSS SDK are required.
The VSS support is enabled by the configure option like below:
  ./configure --with-vss-sdk="/path/to/VSS SDK"

If the path is omitted, it tries to search the headers from default paths
and VSS support is enabled only if the SDK is found.
VSS support is disabled if --without-vss-sdk or --with-vss-sdk=no is
specified.

VSS SDK is available from:
  http://www.microsoft.com/en-us/download/details.aspx?id=23490

To cross-compile using mingw, you need to setup the SDK on Windows
environments to extract headers. You can also extract the SDK headers on
POSIX environments using scripts/extract-vss-headers and msitools.

In addition, --with-win-sdk="/path/to/Windows SDK" option is also added to
specify path to Windows SDK, which may be used for native-compile of .tlb
file of qemu-ga VSS provider. However, this is usually unnecessary because
pre-compiled .tlb file is included.

Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Michael Roth 
---
 .gitignore |1 +
 Makefile   |1 +
 configure  |   69 
 3 files changed, 71 insertions(+)

diff --git a/.gitignore b/.gitignore
index 0fe114d..02d15f0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -79,6 +79,7 @@ fsdev/virtfs-proxy-helper.pod
 *.la
 *.pc
 .libs
+.sdk
 *.swp
 *.orig
 .pc
diff --git a/Makefile b/Makefile
index c06bfab..ec35a15 100644
--- a/Makefile
+++ b/Makefile
@@ -273,6 +273,7 @@ distclean: clean
for d in $(TARGET_DIRS); do \
rm -rf $$d || exit 1 ; \
 done
+   rm -Rf .sdk
if test -f pixman/config.log; then make -C pixman distclean; fi
if test -f dtc/version_gen.h; then make $(DTC_MAKE_ARGS) clean; fi
 
diff --git a/configure b/configure
index 5e89e5d..48736b3 100755
--- a/configure
+++ b/configure
@@ -232,6 +232,8 @@ usb_redir=""
 glx=""
 zlib="yes"
 guest_agent="yes"
+guest_agent_with_vss="no"
+vss_win32_sdk=""
 want_tools="yes"
 libiscsi=""
 coroutine=""
@@ -927,6 +929,14 @@ for opt do
   ;;
   --disable-guest-agent) guest_agent="no"
   ;;
+  --with-vss-sdk) vss_win32_sdk=""
+  ;;
+  --with-vss-sdk=*) vss_win32_sdk="$optarg"
+  ;;
+  --without-vss-sdk) vss_win32_sdk="no"
+  ;;
+  --with-win-sdk=*) win_sdk="$optarg"
+  ;;
   --enable-tools) want_tools="yes"
   ;;
   --disable-tools) want_tools="no"
@@ -1159,6 +1169,8 @@ echo "  --disable-usb-redir  disable usb network 
redirection support"
 echo "  --enable-usb-redir   enable usb network redirection support"
 echo "  --disable-guest-agentdisable building of the QEMU Guest Agent"
 echo "  --enable-guest-agent enable building of the QEMU Guest Agent"
+echo "  --with-vss-sdk=SDK-path  enable Windows VSS support in QEMU Guest 
Agent"
+echo "  --with-win-sdk=SDK-path  path to Windows Platform SDK (to build VSS 
.tlb)"
 echo "  --disable-seccompdisable seccomp support"
 echo "  --enable-seccomp enables seccomp support"
 echo "  --with-coroutine=BACKEND coroutine backend. Supported options:"
@@ -3075,6 +3087,57 @@ if test "$usb_redir" != "no" ; then
 fi
 
 ##
+# check if we have VSS SDK headers for win
+
+if test "$mingw32" = "yes" -a "$guest_agent" = "yes" -a "$vss_win32_sdk" != 
"no" ; then
+  case "$vss_win32_sdk" in
+"")   vss_win32_include="-I$source_path" ;;
+*\ *) # The SDK is installed in "Program Files" by default, but we cannot
+  # handle path with spaces. So we symlink the headers into ".sdk/vss".
+  vss_win32_include="-I$source_path/.sdk/vss"
+ symlink "$vss_win32_sdk/inc" "$source_path/.sdk/vss/inc"
+ ;;
+*)vss_win32_include="-I$vss_win32_sdk"
+  esac
+  cat > $TMPC << EOF
+#define __MIDL_user_allocate_free_DEFINED__
+#include 
+int main(void) { return VSS_CTX_BACKUP; }
+EOF
+  if compile_prog "$vss_win32_include" "" ; then
+guest_agent_with_vss="yes"
+QEMU_CFLAGS="$QEMU_CFLAGS $vss_win32_include"
+libs_qga="-lole32 -loleaut32 -lshlwapi -luuid -lstdc++ 
-Wl,--enable-stdcall-fixup $libs_qga"
+  else
+if test "$vss_win32_sdk" != "" ; then
+  echo "ERROR: Please download and install Microsoft VSS SDK:"
+  echo "ERROR:   
http://www.microsoft.com/en-us/download/details.aspx?id=23490";
+  echo "ERROR: On POSIX-systems, you can extract the SDK headers by:"
+  echo "ERROR:   scripts/extract-vsssdk-headers setup.exe"
+  echo "ERROR: The headers are extracted in the directory \`inc'."
+  feature_not_found "VSS support"
+fi
+guest_agent_with_vss="no"
+  fi
+fi
+
+##
+# lookup Windows platform SDK (if not specified)
+# The SDK is needed only to build .tlb (type library) file of guest agent
+# VSS provider from the source. It is usually unnecessary because the
+# pre-compiled .tlb file is included.
+
+if test "$mingw32" = "yes" -a "$guest_agent" = "yes" -a 
"$guest_agent_with_vss" = "yes" 

[Qemu-devel] [PATCH v8 00/10] qemu-ga: fsfreeze on Windows using VSS

[Tomoki Sekiyama]

Hi,

This is v8 of patch series to add fsfreeze for Windows qemu-guest-agent.

changes from v7:
 - Remove redundant re-assign to $cxx in configure (patch 01/10)
 - Add comment and cleanup check for ':' used in class definition (patch 03/10)
 - Fail installation if VSS provider is already installed (patch 07/10)
 - Disable VSS feature if 32bit agent runs on 64bit Windows (patch 08/10)

v7: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg02316.html


* Description
  In Windows, VSS (Volume Shadow Copy Service) provides a facility to
  quiesce filesystems and applications before disk snapshots are taken.
  This patch series implements "fsfreeze" command of qemu-ga using VSS.


* How to build & run qemu-ga with VSS support

 - Download Microsoft VSS SDK from:
   http://www.microsoft.com/en-us/download/details.aspx?id=23490

 - Setup the SDK
   scripts/extract-vsssdk-headers setup.exe (on POSIX-systems)

 - Specify installed SDK directory to configure option as:
   ./configure -with-vss-sdk="path/to/VSS SDK" --cross-prefix=i686-w64-mingw32-

 - make qemu-ga.exe qga/vss-win32/qga-vss.{dll,tlb}

 - Install qemu-ga.exe, qga/vss-win32/qga-vss.{dll,tlb}, and
   the other required mingw libraries into the same directory in guests

 - Run `qemu-ga.exe -s install' and `net start qemu-ga' in the guests

Any feedback are appreciated.

---
Tomoki Sekiyama (10):
  configure: Support configuring C++ compiler
  Add c++ keywords to QAPI helper script
  checkpatch.pl: Check .cpp files
  Add a script to extract VSS SDK headers on POSIX system
  qemu-ga: Add configure options to specify path to Windows/VSS SDK
  error: Add error_set_win32 and error_setg_win32
  qemu-ga: Add Windows VSS provider and requester as DLL
  qemu-ga: Call Windows VSS requester in fsfreeze command handler
  qemu-ga: Install Windows VSS provider on `qemu-ga -s install'
  QMP/qemu-ga-client: Make timeout longer for guest-fsfreeze-freeze command


 .gitignore |1 
 Makefile   |3 
 Makefile.objs  |2 
 QMP/qemu-ga-client |4 
 configure  |   87 +++
 hmp.c  |2 
 hw/pci/pci.c   |2 
 include/qapi/error.h   |   13 +
 qga/Makefile.objs  |5 
 qga/commands-win32.c   |   82 ++
 qga/main.c |   10 +
 qga/vss-win32.c|  166 +
 qga/vss-win32.h|   27 ++
 qga/vss-win32/Makefile.objs|   23 ++
 qga/vss-win32/install.cpp  |  458 
 qga/vss-win32/provider.cpp |  513 
 qga/vss-win32/qga-vss.def  |   13 +
 qga/vss-win32/qga-vss.idl  |   20 ++
 qga/vss-win32/qga-vss.tlb  |  Bin
 qga/vss-win32/requester.cpp|  487 ++
 qga/vss-win32/requester.h  |   42 +++
 qga/vss-win32/vss-common.h |  128 ++
 rules.mak  |9 +
 scripts/checkpatch.pl  |   34 ++-
 scripts/extract-vsssdk-headers |   35 +++
 scripts/qapi.py|   12 +
 util/error.c   |   35 +++
 27 files changed, 2191 insertions(+), 22 deletions(-)
 create mode 100644 qga/vss-win32.c
 create mode 100644 qga/vss-win32.h
 create mode 100644 qga/vss-win32/Makefile.objs
 create mode 100644 qga/vss-win32/install.cpp
 create mode 100644 qga/vss-win32/provider.cpp
 create mode 100644 qga/vss-win32/qga-vss.def
 create mode 100644 qga/vss-win32/qga-vss.idl
 create mode 100644 qga/vss-win32/qga-vss.tlb
 create mode 100644 qga/vss-win32/requester.cpp
 create mode 100644 qga/vss-win32/requester.h
 create mode 100644 qga/vss-win32/vss-common.h
 create mode 100755 scripts/extract-vsssdk-headers

[Qemu-devel] [PATCH v8 03/10] checkpatch.pl: Check .cpp files

[Tomoki Sekiyama]

Enable checkpatch.pl to apply the same checks as C source files for
C++ files with .cpp extensions. It also adds some exceptions for C++
sources to suppress errors for:
  - <> used in C++ template arguments (e.g. template )
  - :: used to represent namespaces   (e.g. SomeClass::method())
  - : used in class declaration   (e.g. class T : public Super)
  - ~ used in destructor method name  (e.g. T::~T())
  - spacing around 'catch'(e.g. catch (...))

Signed-off-by: Tomoki Sekiyama 
---
 scripts/checkpatch.pl |   34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ec0aa4c..9d46e5a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1363,7 +1363,7 @@ sub process {
 # Check for incorrect file permissions
if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) {
my $permhere = $here . "FILE: $realfile\n";
-   if ($realfile =~ 
/(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl)$/) {
+   if ($realfile =~ 
/(Makefile|Kconfig|\.c|\.cpp|\.h|\.S|\.tmpl)$/) {
ERROR("do not set execute permissions for 
source files\n" . $permhere);
}
}
@@ -1460,7 +1460,7 @@ sub process {
}
 
 # check we are in a valid source file if not then ignore this hunk
-   next if ($realfile !~ /\.(h|c|s|S|pl|sh)$/);
+   next if ($realfile !~ /\.(h|c|cpp|s|S|pl|sh)$/);
 
 #80 column limit
if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ &&
@@ -1495,7 +1495,7 @@ sub process {
}
 
 # check we are in a valid source file C or perl if not then ignore this hunk
-   next if ($realfile !~ /\.(h|c|pl)$/);
+   next if ($realfile !~ /\.(h|c|cpp|pl)$/);
 
 # in QEMU, no tabs are allowed
if ($rawline =~ /^\+.*\t/) {
@@ -1505,7 +1505,7 @@ sub process {
}
 
 # check we are in a valid C source file if not then ignore this hunk
-   next if ($realfile !~ /\.(h|c)$/);
+   next if ($realfile !~ /\.(h|c|cpp)$/);
 
 # check for RCS/CVS revision markers
if ($rawline =~ /^\+.*\$(Revision|Log|Id)(?:\$|)/) {
@@ -1969,6 +1969,9 @@ sub process {
asm|__asm__)$/x)
{
 
+   # Ignore 'catch (...)' in C++
+   } elsif ($name =~ /^catch$/ && $realfile =~ 
/(\.cpp|\.h)$/) {
+
# cpp #define statements have non-optional spaces, ie
# if there is a space between the name and the open
# parenthesis it is simply not a parameter group.
@@ -1992,7 +1995,7 @@ sub process {
\+=|-=|\*=|\/=|%=|\^=|\|=|&=|
=>|->|<<|>>|<|>|=|!|~|
&&|\|\||,|\^|\+\+|--|&|\||\+|-|\*|\/|%|
-   \?|:
+   \?|::|:
}x;
my @elements = split(/($ops|;)/, $opline);
my $off = 0;
@@ -2062,6 +2065,10 @@ sub process {
# // is a comment
} elsif ($op eq '//') {
 
+   # Ignore : used in class declaration in C++
+   } elsif ($opv eq ':B' && $ctx =~ /Wx[WE]/ &&
+$line =~ /class/ && $realfile 
=~ /(\.cpp|\.h)$/) {
+
# No spaces for:
#   ->
#   :   when part of a bitfield
@@ -2088,7 +2095,10 @@ sub process {
} elsif ($op eq '!' || $op eq '~' ||
 $opv eq '*U' || $opv eq '-U' ||
 $opv eq '&U' || $opv eq '&&U') {
-   if ($ctx !~ /[WEBC]x./ && $ca !~ 
/(?:\)|!|~|\*|-|\&|\||\+\+|\-\-|\{)$/) {
+   if ($op eq '~' && $ca =~ /::$/ && 
$realfile =~ /(\.cpp|\.h)$/) {
+   # '~' used as a name of 
Destructor
+
+   } elsif ($ctx !~ /[WEBC]x./ && $ca !~ 
/(?:\)|!|~|\*|-|\&|\||\+\+|\-\-|\{)$/) {
ERROR("space required before 
that '$op' $at\n" . $hereptr);
}
if ($op eq '*' && $cc 
=~/\s*$Modifier\b/) {
@@ -2135,6 +2145,18 @@ sub process {
} elsif ($ctx !~ /[EWC]x[CWE]/) {
my $ok = 0;
 
+   if ($realfile =~ /\.cpp|\.h$/) {
+   # Ignore template arguments 

[Qemu-devel] [PATCH v8 04/10] Add a script to extract VSS SDK headers on POSIX system

[Tomoki Sekiyama]

VSS SDK(*) setup.exe is only runnable on Windows. This adds a script
to extract VSS SDK headers on POSIX-systems using msitools.

  * http://www.microsoft.com/en-us/download/details.aspx?id=23490

From: Paolo Bonzini 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Michael Roth 
---
 scripts/extract-vsssdk-headers |   35 +++
 1 file changed, 35 insertions(+)
 create mode 100755 scripts/extract-vsssdk-headers

diff --git a/scripts/extract-vsssdk-headers b/scripts/extract-vsssdk-headers
new file mode 100755
index 000..9e38510
--- /dev/null
+++ b/scripts/extract-vsssdk-headers
@@ -0,0 +1,35 @@
+#! /bin/bash
+
+# extract-vsssdk-headers
+# Author: Paolo Bonzini 
+
+set -e
+if test $# != 1 || ! test -f "$1"; then
+  echo 'Usage: extract-vsssdk-headers /path/to/setup.exe' >&2
+  exit 1
+fi
+
+if ! command -v msiextract > /dev/null; then
+  echo 'msiextract not found. Please install msitools.' >&2
+  exit 1
+fi
+
+if test -e inc; then
+  echo '"inc" already exists.' >&2
+  exit 1
+fi
+
+# Extract .MSI file in the .exe, looking for the OLE compound
+# document signature.  Extra data at the end does not matter.
+export LC_ALL=C
+MAGIC=$'\xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1'
+offset=$(grep -abom1 "$MAGIC" "$1" | sed -n 's/:/\n/; P')
+tmpdir=$(mktemp -d)
+trap 'rm -fr -- "$tmpdir" vsssdk.msi' EXIT HUP INT QUIT ALRM TERM
+tail -c +$(($offset+1)) -- "$1" > vsssdk.msi
+
+# Now extract the files.
+msiextract -C $tmpdir vsssdk.msi
+mv "$tmpdir/Program Files/Microsoft/VSSSDK72/inc" inc
+echo 'Extracted SDK headers into "inc" directory.'
+exit 0

[Qemu-devel] [PATCH v8 01/10] configure: Support configuring C++ compiler

[Tomoki Sekiyama]

Add configuration for C++ compiler in configure and Makefiles.
The C++ compiler is choosed as following:
 - ${CXX}, if it is specified.
 - ${cross_prefix}g++, if ${cross_prefix} is specified.
 - Otherwise, c++ is used.

Currently, usage of C++ language is only for access to Windows VSS
using COM+ services in qemu-guest-agent for Windows.

Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Laszlo Ersek 
---
 configure |   13 +
 rules.mak |9 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 7c45db2..5e89e5d 100755
--- a/configure
+++ b/configure
@@ -252,6 +252,8 @@ for opt do
   ;;
   --cc=*) CC="$optarg"
   ;;
+  --cxx=*) CXX="$optarg"
+  ;;
   --source-path=*) source_path="$optarg"
   ;;
   --cpu=*) cpu="$optarg"
@@ -282,6 +284,12 @@ else
   cc="${CC-${cross_prefix}gcc}"
 fi
 
+if test -z "${CXX}${cross_prefix}"; then
+  cxx="c++"
+else
+  cxx="${CXX-${cross_prefix}g++}"
+fi
+
 ar="${AR-${cross_prefix}ar}"
 as="${AS-${cross_prefix}as}"
 cpp="${CPP-$cc -E}"
@@ -622,6 +630,8 @@ for opt do
   ;;
   --host-cc=*) host_cc="$optarg"
   ;;
+  --cxx=*)
+  ;;
   --objcc=*) objcc="$optarg"
   ;;
   --make=*) make="$optarg"
@@ -1023,6 +1033,7 @@ echo "  --cross-prefix=PREFIXuse PREFIX for compile 
tools [$cross_prefix]"
 echo "  --cc=CC  use C compiler CC [$cc]"
 echo "  --host-cc=CC use C compiler CC [$host_cc] for code run at"
 echo "   build time"
+echo "  --cxx=CXXuse C++ compiler CXX [$cxx]"
 echo "  --objcc=OBJCCuse Objective-C compiler OBJCC [$objcc]"
 echo "  --extra-cflags=CFLAGSappend extra C compiler flags QEMU_CFLAGS"
 echo "  --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS"
@@ -3499,6 +3510,7 @@ fi
 echo "Source path   $source_path"
 echo "C compiler$cc"
 echo "Host C compiler   $host_cc"
+echo "C++ compiler  $cxx"
 echo "Objective-C compiler $objcc"
 echo "CFLAGS$CFLAGS"
 echo "QEMU_CFLAGS   $QEMU_CFLAGS"
@@ -4076,6 +4088,7 @@ echo "PYTHON=$python" >> $config_host_mak
 echo "CC=$cc" >> $config_host_mak
 echo "CC_I386=$cc_i386" >> $config_host_mak
 echo "HOST_CC=$host_cc" >> $config_host_mak
+echo "CXX=$cxx" >> $config_host_mak
 echo "OBJCC=$objcc" >> $config_host_mak
 echo "AR=$ar" >> $config_host_mak
 echo "AS=$as" >> $config_host_mak
diff --git a/rules.mak b/rules.mak
index 4499745..abc2e84 100644
--- a/rules.mak
+++ b/rules.mak
@@ -8,9 +8,13 @@ MAKEFLAGS += -rR
 %.d:
 %.h:
 %.c:
+%.cpp:
 %.m:
 %.mak:
 
+# Flags for C++ compilation
+QEMU_CXXFLAGS = -D__STDC_LIMIT_MACROS $(filter-out -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wold-style-declaration 
-Wold-style-definition -Wredundant-decls, $(QEMU_CFLAGS))
+
 # Flags for dependency generation
 QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d
 
@@ -50,6 +54,9 @@ endif
 %.o: %.asm
$(call quiet-command,$(AS) $(ASFLAGS) -o $@ $<,"  AS
$(TARGET_DIR)$@")
 
+%.o: %.cpp
+   $(call quiet-command,$(CXX) $(QEMU_INCLUDES) $(QEMU_CXXFLAGS) 
$(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  CXX   $(TARGET_DIR)$@")
+
 %.o: %.m
$(call quiet-command,$(OBJCC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) 
$(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  OBJC  $(TARGET_DIR)$@")
 
@@ -70,7 +77,7 @@ quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1))
 cc-option = $(if $(shell $(CC) $1 $2 -S -o /dev/null -xc /dev/null \
   >/dev/null 2>&1 && echo OK), $2, $3)
 
-VPATH_SUFFIXES = %.c %.h %.S %.m %.mak %.texi %.sh %.rc
+VPATH_SUFFIXES = %.c %.h %.S %.cpp %.m %.mak %.texi %.sh %.rc
 set-vpath = $(if $1,$(foreach PATTERN,$(VPATH_SUFFIXES),$(eval vpath 
$(PATTERN) $1)))
 
 # find-in-path

Re: [Qemu-devel] [PATCH 1/2] prep_pci: set isa_mem_base in the PCI host bridge

[Andreas Färber]

Am 23.07.2013 23:16, schrieb Hervé Poussineau:
> Currently, it is done by i82378 device, which shouldn't care of it.
> 
> Signed-off-by: Hervé Poussineau 
> ---
>  hw/isa/i82378.c|3 ---
>  hw/pci-host/prep.c |2 ++
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
> index b25ed04..de71d81 100644
> --- a/hw/isa/i82378.c
> +++ b/hw/isa/i82378.c
> @@ -45,7 +45,6 @@ typedef struct I82378State {
>  typedef struct PCIi82378State {
>  PCIDevice pci_dev;
>  uint32_t isa_io_base;
> -uint32_t isa_mem_base;
>  I82378State state;
>  } PCIi82378State;
>  
> @@ -234,7 +233,6 @@ static int pci_i82378_init(PCIDevice *dev)
>  pci_set_long(dev->wmask + PCI_BASE_ADDRESS_0, 0);
>  pci_set_long(pci_conf + PCI_BASE_ADDRESS_0, pci->isa_io_base);
>  
> -isa_mem_base = pci->isa_mem_base;
>  isa_bus_new(&dev->qdev, pci_address_space_io(dev));
>  
>  i82378_init(&dev->qdev, s);
> @@ -244,7 +242,6 @@ static int pci_i82378_init(PCIDevice *dev)
>  
>  static Property i82378_properties[] = {
>  DEFINE_PROP_HEX32("iobase", PCIi82378State, isa_io_base, 0x8000),
> -DEFINE_PROP_HEX32("membase", PCIi82378State, isa_mem_base, 0xc000),
>  DEFINE_PROP_END_OF_LIST()
>  };
>  
> diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep.c
> index b41d564..d6bcc63 100644
> --- a/hw/pci-host/prep.c
> +++ b/hw/pci-host/prep.c
> @@ -119,6 +119,8 @@ static void raven_pcihost_realizefn(DeviceState *d, Error 
> **errp)
>  MemoryRegion *address_space_mem = get_system_memory();
>  int i;
>  
> +isa_mem_base = 0xc000;
> +
>  for (i = 0; i < 4; i++) {
>  sysbus_init_irq(dev, &s->irq[i]);
>  }

Patch is okay with me, but I wonder what we still need the global
isa_mem_base for? The only users seem to be VGA, adding offsets to it.

Regards,
Andreas

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Peter Maydell]

On 23 July 2013 23:12, Andreas Färber  wrote:
> I wonder how many public fields do we actually have? Close to zero?
> Might there be a way to mark all fields of a struct as private at struct
> level, except for those explicitly marked up as public?

No, I don't think this is possible -- there is no
"not-actually-deprecated" attribute.

IIRC Anthony wanted to be able to do direct field
access for properties (esp. links), which would
then be examples of public fields.

-- PMM

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Andreas Färber]

Am 24.07.2013 00:10, schrieb Peter Maydell:
> On 23 July 2013 23:08, Andreas Färber  wrote:
>> Anyway, before we get lost in a bikeshed discussion, if the
>> underscore'ization of the type names is to everyone's liking now, I
>> would very much like to queue the QOM cast patches on qom-next
> 
> Which particular patches (whole series?) ?

Patches 01, 07 (changed in v2), 12. That's 4x FROM_SYSBUS(). :)

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Andreas Färber]

Am 23.07.2013 23:55, schrieb Alexander Graf:
> On 23.07.2013, at 23:52, Peter Maydell wrote:
>> On 23 July 2013 22:36, Alexander Graf  wrote:
>>>
>>> Or maybe
>>>
>>> struct MyObject {
>>>  PUBLIC_FIELDS
>>>  __field int publicfield;
>>>  PRIVATE_FIELDS
>>>  __field int privatefield;
>>> }
>>
>> I can't see an obvious way to make those do the right
>> thing with the C preprocessor... am I missing something?
> 
> No, I'm probably just daydreaming :). Macros can't redefine other defines, so 
> this probably won't work
> 
> So yes, prepending the visibility on every field seems to be the most 
> straight forward choice.

I wonder how many public fields do we actually have? Close to zero?
Might there be a way to mark all fields of a struct as private at struct
level, except for those explicitly marked up as public?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Peter Maydell]

On 23 July 2013 23:08, Andreas Färber  wrote:
> Anyway, before we get lost in a bikeshed discussion, if the
> underscore'ization of the type names is to everyone's liking now, I
> would very much like to queue the QOM cast patches on qom-next

Which particular patches (whole series?) ? I'll review them,
since I'm now happy that we can add the annotations later.

> (independent of whether you apply parts of the series to arm-devs.next).

I don't at this point plan to apply anything to arm-devs.next
except bugfixes before 1.6 is released.

-- PMM

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Andreas Färber]

Am 23.07.2013 23:52, schrieb Peter Maydell:
> On 23 July 2013 22:36, Alexander Graf  wrote:
>> Am 23.07.2013 um 23:16 schrieb Peter Maydell :
>>> On 23 July 2013 20:15, Peter Maydell  wrote:
[C needing access to full struct definition for composite use]
 I had a thought about this. Suppose we have our class header
 files do something like this:

 #ifdef MYCLASS_IMPLEMENTATION
 #define PRIVATE
 #else
 #ifdef __GNUC__
 #define PRIVATE __attribute__((deprecated("this is a private field")))
 #else
 #define PRIVATE
 #endif

 typedef struct MyObject {
   int publicfield;
   int privatefield PRIVATE;
 } MyObject;
>>>
>>> Forgot to say, but if people don't think this is an
>>> intrinsically terrible idea I'll put together a patch that
>>> does this sometime this week.
>>
>> I like the idea, but could we make this slightly less upper case? Something 
>> like
>>
>>   __private int privatefield;
>>
>> feels more readable imho.
> 
> Well, __ is using the reserved namespace, but we could use something
> else, and it looks like gcc lets us put the attribute at the front.
> Since we'll want to undef whatever we pick after the struct is defined
> we can actually use pretty much anything without worrying about it
> stealing namespace.
> (We could even use just 'private' if we didn't mind (a) not being
> able to compile with a C++ compiler

We still have many occurrences of "klass" around as proof that we try to
be C++ compatible. ;)

> and (b) confusing everybody
> completely :-))

I wouldn't generally mind annotating fields. But let's ask Michael about
this - QIDL tried to annotate fields in a similar way for migration status.

>> Or maybe
>>
>> struct MyObject {
>>   PUBLIC_FIELDS
>>   __field int publicfield;
>>   PRIVATE_FIELDS
>>   __field int privatefield;
>> }
> 
> I can't see an obvious way to make those do the right
> thing with the C preprocessor... am I missing something?

gtk-doc wouldn't understand that, and I can't think of a way that
PRIVATE_FIELDS could redefine __field (or field) to do the right thing.

Anyway, before we get lost in a bikeshed discussion, if the
underscore'ization of the type names is to everyone's liking now, I
would very much like to queue the QOM cast patches on qom-next
(independent of whether you apply parts of the series to arm-devs.next).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Scott Wood]

On 07/23/2013 04:44:02 PM, Alexander Graf wrote:



Am 23.07.2013 um 23:19 schrieb Scott Wood :

> On 07/23/2013 04:15:59 PM, Alexander Graf wrote:
>> On 23.07.2013, at 21:38, Scott Wood wrote:
>> > On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> >> Today we generate the device tree once on machine  
initialization and then

>> >> store the finalized blob in memory to reload it on reset.
>> >> This is bad for 2 reasons. First we potentially waste a bunch  
of RAM for no
>> >> good reason, as we have all information required to regenerate  
the device

>> >> tree available anyways.
>> >> The second reason is even more important. On machine init when  
we generate
>> >> the device tree for the first time, we don't have all of the  
devices fully
>> >> initialized yet. But the device tree needs to potentially walk  
devices to

>> >> put information about them into the device tree.
>> >
>> > If you can't produce the entire device tree at init time, how  
can you calculate its size with a dry run?

>> >
>> > Device trees are generally pretty small; couldn't we just set a  
maximum size and allocate that much space?
>> It's what we do, unless we load it from the disk. In that case we  
take the fdt size from disk.

>
> So why do we need the dry run stuff?

Because dumpdtb otherwise generates a halfway complete dtb on the  
first dry pass as device realization is yet incomplete :).


What I mean is why have a first pass at all?

-Scott

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Alexander Graf]

On 23.07.2013, at 23:55, Scott Wood wrote:

> On 07/23/2013 04:44:02 PM, Alexander Graf wrote:
>> Am 23.07.2013 um 23:19 schrieb Scott Wood :
>> > On 07/23/2013 04:15:59 PM, Alexander Graf wrote:
>> >> On 23.07.2013, at 21:38, Scott Wood wrote:
>> >> > On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> >> >> Today we generate the device tree once on machine initialization and 
>> >> >> then
>> >> >> store the finalized blob in memory to reload it on reset.
>> >> >> This is bad for 2 reasons. First we potentially waste a bunch of RAM 
>> >> >> for no
>> >> >> good reason, as we have all information required to regenerate the 
>> >> >> device
>> >> >> tree available anyways.
>> >> >> The second reason is even more important. On machine init when we 
>> >> >> generate
>> >> >> the device tree for the first time, we don't have all of the devices 
>> >> >> fully
>> >> >> initialized yet. But the device tree needs to potentially walk devices 
>> >> >> to
>> >> >> put information about them into the device tree.
>> >> >
>> >> > If you can't produce the entire device tree at init time, how can you 
>> >> > calculate its size with a dry run?
>> >> >
>> >> > Device trees are generally pretty small; couldn't we just set a maximum 
>> >> > size and allocate that much space?
>> >> It's what we do, unless we load it from the disk. In that case we take 
>> >> the fdt size from disk.
>> >
>> > So why do we need the dry run stuff?
>> Because dumpdtb otherwise generates a halfway complete dtb on the first dry 
>> pass as device realization is yet incomplete :).
> 
> What I mean is why have a first pass at all?

Ah, you mean we should just always limit ourselves to the 8MB we reserve for 
the device tree? That would work, yes.


Alex

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Alexander Graf]

On 23.07.2013, at 23:52, Peter Maydell wrote:

> On 23 July 2013 22:36, Alexander Graf  wrote:
>> 
>> 
>> Am 23.07.2013 um 23:16 schrieb Peter Maydell :
>> 
>>> On 23 July 2013 20:15, Peter Maydell  wrote:
 I had a thought about this. Suppose we have our class header
 files do something like this:
 
 #ifdef MYCLASS_IMPLEMENTATION
 #define PRIVATE
 #else
 #ifdef __GNUC__
 #define PRIVATE __attribute__((deprecated("this is a private field")))
 #else
 #define PRIVATE
 #endif
 
 typedef struct MyObject {
  int publicfield;
  int privatefield PRIVATE;
 } MyObject;
>>> 
>>> Forgot to say, but if people don't think this is an
>>> intrinsically terrible idea I'll put together a patch that
>>> does this sometime this week.
>> 
>> I like the idea, but could we make this slightly less upper case? Something 
>> like
>> 
>>  __private int privatefield;
>> 
>> feels more readable imho.
> 
> Well, __ is using the reserved namespace, but we could use something
> else, and it looks like gcc lets us put the attribute at the front.
> Since we'll want to undef whatever we pick after the struct is defined
> we can actually use pretty much anything without worrying about it
> stealing namespace.

Very nice :). And it aligns pretty well with the __user hint in Linux.

> (We could even use just 'private' if we didn't mind (a) not being
> able to compile with a C++ compiler and (b) confusing everybody
> completely :-))
> 
>> Or maybe
>> 
>> struct MyObject {
>>  PUBLIC_FIELDS
>>  __field int publicfield;
>>  PRIVATE_FIELDS
>>  __field int privatefield;
>> }
> 
> I can't see an obvious way to make those do the right
> thing with the C preprocessor... am I missing something?

No, I'm probably just daydreaming :). Macros can't redefine other defines, so 
this probably won't work

So yes, prepending the visibility on every field seems to be the most straight 
forward choice.


Alex

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Peter Maydell]

On 23 July 2013 22:36, Alexander Graf  wrote:
>
>
> Am 23.07.2013 um 23:16 schrieb Peter Maydell :
>
>> On 23 July 2013 20:15, Peter Maydell  wrote:
>>> I had a thought about this. Suppose we have our class header
>>> files do something like this:
>>>
>>> #ifdef MYCLASS_IMPLEMENTATION
>>> #define PRIVATE
>>> #else
>>> #ifdef __GNUC__
>>> #define PRIVATE __attribute__((deprecated("this is a private field")))
>>> #else
>>> #define PRIVATE
>>> #endif
>>>
>>> typedef struct MyObject {
>>>   int publicfield;
>>>   int privatefield PRIVATE;
>>> } MyObject;
>>
>> Forgot to say, but if people don't think this is an
>> intrinsically terrible idea I'll put together a patch that
>> does this sometime this week.
>
> I like the idea, but could we make this slightly less upper case? Something 
> like
>
>   __private int privatefield;
>
> feels more readable imho.

Well, __ is using the reserved namespace, but we could use something
else, and it looks like gcc lets us put the attribute at the front.
Since we'll want to undef whatever we pick after the struct is defined
we can actually use pretty much anything without worrying about it
stealing namespace.
(We could even use just 'private' if we didn't mind (a) not being
able to compile with a C++ compiler and (b) confusing everybody
completely :-))

> Or maybe
>
> struct MyObject {
>   PUBLIC_FIELDS
>   __field int publicfield;
>   PRIVATE_FIELDS
>   __field int privatefield;
> }

I can't see an obvious way to make those do the right
thing with the C preprocessor... am I missing something?

-- PMM

Re: [Qemu-devel] [PATCH v7 03/10] checkpatch.pl: Check .cpp files

[Tomoki Sekiyama]

On 7/22/13 17:21 , "Michael Roth"  wrote:

>Quoting Tomoki Sekiyama (2013-07-15 11:20:37)
>> Enable checkpatch.pl to apply the same checks as C source files for
>> C++ files with .cpp extensions. It also adds some exceptions for C++
>> sources to suppress errors for:
>>   - <> used in C++ template arguments (e.g. template )
>>   - :: used to represent namespaces   (e.g. SomeClass::method())
>>   - : used in class declaration   (e.g. class T : public Super)
>>   - ~ used in destructor method name  (e.g. T::~T())
>>   - spacing around 'catch'(e.g. catch (...))
>> 
>> Signed-off-by: Tomoki Sekiyama 
>
>One small nit below about documentation. Looks good otherwise.

>>@@ -2066,7 +2069,8 @@ sub process {
>> #   ->
>> #   :   when part of a bitfield
>> } elsif ($op eq '->' || $opv eq ':B') {
>> -   if ($ctx =~ /Wx.|.xW/) {
>> +   if ($ctx =~ /Wx.|.xW/ &&
>> +   !($opv eq ':B' && $line
>>=~ /class/)) {
>
>Everything else seemed fairly obvious or was well commented, but I
>couldn't
>figure out what this change was for. Could you insert a small comment to
>explain?

Sure. This is suppressing errors for : used in class declaration.
I will do some cleanups for this.

Thanks,
Tomoki Sekiyama

Re: [Qemu-devel] [PATCH v7 01/10] configure: Support configuring C++ compiler

[Tomoki Sekiyama]

Hi Michael,
Thanks for your review.

On 7/22/13 16:53 , "Michael Roth"  wrote:

>Quoting Tomoki Sekiyama (2013-07-15 11:20:29)
>> Add configuration for C++ compiler in configure and Makefiles.
>> The C++ compiler is choosed as following:
>>  - ${CXX}, if it is specified.
>>  - ${cross_prefix}g++, if ${cross_prefix} is specified.
>>  - Otherwise, c++ is used.
>> 
>> Currently, usage of C++ language is only for access to Windows VSS
>> using COM+ services in qemu-guest-agent for Windows.
>> 
>> Signed-off-by: Tomoki Sekiyama 
>> Reviewed-by: Laszlo Ersek 
>> ---
>>  configure |   13 +
>>  rules.mak |9 -
>>  2 files changed, 21 insertions(+), 1 deletion(-)
>> 
>> diff --git a/configure b/configure
>> index cb0f870..6923b65 100755
>> --- a/configure
>> +++ b/configure
>> @@ -251,6 +251,8 @@ for opt do
>>;;
>>--cc=*) CC="$optarg"
>>;;
>> +  --cxx=*) CXX="$optarg"
>> +  ;;
>>--source-path=*) source_path="$optarg"
>>;;
>>--cpu=*) cpu="$optarg"
>> @@ -281,6 +283,12 @@ else
>>cc="${CC-${cross_prefix}gcc}"
>>  fi
>> 
>> +if test -z "${CXX}${cross_prefix}"; then
>> +  cxx="c++"
>> +else
>> +  cxx="${CXX-${cross_prefix}g++}"
>> +fi
>> +
>>  ar="${AR-${cross_prefix}ar}"
>>  as="${AS-${cross_prefix}as}"
>>  cpp="${CPP-$cc -E}"
>> @@ -621,6 +629,8 @@ for opt do
>>;;
>>--host-cc=*) host_cc="$optarg"
>>;;
>> +  --cxx=*) cxx="$optarg"
>> +  ;;
>
>Since we've already determined cxx in the first pass (overriding other
>defaults --cxx argument if it's present), I think re-assigning here
>is unecessary.
>
>Otherwise looks good.

OK, I will remove the assignment.

Thanks,
Tomoki Sekiyama

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Alexander Graf]

Am 23.07.2013 um 23:19 schrieb Scott Wood :

> On 07/23/2013 04:15:59 PM, Alexander Graf wrote:
>> On 23.07.2013, at 21:38, Scott Wood wrote:
>> > On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> >> Today we generate the device tree once on machine initialization and then
>> >> store the finalized blob in memory to reload it on reset.
>> >> This is bad for 2 reasons. First we potentially waste a bunch of RAM for 
>> >> no
>> >> good reason, as we have all information required to regenerate the device
>> >> tree available anyways.
>> >> The second reason is even more important. On machine init when we generate
>> >> the device tree for the first time, we don't have all of the devices fully
>> >> initialized yet. But the device tree needs to potentially walk devices to
>> >> put information about them into the device tree.
>> >
>> > If you can't produce the entire device tree at init time, how can you 
>> > calculate its size with a dry run?
>> >
>> > Device trees are generally pretty small; couldn't we just set a maximum 
>> > size and allocate that much space?
>> It's what we do, unless we load it from the disk. In that case we take the 
>> fdt size from disk.
> 
> So why do we need the dry run stuff?

Because dumpdtb otherwise generates a halfway complete dtb on the first dry 
pass as device realization is yet incomplete :).


Alex

> 
> -SCott

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Alexander Graf]

Am 23.07.2013 um 23:16 schrieb Peter Maydell :

> On 23 July 2013 20:15, Peter Maydell  wrote:
>> On 23 July 2013 03:43, Andreas Färber  wrote:
>>> v2 improves internal vs. "public" header separation for GIC.
>>> As before, no feedback was received to address PMM's QOM concerns,
>>> so this is what we have as design patterns for the moment.
>> 
>> I had a thought about this. Suppose we have our class header
>> files do something like this:
>> 
>> #ifdef MYCLASS_IMPLEMENTATION
>> #define PRIVATE
>> #else
>> #ifdef __GNUC__
>> #define PRIVATE __attribute__((deprecated("this is a private field")))
>> #else
>> #define PRIVATE
>> #endif
>> 
>> typedef struct MyObject {
>>   int publicfield;
>>   int privatefield PRIVATE;
>> } MyObject;
> 
> Forgot to say, but if people don't think this is an
> intrinsically terrible idea I'll put together a patch that
> does this sometime this week.

I like the idea, but could we make this slightly less upper case? Something like

  __private int privatefield;

feels more readable imho. Or maybe

struct MyObject {
  PUBLIC_FIELDS
  __field int publicfield;
  PRIVATE_FIELDS
  __field int privatefield;
}

We already have comments indicating the sections, so replacing them by valid 
macros feels sensible.
  

Alex

Re: [Qemu-devel] [PATCHv2] [RFC 2/7] aio / timers: qemu-timer.c utility functions and add list of clocks

[Alex Bligh]

Richard,

--On 23 July 2013 13:09:18 -0800 Richard Henderson  wrote:


On 07/20/2013 10:06 AM, Alex Bligh wrote:

+int64_t qemu_clock_deadline_ns(QEMUClock *clock);
+int64_t qemu_clock_deadline_all_ns(void);
+int qemu_timeout_ns_to_ms(int64_t ns);
+gint qemu_g_poll_ns(GPollFD *fds, guint nfds, int64_t timeout);


Why continue with the g_ prefix here?  Surely qemu_poll_ns is sufficient.


Only because it was a g_ type function (takes GPollFD*, guint, and returns
gint). Quite happy to make it a qemu_poll_ns. Perhaps I should make it take
uint and return int at the same time.

TBH I am confused as to why we use g_poll at all. I thought originally
we were using it for win32, but that doesn't use g_poll. Given poll is
POSIX, what platforms do we target which are glib, !win32, and !posix?
Using straight posix would be easier.

--
Alex Bligh

Re: [Qemu-devel] [PATCH 0/2] vdso for x86_64-linux-user

[Peter Maydell]

On 23 July 2013 21:27, Richard Henderson  wrote:
> This is a refresh of a patch I wrote in 2010, and have re-posted every
> 6 months thereafter.  To my knowledge, it has never been reviewed.
>
> It supplies a replacement for the required x86-64 vdso.  Anyone trying
> to emulate x86_64-linux on a host other than same will quickly run into
> the lack of a gettimeofday syscall, which glibc assumes is always
> provided by the vdso.

Do we really need to mess with building an x86 shared object
and pulling it in, rather than the kind of ad-hoc way we
handle the ARM commpage?

-- PMM

Re: [Qemu-devel] [PATCH] sun4m: add display width and height to the firmware configuration

[Mark Cave-Ayland]

On 15/06/13 14:55, Mark Cave-Ayland wrote:


Currently the graphics resolution for TCX is fixed at 1024x768, however
other framebuffers are capable of supporting additional resolutions.

Signed-off-by: Mark Cave-Ayland
---
  hw/sparc/sun4m.c |4 
  1 file changed, 4 insertions(+)

diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index 0e86ca7..5b7868e 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -66,6 +66,8 @@
  #define PROM_FILENAME"openbios-sparc32"
  #define CFG_ADDR 0xd0510ULL
  #define FW_CFG_SUN4M_DEPTH   (FW_CFG_ARCH_LOCAL + 0x00)
+#define FW_CFG_SUN4M_WIDTH   (FW_CFG_ARCH_LOCAL + 0x01)
+#define FW_CFG_SUN4M_HEIGHT  (FW_CFG_ARCH_LOCAL + 0x02)

  #define MAX_CPUS 16
  #define MAX_PILS 16
@@ -991,6 +993,8 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, 
ram_addr_t RAM_size,
  fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
  fw_cfg_add_i16(fw_cfg, FW_CFG_MACHINE_ID, hwdef->machine_id);
  fw_cfg_add_i16(fw_cfg, FW_CFG_SUN4M_DEPTH, graphic_depth);
+fw_cfg_add_i16(fw_cfg, FW_CFG_SUN4M_WIDTH, graphic_width);
+fw_cfg_add_i16(fw_cfg, FW_CFG_SUN4M_HEIGHT, graphic_height);
  fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_ADDR, KERNEL_LOAD_ADDR);
  fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, kernel_size);
  if (kernel_cmdline) {


Ping?


ATB,

Mark.

Re: [Qemu-devel] [PATCH v2 17/17] block: look for zero blocks in bs->file

[Peter Lieven]

Am 19.07.2013 19:07, schrieb Paolo Bonzini:
> Il 19/07/2013 09:33, Stefan Hajnoczi ha scritto:
>> On Tue, Jul 16, 2013 at 06:29:28PM +0200, Paolo Bonzini wrote:
>>> diff --git a/block.c b/block.c
>>> index 557ce29..2d7d71f 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -2977,7 +2977,7 @@ static int64_t coroutine_fn 
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>>   int nb_sectors, int 
>>> *pnum)
>>>  {
>>>  int64_t n;
>>> -int64_t ret;
>>> +int64_t ret, ret2;
>>>  
>>>  if (sector_num >= bs->total_sectors) {
>>>  *pnum = 0;
>>> @@ -3003,6 +3003,14 @@ static int64_t coroutine_fn 
>>> bdrv_co_get_block_status(BlockDriverState *bs,
>>>  ret |= BDRV_BLOCK_ZERO;
>>>  }
>>>  
>>> +if (bs->file &&
>>> +(ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) &&
>>> +(ret & BDRV_BLOCK_OFFSET_VALID)) {
>>> +ret2 = bdrv_co_get_block_status(bs->file, ret >> BDRV_SECTOR_BITS,
>>> +*pnum, pnum);
>>> +ret |= (ret2 & BDRV_BLOCK_ZERO);
>>> +}
>> This patch breaks qemu-iotests 030 (image streaming).
>>
>> The problem is that bdrv_co_get_block_status() uses bs->total_sectors
>> directly instead of calling bdv_get_geometry()/bdrv_getlength().
>>
>> With qcow2 the bs->file can grow on disk.  We don't update
>> bs->total_sectors.
>>
>> Then this patch calls bdrv_co_get_block_status(bs->file) where we fail
>> with *pnum = 0, ret = 0 because bs->total_sectors suggests it is beyond
>> the end of the file.
>>
>> The result is that 030 goes into an infinite loop.
>>
>> As a quick test I switched the direct bs->total_sectors accesses to
>> bdrv_get_geometry() and it stopped hanging.  Perhaps the
>> bs->total_sectors caching needs to be improved though.
> Yes, fixing the caching also resolves the failure.  I'll send a v3 next
> Monday or perhaps Sunday.
Do you have the v3 ready?

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Scott Wood]

On 07/23/2013 04:15:59 PM, Alexander Graf wrote:


On 23.07.2013, at 21:38, Scott Wood wrote:

> On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> Today we generate the device tree once on machine initialization  
and then

>> store the finalized blob in memory to reload it on reset.
>> This is bad for 2 reasons. First we potentially waste a bunch of  
RAM for no
>> good reason, as we have all information required to regenerate the  
device

>> tree available anyways.
>> The second reason is even more important. On machine init when we  
generate
>> the device tree for the first time, we don't have all of the  
devices fully
>> initialized yet. But the device tree needs to potentially walk  
devices to

>> put information about them into the device tree.
>
> If you can't produce the entire device tree at init time, how can  
you calculate its size with a dry run?

>
> Device trees are generally pretty small; couldn't we just set a  
maximum size and allocate that much space?


It's what we do, unless we load it from the disk. In that case we  
take the fdt size from disk.


So why do we need the dry run stuff?

-SCott

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Alexander Graf]

On 23.07.2013, at 21:38, Scott Wood wrote:

> On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
>> Today we generate the device tree once on machine initialization and then
>> store the finalized blob in memory to reload it on reset.
>> This is bad for 2 reasons. First we potentially waste a bunch of RAM for no
>> good reason, as we have all information required to regenerate the device
>> tree available anyways.
>> The second reason is even more important. On machine init when we generate
>> the device tree for the first time, we don't have all of the devices fully
>> initialized yet. But the device tree needs to potentially walk devices to
>> put information about them into the device tree.
> 
> If you can't produce the entire device tree at init time, how can you 
> calculate its size with a dry run?
> 
> Device trees are generally pretty small; couldn't we just set a maximum size 
> and allocate that much space?

It's what we do, unless we load it from the disk. In that case we take the fdt 
size from disk.


Alex

Re: [Qemu-devel] [PATCH v2 10/17] block: define get_block_status return value

[Peter Lieven]

Am 20.07.2013 09:00, schrieb Paolo Bonzini:
> Il 19/07/2013 15:06, Peter Lieven ha scritto:
> Il 19/07/2013 08:48, Peter Lieven ha scritto:
>>> -return bdrv_get_block_status(bs, sector_num, nb_sectors, pnum);
>>> +int64_t ret = bdrv_get_block_status(bs, sector_num, nb_sectors,
>>> pnum);
>>> +return
>>> +(ret & BDRV_BLOCK_DATA) ||
>>> +((ret & BDRV_BLOCK_ZERO) && !bdrv_has_zero_init(bs));
>> i do also not understand the "((ret & BDRV_BLOCK_ZERO) &&
>> !bdrv_has_zero_init(bs))";
>> if a block is unallocated and reads as zero, but the device lacks zero
>> init, it is declared as allocated with this, isn't it?
>> If it is zero and allocated the API should return only BDRV_BLOCK_DATA
>> and if it is zero and unallocated only BDRV_BLOCK_ZERO or not?
>>
>> What I mean is the new API shouldn't change the behaviour of the old
>> bdrv_is_allocated().
>> It would have returned
>>
>> (ret & BDRV_BLOCK_DATA) regardless if BDRV_BLOCK_ZERO or not.
> bdrv_is_allocated must return true for some zero clusters, even
> if BDRV_BLOCK_DATA = 0.  See
>
> commit 381b487d54ba18c73df9db8452028a330058c505
> Author: Paolo Bonzini 
> Date:   Wed Mar 6 18:02:01 2013 +0100
>
> qcow2: make is_allocated return true for zero clusters
> 
> Otherwise, live migration of the top layer will miss zero clusters and
> let the backing file show through.  This also matches what is done in qed.
> 
> QCOW2_CLUSTER_ZERO clusters are invalid in v2 image files.  Check this
> directly in qcow2_get_cluster_offset instead of replicating the test
> everywhere.
> 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Paolo Bonzini 
> Signed-off-by: Stefan Hajnoczi 
>
> I think the source of the confusion is that SCSI "GET LBA STATUS"
> does not have to deal with backing files, bdrv_is_allocated must.
> If bs->backing_hd != NULL, bdrv_is_allocated is not about allocation
> of blocks in the SCSI sense; it's a query for "does the block come
> from this BDS or rather from its backing file?".
Ok, this makes it clearer. Thanks for pointing that out.
the bdrv_get_block_status() will add the possibility to
check for the allocation status which is a good thing.

Peter

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Peter Maydell]

On 23 July 2013 20:15, Peter Maydell  wrote:
> On 23 July 2013 03:43, Andreas Färber  wrote:
>> v2 improves internal vs. "public" header separation for GIC.
>> As before, no feedback was received to address PMM's QOM concerns,
>> so this is what we have as design patterns for the moment.
>
> I had a thought about this. Suppose we have our class header
> files do something like this:
>
> #ifdef MYCLASS_IMPLEMENTATION
> #define PRIVATE
> #else
> #ifdef __GNUC__
> #define PRIVATE __attribute__((deprecated("this is a private field")))
> #else
> #define PRIVATE
> #endif
>
> typedef struct MyObject {
>int publicfield;
>int privatefield PRIVATE;
> } MyObject;

Forgot to say, but if people don't think this is an
intrinsically terrible idea I'll put together a patch that
does this sometime this week.

-- PMM

[Qemu-devel] [PATCH 2/2] i82378: cleanup implementation

[Hervé Poussineau]

- i82378 only exists on PCI bus ; do not split implementation in 2 structures
- remove BARs, which are not specified in datasheet
- replace custom isa_mmio implementation by PCI bus IO region usage
- use QOM casts when required

Signed-off-by: Hervé Poussineau 
---
 hw/isa/i82378.c |  220 ---
 1 file changed, 48 insertions(+), 172 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index de71d81..f2045de 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -22,134 +22,27 @@
 #include "hw/timer/i8254.h"
 #include "hw/audio/pcspk.h"
 
-//#define DEBUG_I82378
-
-#ifdef DEBUG_I82378
-#define DPRINTF(fmt, ...) \
-do { fprintf(stderr, "i82378: " fmt , ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF(fmt, ...) \
-do {} while (0)
-#endif
-
-#define BADF(fmt, ...) \
-do { fprintf(stderr, "i82378 ERROR: " fmt , ## __VA_ARGS__); } while (0)
+#define TYPE_I82378 "i82378"
+#define I82378(obj) \
+OBJECT_CHECK(I82378State, (obj), TYPE_I82378)
 
 typedef struct I82378State {
+PCIDevice parent_obj;
 qemu_irq out[2];
 qemu_irq *i8259;
 MemoryRegion io;
-MemoryRegion mem;
 } I82378State;
 
-typedef struct PCIi82378State {
-PCIDevice pci_dev;
-uint32_t isa_io_base;
-I82378State state;
-} PCIi82378State;
-
-static const VMStateDescription vmstate_pci_i82378 = {
-.name = "pci-i82378",
+static const VMStateDescription vmstate_i82378 = {
+.name = "i82378",
 .version_id = 0,
 .minimum_version_id = 0,
 .fields = (VMStateField[]) {
-VMSTATE_PCI_DEVICE(pci_dev, PCIi82378State),
+VMSTATE_PCI_DEVICE(parent_obj, I82378State),
 VMSTATE_END_OF_LIST()
 },
 };
 
-static void i82378_io_write(void *opaque, hwaddr addr,
-uint64_t value, unsigned int size)
-{
-switch (size) {
-case 1:
-DPRINTF("%s: " TARGET_FMT_plx "=%02" PRIx64 "\n", __func__,
-addr, value);
-cpu_outb(addr, value);
-break;
-case 2:
-DPRINTF("%s: " TARGET_FMT_plx "=%04" PRIx64 "\n", __func__,
-addr, value);
-cpu_outw(addr, value);
-break;
-case 4:
-DPRINTF("%s: " TARGET_FMT_plx "=%08" PRIx64 "\n", __func__,
-addr, value);
-cpu_outl(addr, value);
-break;
-default:
-abort();
-}
-}
-
-static uint64_t i82378_io_read(void *opaque, hwaddr addr,
-   unsigned int size)
-{
-DPRINTF("%s: " TARGET_FMT_plx "\n", __func__, addr);
-switch (size) {
-case 1:
-return cpu_inb(addr);
-case 2:
-return cpu_inw(addr);
-case 4:
-return cpu_inl(addr);
-default:
-abort();
-}
-}
-
-static const MemoryRegionOps i82378_io_ops = {
-.read = i82378_io_read,
-.write = i82378_io_write,
-.endianness = DEVICE_LITTLE_ENDIAN,
-};
-
-static void i82378_mem_write(void *opaque, hwaddr addr,
- uint64_t value, unsigned int size)
-{
-switch (size) {
-case 1:
-DPRINTF("%s: " TARGET_FMT_plx "=%02" PRIx64 "\n", __func__,
-addr, value);
-cpu_outb(addr, value);
-break;
-case 2:
-DPRINTF("%s: " TARGET_FMT_plx "=%04" PRIx64 "\n", __func__,
-addr, value);
-cpu_outw(addr, value);
-break;
-case 4:
-DPRINTF("%s: " TARGET_FMT_plx "=%08" PRIx64 "\n", __func__,
-addr, value);
-cpu_outl(addr, value);
-break;
-default:
-abort();
-}
-}
-
-static uint64_t i82378_mem_read(void *opaque, hwaddr addr,
-unsigned int size)
-{
-DPRINTF("%s: " TARGET_FMT_plx "\n", __func__, addr);
-switch (size) {
-case 1:
-return cpu_inb(addr);
-case 2:
-return cpu_inw(addr);
-case 4:
-return cpu_inl(addr);
-default:
-abort();
-}
-}
-
-static const MemoryRegionOps i82378_mem_ops = {
-.read = i82378_mem_read,
-.write = i82378_mem_write,
-.endianness = DEVICE_LITTLE_ENDIAN,
-};
-
 static void i82378_request_out0_irq(void *opaque, int irq, int level)
 {
 I82378State *s = opaque;
@@ -159,19 +52,36 @@ static void i82378_request_out0_irq(void *opaque, int irq, 
int level)
 static void i82378_request_pic_irq(void *opaque, int irq, int level)
 {
 DeviceState *dev = opaque;
-PCIDevice *pci = DO_UPCAST(PCIDevice, qdev, dev);
-PCIi82378State *s = DO_UPCAST(PCIi82378State, pci_dev, pci);
-
-qemu_set_irq(s->state.i8259[irq], level);
+qemu_set_irq(I82378(dev)->i8259[irq], level);
 }
 
-static void i82378_init(DeviceState *dev, I82378State *s)
+static void i82378_realize(DeviceState *dev, Error **errp)
 {
-ISABus *isabus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
-ISADevice *pit;
+PCIDevice *pci = PCI_DEVICE(dev);
+I82378State *s = I82378(dev);
+DeviceClass *dc;
+uint8_t *pci_conf;
+ISABus *isabus;
 ISADevice *isa;
   

[Qemu-devel] [PATCH 1/2] prep_pci: set isa_mem_base in the PCI host bridge

[Hervé Poussineau]

Currently, it is done by i82378 device, which shouldn't care of it.

Signed-off-by: Hervé Poussineau 
---
 hw/isa/i82378.c|3 ---
 hw/pci-host/prep.c |2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index b25ed04..de71d81 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -45,7 +45,6 @@ typedef struct I82378State {
 typedef struct PCIi82378State {
 PCIDevice pci_dev;
 uint32_t isa_io_base;
-uint32_t isa_mem_base;
 I82378State state;
 } PCIi82378State;
 
@@ -234,7 +233,6 @@ static int pci_i82378_init(PCIDevice *dev)
 pci_set_long(dev->wmask + PCI_BASE_ADDRESS_0, 0);
 pci_set_long(pci_conf + PCI_BASE_ADDRESS_0, pci->isa_io_base);
 
-isa_mem_base = pci->isa_mem_base;
 isa_bus_new(&dev->qdev, pci_address_space_io(dev));
 
 i82378_init(&dev->qdev, s);
@@ -244,7 +242,6 @@ static int pci_i82378_init(PCIDevice *dev)
 
 static Property i82378_properties[] = {
 DEFINE_PROP_HEX32("iobase", PCIi82378State, isa_io_base, 0x8000),
-DEFINE_PROP_HEX32("membase", PCIi82378State, isa_mem_base, 0xc000),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep.c
index b41d564..d6bcc63 100644
--- a/hw/pci-host/prep.c
+++ b/hw/pci-host/prep.c
@@ -119,6 +119,8 @@ static void raven_pcihost_realizefn(DeviceState *d, Error 
**errp)
 MemoryRegion *address_space_mem = get_system_memory();
 int i;
 
+isa_mem_base = 0xc000;
+
 for (i = 0; i < 4; i++) {
 sysbus_init_irq(dev, &s->irq[i]);
 }
-- 
1.7.10.4

[Qemu-devel] [PATCH 0/2] prep/i82378: simplify and enhance i82378 chipset implementation

[Hervé Poussineau]

Hi,

First patch simply move the choice of isa_mem_base from i82378 to PReP PCI 
chipset,
where it belongs.
Second patch rewrites most of the i82378 implementation, now that old_portio
memory access method has been removed. It also updates implementation to current
QEMU standards.

A lot of work will be needed for PReP Raven PCI chipset, including creating
correct regions for PCI memory region, PCI I/O region, custom PCI address 
space...
However, that's not the goal of this small patchset.

Hervé Poussineau (2):
  prep_pci: set isa_mem_base in the PCI host bridge
  i82378: cleanup implementation

 hw/isa/i82378.c|  223 +++-
 hw/pci-host/prep.c |2 +
 2 files changed, 50 insertions(+), 175 deletions(-)

-- 
1.7.10.4

Re: [Qemu-devel] [PATCHv2] [RFC 2/7] aio / timers: qemu-timer.c utility functions and add list of clocks

[Richard Henderson]

On 07/20/2013 10:06 AM, Alex Bligh wrote:
> +int64_t qemu_clock_deadline_ns(QEMUClock *clock);
> +int64_t qemu_clock_deadline_all_ns(void);
> +int qemu_timeout_ns_to_ms(int64_t ns);
> +gint qemu_g_poll_ns(GPollFD *fds, guint nfds, int64_t timeout);

Why continue with the g_ prefix here?  Surely qemu_poll_ns is sufficient.


r~

Re: [Qemu-devel] [PULL v2 0/2] alpha-softmmu updates

[Richard Henderson]

Ping.


r~

On 07/18/2013 07:23 AM, Richard Henderson wrote:
> Changes v1-v2:
>   * Update submodule, which I'd forgotten we had.
> 
> 
> r~
> 
> 
> The following changes since commit 6453a3a69488196f26d12654c6b148446abdf3d6:
> 
>   Merge remote-tracking branch 'quintela/migration.next' into staging 
> (2013-07-15 14:49:16 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/rth7680/qemu.git axp-next
> 
> for you to fetch changes up to b957a1b03cfd56134519ebc01ba8fe1b166c0c84:
> 
>   pc-bios: Update palcode-clipper (2013-07-18 08:17:42 -0700)
> 
> 
> Richard Henderson (2):
>   target-alpha: Move alarm to vm_clock
>   pc-bios: Update palcode-clipper
> 
>  .gitmodules   |   2 +-
>  hw/alpha/typhoon.c|   2 +-
>  pc-bios/README|   2 +-
>  pc-bios/palcode-clipper   | Bin 185703 -> 133550 bytes
>  roms/qemu-palcode |   2 +-
>  target-alpha/helper.h |   3 ++-
>  target-alpha/sys_helper.c |   7 ++-
>  target-alpha/translate.c  |  12 
>  8 files changed, 20 insertions(+), 10 deletions(-)
> 

Re: [Qemu-devel] [PULL 0/3] Queued tcg patches

[Richard Henderson]

Ping.


r~

On 07/15/2013 12:25 PM, Richard Henderson wrote:
> The following are the outstanding TCG patches (that I know of)
> that have been previously posted and reviewed.  Please pull.
> 
> 
> r~
> 
> 
> The following changes since commit 2562becfc126ed7678c662ee23b7c1fe135d8966:
> 
>   Merge remote-tracking branch 'cohuck/virtio-ccw-upstr' into staging 
> (2013-07-15 14:02:41 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/rth7680/qemu.git tcg-next
> 
> for you to fetch changes up to f290e4988dd8eb012de0517a1ff93df130e87da1:
> 
>   Merge git://github.com/hw-claudio/qemu-aarch64-queue into tcg-next 
> (2013-07-15 13:21:10 -0700)
> 
> 
> 
> Claudio Fontana (1):
>   tcg/aarch64: implement ldst 12bit scaled uimm offset
> 
> Jani Kokkonen (1):
>   tcg/aarch64: Implement tlb lookup fast path
> 
> Richard Henderson (2):
>   tcg: Remove temp_buf
>   Merge git://github.com/hw-claudio/qemu-aarch64-queue into tcg-next
> 
>  configure|   2 +-
>  include/exec/cpu-defs.h  |   2 -
>  include/exec/exec-all.h  |  14 +++
>  tcg/aarch64/tcg-target.c | 256 
> +--
>  4 files changed, 218 insertions(+), 56 deletions(-)
> 

Re: [Qemu-devel] [PATCH 0/4] po/Makefile: Fix regression and some minor issues

[Anthony Liguori]

On Tue, Jul 23, 2013 at 3:47 PM, Anthony Liguori  wrote:
> Stefan Weil  writes:
>
>> Am 18.07.2013 21:52, schrieb Stefan Weil:
>>> Am 16.07.2013 07:16, schrieb Stefan Weil:
 Am 05.07.2013 22:55, schrieb Stefan Weil:
> These patches are included:
>
> [PATCH 1/4] po/Makefile: Fix and improve help message
> [PATCH 2/4] po/Makefile: Fix *.mo generation for out-of-tree builds
> [PATCH 3/4] po/Makefile: Fix generation of messages.po
> [PATCH 4/4] po/Makefile: Use macro quiet-command for nice looking
>
> Regards
> Stefan W.
 Ping?
>>> Ping^2
>>>
>>
>> Ping^3
>>
>> Who is maintaining GTK? Anthony?
>>
>> Is there any chance to get some of the issues which
>> are addressed by this series fixed in the next version of
>> QEMU?
>>
>> Patch 1 certainly could also be applied via qemu-trivial,
>> maybe some of the others, too. See
>> http://patchwork.ozlabs.org/patch/257202/.
>
> I really don't understand why, but patches completely ignored this
> thread so I haven't seen it until this ping.  I can't see any reason off
> hand but will investigate further.

Ah, it's quite obvious now.

Your leader has a typo, "PATH" instead of "PATCH".  My scripts ignore
threads that do not have "PATCH" or "PULL" in the subject.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/4] po/Makefile: Fix regression and some minor issues

[Anthony Liguori]

Stefan Weil  writes:

> Am 18.07.2013 21:52, schrieb Stefan Weil:
>> Am 16.07.2013 07:16, schrieb Stefan Weil:
>>> Am 05.07.2013 22:55, schrieb Stefan Weil:
 These patches are included:

 [PATCH 1/4] po/Makefile: Fix and improve help message
 [PATCH 2/4] po/Makefile: Fix *.mo generation for out-of-tree builds
 [PATCH 3/4] po/Makefile: Fix generation of messages.po
 [PATCH 4/4] po/Makefile: Use macro quiet-command for nice looking

 Regards
 Stefan W.
>>> Ping?
>> Ping^2
>>
>
> Ping^3
>
> Who is maintaining GTK? Anthony?
>
> Is there any chance to get some of the issues which
> are addressed by this series fixed in the next version of
> QEMU?
>
> Patch 1 certainly could also be applied via qemu-trivial,
> maybe some of the others, too. See
> http://patchwork.ozlabs.org/patch/257202/.

I really don't understand why, but patches completely ignored this
thread so I haven't seen it until this ping.  I can't see any reason off
hand but will investigate further.

Is it possible you sent this differently than you have sent series in
the past?

At any rate, it's enqueued now, will push shortly after testing
completes.  Sorry about that.

Regards,

Anthony Liguori

>
> Stefan

Re: [Qemu-devel] [qom-cpu PATCH 2/2] i386: disable PMU passthrough mode by default

[Paolo Bonzini]

Il 23/07/2013 19:41, Eduardo Habkost ha scritto:
> On Tue, Jul 23, 2013 at 06:23:08PM +0200, Paolo Bonzini wrote:
>> Il 23/07/2013 17:40, Eduardo Habkost ha scritto:
>>> On Tue, Jul 23, 2013 at 05:09:02PM +0200, Paolo Bonzini wrote:
 Il 23/07/2013 16:13, Eduardo Habkost ha scritto:
> On Tue, Jul 23, 2013 at 11:18:03AM +0200, Paolo Bonzini wrote:
>> Il 22/07/2013 21:25, Eduardo Habkost ha scritto:
>>> Bug description: QEMU currently gets all bits from GET_SUPPORTED_CPUID
>>> for CPUID leaf 0xA and passes them directly to the guest. This makes
>>> the guest ABI depend on host kernel and host CPU capabilities, and
>>> breaks live migration if we migrate between host with different
>>> capabilities (e.g. different number of PMU counters).
>>>
>>> This patch adds a "pmu-passthrough" property to X86CPU, and set it to
>>> true only on "-cpu host", or on pc-*-1.5 and older machine-types.
>>
>> Can we just call the property "pmu"?  It doesn't have to be passthough.
>
> Yes, but the only options we have today are "no PMU" and "passthrough
> PMU". I wouldn't like to make "pmu=on" enable the passthrough behavior
> implicitly (I don't want things that break live-migration to be enabled
> without making it explicit that it is a host-dependent/passthrough
> mode).

 I think "passthrough PMU" should be considered a bug except of course
 with "-cpu host".

 If "-cpu Nehalem,pmu=on" goes from passthrough to Nehalem-compatible in
 a future QEMU release, that'll be a bugfix.
>>>
>>> Exactly. But then I don't understand your suggestion. We still need a
>>> property to enable pasthrough behavior on old machine-types (not
>>> perfect, but a best-effort way to try to keep compatibility),
>>
>> Do we?
>>
>> We only need "pmu=on"---which right now is buggy on old machine types
>> because it will always passthrough.
> 
> I am not sure I understand what you are arguing for.
> 
> You agree that pmu=on needs to keep the buggy passthrough behavior on
> pc-1.5 and older, right?

I agree it needs to remain enabled on 1.5.  But if, for example, 1.8
makes pmu=on emulate a Nehalem-compatible PMU, I think it is fine if
pc-1.5 moves from a host-compatible PMU to a Nehalem-compatible PMU.

The reason is that pc-1.5 has never guaranteed any feature of the
emulated PMU.

Paolo

[Qemu-devel] [PATCH 1/2] linux-user: Build vdso for x64.

[Richard Henderson]

... Well, sortof.  The Makefile bits are broken.
Patch to load the vdso into the running program to follow.

Signed-off-by: Richard Henderson 
---
 Makefile  |   3 +-
 pc-bios/Makefile  |   5 +++
 pc-bios/vdso-linux-x64.S  | 100 ++
 pc-bios/vdso-linux-x64.ld |  79 
 pc-bios/vdso-linux-x64.so | Bin 0 -> 7419 bytes
 5 files changed, 186 insertions(+), 1 deletion(-)
 create mode 100644 pc-bios/vdso-linux-x64.S
 create mode 100644 pc-bios/vdso-linux-x64.ld
 create mode 100755 pc-bios/vdso-linux-x64.so

diff --git a/Makefile b/Makefile
index c06bfab..0148da1 100644
--- a/Makefile
+++ b/Makefile
@@ -296,7 +296,8 @@ multiboot.bin linuxboot.bin kvmvapic.bin \
 s390-zipl.rom \
 s390-ccw.img \
 spapr-rtas.bin slof.bin \
-palcode-clipper
+palcode-clipper \
+vdso-linux-x64.so
 else
 BLOBS=
 endif
diff --git a/pc-bios/Makefile b/pc-bios/Makefile
index 315288d..70e2485 100644
--- a/pc-bios/Makefile
+++ b/pc-bios/Makefile
@@ -15,5 +15,10 @@ all: $(TARGETS)
 %.dtb: %.dts
dtc -I dts -O dtb -o $@ $<
 
+vdso-linux-x64.so: vdso-linux-x64.o vdso-linux-x64.ld
+   $(CC) -nostdlib -shared -Wl,-T,vdso-linux-x64.ld \
+ -Wl,-h,linux-vdso.so.1 -Wl,--hash-style=both \
+ vdso-linux-x64.o -o $@
+
 clean:
rm -f $(TARGETS) *.o *~
diff --git a/pc-bios/vdso-linux-x64.S b/pc-bios/vdso-linux-x64.S
new file mode 100644
index 000..92efcd1
--- /dev/null
+++ b/pc-bios/vdso-linux-x64.S
@@ -0,0 +1,100 @@
+/*
+ *  x86-64 linux replacement vdso.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#include 
+
+   .globl  __vdso_clock_gettime
+   .type   __vdso_clock_gettime, @function
+   .balign 16
+   .cfi_startproc
+__vdso_clock_gettime:
+   mov $__NR_clock_gettime, %eax
+   syscall
+   ret
+   .cfi_endproc
+   .size   __vdso_clock_gettime, . - __vdso_clock_gettime
+
+clock_gettime = __vdso_clock_gettime
+   .weak   clock_gettime
+
+
+   .globl  __vdso_gettimeofday
+   .type   __vdso_gettimeofday, @function
+   .balign 16
+   .cfi_startproc
+__vdso_gettimeofday:
+   mov $__NR_gettimeofday, %eax
+   syscall
+   ret
+   .cfi_endproc
+   .size   __vdso_gettimeofday, . - __vdso_gettimeofday
+
+gettimeofday = __vdso_gettimeofday
+   .weak   gettimeofday
+
+
+   .globl  __vdso_getcpu
+   .type   __vdso_getcpu, @function
+   .balign 16
+   .cfi_startproc
+__vdso_getcpu:
+   /* ??? There is no syscall number for this allocated on x64.
+  We can handle this several ways:
+
+  (1) Invent a syscall number for use within qemu.
+   It should be easy enough to pick a number that
+   is well out of the way of the kernel numbers.
+
+   (2) Force the emulated cpu to support the rdtscp insn,
+  and initialize the TSC_AUX value the appropriate value.
+
+  (3) Pretend that we're always running on cpu 0.
+
+  This last is the one that's implemented here, with the
+  tiny bit of extra code to support rdtscp in place.  */
+
+   xor %ecx, %ecx  /* rdtscp w/ tsc_aux = 0 */
+
+   /* if (cpu != NULL) *cpu = (ecx & 0xfff); */
+   test%rdi, %rdi
+   jz  1f
+   mov %ecx, %eax
+   and $0xfff, %eax
+   mov %eax, (%rdi)
+
+   /* if (node != NULL) *node = (ecx >> 12); */
+1: test%rsi, %rsi
+   jz  2f
+   shr $12, %ecx
+   mov %ecx, (%rsi)
+
+2: xor %eax, %eax
+   ret
+   .cfi_endproc
+   .size   __vdso_getcpu, . - __vdso_getcpu
+
+getcpu = __vdso_getcpu
+   .weak   getcpu
+
+/* ??? Perhaps add elf notes.  E.g.
+
+   #include 
+   ELFNOTE_START(Linux, 0, "a")
+   .long LINUX_VERSION_CODE
+   ELFNOTE_END
+
+   but what version number would we set for QEMU?  */
diff --git a/pc-bios/vdso-linux-x64.ld b/pc-bios/vdso-linux-x64.ld
new file mode 100644
index 000..9e7e2d1
--- /dev/null
+++ b/pc-bios/vdso-linux-x64.ld
@@ -0,0 +1,79 @@
+/*
+ * Linker script for linux x64 replacement vdso.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the Lice

[Qemu-devel] [PATCH 0/2] vdso for x86_64-linux-user

[Richard Henderson]

This is a refresh of a patch I wrote in 2010, and have re-posted every
6 months thereafter.  To my knowledge, it has never been reviewed.

It supplies a replacement for the required x86-64 vdso.  Anyone trying
to emulate x86_64-linux on a host other than same will quickly run into
the lack of a gettimeofday syscall, which glibc assumes is always
provided by the vdso.


r~


Richard Henderson (2):
  linux-user: Build vdso for x64.
  linux-user: Load a VDSO for x86-64.

 Makefile  |   3 +-
 linux-user/elfload.c  | 197 --
 pc-bios/Makefile  |   5 ++
 pc-bios/vdso-linux-x64.S  | 100 +++
 pc-bios/vdso-linux-x64.ld |  79 +++
 pc-bios/vdso-linux-x64.so | Bin 0 -> 7419 bytes
 6 files changed, 376 insertions(+), 8 deletions(-)
 create mode 100644 pc-bios/vdso-linux-x64.S
 create mode 100644 pc-bios/vdso-linux-x64.ld
 create mode 100755 pc-bios/vdso-linux-x64.so

-- 
1.8.3.1

[Qemu-devel] [PATCH 2/2] linux-user: Load a VDSO for x86-64.

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 linux-user/elfload.c | 197 +--
 1 file changed, 190 insertions(+), 7 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 7ce2eab..0ceae28 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -197,6 +197,8 @@ static void elf_core_copy_regs(target_elf_gregset_t *regs, 
const CPUX86State *en
 (*regs)[26] = env->segs[R_GS].selector & 0x;
 }
 
+#define VDSO_BASENAME  "vdso-linux-x64.so"
+
 #else
 
 #define ELF_START_MMAP 0x8000
@@ -1029,6 +1031,10 @@ static inline void init_thread(struct target_pt_regs 
*regs, struct image_info *i
 #define ELF_HWCAP 0
 #endif
 
+#ifndef VDSO_BASENAME
+#define VDSO_BASENAME NULL
+#endif
+
 #ifdef TARGET_ABI32
 #undef ELF_CLASS
 #define ELF_CLASS ELFCLASS32
@@ -1332,7 +1338,8 @@ static abi_ulong loader_build_fdpic_loadmap(struct 
image_info *info, abi_ulong s
 static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
struct elfhdr *exec,
struct image_info *info,
-   struct image_info *interp_info)
+   struct image_info *interp_info,
+   struct image_info *vdso_info)
 {
 abi_ulong sp;
 abi_ulong sp_auxv;
@@ -1388,16 +1395,21 @@ static abi_ulong create_elf_tables(abi_ulong p, int 
argc, int envc,
  */
 sp = sp &~ (abi_ulong)15;
 size = (DLINFO_ITEMS + 1) * 2;
-if (k_platform)
+if (k_platform) {
 size += 2;
+}
+if (vdso_info) {
+size += 4;
+}
 #ifdef DLINFO_ARCH_ITEMS
 size += DLINFO_ARCH_ITEMS * 2;
 #endif
 size += envc + argc + 2;
 size += 1;  /* argc itself */
 size *= n;
-if (size & 15)
+if (size & 15) {
 sp -= 16 - (size & 15);
+}
 
 /* This is correct because Linux defines
  * elf_addr_t as Elf32_Off / Elf64_Off
@@ -1426,8 +1438,13 @@ static abi_ulong create_elf_tables(abi_ulong p, int 
argc, int envc,
 NEW_AUX_ENT(AT_CLKTCK, (abi_ulong) sysconf(_SC_CLK_TCK));
 NEW_AUX_ENT(AT_RANDOM, (abi_ulong) u_rand_bytes);
 
-if (k_platform)
+if (k_platform) {
 NEW_AUX_ENT(AT_PLATFORM, u_platform);
+}
+if (vdso_info) {
+NEW_AUX_ENT(AT_SYSINFO, vdso_info->entry);
+NEW_AUX_ENT(AT_SYSINFO_EHDR, vdso_info->load_addr);
+}
 #ifdef ARCH_DLINFO
 /*
  * ARCH_DLINFO must come last so platform specific code can enforce
@@ -1843,6 +1860,165 @@ static void load_elf_interp(const char *filename, 
struct image_info *info,
 exit(-1);
 }
 
+static void load_elf_vdso(const char *basename, struct image_info *info,
+  char bprm_buf[BPRM_BUF_SIZE])
+{
+const char *errmsg;
+char *filename;
+int fd, retval, i;
+abi_ulong load_bias;
+
+/* ??? What we really need access to is qemu_find_file, but that is
+   only built for system targets at the moment.  */
+filename = alloca(strlen(CONFIG_QEMU_DATADIR "/") + strlen(basename) + 1);
+stpcpy(stpcpy(filename, CONFIG_QEMU_DATADIR "/"), basename);
+
+fd = open(filename, O_RDONLY);
+if (fd < 0) {
+goto exit_perror;
+}
+
+retval = read(fd, bprm_buf, BPRM_BUF_SIZE);
+if (retval < 0) {
+goto exit_perror;
+}
+if (retval < BPRM_BUF_SIZE) {
+memset(bprm_buf + retval, 0, BPRM_BUF_SIZE - retval);
+}
+
+load_elf_image(basename, fd, info, NULL, bprm_buf);
+load_bias = info->load_bias;
+
+/* We most likely need to relocate the VDSO image.  The one built into
+   the kernel is built for a fixed address.  The one built for QEMU is
+   not, since that requires close control of the guest address space.  */
+if (load_bias) {
+struct elfhdr *ehdr = (struct elfhdr *)bprm_buf;
+struct elf_phdr *phdr;
+abi_ulong dynamic_addr = -1;
+abi_ulong dynsym_addr = -1;
+
+/* ??? Assume QEMU's VDSO is built "properly", which arranges
+   for the PHDRs, and all the sections manipulated below, to
+   be included with a writable load segment.  */
+
+/* ??? One might think that we'd need to relocate ehdr.e_entry,
+   but for some reason glibc does that one itself, though that
+   is also available via the AT_SYSINFO entry.  */
+
+/* Relocate the program headers.  */
+phdr = (struct elf_phdr *)g2h(info->load_addr + ehdr->e_phoff);
+bswap_phdr(phdr, ehdr->e_phnum);
+for (i = 0; i < ehdr->e_phnum; ++i) {
+phdr[i].p_vaddr += load_bias;
+phdr[i].p_paddr += load_bias;
+if (phdr[i].p_type == PT_DYNAMIC) {
+dynamic_addr = phdr[i].p_vaddr;
+}
+}
+bswap_phdr(phdr, ehdr->e_phnum);
+
+/* Relocate the DYNAMIC entries.  */
+if (dynamic_addr != -1) {
+abi_ulong tag, val, *dyn = (abi_ulong *)g2h(dynamic_ad

Re: [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive options

[Ian Main]

On Wed, Jul 17, 2013 at 05:09:05PM +0200, Kevin Wolf wrote:
> Am 17.07.2013 um 16:16 hat Paolo Bonzini geschrieben:
> > Il 17/07/2013 15:48, Kevin Wolf ha scritto:
> > >> I understand this is the right thing to do long term, but pre-opening of
> > >> the target is not really needed for fleecing.
> > > 
> > > So for how much longer should we plan to procrastinate? (I know, not an
> > > entirely fair question, but we have to make the step at some point)
> > 
> > If we bring it up during soft freeze, we will procrastinate it a lot. :)
> >  If we bring it up at the beginning of a release cycle, the wait could
> > be as short as 1 month...
> > 
> > > And we'll want to reference existing BDSes as backing/protocol files in
> > > blockdev-add soon anyway, so if we decide against it here, it's just
> > > moving from Fam's to-do list to mine...
> > 
> > We can reconsider these very patches in 1 month.  It's just the timing,
> > combined with the fact that this is not necessary for fleecing, that I'm
> > uncomfortable with.
> 
> Okay, I see where this is going. Let me reinforce one fundamental policy
> that you may not like. I've rejected patches based on it before and I'll
> likely have to do it again in the future. This is it:
> 
> I'm not going to compromise on upstream APIs to accommodate
> downstream schedules.
> 
> If doing things properly means moving fleecing to 1.7, so be it. There's
> no pressure to have it in upstream 1.6. It might mean downstream patches
> for some distro, but that's not a valid point in upstream design
> discussions.

I'll just throw out there that *I'm* feeling pressure for 1.6, but at
the same time I understand your concerns.  Some feel that independent of
distro concerns this is a feature gap for KVM/qemu.

It seems to me a practical approach of taking what is needed to get this
working while also putting out patches for doing it right would work out
well in the end.

Anyway, just my 2c.  I am just helping out and I know you guys have to
deal with the long term effects so I respect your decisions. 

Ian

> Now is the right time to discuss design changes for 1.7, so that as soon
> as block-next starts to come to life (i.e. beginning of August), we can
> start with implementing this at the earliest possible point in the 1.7
> release cycle.
> 
> > > I guess we can give a name to the target, and we can make drive-backup
> > > automatically connect the target with the original as its backing file
> > > (still needs the refcounting, by the way).
> > 
> > No, it doesn't need the refcounting (see my reply to the cover letter).
> >  In his next submission of drive-backup sync modes, Ian is already going
> > to handle the automatic connection of the target with the original.
> 
> Okay, I'll have a look, but I can't imagine how it work without
> refcounting. As soon as it has a name, you can attach the target to a
> guest, nbd server, start block jobs and do all kinds of fun with it so
> that taking it away when the source goes away becomes problematic. But
> I'll have a look at the patches and hope that the commit messages
> explain the details.
> 
> > > But is giving a name to the
> > > target not enough to allow "interesting" things to be done? I don't
> > > remember the details from the mirroring discussion, but it seems it were
> > > enough that you didn't want to do it.
> > 
> > Yes, but this time we have to bite the bullet on that one at least,
> > because we have no other choice (we want to do at least one
> > "interesting" thing, namely connect to it with the NBD server).
> 
> Yes, like I said, we might not feel comfortable with enabling these
> cases, but not enabling them isn't an option either. So now is the time
> to do the real thing.
> 
> Kevin

Re: [Qemu-devel] [PATCH 0/4] po/Makefile: Fix regression and some minor issues

[Stefan Weil]

Am 18.07.2013 21:52, schrieb Stefan Weil:
> Am 16.07.2013 07:16, schrieb Stefan Weil:
>> Am 05.07.2013 22:55, schrieb Stefan Weil:
>>> These patches are included:
>>>
>>> [PATCH 1/4] po/Makefile: Fix and improve help message
>>> [PATCH 2/4] po/Makefile: Fix *.mo generation for out-of-tree builds
>>> [PATCH 3/4] po/Makefile: Fix generation of messages.po
>>> [PATCH 4/4] po/Makefile: Use macro quiet-command for nice looking
>>>
>>> Regards
>>> Stefan W.
>> Ping?
> Ping^2
>

Ping^3

Who is maintaining GTK? Anthony?

Is there any chance to get some of the issues which
are addressed by this series fixed in the next version of
QEMU?

Patch 1 certainly could also be applied via qemu-trivial,
maybe some of the others, too. See
http://patchwork.ozlabs.org/patch/257202/.

Stefan

Re: [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive options

[Ian Main]

On Mon, Jul 22, 2013 at 02:07:15PM +0800, Fam Zheng wrote:
> On Wed, 07/17 14:36, Paolo Bonzini wrote:
> > Il 17/07/2013 11:42, Fam Zheng ha scritto:
> > > This option allows overriding backing hd of drive. If the target drive
> > > exists, it's referenced as the backing file and refcount incremented.
> > > 
> > > Example:
> > > qemu-system-x86_64 -drive \
> > > file.filename=foo.qcow2,if=none,id=foo \
> > > -drive file=bar.qcow2,backing=foo
> > 
> > I guess this is where we need the soft reference.
> > 
> > This has a _lot_ of potential for misuse, I think Kevin bashed me and
> > Federico very heavily when we tried to do something similar.
> > 
> > block/backup.c is the right place where we can override the backing hd
> > of the drive.  Perhaps we can add a way to open a file with
> > BDRV_O_NO_BACKING from the command line.
> 
> OK. If we get the override in block/backup.c, the only thing we need is
> naming the target so we can add it to nbd server. If refcounting,
> overriding backing with option and blockdev-backup are still good to
> have, I can split them and targeting to future releases.

In my latest patchset I have attempted to override the backing hd of the
target.  It is a little over my head however so any input there would be
appreciated.  It seems to me like applying that patch would get us a
working baseline and then you can add the more fancy stuff on top of
that?  That sound reasonable?

Ian

Re: [Qemu-devel] [PATCH V6 0/3] Implement sync modes for drive-backup.

[Ian Main]

On Tue, Jul 23, 2013 at 01:53:51PM +0200, Stefan Hajnoczi wrote:
> On Mon, Jul 22, 2013 at 03:09:17PM -0700, Ian Main wrote:
> > This patch adds sync modes on top of the work that Stefan Hajnoczi has done.
> > 
> > These patches apply on kevin/block.
> > 
> > Hopefully all is in order as this is my first QEMU patch.  Many thanks to
> > Stephan and Fam Zheng for their help.
> > 
> > V2:
> > 
> > - No longer poll, instead use qemu_coroutine_yield().
> > - Use bdrv_co_is_allocated().
> > - Much better SYNC_MODE_NONE test.
> > 
> > V3:
> > 
> > - A few style fixes.
> > - Better commit message explaining how TOP and NONE operate.
> > - Verified using checkpatch.pl.
> > 
> > V4:
> > 
> > - Add patch to use the source as a backing hd during backup.
> > - Add patch to default sync mode none to qcow2.
> > 
> > V5:
> > 
> > - Fix qcow2 patch.  Forgot to git add final version.
> > 
> > V6:
> > 
> > - Default to requiring 'format' when mode is absolute-paths.
> > - Removed one bad hunk that was misapplying.
> > - Fixed docs, examples and tests to match changes.
> > - Added tests for format bad/missing.
> > - Added bdrv_set_in_use() to target.
> > - Default to qcow2 patch not required.
> > 
> > Ian Main (3):
> >   Implement sync modes for drive-backup.
> >   Add tests for sync modes 'TOP' and 'NONE'
> >   Add backing drive while performing backup.
> > 
> >  block/backup.c| 107 
> > +
> >  blockdev.c|  36 +-
> >  include/block/block_int.h |   4 +-
> >  qapi-schema.json  |   4 +-
> >  qmp-commands.hx   |   2 +
> >  tests/qemu-iotests/055| 108 
> > +-
> >  tests/qemu-iotests/055.out|   4 +-
> >  tests/qemu-iotests/group  |   2 +-
> >  tests/qemu-iotests/iotests.py |   5 ++
> >  9 files changed, 211 insertions(+), 61 deletions(-)
> 
> This patch mostly takes care of image fleecing except it does not give
> the target a device name which can be used by nbd-server-add.

It's not clear to me how to do that.  I looked through Fams series and
was hoping to find a clue there but I may have missed it.
 
> Fam's series tackles the target device name and some of the overlapping
> problems with your series.

Yes which is great.
 
> The core feature in your series is sync=top|none and that needs to be
> merged.
> 
> Now we need to figure out which patches to take and what must be
> changed.  Please see the sub-threads on Fam's series.  Perhaps we can
> reach a consensus there.

Yes I'm happy to offer whatever help this is.  It does seem like
applying this is the next logical move however.  Fam could then base his
patch on top of this one.  At some point soon we need to reconcile
everything and to me that seems the logical way.  There actually doesn't
seem to be too much overlap in effort from what I can see.

Fam, what do you think?  I'm happy to make changes to make it easier for
your patchset too.

Ian
 

Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset

[Scott Wood]

On 07/22/2013 10:28:17 AM, Alexander Graf wrote:
Today we generate the device tree once on machine initialization and  
then

store the finalized blob in memory to reload it on reset.

This is bad for 2 reasons. First we potentially waste a bunch of RAM  
for no
good reason, as we have all information required to regenerate the  
device

tree available anyways.

The second reason is even more important. On machine init when we  
generate
the device tree for the first time, we don't have all of the devices  
fully
initialized yet. But the device tree needs to potentially walk  
devices to

put information about them into the device tree.


If you can't produce the entire device tree at init time, how can you  
calculate its size with a dry run?


Device trees are generally pretty small; couldn't we just set a maximum  
size and allocate that much space?


-Scott

Re: [Qemu-devel] [PATCH v2 00/16] arm: A9MPCore+A15MPCore QOM'ification

[Peter Maydell]

On 23 July 2013 03:43, Andreas Färber  wrote:
> v2 improves internal vs. "public" header separation for GIC.
> As before, no feedback was received to address PMM's QOM concerns,
> so this is what we have as design patterns for the moment.

I had a thought about this. Suppose we have our class header
files do something like this:

#ifdef MYCLASS_IMPLEMENTATION
#define PRIVATE
#else
#ifdef __GNUC__
#define PRIVATE __attribute__((deprecated("this is a private field")))
#else
#define PRIVATE
#endif

typedef struct MyObject {
   int publicfield;
   int privatefield PRIVATE;
} MyObject;

Then we can allow both users of the class and the implementation
to share the same header file (obviously only the implementation
defines MYCLASS_IMPLEMENTATION before using it). The users can
embed the struct MyObject with no problems, but if they try
to directly access a private field this happens:

/tmp/zz9.c:22:5: warning: ‘privatefield’ is deprecated (declared at
/tmp/zz9.c:12): this is a private field [-Wdeprecated-declarations]

(Since this is only a safety-guard against accidental uses,
it's OK that it's only present when building with gcc.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4 00/12] Boot order tests

[Anthony Liguori]

Applied.  Thanks.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/2] Provide sextract32() and sextract64()

[Anthony Liguori]

Applied.  Thanks.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] memory: Fix zero-sized memory region print

[Anthony Liguori]

Applied.  Thanks.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] configure: Remove ldscripts

[Anthony Liguori]

Applied.  Thanks.

Regards,

Anthony Liguori

Re: [Qemu-devel] Emulating mips

[Renich Bon Ciric]

On Tue, Jul 23, 2013 at 4:06 AM, Andreas Färber  wrote:
> Hello,
>
> Am 23.07.2013 07:16, schrieb Renich Bon Ciric:
>> I'm trying to run some rom file I got from a client. It's a sc2005
>> processor; supposedly compatible with 4k.
>>
>> Anyway, I do this:
>>
>> qemu-system-mips -M mips -pflash 301-3100\ -\ user\ specified\ -\
>> Full.bin -serial stdio
>>
>> The processor goes to 100% but I see nothing, not in the serial
>> console nor in the window (monitor, maybe?)
>
> You didn't mention which version you're using, so try latest stable 1.5
> or qemu.git.
>
> You need to know what board the ROM file was for, you can view the list
> with -M '?' - if it's none of those, chances are you need to implement
> the machine first.

Yeah, the board is none from the list; so maybe I need to look into
implementing, huh? 

> Note that there's qemu-system-mips and qemu-system-mipsel depending on
> endianness, and you can usually override the CPU via -cpu, again see
> -cpu '?' for a list.

Thanks a lot, Andreas. The info is very useful. Have a nice day.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] linux-user: correct argument number for sys_mremap and sys_splice

[Peter Maydell]

On 23 July 2013 18:18, Michael Tokarev  wrote:
> 23.07.2013 21:00, Petar Jovanovic wrote:
>> From: Petar Jovanovic 
>>
>> sys_mremap missed 5th argument (new_address), which caused examples that
>> remap to a specific address to fail.
>> sys_splice missed 5th and 6th argument which caused different examples to
>> fail.
>> This change has an effect on MIPS target only.
>
> While splice is obvious and appears to be correct, with mremap I'm not
> this sure.

This table in QEMU corresponds to the table in the kernel
in arch/mips/kernel/scall32-o32.S and should generally have
the same numbers in it.

The fix to mremap corresponds to Linux kernel commit 7dbdf43c
(from 2006); the fix to splice is 08d30879 (from 2008).

> On the other hand, sys_open is also declared as having 3
> arguments while the 3rd one (mode) is also optional,

Yes. All the number-of-arguments param does is cause
the main.c code to fish the extra arguments out of the stack,
since the MIPS 32 bit ABI doesn't have enough registers for
all of them to be in registers. If the argument is optional
and isn't used in this case, it means we've just copied
garbage as the arg6/7/8 param to do_syscall(), which is
exactly the same situation as if the guest ABI put all
syscall args in registers.

> until your last comment which states that the change has only effect
> on MIPS.  Which is quite puzzling to me

It's trivially obvious that it only has effect on MIPS,
because it's patching a piece of code which is inside
an #ifdef TARGET_MIPS guard.

Petar: I think it would be a good idea if you checked
the whole of our table against a recent kernel and made
sure we're in sync for everything, rather than fixing
things one at a time.

Reviewed-by: Peter Maydell 

-- PMM

Re: [Qemu-devel] [qom-cpu PATCH 2/2] i386: disable PMU passthrough mode by default

[Eduardo Habkost]

On Tue, Jul 23, 2013 at 06:23:08PM +0200, Paolo Bonzini wrote:
> Il 23/07/2013 17:40, Eduardo Habkost ha scritto:
> > On Tue, Jul 23, 2013 at 05:09:02PM +0200, Paolo Bonzini wrote:
> >> Il 23/07/2013 16:13, Eduardo Habkost ha scritto:
> >>> On Tue, Jul 23, 2013 at 11:18:03AM +0200, Paolo Bonzini wrote:
>  Il 22/07/2013 21:25, Eduardo Habkost ha scritto:
> > Bug description: QEMU currently gets all bits from GET_SUPPORTED_CPUID
> > for CPUID leaf 0xA and passes them directly to the guest. This makes
> > the guest ABI depend on host kernel and host CPU capabilities, and
> > breaks live migration if we migrate between host with different
> > capabilities (e.g. different number of PMU counters).
> >
> > This patch adds a "pmu-passthrough" property to X86CPU, and set it to
> > true only on "-cpu host", or on pc-*-1.5 and older machine-types.
> 
>  Can we just call the property "pmu"?  It doesn't have to be passthough.
> >>>
> >>> Yes, but the only options we have today are "no PMU" and "passthrough
> >>> PMU". I wouldn't like to make "pmu=on" enable the passthrough behavior
> >>> implicitly (I don't want things that break live-migration to be enabled
> >>> without making it explicit that it is a host-dependent/passthrough
> >>> mode).
> >>
> >> I think "passthrough PMU" should be considered a bug except of course
> >> with "-cpu host".
> >>
> >> If "-cpu Nehalem,pmu=on" goes from passthrough to Nehalem-compatible in
> >> a future QEMU release, that'll be a bugfix.
> > 
> > Exactly. But then I don't understand your suggestion. We still need a
> > property to enable pasthrough behavior on old machine-types (not
> > perfect, but a best-effort way to try to keep compatibility),
> 
> Do we?
> 
> We only need "pmu=on"---which right now is buggy on old machine types
> because it will always passthrough.

I am not sure I understand what you are arguing for.

You agree that pmu=on needs to keep the buggy passthrough behavior on
pc-1.5 and older, right?

In that case, how do you suggest I let QEMU know that only pc-1.5 and
older should have the buggy behavior enabled when pmu=on? I understand
that compat_props is the appropriate place for that, and that's why I
need a "please-enable-the-old-buggy-pmu-passthrough-behavior" property
that I can add to PC_COMPAT_1_5.

> 
> Paolo
> 
> > and I
> > named that option "pmu-passthrough". How do you think we should name it?
> 

-- 
Eduardo

Re: [Qemu-devel] [Qemu-trivial] [PATCH] PPC: dbdma: macio: Fix format specifiers (build regression)

[Michael Tokarev]

21.07.2013 18:58, Stefan Weil wrote:
> Am 20.07.2013 16:24, schrieb Andreas Färber:
>>
>> Anthony recently stated very clearly that in order for him to pick up a
>> patch it needs to have a Reviewed-by. This one only got an Acked-by.
> 
> 
> No rule without exception. When I look at the list of patches
> which were picked up recently, I see lots of patches without
> a Reviewed-by.
> 
> I still think that build regressions should be fixed
> very fast and don't understand why it takes so long:

I reviewed the patch and it appears to be correct.
Applied to the trivial patches queue.
Thanks,

/mjt

[Qemu-devel] [PULL 0/3] migration queue

[Juan Quintela]

Hi Anthony

please,  pull.

This has Vinod changes for auto-converge.

I merged by hand the problems, and tested that it works and compiles
for everything.

Thanks,  Juan.

PD: there were a prototype missing and the event name on trace-events,
fixed both.

The following changes since commit 25ca6a1f5a3ee0a1ae670590877ed14f05e28fba:

  Merge remote-tracking branch 'agraf/ppc-for-upstream' into staging 
(2013-07-12 07:58:31 -0500)

are available in the git repository at:


  git://github.com/juanquintela/qemu.git migration.next

for you to fetch changes up to 7ca1dfad952d8a8655b32e78623edcc38a51b14a:

  Force auto-convegence of live migration (2013-07-12 20:35:08 +0200)


Chegu Vinod (3):
  Introduce async_run_on_cpu()
  Add 'auto-converge' migration capability
  Force auto-convegence of live migration

 arch_init.c   | 81 +++
 cpus.c| 29 
 include/migration/migration.h |  2 ++
 include/qemu-common.h |  1 +
 include/qom/cpu.h | 10 ++
 migration.c   |  9 +
 qapi-schema.json  |  2 +-
 trace-events  |  1 +
 8 files changed, 134 insertions(+), 1 deletion(-)

Re: [Qemu-devel] [Qemu-trivial] [PATCH] linux-user: correct argument number for sys_mremap and sys_splice

[Michael Tokarev]

23.07.2013 21:00, Petar Jovanovic wrote:
> From: Petar Jovanovic 
> 
> sys_mremap missed 5th argument (new_address), which caused examples that
> remap to a specific address to fail.
> sys_splice missed 5th and 6th argument which caused different examples to
> fail.
> This change has an effect on MIPS target only.

While splice is obvious and appears to be correct, with mremap I'm not
this sure.  The last, 5th argument of mremap(), which is `void *new_address',
is optional and may be either present or not.  So, without understanding
how the underlying tables/code works, I'm not really sure if the resulting
change will work or not.  On the other hand, sys_open is also declared as
having 3 arguments while the 3rd one (mode) is also optional, so the patch
appears to be correct there as well, so I was almost ready to apply it,
until your last comment which states that the change has only effect on
MIPS.  Which is quite puzzling to me who, again, does not really know
how the code works.

So either the patch isn't trivial enough, or maybe you can provide some
more verbose explanation... ;)

Thanks,

/mjt

Re: [Qemu-devel] [Qemu-trivial] [PATCH] watchdog: Remove break after exit

[Michael Tokarev]

23.07.2013 08:46, Stefan Weil wrote:
> This was dead code.

Thanks, applied to the trivial patches queue.

/mjt

Re: [Qemu-devel] [Qemu-trivial] [PATCH] exec: Remove env from list of poisoned names

[Michael Tokarev]

21.07.2013 18:43, Stefan Weil wrote:
> The global variable env was removed some time ago, so this name may be
> used without any restriction now.

Thanks, applied to the trivial patches queue.

/mjt

Re: [Qemu-devel] [PATCH 03/16] vl: convert -m to qemu_opts_parse()

[Paolo Bonzini]

Il 23/07/2013 18:22, Igor Mammedov ha scritto:
> Signed-off-by: Igor Mammedov 
> ---
>  qemu-options.hx |9 +++--
>  vl.c|   53 +++--
>  2 files changed, 54 insertions(+), 8 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 137a39b..f799b3d 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -210,8 +210,13 @@ use is discouraged as it may be removed from future 
> versions.
>  ETEXI
>  
>  DEF("m", HAS_ARG, QEMU_OPTION_m,
> -"-m megs set virtual RAM size to megs MB [default="
> -stringify(DEFAULT_RAM_SIZE) "]\n", QEMU_ARCH_ALL)
> +"-m [mem=]megs[,slots=n,maxmem=size]\n"
> +"set virtual RAM size to megs MB [default="
> +stringify(DEFAULT_RAM_SIZE) "]\n"
> +"mem=start-up memory amount\n"
> +"slots=maximum number of hotplug slots\n"
> +"maxmem=maximum total amount of memory\n",
> +QEMU_ARCH_ALL)
>  STEXI
>  @item -m @var{megs}
>  @findex -m
> diff --git a/vl.c b/vl.c
> index bf0c658..16c6f1e 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -516,6 +516,27 @@ static QemuOptsList qemu_realtime_opts = {
>  },
>  };
>  
> +static QemuOptsList qemu_mem_opts = {
> +.name = "memory-opts",
> +.implied_opt_name = "mem",
> +.head = QTAILQ_HEAD_INITIALIZER(qemu_mem_opts.head),

This should have

.merge_lists = true,

Paolo

> +.desc = {
> +{
> +.name = "mem",
> +.type = QEMU_OPT_SIZE,
> +},
> +{
> +.name = "slots",
> +.type = QEMU_OPT_NUMBER,
> +},
> +{
> +.name = "maxmem",
> +.type = QEMU_OPT_SIZE,
> +},
> +{ /* end of list */ }
> +},
> +};
> +
>  const char *qemu_get_vm_name(void)
>  {
>  return qemu_name;
> @@ -2933,6 +2954,7 @@ int main(int argc, char **argv, char **envp)
>  qemu_add_opts(&qemu_object_opts);
>  qemu_add_opts(&qemu_tpmdev_opts);
>  qemu_add_opts(&qemu_realtime_opts);
> +qemu_add_opts(&qemu_mem_opts);
>  
>  runstate_init();
>  
> @@ -3224,21 +3246,40 @@ int main(int argc, char **argv, char **envp)
>  exit(0);
>  break;
>  case QEMU_OPTION_m: {
> -int64_t value;
>  uint64_t sz;
> -char *end;
> +const char *end;
> +char *s;
>  
> -value = strtosz(optarg, &end);
> -if (value < 0 || *end) {
> -fprintf(stderr, "qemu: invalid ram size: %s\n", optarg);
> +opts = qemu_opts_parse(qemu_find_opts("memory-opts"),
> +   optarg, 1);
> +if (!opts) {
>  exit(1);
>  }
> -sz = QEMU_ALIGN_UP((uint64_t)value, 8192);
> +
> +/* fixup legacy sugffix-less format */
> +end = qemu_opt_get(opts, "mem");
> +if (g_ascii_isdigit(end[strlen(end) - 1])) {
> +s = g_strconcat(end, "M", NULL);
> +qemu_opt_set(opts, "mem", s);
> +g_free(s);
> +}
> +
> +sz = QEMU_ALIGN_UP(qemu_opt_get_size(opts, "mem", 0), 8192);
>  ram_size = sz;
>  if (ram_size != sz) {
>  fprintf(stderr, "qemu: ram size too large\n");
>  exit(1);
>  }
> +/* store aligned value for future use */
> +s = g_strdup_printf("%" PRIu64, sz);
> +qemu_opt_set(opts, "mem", s);
> +g_free(s);
> +
> +sz = qemu_opt_get_size(opts, "maxmem", ram_size);
> +if (sz < ram_size) {
> +fprintf(stderr, "qemu: maxmem must be > initial 
> memory\n");
> +exit(1);
> +}
>  break;
>  }
>  #ifdef CONFIG_TPM
> 

Re: [Qemu-devel] [PATCH 10/16] dimm: add busy slot check and slot auto-allocation

[Paolo Bonzini]

Il 23/07/2013 18:23, Igor Mammedov ha scritto:
> - if slot property is not specified on -device/device_add command,
> treat default value as request for assigning DimmDevice to
> the first free slot.

Even with "-m" instead of "-numa mem", I think this is problematic
because we still need to separate the host and guest parts of the DIMM
device.  "-numa mem" (or the QMP command that Wanlong added) will be
necessary to allocate memory on the host side before adding a DIMM.

So slots will have three states: free (created with "-m"), allocated (a
free slot moves to this state with "-numa mem...,populated=no" when
migrating, or with the QMP command for regular hotplug), populated (an
allocated slot moves to this state with "-device dimm").

You would be able to plug a DIMM only into an allocated slot, and the
size will be specified on the slot rather than the DIMM device.

In general, I don't think free slots should be managed by the DimmBus,
and host vs. guest separation should be there even if we accept your
"-m" extension (doesn't look bad at all, I must say).

Paolo

Re: [Qemu-devel] [Qemu-trivial] [PATCH] hw/9pfs: Fix potential memory leak and avoid reuse of freed memory

[Michael Tokarev]

19.07.2013 23:11, Stefan Weil wrote:
> Am 04.07.2013 10:53, schrieb M. Mohan Kumar:
>> Stefan Weil  writes:
>>
>>> The leak was reported by cppcheck.
>>>
>>> Function proxy_init also calls g_free for ctx->fs_root.
>>> Avoid reuse of this memory by setting ctx->fs_root to NULL.
>>>
>>> Signed-off-by: Stefan Weil 
>> Reviewed-by: M. Mohan Kumar 

Thanks, applied to the trivial patches queue.

/mjt

[Qemu-devel] [PATCH] linux-user: correct argument number for sys_mremap and sys_splice

[Petar Jovanovic]

From: Petar Jovanovic 

sys_mremap missed 5th argument (new_address), which caused examples that
remap to a specific address to fail.
sys_splice missed 5th and 6th argument which caused different examples to
fail.
This change has an effect on MIPS target only.

Signed-off-by: Petar Jovanovic 
---
 linux-user/main.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index 99c3b3f..1c20229 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1957,7 +1957,7 @@ static const uint8_t mips_syscall_args[] = {
MIPS_SYS(sys_sched_get_priority_min, 1)
MIPS_SYS(sys_sched_rr_get_interval, 2)  /* 4165 */
MIPS_SYS(sys_nanosleep, 2)
-   MIPS_SYS(sys_mremap , 4)
+   MIPS_SYS(sys_mremap , 5)
MIPS_SYS(sys_accept , 3)
MIPS_SYS(sys_bind   , 3)
MIPS_SYS(sys_connect, 3)/* 4170 */
@@ -2094,7 +2094,7 @@ static const uint8_t mips_syscall_args[] = {
MIPS_SYS(sys_pselect6, 6)
MIPS_SYS(sys_ppoll, 5)
MIPS_SYS(sys_unshare, 1)
-   MIPS_SYS(sys_splice, 4)
+   MIPS_SYS(sys_splice, 6)
MIPS_SYS(sys_sync_file_range, 7) /* 4305 */
MIPS_SYS(sys_tee, 4)
MIPS_SYS(sys_vmsplice, 4)
-- 
1.7.9.5

[Qemu-devel] [PATCH 02/16] vl: set default ram_size during variable initialization

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 vl.c |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/vl.c b/vl.c
index 8190504..bf0c658 100644
--- a/vl.c
+++ b/vl.c
@@ -2947,7 +2947,7 @@ int main(int argc, char **argv, char **envp)
 module_call_init(MODULE_INIT_MACHINE);
 machine = find_default_machine();
 cpu_model = NULL;
-ram_size = 0;
+ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
 snapshot = 0;
 cyls = heads = secs = 0;
 translation = BIOS_ATA_TRANSLATION_AUTO;
@@ -4064,11 +4064,6 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 
-/* init the memory */
-if (ram_size == 0) {
-ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
-}
-
 if (qemu_opts_foreach(qemu_find_opts("device"), device_help_func, NULL, 0)
 != 0) {
 exit(0);
-- 
1.7.1

[Qemu-devel] [PATCH 15/16] pc: update acpi-dsdt.hex.generated and add ssdt-mem.hex.generated

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 hw/i386/acpi-dsdt.hex.generated |  633 ++-
 hw/i386/ssdt-mem.hex.generated  |  161 ++
 2 files changed, 785 insertions(+), 9 deletions(-)
 create mode 100644 hw/i386/ssdt-mem.hex.generated

diff --git a/hw/i386/acpi-dsdt.hex.generated b/hw/i386/acpi-dsdt.hex.generated
index 68cab3e..39fbe41 100644
--- a/hw/i386/acpi-dsdt.hex.generated
+++ b/hw/i386/acpi-dsdt.hex.generated
@@ -3,12 +3,12 @@ static unsigned char AcpiDsdtAmlCode[] = {
 0x53,
 0x44,
 0x54,
-0x37,
-0x11,
+0x9e,
+0x13,
 0x0,
 0x0,
 0x1,
-0xe1,
+0x5,
 0x42,
 0x58,
 0x50,
@@ -31,9 +31,9 @@ static unsigned char AcpiDsdtAmlCode[] = {
 0x4e,
 0x54,
 0x4c,
-0x28,
-0x5,
-0x10,
+0x23,
+0x1,
+0x9,
 0x20,
 0x10,
 0x49,
@@ -4248,8 +4248,613 @@ static unsigned char AcpiDsdtAmlCode[] = {
 0x75,
 0x60,
 0x10,
+0x4c,
+0x25,
+0x5f,
+0x53,
+0x42,
+0x5f,
+0x5b,
+0x80,
+0x48,
+0x50,
+0x4d,
+0x52,
+0x1,
+0xb,
+0x80,
+0xaf,
+0xa,
+0x18,
+0x5b,
+0x81,
+0x1f,
+0x48,
+0x50,
+0x4d,
+0x52,
+0x3,
+0x4d,
+0x52,
+0x42,
+0x4c,
+0x20,
+0x4d,
+0x52,
+0x42,
+0x48,
+0x20,
+0x4d,
+0x52,
+0x4c,
+0x4c,
+0x20,
+0x4d,
+0x52,
+0x4c,
+0x48,
+0x20,
+0x4d,
+0x50,
+0x58,
+0x5f,
+0x20,
+0x5b,
+0x81,
+0x1d,
+0x48,
+0x50,
+0x4d,
+0x52,
+0x1,
+0x0,
+0x40,
+0xa,
+0x4d,
+0x56,
+0x45,
+0x52,
+0x8,
+0x4d,
+0x45,
+0x53,
+0x5f,
+0x1,
+0x4d,
+0x49,
 0x4e,
-0x9,
+0x53,
+0x1,
+0x4d,
+0x52,
+0x4d,
+0x56,
+0x1,
+0x5b,
+0x1,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0x0,
+0x5b,
+0x81,
+0x15,
+0x48,
+0x50,
+0x4d,
+0x52,
+0x3,
+0x4d,
+0x53,
+0x45,
+0x4c,
+0x20,
+0x4d,
+0x4f,
+0x45,
+0x56,
+0x20,
+0x4d,
+0x4f,
+0x53,
+0x43,
+0x20,
+0x14,
+0x4f,
+0x4,
+0x4d,
+0x45,
+0x53,
+0x43,
+0x0,
+0x70,
+0x0,
+0x60,
+0x5b,
+0x23,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xff,
+0xff,
+0xa2,
+0x34,
+0x95,
+0x60,
+0x4d,
+0x44,
+0x4e,
+0x52,
+0x70,
+0x60,
+0x4d,
+0x53,
+0x45,
+0x4c,
+0xa0,
+0x13,
+0x93,
+0x4d,
+0x49,
+0x4e,
+0x53,
+0x1,
+0x4d,
+0x54,
+0x46,
+0x59,
+0x60,
+0x1,
+0x70,
+0x1,
+0x4d,
+0x49,
+0x4e,
+0x53,
+0xa0,
+0xe,
+0x93,
+0x4d,
+0x52,
+0x4d,
+0x56,
+0x1,
+0x4d,
+0x54,
+0x46,
+0x59,
+0x60,
+0xa,
+0x3,
+0x72,
+0x60,
+0x1,
+0x60,
+0x5b,
+0x27,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xa4,
+0x1,
+0x14,
+0x2d,
+0x4d,
+0x52,
+0x53,
+0x54,
+0x1,
+0x70,
+0x0,
+0x60,
+0x5b,
+0x23,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xff,
+0xff,
+0x70,
+0x99,
+0x68,
+0x0,
+0x4d,
+0x53,
+0x45,
+0x4c,
+0xa0,
+0xb,
+0x93,
+0x4d,
+0x45,
+0x53,
+0x5f,
+0x1,
+0x70,
+0xa,
+0xf,
+0x60,
+0x5b,
+0x27,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xa4,
+0x60,
+0x14,
+0x4f,
+0x11,
+0x4d,
+0x43,
+0x52,
+0x53,
+0x1,
+0x5b,
+0x23,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xff,
+0xff,
+0x70,
+0x99,
+0x68,
+0x0,
+0x4d,
+0x53,
+0x45,
+0x4c,
+0x8,
+0x4d,
+0x52,
+0x36,
+0x34,
+0x11,
+0x33,
+0xa,
+0x30,
+0x8a,
+0x2b,
+0x0,
+0x0,
+0xc,
+0x3,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0xfe,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0x0,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0xff,
+0x79,
+0x0,
+0x8a,
+0x4d,
+0x52,
+0x36,
+0x34,
+0xa,
+0xe,
+0x4d,
+0x49,
+0x4e,
+0x4c,
+0x8a,
+0x4d,
+0x52,
+0x36,
+0x34,
+0xa,
+0x12,
+0x4d,
+0x49,
+0x4e,
+0x48,
+0x8a,
+0x4d,
+0x52,
+0x36,
+0x34,
+0xa,
+0x26,
+0x4c,
+0x45,
+0x4e,
+0x4c,
+0x8a,
+0x4d,
+0x52,
+0x36,
+0x34,
+0xa,
+0x2a,
+0x4c,
+0x45,
+0x4e,
+0x48,
+0x8a,
+0x4d,
+0x52,
+0x36,
+0x34,
+0xa,
+0x16,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x8a,
+0x4d,
+0x52,
+0x36,
+0x34,
+0xa,
+0x1a,
+0x4d,
+0x41,
+0x58,
+0x48,
+0x70,
+0x4d,
+0x52,
+0x42,
+0x48,
+0x4d,
+0x49,
+0x4e,
+0x48,
+0x70,
+0x4d,
+0x52,
+0x42,
+0x4c,
+0x4d,
+0x49,
+0x4e,
+0x4c,
+0x70,
+0x4d,
+0x52,
+0x4c,
+0x48,
+0x4c,
+0x45,
+0x4e,
+0x48,
+0x70,
+0x4d,
+0x52,
+0x4c,
+0x4c,
+0x4c,
+0x45,
+0x4e,
+0x4c,
+0x72,
+0x4d,
+0x49,
+0x4e,
+0x4c,
+0x4c,
+0x45,
+0x4e,
+0x4c,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x72,
+0x4d,
+0x49,
+0x4e,
+0x48,
+0x4c,
+0x45,
+0x4e,
+0x48,
+0x4d,
+0x41,
+0x58,
+0x48,
+0xa0,
+0x1f,
+0x7d,
+0x95,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x4d,
+0x49,
+0x4e,
+0x4c,
+0x95,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x4c,
+0x45,
+0x4e,
+0x4c,
+0x0,
+0x72,
+0x4d,
+0x41,
+0x58,
+0x48,
+0x1,
+0x4d,
+0x41,
+0x58,
+0x48,
+0xa0,
+0x17,
+0x93,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x0,
+0x74,
+0x4d,
+0x41,
+0x58,
+0x48,
+0x1,
+0x4d,
+0x41,
+0x58,
+0x48,
+0x70,
+0xff,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0xa1,
+0xb,
+0x74,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x1,
+0x4d,
+0x41,
+0x58,
+0x4c,
+0x5b,
+0x27,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xa4,
+0x4d,
+0x52,
+0x36,
+0x34,
+0x14,
+0x24,
+0x4d,
+0x50,
+0x58,
+0x4d,
+0x1,
+0x5b,
+0x23,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xff,
+0xff,
+0x70,
+0x99,
+0x68,
+0x0,
+0x4d,
+0x53,
+0x45,
+0x4c,
+0x70,
+0x4d,
+0x50,
+0x58,
+0x5f,
+0x60,
+0x5b,
+0x27,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xa4,
+0x60,
+0x14,
+0x28,
+0x4d,
+0x4f,
+0x53,
+0x54,
+0x4,
+0x5b,
+0x23,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0xff,
+0xff,
+0x70,
+0x99,
+0x68,
+0x0,
+0x4d,
+0x53,
+0x45,
+0x4c,
+0x70,
+0x69,
+0x4d,
+0x4f,
+0x45,
+0x56,
+0x70,
+0x6a,
+0x4d,
+0x4f,
+0x53,
+0x43,
+0x5b,
+0x27,
+0x4d,
+0x4c,
+0x43,
+0x4b,
+0

[Qemu-devel] [PULL 09/21] linux-user: Add missing 'break' in i386 get_thread_area syscall

[riku . voipio]

From: Peter Maydell 

The i386 code for the get_thread_area syscall was missing a
'break' which meant it would have fallen through into the
implementation of the following syscall; add it.

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Signed-off-by: Riku Voipio 
---
 linux-user/syscall.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9619656..642d0a3 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -8572,6 +8572,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 case TARGET_NR_get_thread_area:
 #if defined(TARGET_I386) && defined(TARGET_ABI32)
 ret = do_get_thread_area(cpu_env, arg1);
+break;
 #elif defined(TARGET_M68K)
 {
 TaskState *ts = ((CPUArchState *)cpu_env)->opaque;
-- 
1.8.1.2

[Qemu-devel] [PULL 20/21] linux-user: Unlock mmap_lock when resuming guest from page_unprotect

[riku . voipio]

From: Alexander Graf 

The page_unprotect() function is running everything locked. Before every
potential exit path of the function mmap_unlock() gets called to make sure
we don't leak the lock.

However, the function calls tb_invalidate_phys_page() which again can
exit a signal through longjmp, leaving our mmap_unlock() attempts in vain.

Add a hint to tb_invalidate_phys_page() that we need to unlock before we
can leave back into guest context, so that we don't leak the lock.

This fixes 16-bit i386 wine programs running in linux-user for me.

Signed-off-by: Alexander Graf 
Signed-off-by: Riku Voipio 
---
 translate-all.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/translate-all.c b/translate-all.c
index e8683d2..3b5fc7c 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -1148,7 +1148,8 @@ void tb_invalidate_phys_page_fast(tb_page_addr_t start, 
int len)
 
 #if !defined(CONFIG_SOFTMMU)
 static void tb_invalidate_phys_page(tb_page_addr_t addr,
-uintptr_t pc, void *puc)
+uintptr_t pc, void *puc,
+bool locked)
 {
 TranslationBlock *tb;
 PageDesc *p;
@@ -1206,6 +1207,9 @@ static void tb_invalidate_phys_page(tb_page_addr_t addr,
itself */
 cpu->current_tb = NULL;
 tb_gen_code(env, current_pc, current_cs_base, current_flags, 1);
+if (locked) {
+mmap_unlock();
+}
 cpu_resume_from_signal(env, puc);
 }
 #endif
@@ -1723,7 +1727,7 @@ void page_set_flags(target_ulong start, target_ulong end, 
int flags)
 if (!(p->flags & PAGE_WRITE) &&
 (flags & PAGE_WRITE) &&
 p->first_tb) {
-tb_invalidate_phys_page(addr, 0, NULL);
+tb_invalidate_phys_page(addr, 0, NULL, false);
 }
 p->flags = flags;
 }
@@ -1818,7 +1822,7 @@ int page_unprotect(target_ulong address, uintptr_t pc, 
void *puc)
 
 /* and since the content will be modified, we must invalidate
the corresponding translated code. */
-tb_invalidate_phys_page(addr, pc, puc);
+tb_invalidate_phys_page(addr, pc, puc, true);
 #ifdef DEBUG_TB_CHECK
 tb_invalidate_check(addr);
 #endif
-- 
1.8.1.2

[Qemu-devel] [PATCH V3 for-1.6 4/5] block: Add iops_sector_count to do the iops accounting for a given io size.

[Benoît Canet]

This feature can be used in case where users are avoiding the iops limit by
doing jumbo I/Os hammering the storage backend.

Signed-off-by: Benoit Canet 
---
 block.c   |8 +++-
 block/qapi.c  |4 
 blockdev.c|   22 +-
 hmp.c |8 ++--
 include/block/block_int.h |1 +
 qapi-schema.json  |   10 --
 qemu-options.hx   |2 +-
 qmp-commands.hx   |8 ++--
 8 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/block.c b/block.c
index f1cd9c0..bb4f8e4 100644
--- a/block.c
+++ b/block.c
@@ -368,6 +368,12 @@ static bool 
bdrv_is_any_threshold_exceeded(BlockDriverState *bs, int nb_sectors,
bool is_write)
 {
 bool bps_ret, iops_ret;
+double   ios = 1.0;
+
+if (bs->io_limits.iops_sector_count) {
+ios = ((double) nb_sectors) / bs->io_limits.iops_sector_count;
+ios = MAX(ios, 1.0);
+}
 
 /* check if any bandwith or per IO threshold has been exceeded */
 bps_ret = bdrv_is_bps_threshold_exceeded(bs, is_write);
@@ -391,7 +397,7 @@ static bool bdrv_is_any_threshold_exceeded(BlockDriverState 
*bs, int nb_sectors,
 /* the IO is authorized so do the accounting and return false */
 bs->leaky_buckets.bytes[is_write] += (int64_t)nb_sectors *
  BDRV_SECTOR_SIZE;
-bs->leaky_buckets.ios[is_write]++;
+bs->leaky_buckets.ios[is_write] += ios;
 
 return false;
 }
diff --git a/block/qapi.c b/block/qapi.c
index 03f1604..f81081c 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -259,6 +259,10 @@ void bdrv_query_info(BlockDriverState *bs,
bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_WRITE];
 info->inserted->iops_wr_threshold =
bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_WRITE];
+info->inserted->has_iops_sector_count =
+   bs->io_limits.iops_sector_count;
+info->inserted->iops_sector_count =
+   bs->io_limits.iops_sector_count;
 }
 
 bs0 = bs;
diff --git a/blockdev.c b/blockdev.c
index 241ebe8..d56e8a1 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -352,6 +352,11 @@ static bool do_check_io_limits(BlockIOLimit *io_limits, 
Error **errp)
 return false;
 }
 
+if (io_limits->iops_sector_count < 0) {
+error_setg(errp, "iops_sector_count must be 0 or greater");
+return false;
+}
+
 return true;
 }
 
@@ -563,6 +568,10 @@ DriveInfo *drive_init(QemuOpts *all_opts, 
BlockInterfaceType block_default_type)
 qemu_opt_get_number(opts, "iops_wr_threshold",
 io_limits.iops[BLOCK_IO_LIMIT_WRITE] / 
THROTTLE_HZ);
 
+io_limits.iops_sector_count =
+   qemu_opt_get_number(opts, "iops_sector_count", 0);
+ 
+
 if (!do_check_io_limits(&io_limits, &error)) {
 error_report("%s", error_get_pretty(error));
 error_free(error);
@@ -1260,7 +1269,9 @@ void qmp_block_set_io_throttle(const char *device, 
int64_t bps, int64_t bps_rd,
bool has_iops_rd_threshold,
int64_t iops_rd_threshold,
bool has_iops_wr_threshold,
-   int64_t iops_wr_threshold, Error **errp)
+   int64_t iops_wr_threshold,
+   bool has_iops_sector_count,
+   int64_t iops_sector_count, Error **errp)
 {
 BlockIOLimit io_limits;
 BlockDriverState *bs;
@@ -1283,6 +1294,7 @@ void qmp_block_set_io_throttle(const char *device, 
int64_t bps, int64_t bps_rd,
 io_limits.iops_threshold[BLOCK_IO_LIMIT_TOTAL] = iops / THROTTLE_HZ;
 io_limits.iops_threshold[BLOCK_IO_LIMIT_READ]  = iops_rd / THROTTLE_HZ;
 io_limits.iops_threshold[BLOCK_IO_LIMIT_WRITE] = iops_wr / THROTTLE_HZ;
+io_limits.iops_sector_count = 0;
 
 /* override them with givens values if present */
 if (has_bps_threshold) {
@@ -1304,6 +1316,10 @@ void qmp_block_set_io_throttle(const char *device, 
int64_t bps, int64_t bps_rd,
 io_limits.iops_threshold[BLOCK_IO_LIMIT_WRITE] = iops_wr_threshold;
 }
 
+if (has_iops_sector_count) {
+io_limits.iops_sector_count = iops_sector_count;
+}
+
 if (!do_check_io_limits(&io_limits, errp)) {
 return;
 }
@@ -2007,6 +2023,10 @@ QemuOptsList qemu_common_drive_opts = {
 .type = QEMU_OPT_NUMBER,
 .help = "write bytes threshold",
 },{
+.name = "iops_sector_count",
+.type = QEMU_OPT_NUMBER,
+.help = "when limiting by iops max size of an I/O in sector",
+},{
 .name = "copy-on-read",
 .type = QEMU_OPT_BOOL,
 .help = "copy read data from backing file into image file",
diff --git a/h

[Qemu-devel] [PATCH V3 for-1.6 5/5] block: Add throttling percentage metrics.

[Benoît Canet]

This metrics show how many percent of the time I/Os are put on hold by the
throttling algorithm.
This metric could be used by system administrators or cloud stack developpers
to decide when the throttling settings must be changed.

Signed-off-by: Benoit Canet 
---
 block.c   |   27 ++-
 block/qapi.c  |4 
 hmp.c |6 --
 include/block/block_int.h |2 ++
 qapi-schema.json  |4 +++-
 5 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/block.c b/block.c
index bb4f8e4..6bb8570 100644
--- a/block.c
+++ b/block.c
@@ -118,12 +118,21 @@ int is_windows_drive(const char *filename)
 #endif
 
 /* throttling disk I/O limits */
+static void bdrv_reset_throttling_metrics(BlockDriverState *bs)
+{
+/* iddle -> reset values */
+bs->throttling_percentage = 0;
+bs->full_since = 0;
+}
+
 void bdrv_io_limits_disable(BlockDriverState *bs)
 {
 bs->io_limits_enabled = false;
 
 while (qemu_co_enter_next(&bs->throttled_reqs)) {
 }
+
+bdrv_reset_throttling_metrics(bs);
 }
 
 static void bdrv_make_bps_buckets_leak(BlockDriverState *bs, int64_t delta)
@@ -213,7 +222,8 @@ static void bdrv_make_iops_buckets_leak(BlockDriverState 
*bs, int64_t delta)
 static void bdrv_leak_if_needed(BlockDriverState *bs)
 {
 int64_t now;
-int64_t delta;
+int64_t delta; /* the delta that would be ideally the timer period */
+int64_t delta_full; /* the delta where the bucket is full */
 
 if (!bs->must_leak) {
 return;
@@ -223,6 +233,14 @@ static void bdrv_leak_if_needed(BlockDriverState *bs)
 
 now = qemu_get_clock_ns(rt_clock);
 delta = now - bs->previous_leak;
+/* compute throttle percentage reflecting how long IO are hold on average 
*/
+if (bs->full_since) {
+delta_full = now - bs->full_since;
+bs->throttling_percentage = (delta_full * 100) / delta;
+bs->full_since = 0;
+} else {
+bs->throttling_percentage = 0;
+}
 bs->previous_leak = now;
 
 bdrv_make_bps_buckets_leak(bs, delta);
@@ -260,6 +278,7 @@ static void bdrv_block_timer(void *opaque)
 /* disable throttling time on iddle for economy purpose */
 if (bdrv_throttling_is_iddle(bs)) {
 bdrv_block_timer_disable(bs);
+bdrv_reset_throttling_metrics(bs);
 return;
 }
 
@@ -280,6 +299,7 @@ static void bdrv_block_timer_enable(BlockDriverState *bs)
 
 bs->block_timer = qemu_new_timer_ns(vm_clock, bdrv_block_timer, bs);
 bs->previous_leak = qemu_get_clock_ns(rt_clock);
+bdrv_reset_throttling_metrics(bs);
 qemu_mod_timer(bs->block_timer,
qemu_get_clock_ns(vm_clock) +
BLOCK_IO_THROTTLE_PERIOD);
@@ -432,6 +452,11 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
  * not full
  */
 while (bdrv_is_any_threshold_exceeded(bs, nb_sectors, is_write)) {
+/* remember since when the code decided to block the first I/O */
+if (qemu_co_queue_empty(&bs->throttled_reqs)) {
+bs->full_since = qemu_get_clock_ns(rt_clock);
+}
+
 bdrv_leak_if_needed(bs);
 qemu_co_queue_wait_insert_head(&bs->throttled_reqs);
 bdrv_leak_if_needed(bs);
diff --git a/block/qapi.c b/block/qapi.c
index f81081c..bd1c6af 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -263,6 +263,10 @@ void bdrv_query_info(BlockDriverState *bs,
bs->io_limits.iops_sector_count;
 info->inserted->iops_sector_count =
bs->io_limits.iops_sector_count;
+info->inserted->has_throttling_percentage =
+   bs->throttling_percentage;
+info->inserted->throttling_percentage =
+   bs->throttling_percentage;
 }
 
 bs0 = bs;
diff --git a/hmp.c b/hmp.c
index 3912305..9dc4862 100644
--- a/hmp.c
+++ b/hmp.c
@@ -348,7 +348,8 @@ void hmp_info_block(Monitor *mon, const QDict *qdict)
 " iops_threshold=%" PRId64
 " iops_rd_threshold=%" PRId64
 " iops_wr_threshold=%" PRId64
-" iops_sector_count=%" PRId64 "\n",
+" iops_sector_count=%" PRId64
+" throttling_percentage=%" PRId64 "\n",
 info->value->inserted->bps,
 info->value->inserted->bps_rd,
 info->value->inserted->bps_wr,
@@ -361,7 +362,8 @@ void hmp_info_block(Monitor *mon, const QDict *qdict)
 info->value->inserted->iops_threshold,
 info->value->inserted->iops_rd_threshold,
 info->value->inserted->iops_wr_threshold,
-info->value->inserted->iops_sector_count);
+info->value->inserted->iops_sector_count,
+  

[Qemu-devel] KVM call minutes for 2013-07-23

[Juan Quintela]

- Or how to confuse dates: I am very good at it (quintela)
  Sorry again.

- Organizational trivia: We are changing the call number details
  If you don't receive an invite in the following days,  let me now.

- s390: has different reset interfaces
  (only cpus,  also memory,  some devices)
  They need to reset some specific subsystems and not others (or the
  other way around, reset everything except ...)

  In x86: soft reset: reset only the cpu, not the devices (keyboard
  controller reset).  Reset at top level resets everything.  And you
  can reset things a subsystem (for instance pci) with qdev.  So the
  infrastructure should be there.

  In some platforms they need to regenerate the device tree after
  reset, so there is a reset_hook() for stuff like that.

  How to reset all devices except CPU?

  What event should we generate for each reset type?

  We can use qdev_reset() to behave as we want.  What to do with non qdev 
devices?

  Write to one register in the ppc machine.

[Qemu-devel] KVM call agenda for 2013-08-06

[Juan Quintela]

Hi

Please, send any topic that you are interested in covering.

Thanks, Juan.

PD.  If you want to attend and you don't have the call details,
  contact me.

PD2. Remember that conference code has changed,  contact me if you don't
 receive the details.

[Qemu-devel] [PATCH V3 for-1.6 2/5] block: Modify the throttling code to implement the leaky bucket algorithm.

[Benoît Canet]

This patch replace the previous algorithm by the well described leaky bucket
algorithm: A bucket is filled by the incoming IOs and a periodic timer decrement
the counter to make the bucket leak. When a given threshold is reached the
bucket is full and the IOs are hold.

In this patch the threshold is set to a default value to make the code behave
like the previous implementation.

In the next patch the threshold will be exposed in QMP to let the user control
the burstiness of the throttling.

Signed-off-by: Benoit Canet 
---
 block.c   |  454 +++--
 blockdev.c|   71 +--
 include/block/block_int.h |   15 +-
 3 files changed, 339 insertions(+), 201 deletions(-)

diff --git a/block.c b/block.c
index dc72643..f1cd9c0 100644
--- a/block.c
+++ b/block.c
@@ -86,13 +86,6 @@ static void coroutine_fn bdrv_co_do_rw(void *opaque);
 static int coroutine_fn bdrv_co_do_write_zeroes(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors);
 
-static bool bdrv_exceed_bps_limits(BlockDriverState *bs, int nb_sectors,
-bool is_write, double elapsed_time, uint64_t *wait);
-static bool bdrv_exceed_iops_limits(BlockDriverState *bs, bool is_write,
-double elapsed_time, uint64_t *wait);
-static bool bdrv_exceed_io_limits(BlockDriverState *bs, int nb_sectors,
-bool is_write, int64_t *wait);
-
 static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
 QTAILQ_HEAD_INITIALIZER(bdrv_states);
 
@@ -101,6 +94,8 @@ static QLIST_HEAD(, BlockDriver) bdrv_drivers =
 
 /* If non-zero, use only whitelisted block drivers */
 static int use_bdrv_whitelist;
+/* boolean used to inform the throttling code that a bdrv_drain_all is issued 
*/
+static bool draining;
 
 #ifdef _WIN32
 static int is_windows_drive_prefix(const char *filename)
@@ -129,28 +124,170 @@ void bdrv_io_limits_disable(BlockDriverState *bs)
 
 while (qemu_co_enter_next(&bs->throttled_reqs)) {
 }
+}
 
-if (bs->block_timer) {
-qemu_del_timer(bs->block_timer);
-qemu_free_timer(bs->block_timer);
-bs->block_timer = NULL;
+static void bdrv_make_bps_buckets_leak(BlockDriverState *bs, int64_t delta)
+{
+int64_t *bytes = bs->leaky_buckets.bytes;
+int64_t read_leak, write_leak;
+
+/* the limit apply to both reads and writes */
+if (bs->io_limits.bps[BLOCK_IO_LIMIT_TOTAL]) {
+/* compute half the total leak */
+int64_t leak = ((bs->io_limits.bps[BLOCK_IO_LIMIT_TOTAL] * delta) /
+   NANOSECONDS_PER_SECOND);
+int remain = leak % 2;
+leak /= 2;
+
+/* the read bucket is smaller than half the quantity to leak so take
+ * care adding the leak difference to write leak
+ */
+if (bytes[BLOCK_IO_LIMIT_READ] <= leak) {
+read_leak = bytes[BLOCK_IO_LIMIT_READ];
+write_leak = 2 * leak + remain - bytes[BLOCK_IO_LIMIT_READ];
+/* symetric case */
+} else if (bytes[BLOCK_IO_LIMIT_WRITE] <= leak) {
+write_leak = bytes[BLOCK_IO_LIMIT_WRITE];
+read_leak = 2 * leak + remain - bytes[BLOCK_IO_LIMIT_WRITE];
+/* both bucket above leak count use half the total leak for both */
+} else {
+write_leak = leak;
+read_leak = leak + remain;
+}
+/* else we consider that limits are separated */
+} else {
+read_leak = (bs->io_limits.bps[BLOCK_IO_LIMIT_READ] * delta) /
+NANOSECONDS_PER_SECOND;
+write_leak = (bs->io_limits.bps[BLOCK_IO_LIMIT_WRITE] * delta) /
+ NANOSECONDS_PER_SECOND;
+}
+
+/* make the buckets leak */
+bytes[BLOCK_IO_LIMIT_READ]  = MAX(bytes[BLOCK_IO_LIMIT_READ] - read_leak,
+  0);
+bytes[BLOCK_IO_LIMIT_WRITE] = MAX(bytes[BLOCK_IO_LIMIT_WRITE] - write_leak,
+  0);
+}
+
+static void bdrv_make_iops_buckets_leak(BlockDriverState *bs, int64_t delta)
+{
+double *ios = bs->leaky_buckets.ios;
+int64_t read_leak, write_leak;
+
+/* the limit apply to both reads and writes */
+if (bs->io_limits.iops[BLOCK_IO_LIMIT_TOTAL]) {
+/* compute half the total leak */
+int64_t leak = ((bs->io_limits.iops[BLOCK_IO_LIMIT_TOTAL] * delta) /
+   NANOSECONDS_PER_SECOND);
+int remain = leak % 2;
+leak /= 2;
+
+/* the read bucket is smaller than half the quantity to leak so take
+ * care adding the leak difference to write leak
+ */
+if (ios[BLOCK_IO_LIMIT_READ] <= leak) {
+read_leak = ios[BLOCK_IO_LIMIT_READ];
+write_leak = 2 * leak + remain - ios[BLOCK_IO_LIMIT_READ];
+/* symetric case */
+} else if (ios[BLOCK_IO_LIMIT_WRITE] <= leak) {
+write_leak = ios[BLOCK_IO_LIMIT_WRITE];
+read_leak = 2 * leak + remain - ios[BLOCK_IO_LIMIT_WRITE];
+/* both bucket above leak count use ha

[Qemu-devel] [PATCH V3 for-1.6 0/5] Leaky bucket throttling and features

[Benoît Canet]

The first patch fixes the throttling which was broken by a previous commit.

The next patch replace the existing throttling algorithm by the well described
leaky bucket algorithm.

Third patch implement bursting by adding *_threshold parameters to
qmp_block_set_io_throttle.

The last one allow to define the max size of an io when throttling by iops via
iops_sector_count to avoid vm users cheating on the iops limit.

The last patch adds a metric reflecting how much the I/O are throttled.

since v1:
Add throttling percentage metric [Benoît]

since v2:
Enable timer only during I/O activity [Stefan]
Mark function as coroutine_fn [Stefan]
Guard these function checking they are in a coroutine [Stefan]
Use defines to access buckets [Stefan]
Fix typo [Stefan]
reset throttling metric on iddle [Benoît]
rename invalid to check_io_limit [Stefan]

Benoît Canet (5):
  block: Repair the throttling code.
  block: Modify the throttling code to implement the leaky bucket
algorithm.
  block: Add support for throttling burst threshold in QMP and the
command line.
  block: Add iops_sector_count to do the iops accounting for a given io
size.
  block: Add throttling percentage metrics.

 block.c   |  493 -
 block/qapi.c  |   32 +++
 blockdev.c|  174 ++--
 hmp.c |   38 +++-
 include/block/block_int.h |   18 +-
 include/block/coroutine.h |9 +-
 qapi-schema.json  |   42 +++-
 qemu-coroutine-lock.c |   20 +-
 qemu-options.hx   |2 +-
 qmp-commands.hx   |   34 +++-
 10 files changed, 642 insertions(+), 220 deletions(-)

-- 
1.7.10.4

Re: [Qemu-devel] [libvirt] [PATCH 6/7] qemu: Probe QEMU binary for host CPU

[Eric Blake]

[adding qemu]

On 07/23/2013 10:19 AM, Daniel P. Berrange wrote:
> On Tue, Jul 23, 2013 at 06:11:35PM +0200, Jiri Denemark wrote:
>> Since QEMU and kvm may filter some host CPU features or add efficiently
>> emulated features, asking QEMU binary for host CPU data provides
>> better results when we later use the data for building guest CPUs.
>> ---

>> +virCommandAddArg(cmd, "-machine");
>> +virCommandAddArgFormat(cmd, "%s,accel=kvm",
>> +   qemuCaps->machineTypes[0]);
>> +

> 
> 
> This code is causing us to invoke the QEMU binary multiple times,
> which is something we worked really hard to get away from. I really,
> really don't like this as an approach. QEMU needs to be able to
> give us the data we need here without multiple invocations.
> 
> eg, by allowing the monitor command to specify 'kvm' vs 'qemu'
> when asking for data, so you can interrogate it without having
> to re-launch it with different accel=XXX args.

We don't know if -machine accel=kvm is a valid option until after
issuing some QMP commands, but now we are forced to reinvoke a new qemu
with -machine accel=kvm enabled in order to get the query to give us
accurate answers.  I agree that this is less than desirable; hopefully
the qemu folks can help us figure out a solution, now that we are
bringing attention to the issue.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 16/16] pc: ACPI BIOS: reserve SRAT entry for hotplug mem hole

[Igor Mammedov]

Needed for Windows to use hotplugged memory device, otherwise
it complains that server is not configured for memory hotplug.
Tests shows that aftewards it uses dynamically provided
proximity value from _PXM() method.

Signed-off-by: Igor Mammedov 
---
 hw/i386/acpi-build.c |   31 +++
 1 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 7d7fa1f..69e8e68 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -477,15 +477,19 @@ build_hpet(GArray *table_data, GArray *linker)
  (void*)hpet, ACPI_HPET_SIGNATURE, sizeof(*hpet), 1);
 }
 
+#define SRAT_MEM_ENABLED 1
+#define SRAT_MEM_HOTPLUG 2
+
 static void
-acpi_build_srat_memory(AcpiSratMemoryAffinity *numamem,
-   uint64_t base, uint64_t len, int node, int enabled)
+acpi_build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
+   uint64_t len, int node, bool enabled, bool hotplug)
 {
 numamem->type = ACPI_SRAT_MEMORY;
 numamem->length = sizeof(*numamem);
 memset(numamem->proximity, 0, 4);
 numamem->proximity[0] = node;
-numamem->flags = cpu_to_le32(!!enabled);
+numamem->flags |= enabled ? cpu_to_le32(SRAT_MEM_ENABLED) : 0;
+numamem->flags |= hotplug ? cpu_to_le32(SRAT_MEM_HOTPLUG) : 0;
 numamem->base_addr = cpu_to_le64(base);
 numamem->range_length = cpu_to_le64(len);
 }
@@ -503,10 +507,13 @@ build_srat(GArray *table_data, GArray *linker,
 int srat_size;
 int slots;
 uint64_t mem_len, mem_base, next_base;
+uint64_t hotplug_mem_size = guest_info->hotplug_mem_win.end -
+guest_info->hotplug_mem_win.begin;
 
 srat_size = sizeof(*srat) +
 sizeof(AcpiSratProcessorAffinity) * guest_info->apic_id_limit +
-sizeof(AcpiSratMemoryAffinity) * (guest_info->numa_nodes + 2);
+sizeof(AcpiSratMemoryAffinity) * (guest_info->numa_nodes + 2 +
+(hotplug_mem_size ? 1 : 0));
 
 srat = acpi_data_push(table_data, srat_size);
 srat->reserved1 = cpu_to_le32(1);
@@ -535,7 +542,7 @@ build_srat(GArray *table_data, GArray *linker,
 slots = 0;
 next_base = 0;
 
-acpi_build_srat_memory(numamem, 0, 640*1024, 0, 1);
+acpi_build_srat_memory(numamem, 0, 640*1024, 0, true, false);
 next_base = 1024 * 1024;
 numamem++;
 slots++;
@@ -551,7 +558,8 @@ build_srat(GArray *table_data, GArray *linker,
 next_base > guest_info->ram_size) {
 mem_len -= next_base - guest_info->ram_size;
 if (mem_len > 0) {
-acpi_build_srat_memory(numamem, mem_base, mem_len, i-1, 1);
+acpi_build_srat_memory(numamem, mem_base, mem_len, i-1,
+   true, false);
 numamem++;
 slots++;
 }
@@ -559,15 +567,22 @@ build_srat(GArray *table_data, GArray *linker,
 mem_len = next_base - guest_info->ram_size;
 next_base += (1ULL << 32) - guest_info->ram_size;
 }
-acpi_build_srat_memory(numamem, mem_base, mem_len, i-1, 1);
+acpi_build_srat_memory(numamem, mem_base, mem_len, i-1, true, false);
 numamem++;
 slots++;
 }
+
 for (; slots < guest_info->numa_nodes + 2; slots++) {
-acpi_build_srat_memory(numamem, 0, 0, 0, 0);
+acpi_build_srat_memory(numamem, 0, 0, 0, false, false);
 numamem++;
 }
 
+/* allocate fake hotplug region upto maxmem for Windows */
+if (hotplug_mem_size) {
+acpi_build_srat_memory(numamem, guest_info->hotplug_mem_win.begin,
+   hotplug_mem_size, 0, true, true);
+}
+
 build_header(linker, table_data,
  (void*)srat, ACPI_SRAT_SIGNATURE, srat_size, 1);
 }
-- 
1.7.1

[Qemu-devel] [PATCH 14/16] pc: ACPI BIOS: implement memory hotplug interface

[Igor Mammedov]

- provides static DSDT object for memory hotplug
- SSDT template for memory devices and runtime generator
  of them in SSDT table.

Signed-off-by: Vasilis Liaskovitis 
Signed-off-by: Igor Mammedov 
---
 hw/i386/Makefile.objs |2 +-
 hw/i386/acpi-build.c  |   33 +
 hw/i386/acpi-dsdt-mem-hotplug.dsl |  144 +
 hw/i386/acpi-dsdt.dsl |5 +-
 hw/i386/ssdt-mem.dsl  |   76 +++
 5 files changed, 258 insertions(+), 2 deletions(-)
 create mode 100644 hw/i386/acpi-dsdt-mem-hotplug.dsl
 create mode 100644 hw/i386/ssdt-mem.dsl

diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 2ab2572..fa919e6 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -6,7 +6,7 @@ obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
 obj-y += kvmvapic.o
 obj-y += acpi-build.o
 obj-y += bios-linker-loader.o
-hw/i386/acpi-build.o: hw/i386/acpi-build.c hw/i386/acpi-dsdt.hex 
hw/i386/ssdt-proc.hex hw/i386/ssdt-pcihp.hex hw/i386/ssdt-misc.hex 
hw/i386/q35-acpi-dsdt.hex
+hw/i386/acpi-build.o: hw/i386/acpi-build.c hw/i386/acpi-dsdt.hex 
hw/i386/ssdt-proc.hex hw/i386/ssdt-pcihp.hex hw/i386/ssdt-misc.hex 
hw/i386/q35-acpi-dsdt.hex hw/i386/ssdt-mem.hex
 hw/i386/pc_piix.o: hw/i386/pc_piix.c hw/i386/acpi-dsdt.hex
 hw/i386/pc_q35.o: hw/i386/pc_q35.c hw/i386/q35-acpi-dsdt.hex
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index bc44f95..7d7fa1f 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -35,6 +35,7 @@
 #include "hw/nvram/fw_cfg.h"
 #include "hw/i386/bios-linker-loader.h"
 #include "hw/loader.h"
+#include "qemu/config-file.h"
 
 #define ACPI_BUILD_APPNAME  "Bochs"
 #define ACPI_BUILD_APPNAME6 "BOCHS "
@@ -267,6 +268,17 @@ acpi_encode_len(uint8_t *ssdt_ptr, int length, int bytes)
 #define ACPI_PCIHP_SIZEOF (*ssdt_pcihp_end - *ssdt_pcihp_start)
 #define ACPI_PCIHP_AML (ssdp_pcihp_aml + *ssdt_pcihp_start)
 
+#include "hw/i386/ssdt-mem.hex"
+
+/* 0x5B 0x82 DeviceOp PkgLength NameString DimmID */
+#define ACPI_MEM_AML (ssdm_mem_aml + *ssdt_mem_start)
+#define ACPI_MEM_SIZEOF (*ssdt_mem_end - *ssdt_mem_start)
+#define ACPI_MEM_OFFSET_HEX (*ssdt_mem_name - *ssdt_mem_start + 2)
+#define ACPI_MEM_OFFSET_ID (*ssdt_mem_id - *ssdt_mem_start + 7)
+#define ACPI_MEM_DEV_COUNT_OBJ (ssdm_mem_aml + *ssdt_mem_count_name - 1)
+#define ACPI_MEM_DEV_COUNT_OFFSET (*ssdt_mem_count - *ssdt_mem_count_name + 1)
+#define ACPI_MEM_DEV_COUNT_SIZE (*ssdt_mem_start - *ssdt_mem_count_name + 1)
+
 #define ACPI_SSDT_SIGNATURE 0x54445353 /* SSDT */
 #define ACPI_SSDT_HEADER_LENGTH 36
 
@@ -326,11 +338,16 @@ build_ssdt(GArray *table_data, GArray *linker,
FWCfgState *fw_cfg, PcGuestInfo *guest_info)
 {
 int acpi_cpus = MIN(0xff, guest_info->apic_id_limit);
+QemuOpts *opts = qemu_opts_find(qemu_find_opts("memory-opts"), NULL);
+uint32_t acpi_mem_devs = opts ? qemu_opt_get_number(opts, "slots", 0) : 0;
 int length = (sizeof(ssdp_misc_aml) /* _S3_ / _S4_ / 
_S5_ */
   + (1+3+4) /* Scope(_SB_) */
   + (acpi_cpus * ACPI_PROC_SIZEOF)   /* procs */
   + (1+2+5+(12*acpi_cpus))  /* NTFY */
   + (6+2+1+(1*acpi_cpus))   /* CPON */
+  + (1+2+5+(12*acpi_mem_devs))  /* MTFY */
+  + ACPI_MEM_DEV_COUNT_SIZE /* MDNR const */
+  + (acpi_mem_devs * ACPI_MEM_SIZEOF)   /* mem devices */
   + (1+3+4) /* Scope(PCI0) */
   + ((PCI_SLOT_MAX - 1) * ACPI_PCIHP_SIZEOF)/* slots */
   + (1+2+5+(12*(PCI_SLOT_MAX - 1;  /* PCNT */
@@ -407,6 +424,22 @@ build_ssdt(GArray *table_data, GArray *linker,
 for (i=0; ifound_cpus)) ? 0x01 : 0x00;
 
+/* set number of mem devices. i.e. declare Name(MDNR, nb_memdevs) */
+memcpy(ssdt_ptr, ACPI_MEM_DEV_COUNT_OBJ, ACPI_MEM_DEV_COUNT_SIZE);
+memcpy(ssdt_ptr + ACPI_MEM_DEV_COUNT_OFFSET, &acpi_mem_devs, 4);
+ssdt_ptr += ACPI_MEM_DEV_COUNT_SIZE;
+
+/* build mem devices and notifiers for them */
+for (i = 0; i < acpi_mem_devs; i++) {
+char id[5];
+snprintf(id, sizeof(id), "%02x", i);
+memcpy(ssdt_ptr, ACPI_MEM_AML, ACPI_MEM_SIZEOF);
+memcpy(ssdt_ptr + ACPI_MEM_OFFSET_HEX, id, 2);
+memcpy(ssdt_ptr + ACPI_MEM_OFFSET_ID, id, 2);
+ssdt_ptr += ACPI_MEM_SIZEOF;
+}
+ssdt_ptr = build_notify(ssdt_ptr, "MTFY", 0, acpi_mem_devs, "MP00", 2);
+
 /* build Scope(PCI0) opcode */
 *(ssdt_ptr++) = 0x10; /* ScopeOp */
 ssdt_ptr = acpi_encode_len(ssdt_ptr, length - (ssdt_ptr - ssdt), 3);
diff --git a/hw/i386/acpi-dsdt-mem-hotplug.dsl 
b/hw/i386/acpi-dsdt-mem-hotplug.dsl
new file mode 100644
index 000..3803edb
--- /dev/null
+++ b/hw/i386/acpi-dsdt-mem-hotplug.dsl
@@ -0,0 +1,144 @@
+/*

Re: [Qemu-devel] QCOW2 cryptography and secure key handling

[Daniel P. Berrange]

On Tue, Jul 23, 2013 at 05:22:47PM +0200, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Canet wrote:
> > > More generally, QCow2's current encryption support is woefully inadequate
> > > from a design POV. If we wanted better encryption built-in to QEMU it is
> > > best to just deprecate the current encryption support and define a new
> > > qcow2 extension based around something like the LUKS data format. Using
> > > the LUKS data format precisely would be good from a data portability
> > > POV, since then you can easily switch your images between LUKS encrypted
> > > block device & qcow2-with-luks image file, without needing to re-encrypt
> > > the data.
> > 
> > I read the LUKS specification and undestood enough part of it to understand 
> > the
> > potentials benefits (stronger encryption key, multiple user keys, 
> > possibility to
> > change users keys).
> > 
> > Kevin & Stefan: What do you think about implementing LUKS in QCOW2 ?
> 
> Using standard or proven approachs in crypto is a good thing.  I haven't
> looked at qcow2 encryption in the past because fairly few people
> actually use it.
> 
> One use-case I have heard about is qcow2 files over NFS.  The network
> and the storage system should not see guest data.  Only the host and the
> VM should see the data.

Yep, that is the core usecase. You are securing the system such that
only the VM host administrator/processes can compromise the data. It
is protected against malicious storage and/or network administrators.

> A big win with LUKS is that you can change the passphrase without
> re-encrypting the data.

Other benefits of LUKs are

 - Strong encryption key, even if the passphrase itself is weak
 - Support for multiple passphrases
 - Support for arbitrary different encryption algorithms / settings
 - Ability to detect whether the passphrase is correct or not rather
   than just decrypting to produce garbage

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

[Qemu-devel] [PATCH 12/16] dimm: introduce memory added notifier

[Igor Mammedov]

it will notify ACPI subsystem about added DimmDevice

Signed-off-by: Igor Mammedov 
---
 hw/mem-hotplug/dimm.c   |   13 +
 include/sysemu/sysemu.h |3 +++
 stubs/Makefile.objs |1 +
 stubs/memory_hotplug.c  |6 ++
 4 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 stubs/memory_hotplug.c

diff --git a/hw/mem-hotplug/dimm.c b/hw/mem-hotplug/dimm.c
index 7e3e383..4ecc590 100644
--- a/hw/mem-hotplug/dimm.c
+++ b/hw/mem-hotplug/dimm.c
@@ -22,6 +22,17 @@
 #include "qemu/config-file.h"
 #include "qemu/bitmap.h"
 #include "qemu/range.h"
+#include "qemu/notify.h"
+#include "sysemu/sysemu.h"
+
+/* Memory hot-plug notifiers */
+static NotifierList mem_added_notifiers =
+NOTIFIER_LIST_INITIALIZER(mem_added_notifiers);
+
+void qemu_register_mem_added_notifier(Notifier *notifier)
+{
+notifier_list_add(&mem_added_notifiers, notifier);
+}
 
 static void dimm_bus_initfn(Object *obj)
 {
@@ -204,6 +215,8 @@ static void dimm_realize(DeviceState *dev, Error **errp)
 
 g_assert(dc->register_memory);
 dc->register_memory(bus, dimm, errp);
+
+notifier_list_notify(&mem_added_notifiers, dev);
 }
 
 static void dimm_class_init(ObjectClass *klass, void *data)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 2fb71af..9abbf71 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -156,6 +156,9 @@ void drive_hot_add(Monitor *mon, const QDict *qdict);
 /* CPU hotplug */
 void qemu_register_cpu_added_notifier(Notifier *notifier);
 
+/* Memory hotplug */
+void qemu_register_mem_added_notifier(Notifier *notifier);
+
 /* pcie aer error injection */
 void pcie_aer_inject_error_print(Monitor *mon, const QObject *data);
 int do_pcie_aer_inject_error(Monitor *mon,
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index 9b701b4..2476c3d 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -25,3 +25,4 @@ stub-obj-y += vm-stop.o
 stub-obj-y += vmstate.o
 stub-obj-$(CONFIG_WIN32) += fd-register.o
 stub-obj-y += cpus.o
+stub-obj-y += memory_hotplug.o
diff --git a/stubs/memory_hotplug.c b/stubs/memory_hotplug.c
new file mode 100644
index 000..60844f1
--- /dev/null
+++ b/stubs/memory_hotplug.c
@@ -0,0 +1,6 @@
+#include "qemu/notify.h"
+#include "sysemu/sysemu.h"
+
+void qemu_register_mem_added_notifier(Notifier *notifier)
+{
+}
-- 
1.7.1

[Qemu-devel] [PATCH V3 for-1.6 3/5] block: Add support for throttling burst threshold in QMP and the command line.

[Benoît Canet]

The thresholds of the leaky bucket algorithm can be used to allow some
burstiness.

Signed-off-by: Benoit Canet 
---
 block/qapi.c |   24 +
 blockdev.c   |  105 +++---
 hmp.c|   32 +++--
 qapi-schema.json |   34 --
 qemu-options.hx  |2 +-
 qmp-commands.hx  |   30 ++--
 6 files changed, 205 insertions(+), 22 deletions(-)

diff --git a/block/qapi.c b/block/qapi.c
index a4bc411..03f1604 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -235,6 +235,30 @@ void bdrv_query_info(BlockDriverState *bs,
bs->io_limits.iops[BLOCK_IO_LIMIT_READ];
 info->inserted->iops_wr =
bs->io_limits.iops[BLOCK_IO_LIMIT_WRITE];
+info->inserted->has_bps_threshold =
+   bs->io_limits.bps_threshold[BLOCK_IO_LIMIT_TOTAL];
+info->inserted->bps_threshold =
+   bs->io_limits.bps_threshold[BLOCK_IO_LIMIT_TOTAL];
+info->inserted->has_bps_rd_threshold =
+   bs->io_limits.bps_threshold[BLOCK_IO_LIMIT_READ];
+info->inserted->bps_rd_threshold =
+   bs->io_limits.bps_threshold[BLOCK_IO_LIMIT_READ];
+info->inserted->has_bps_wr_threshold =
+   bs->io_limits.bps_threshold[BLOCK_IO_LIMIT_WRITE];
+info->inserted->bps_wr_threshold =
+   bs->io_limits.bps_threshold[BLOCK_IO_LIMIT_WRITE];
+info->inserted->has_iops_threshold =
+   bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_TOTAL];
+info->inserted->iops_threshold =
+   bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_TOTAL];
+info->inserted->iops_rd_threshold =
+   bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_READ];
+info->inserted->has_iops_rd_threshold =
+   bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_READ];
+info->inserted->has_iops_wr_threshold =
+   bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_WRITE];
+info->inserted->iops_wr_threshold =
+   bs->io_limits.iops_threshold[BLOCK_IO_LIMIT_WRITE];
 }
 
 bs0 = bs;
diff --git a/blockdev.c b/blockdev.c
index 491e4d0..241ebe8 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -341,6 +341,17 @@ static bool do_check_io_limits(BlockIOLimit *io_limits, 
Error **errp)
 return false;
 }
 
+if (io_limits->bps_threshold[BLOCK_IO_LIMIT_TOTAL] < 0 ||
+io_limits->bps_threshold[BLOCK_IO_LIMIT_WRITE] < 0 ||
+io_limits->bps_threshold[BLOCK_IO_LIMIT_READ] < 0 ||
+io_limits->iops_threshold[BLOCK_IO_LIMIT_TOTAL] < 0 ||
+io_limits->iops_threshold[BLOCK_IO_LIMIT_WRITE] < 0 ||
+io_limits->iops_threshold[BLOCK_IO_LIMIT_READ] < 0) {
+error_setg(errp,
+   "threshold values must be 0 or greater");
+return false;
+}
+
 return true;
 }
 
@@ -523,24 +534,34 @@ DriveInfo *drive_init(QemuOpts *all_opts, 
BlockInterfaceType block_default_type)
qemu_opt_get_number(opts, "bps_rd", 0);
 io_limits.bps[BLOCK_IO_LIMIT_WRITE]  =
qemu_opt_get_number(opts, "bps_wr", 0);
+/* bps thresholds */
+io_limits.bps_threshold[BLOCK_IO_LIMIT_TOTAL]  =
+qemu_opt_get_number(opts, "bps_threshold",
+io_limits.bps[BLOCK_IO_LIMIT_TOTAL] / THROTTLE_HZ);
+io_limits.bps_threshold[BLOCK_IO_LIMIT_READ]  =
+qemu_opt_get_number(opts, "bps_rd_threshold",
+io_limits.bps[BLOCK_IO_LIMIT_READ] / THROTTLE_HZ);
+io_limits.bps_threshold[BLOCK_IO_LIMIT_WRITE]  =
+qemu_opt_get_number(opts, "bps_wr_threshold",
+io_limits.bps[BLOCK_IO_LIMIT_WRITE] / THROTTLE_HZ);
+
 io_limits.iops[BLOCK_IO_LIMIT_TOTAL] =
qemu_opt_get_number(opts, "iops", 0);
 io_limits.iops[BLOCK_IO_LIMIT_READ]  =
qemu_opt_get_number(opts, "iops_rd", 0);
 io_limits.iops[BLOCK_IO_LIMIT_WRITE] =
qemu_opt_get_number(opts, "iops_wr", 0);
-io_limits.bps_threshold[BLOCK_IO_LIMIT_TOTAL] =
-   io_limits.bps[BLOCK_IO_LIMIT_TOTAL] / THROTTLE_HZ;
-io_limits.bps_threshold[BLOCK_IO_LIMIT_READ]  =
-   io_limits.bps[BLOCK_IO_LIMIT_READ] / THROTTLE_HZ;
-io_limits.bps_threshold[BLOCK_IO_LIMIT_WRITE] =
-   io_limits.bps[BLOCK_IO_LIMIT_WRITE] / THROTTLE_HZ;
-io_limits.iops_threshold[BLOCK_IO_LIMIT_TOTAL] =
-   io_limits.iops[BLOCK_IO_LIMIT_TOTAL] / THROTTLE_HZ;
+
+/* iops thresholds */
+io_limits.iops_threshold[BLOCK_IO_LIMIT_TOTAL]  =
+qemu_opt_get_number(opts, "iops_threshold",

[Qemu-devel] [PATCH V3 for-1.6 1/5] block: Repair the throttling code.

[Benoît Canet]

The throttling code was segfaulting since commit
02ffb504485f0920cfc75a0982a602f824a9a4f4 because some qemu_co_queue_next caller
does not run in a coroutine.
qemu_co_queue_do_restart assume that the caller is a coroutinne.
As suggested by Stefan fix this by entering the coroutine directly.
Also make sure like suggested that qemu_co_queue_next() and
qemu_co_queue_restart_all() can be called only in coroutines.

Signed-off-by: Benoit Canet 
---
 block.c   |8 
 include/block/coroutine.h |9 +++--
 qemu-coroutine-lock.c |   20 ++--
 3 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/block.c b/block.c
index b560241..dc72643 100644
--- a/block.c
+++ b/block.c
@@ -127,7 +127,8 @@ void bdrv_io_limits_disable(BlockDriverState *bs)
 {
 bs->io_limits_enabled = false;
 
-while (qemu_co_queue_next(&bs->throttled_reqs));
+while (qemu_co_enter_next(&bs->throttled_reqs)) {
+}
 
 if (bs->block_timer) {
 qemu_del_timer(bs->block_timer);
@@ -143,7 +144,7 @@ static void bdrv_block_timer(void *opaque)
 {
 BlockDriverState *bs = opaque;
 
-qemu_co_queue_next(&bs->throttled_reqs);
+qemu_co_enter_next(&bs->throttled_reqs);
 }
 
 void bdrv_io_limits_enable(BlockDriverState *bs)
@@ -1445,8 +1446,7 @@ void bdrv_drain_all(void)
  * a busy wait.
  */
 QTAILQ_FOREACH(bs, &bdrv_states, list) {
-if (!qemu_co_queue_empty(&bs->throttled_reqs)) {
-qemu_co_queue_restart_all(&bs->throttled_reqs);
+while (qemu_co_enter_next(&bs->throttled_reqs)) {
 busy = true;
 }
 }
diff --git a/include/block/coroutine.h b/include/block/coroutine.h
index 377805a..1f2db3e 100644
--- a/include/block/coroutine.h
+++ b/include/block/coroutine.h
@@ -130,12 +130,17 @@ void coroutine_fn qemu_co_queue_wait_insert_head(CoQueue 
*queue);
  *
  * Returns true if a coroutine was restarted, false if the queue is empty.
  */
-bool qemu_co_queue_next(CoQueue *queue);
+bool coroutine_fn qemu_co_queue_next(CoQueue *queue);
 
 /**
  * Restarts all coroutines in the CoQueue and leaves the queue empty.
  */
-void qemu_co_queue_restart_all(CoQueue *queue);
+void coroutine_fn qemu_co_queue_restart_all(CoQueue *queue);
+
+/**
+ * Enter the next coroutine in the queue
+ */
+bool qemu_co_enter_next(CoQueue *queue);
 
 /**
  * Checks if the CoQueue is empty.
diff --git a/qemu-coroutine-lock.c b/qemu-coroutine-lock.c
index d9fea49..aeb33b9 100644
--- a/qemu-coroutine-lock.c
+++ b/qemu-coroutine-lock.c
@@ -88,16 +88,32 @@ static bool qemu_co_queue_do_restart(CoQueue *queue, bool 
single)
 return true;
 }
 
-bool qemu_co_queue_next(CoQueue *queue)
+bool coroutine_fn qemu_co_queue_next(CoQueue *queue)
 {
+assert(qemu_in_coroutine());
 return qemu_co_queue_do_restart(queue, true);
 }
 
-void qemu_co_queue_restart_all(CoQueue *queue)
+void coroutine_fn qemu_co_queue_restart_all(CoQueue *queue)
 {
+assert(qemu_in_coroutine());
 qemu_co_queue_do_restart(queue, false);
 }
 
+bool qemu_co_enter_next(CoQueue *queue)
+{
+Coroutine *next;
+
+next = QTAILQ_FIRST(&queue->entries);
+if (!next) {
+return false;
+}
+
+QTAILQ_REMOVE(&queue->entries, next, co_queue_next);
+qemu_coroutine_enter(next, NULL);
+return true;
+}
+
 bool qemu_co_queue_empty(CoQueue *queue)
 {
 return (QTAILQ_FIRST(&queue->entries) == NULL);
-- 
1.7.10.4

[Qemu-devel] [PATCH 09/16] pc: i440fx: add DimmBus to chipset and map it into hotplug memory region

[Igor Mammedov]

it makes hot-plugged DimmDevices visible in guest address space.

Signed-off-by: Igor Mammedov 
---
 hw/pci-host/piix.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 26bb844..2ac7587 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -32,6 +32,7 @@
 #include "hw/xen/xen.h"
 #include "hw/pci-host/pam.h"
 #include "sysemu/sysemu.h"
+#include "hw/mem-hotplug/dimm.h"
 
 /*
  * I440FX chipset data sheet.
@@ -96,6 +97,7 @@ struct PCII440FXState {
 PAMMemoryRegion pam_regions[13];
 MemoryRegion smram_region;
 uint8_t smm_enabled;
+DimmBus dimm_bus;
 };
 
 
@@ -221,6 +223,8 @@ static int i440fx_initfn(PCIDevice *dev)
 d->dev.config[I440FX_SMRAM] = 0x02;
 
 cpu_smm_register(&i440fx_set_smm, d);
+
+qbus_create_inplace(&d->dimm_bus, TYPE_DIMM_BUS, DEVICE(d), "membus");
 return 0;
 }
 
@@ -244,6 +248,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
 PIIX3State *piix3;
 PCII440FXState *f;
 Range *pci_hole64 = &guest_info->pci_info.w64;
+Range *hotplug_mem = &guest_info->hotplug_mem_win;
 unsigned i;
 
 dev = qdev_create(NULL, "i440FX-pcihost");
@@ -260,6 +265,13 @@ static PCIBus *i440fx_common_init(const char *device_name,
 f->system_memory = address_space_mem;
 f->pci_address_space = pci_address_space;
 f->ram_memory = ram_memory;
+
+f->dimm_bus.base = hotplug_mem->begin;
+memory_region_init(&f->dimm_bus.as, "hotplug-memory",
+   hotplug_mem->end - hotplug_mem->begin);
+memory_region_add_subregion(f->system_memory, f->dimm_bus.base,
+&f->dimm_bus.as);
+
 memory_region_init_alias(&f->pci_hole, "pci-hole", f->pci_address_space,
  pci_hole_start, pci_hole_size);
 memory_region_add_subregion(f->system_memory, pci_hole_start, 
&f->pci_hole);
-- 
1.7.1