Re: [Qemu-devel] [PATCH v4 4/8] intel_iommu: redo configuraton check in realize

[Peter Xu]

On Wed, Oct 05, 2016 at 03:06:53PM +0200, Radim Krčmář wrote:
> * there no point in configuring the device if realization is going to
>   fail, so move the check to the beginning,
> * create a separate function for the check,
> * use error_setg() instead error_report().
> 
> Reviewed-by: Igor Mammedov 
> Signed-off-by: Radim Krčmář 

Reviewed-by: Peter Xu 

Re: [Qemu-devel] [PATCH v4 3/8] intel_iommu: pass whole remapped addresses to apic

[Peter Xu]

On Wed, Oct 05, 2016 at 03:06:52PM +0200, Radim Krčmář wrote:
> The MMIO interface to APIC only allowed 8 bit addresses, which is not
> enough for 32 bit addresses from EIM remapping.
> Intel stored upper 24 bits in the high MSI address, so use the same
> technique. The technique is also used in KVM MSI interface.
> Other APICs are unlikely to handle those upper bits.
> 
> Reviewed-by: Igor Mammedov 
> Signed-off-by: Radim Krčmář 

Again we are assuming MSIMessage as host endianess here.

If there is more spin for this one, maybe we can consider providing a
common function for:

apic_get_class()->send_msi(&msi);

And call it in the two places. But this one is good enough for me, so:

Reviewed-by: Peter Xu 

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH v4 2/8] apic: add send_msi() to APICCommonClass

[Peter Xu]

On Wed, Oct 05, 2016 at 03:06:51PM +0200, Radim Krčmář wrote:
> The MMIO based interface to APIC doesn't work well with MSIs that have
> upper address bits set (remapped x2APIC MSIs).  A specialized interface
> is a quick and dirty way to avoid the shortcoming.
> 
> Reviewed-by: Igor Mammedov 
> Signed-off-by: Radim Krčmář 

Reviewed-by: Peter Xu 

And...

> ---
> v4: r-b Igor
> v2: change apic_send_msi() to accept MSIMessage [Igor]
> ---
>  hw/i386/kvm/apic.c  | 19 +--
>  hw/i386/xen/xen_apic.c  |  6 ++
>  hw/intc/apic.c  |  8 ++--
>  include/hw/i386/apic_internal.h |  4 
>  4 files changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
> index c016e63fc2ba..be55102c00ca 100644
> --- a/hw/i386/kvm/apic.c
> +++ b/hw/i386/kvm/apic.c
> @@ -169,6 +169,17 @@ static void kvm_apic_external_nmi(APICCommonState *s)
>  run_on_cpu(CPU(s->cpu), do_inject_external_nmi, s);
>  }
>  
> +static void kvm_send_msi(MSIMessage *msg)
> +{
> +int ret;
> +
> +ret = kvm_irqchip_send_msi(kvm_state, *msg);
> +if (ret < 0) {
> +fprintf(stderr, "KVM: injection failed, MSI lost (%s)\n",
> +strerror(-ret));

Maybe use error_report() better? A nit not sufficient for a new spin
though.

And, this patch is assuming MSIMessage as host endianess (which is
good to me). Not sure whether we need fixes for the whole MSIMessage
cleanup (after all, kvm_irqchip_send_msi() is taking it as LE). Or we
can do it afterwards since it won't break anything AFAIU.

-- peterx

Re: [Qemu-devel] [PATCH v4 1/8] apic: add global apic_get_class()

[Peter Xu]

On Wed, Oct 05, 2016 at 03:06:50PM +0200, Radim Krčmář wrote:
> Every configuration has only up to one APIC class and we'll be extending
> the class with a function that can be called without an instanced
> object, so a direct access to the class is convenient.
> 
> This patch will break compilation if some code uses apic_get_class()
> with CONFIG_USER_ONLY.
> 
> Suggested-by: Eduardo Habkost 
> Signed-off-by: Radim Krčmář 

Reviewed-by: Peter Xu 

Re: [Qemu-devel] [PATCH v4 3/8] intel_iommu: pass whole remapped addresses to apic

[Peter Xu]

On Sat, Oct 08, 2016 at 02:14:09PM +0800, Peter Xu wrote:
> On Fri, Oct 07, 2016 at 06:24:15PM +0200, Radim Krčmář wrote:
> 
> [...]
> 
> > KVM accepts the address in host endianess and QEMU/VTD code also uses
> > host endianess for internal representation of memory addresses, so this
> > hunk should be fine.
> > 
> > It is confusing, because the VTD is definitely broken with respect to
> > endianess -- it is even trying to swap the order of bits in a byte in
> > the definition of VTD_MSIMessage.
> > I don't believe that dma_memory_write() accepted LE address on BE hosts,
> > so the existing code for filling the address is wrong:
> > 
> >   msg.__addr_head = cpu_to_le32(0xfee);
> 
> Yeah. This is my fault. Sorry for the troubles.
> 
> I have a patch (as well...) to fix this in my local tree, but not
> posted (as mst suggested). Maybe it's time to post some of them now (I
> tried to make patches more into a bunch so that they won't be lost in
> mailing list in case maintainer missed it).

I'll send them after your series to avoid unecessary conflicts.

-- peterx

Re: [Qemu-devel] [PATCH v4 3/8] intel_iommu: pass whole remapped addresses to apic

[Peter Xu]

On Fri, Oct 07, 2016 at 06:24:15PM +0200, Radim Krčmář wrote:

[...]

> KVM accepts the address in host endianess and QEMU/VTD code also uses
> host endianess for internal representation of memory addresses, so this
> hunk should be fine.
> 
> It is confusing, because the VTD is definitely broken with respect to
> endianess -- it is even trying to swap the order of bits in a byte in
> the definition of VTD_MSIMessage.
> I don't believe that dma_memory_write() accepted LE address on BE hosts,
> so the existing code for filling the address is wrong:
> 
>   msg.__addr_head = cpu_to_le32(0xfee);

Yeah. This is my fault. Sorry for the troubles.

I have a patch (as well...) to fix this in my local tree, but not
posted (as mst suggested). Maybe it's time to post some of them now (I
tried to make patches more into a bunch so that they won't be lost in
mailing list in case maintainer missed it). I agree that current code
is never tested on big endian machines yet.

Here it should be:

msg.__addr_head = 0xfee;

> 
> > should it be:
> >  msg.__addr_hi = cpu_to_le32(irq->dest & 0xff00)
> 
> I don't think so.
> 
> Howewer, there are endianess bugs in this patch:
> 
> >> @@ -2281,11 +2282,7 @@ static MemTxResult vtd_mem_ir_write(void *opaque, 
> >> hwaddr addr,
> >>  " for device sid 0x%04x",
> >>  to.address, to.data, sid);
> >>  
> >> -if (dma_memory_write(&address_space_memory, to.address,
> >> - &to.data, size)) {
> >> -VTD_DPRINTF(GENERAL, "error: fail to write 0x%"PRIx64
> >> -" value 0x%"PRIx32, to.address, to.data);
> >> -}
> >> +apic_get_class()->send_msi(&to);
> 
> because dma_memory_write() does magic on data.
> 
> I don't understand how the code should have worked before this series,
> because kvm_apic_mem_write() expects data in little endian and
> apic_mem_writel() expects data in host endian, even though both of them
> are DEVICE_NATIVE_ENDIAN and are called the same way, so one shouldn't
> work.

I guess that's because APIC is only used for x86? Then it does not
matter. And I agree with you that currently MSI is a little bit
confused on endianess.

First of all, I believe in the protocol MSI (along with PCI logics)
should be LE.

Instead, our MSIMessage struct looks more like to be for host
endianess. E.g. in msi_get_message() we are using:

msg.data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));

and pci_get_word() is converting LE to host endianess.

However, in all kvm_irqchip_*() APIs, we are assuming MSIMessage as
LE. E.g.:

int kvm_irqchip_send_msi(KVMState *s, MSIMessage msg)
{
struct kvm_msi msi;
KVMMSIRoute *route;

if (kvm_direct_msi_allowed) {
...
msi.data = le32_to_cpu(msg.data);
...
}
}

These things are conflicting.

Maybe we need to clean this up. And I prefer MSIMessage to be host
endianess.

> 
> And similarly, this hunk is wrong:
> 
> >> @@ -279,18 +280,17 @@ static void vtd_update_iotlb(IntelIOMMUState *s, 
> >> uint16_t source_id,
> >>  static void vtd_generate_interrupt(IntelIOMMUState *s, hwaddr 
> >> mesg_addr_reg,
> >> hwaddr mesg_data_reg)
> >>  {
> >> -hwaddr addr;
> >> -uint32_t data;
> >> +MSIMessage msi;
> >>  
> >>  assert(mesg_data_reg < DMAR_REG_SIZE);
> >>  assert(mesg_addr_reg < DMAR_REG_SIZE);
> >>  
> >> -addr = vtd_get_long_raw(s, mesg_addr_reg);
> >> -data = vtd_get_long_raw(s, mesg_data_reg);
> >> +msi.address = vtd_get_long_raw(s, mesg_addr_reg);
> >> +msi.data = vtd_get_long_raw(s, mesg_data_reg);
> >>  
> >> -VTD_DPRINTF(FLOG, "msi: addr 0x%"PRIx64 " data 0x%"PRIx32, addr, 
> >> data);
> >> -address_space_stl_le(&address_space_memory, addr, data,
> >> - MEMTXATTRS_UNSPECIFIED, NULL);
> >> +VTD_DPRINTF(FLOG, "msi: addr 0x%"PRIx64 " data 0x%"PRIx32,
> >> +msi.address, msi.data);
> >> +apic_get_class()->send_msi(&msi);
> >>  }
> 
> It should have been wrong even before, because address_space_stl_le()
> seems to accept the address in host endianess and not in LE ... UGH.

Again, I guess no one is running VT-d in BE machines. So problems are
not exposed.

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH v3 3/8] intel_iommu: pass whole remapped addresses to apic

[Peter Xu]

On Tue, Oct 04, 2016 at 01:17:28PM +0200, Igor Mammedov wrote:
> On Fri, 30 Sep 2016 18:10:08 +0200
> Radim Krčmář  wrote:
> 
> > The MMIO interface to APIC only allowed 8 bit addresses, which is not
> > enough for 32 bit addresses from EIM remapping.
> > Intel stored upper 24 bits in the high MSI address, so use the same
> > technique. The technique is also used in KVM MSI interface.
> > Other APICs are unlikely to handle those upper bits.
> > 
> > Signed-off-by: Radim Krčmář 
> > ---
> > v2: fix build with enabled DEBUG_INTEL_IOMMU [Peter]
> > ---
> >  hw/i386/intel_iommu.c | 21 +
> >  1 file changed, 9 insertions(+), 12 deletions(-)
> > 
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index 9f4e64af1ad5..c39b62b898d8 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -31,6 +31,7 @@
> >  #include "hw/i386/x86-iommu.h"
> >  #include "hw/pci-host/q35.h"
> >  #include "sysemu/kvm.h"
> > +#include "hw/i386/apic_internal.h"
> >  
> >  /*#define DEBUG_INTEL_IOMMU*/
> >  #ifdef DEBUG_INTEL_IOMMU
> > @@ -279,18 +280,17 @@ static void vtd_update_iotlb(IntelIOMMUState *s, 
> > uint16_t source_id,
> >  static void vtd_generate_interrupt(IntelIOMMUState *s, hwaddr 
> > mesg_addr_reg,
> > hwaddr mesg_data_reg)
> >  {
> > -hwaddr addr;
> > -uint32_t data;
> > +MSIMessage msi;
> >  
> >  assert(mesg_data_reg < DMAR_REG_SIZE);
> >  assert(mesg_addr_reg < DMAR_REG_SIZE);
> >  
> > -addr = vtd_get_long_raw(s, mesg_addr_reg);
> > -data = vtd_get_long_raw(s, mesg_data_reg);
> > +msi.address = vtd_get_long_raw(s, mesg_addr_reg);
> > +msi.data = vtd_get_long_raw(s, mesg_data_reg);
> >  
> > -VTD_DPRINTF(FLOG, "msi: addr 0x%"PRIx64 " data 0x%"PRIx32, addr, data);
> > -address_space_stl_le(&address_space_memory, addr, data,
> > - MEMTXATTRS_UNSPECIFIED, NULL);
> > +VTD_DPRINTF(FLOG, "msi: addr 0x%"PRIx64 " data 0x%"PRIx32,
> > +msi.address, msi.data);
> > +apic_get_class()->send_msi(&msi);
> >  }
> >  
> >  /* Generate a fault event to software via MSI if conditions are met.
> > @@ -2133,6 +2133,7 @@ static void vtd_generate_msi_message(VTDIrq *irq, 
> > MSIMessage *msg_out)
> >  msg.dest_mode = irq->dest_mode;
> >  msg.redir_hint = irq->redir_hint;
> >  msg.dest = irq->dest;
> > +msg.__addr_hi = irq->dest & 0xff00;
> what about BE host? should it be:
> 
>  msg.__addr_hi = cpu_to_le32(irq->dest & 0xff00)
> 
> Also question to Peter, why __addr_hi is not HOST_WORDS_BIGENDIAN conditioned?
> now we have:
> struct VTD_MSIMessage {   
>
> union {   
>
> struct {  
>
> #ifdef HOST_WORDS_BIGENDIAN   
>
> uint32_t __addr_head:12; /* 0xfee */  
>
> [...]  
> #else 
>
> [...]
> uint32_t __addr_head:12; /* 0xfee */  
>
> #endif
>
> uint32_t __addr_hi:32; 

I think __addr_hi is not a bit field at all. It'll be the same if I
put it into the block. E.g., it'll look like:

#ifdef HOST_WORDS_BIGENDIAN
uint32_t __addr_head:12; /* 0xfee */
uint32_t dest:8;
uint32_t __reserved:8;
uint32_t redir_hint:1;
uint32_t dest_mode:1;
uint32_t __not_used:2;
uint32_t __addr_hi:32;
#else
uint32_t __not_used:2;
uint32_t dest_mode:1;
uint32_t redir_hint:1;
uint32_t __reserved:8;
uint32_t dest:8;
uint32_t __addr_head:12; /* 0xfee */
uint32_t __addr_hi:32;
#endif

Only real bit fields (like dest_mode, redir_hint, etc.) order is
handled differently on BE/LE machines. Since __addr_hi is not a bit
field (it's typed as u32, and it's 32 bits long), it should always be
using a higher address comparing to above real bit fields, so no
ordering issue AFAIK.

I have patch in my queue that fixes this (change "__addr_hi:32" to
"__addr_hi"). Though it should not be a big problem.

-- peterx

Re: [Qemu-devel] [PATCH v3] timer: a9gtimer: remove loop to auto-increment comparator

[P J P]

+-- On Fri, 7 Oct 2016, Peter Maydell wrote --+
| This is still losing the setting of gtb->status in the
| case where the auto-increment bit is not set.

Ah, I've sent a revised patch v4. Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH v4] timer: a9gtimer: remove loop to auto-increment comparator

[P J P]

From: Prasad J Pandit 

ARM A9MP processor has a peripheral timer with an auto-increment
register, which holds an increment step value. A user could set
this value to zero. When auto-increment control bit is enabled,
it leads to an infinite loop in 'a9_gtimer_update' while
updating comparator value. Remove this loop incrementing the
comparator value.

Reported-by: Li Qiang 
Signed-off-by: Prasad J Pandit 
---
 hw/timer/a9gtimer.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

Update per
  -> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg01393.html

diff --git a/hw/timer/a9gtimer.c b/hw/timer/a9gtimer.c
index 772f85f..02092dd 100644
--- a/hw/timer/a9gtimer.c
+++ b/hw/timer/a9gtimer.c
@@ -73,6 +73,7 @@ static void a9_gtimer_update(A9GTimerState *s, bool sync)
 
 A9GTimerUpdate update = a9_gtimer_get_update(s);
 int i;
+uint64_t inc;
 int64_t next_cdiff = 0;
 
 for (i = 0; i < s->num_cpu; ++i) {
@@ -82,15 +83,15 @@ static void a9_gtimer_update(A9GTimerState *s, bool sync)
 if ((s->control & R_CONTROL_TIMER_ENABLE) &&
 (gtb->control & R_CONTROL_COMP_ENABLE)) {
 /* R2p0+, where the compare function is >= */
-while (gtb->compare < update.new) {
+if (gtb->compare < update.new) {
 DB_PRINT("Compare event happened for CPU %d\n", i);
 gtb->status = 1;
-if (gtb->control & R_CONTROL_AUTO_INCREMENT) {
-DB_PRINT("Auto incrementing timer compare by %" PRId32 
"\n",
- gtb->inc);
-gtb->compare += gtb->inc;
-} else {
-break;
+if (gtb->control & R_CONTROL_AUTO_INCREMENT && gtb->inc) {
+inc = update.new - gtb->compare - 1;
+inc = QEMU_ALIGN_DOWN(inc, gtb->inc);
+DB_PRINT("Auto incrementing timer compare by %"
+PRId64 "\n", inc);
+gtb->compare += inc;
 }
 }
 cdiff = (int64_t)gtb->compare - (int64_t)update.new + 1;
-- 
2.5.5

Re: [Qemu-devel] Fw: [Qemu-arm] [PATCH v2 0/6] Runtime pagesize computation

[Vijay Kilari]

Hi Peter,

On Fri, Oct 7, 2016 at 7:50 PM, Peter Maydell  wrote:
> On 19 July 2016 at 12:04, Peter Maydell  wrote:
>> On 19 July 2016 at 12:01, Vijay Kilari  wrote:
>>> Hi Peter,
>>>
>>>   Any update on this patch set. Is it merged?
>>
>> No. It's an RFC patchset really, and it was posted during softfreeze,
>> so I never expected or intended it to be merged before the 2.7
>> release. It also needs a respin to address some of the review comments
>> I got on it.
>>
>> What would be useful in getting it further forward would be
>> some good performance benchmarking of more than just migration.
>> In particular whether it improves the speed in TCG emulation
>> mode of aarch64 guests and whether that assert in the definition
>> of TARGET_PAGE_BITS is particularly performance-draining.
>
> If I do a respin of this patchset is anybody willing to do
> the actual perf benchmarking of the TCG emulation?
> Otherwise this is unlikely to go into 2.8.

 I can help you. Let me know details on benchmarkings to be done.
Also, a reference/details about running arm64 guests in TCG mode
would be helpful.

Regards
Vijay

Re: [Qemu-devel] [PATCH] KVM: x86: handle KVM_SET_VCPU_EVENTS/KVM_VCPUEVENT_VALID_SMM properly

[Herongguang (Stephen)]

On 2016/9/23 12:59, herongguang wrote:

From: He Rongguang 

handle KVM_VCPUEVENT_VALID_SMM properly, or kvm-kmod/kernel will crash
in migration destination in gfn_to_rmap() since kvm_memslots_for_spte_role
is false, whilst (vcpu->arch.hflags & HF_SMM_MASK) is true

Signed-off-by: herongguang 
---
  arch/x86/kvm/x86.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 699f872..7ebcb59 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3028,6 +3028,7 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct 
kvm_vcpu *vcpu,
else
clear_bit(KVM_APIC_INIT, 
&vcpu->arch.apic->pending_events);
}
+   kvm_mmu_reset_context(vcpu);
}

kvm_make_request(KVM_REQ_EVENT, vcpu);



Hi, do you think this is OK for linux 4.9?

Re: [Qemu-devel] [PATCH v5 14/14] cryptodev: rename cryptodev stuff

[Gonglei (Arei)]

Hi Eric,

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Friday, October 07, 2016 3:48 AM
> Subject: Re: [Qemu-devel] [PATCH v5 14/14] cryptodev: rename cryptodev stuff
> 
> On 10/06/2016 06:36 AM, Gonglei wrote:
> > Remove qcrypto and/or QCRYPTO prefix in order to
> > make the name shorter because it doesn't repeat
> > any information.
> >
> > Signed-off-by: Gonglei 
> > ---
> >  backends/cryptodev-builtin.c  |  84 
> 
> This file is new as part of your series.  Please rebase this to avoid
> the churn, by making it use the correct naming from the get-go rather
> than an after-the-fact correction.
> 
You are absolutely right, I will rebase it, thanks :)

Regards,
-Gonglei

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

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear

[Alistair Francis]

On Fri, Oct 7, 2016 at 1:04 PM, Seth K  wrote:
> I applied that patch, made qemu and ran my code, I didn't see a change.
>
> According to the STM32F20xxx memory map, the memory range seems to be 0x400
> -- UART 1 is listed as 0x4001 - 0x400103FF. Should that memory region be
> set to 0x400?

I was hoping that would have fixed it.

It sounds like it should be 0x400 then, although it doesn't sound like
this is causing this issue.

>
> I tried that too, no change yet, but maybe I should look at the other memory
> settings.

Maybe, it is very strange that it's not reaching the read/write functions.

Can you try putting print statements in the guest software to make
sure it is writing to the locations you expect and then make sure
there are no conditionals in QEMU that cause the print statements to
not be printed. See what that uncovers.

Thanks,

Alistair

>
> I also tried making these changes in another branch where I made this chip
> have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6.
>
> On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis 
> wrote:
>>
>> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis 
>> wrote:
>> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K  wrote:
>> >> The only machine I saw listed in the help output is "netduino2." I
>> >> pulled
>> >> QEMU from github, was that the right thing to do?
>> >>
>> >> I found the specifications for the stm32f2xx and some similar chips and
>> >> verified the addresses and interrupts are correct.
>> >
>> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support.
>> >
>> > I think we should move this conversation to the bug report as well, I
>> > was hoping that replying to the email would update the bug report but
>> > it doesn't look like it.
>> >
>> >>
>> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are
>> >> coded
>> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS
>> >> limiting
>> >> serial_hds to 4, and I don't know why. I am considering submitting a
>> >> patch.
>> >
>> > I'm not sure why we have that limit, you can submit a patch and see
>> > what everyone says.
>> >
>> >>
>> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and
>> >> output them to sockets. However writes to UARTs 2 and 3 just disappear.
>> >> They
>> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like
>> >> they
>> >> are being intercepted somewhere, and unfortunately my knowledge of QEMU
>> >> is
>> >> too low to know where to look. Any pointers would be greatly
>> >> appreciated.
>> >
>> > Strange. There could be something else addressed there. If you run
>> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to see
>> > the memory map of the system.
>>
>> Hey Seth,
>>
>> What if you try this diff? Does that help?
>>
>> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
>> index 4c6640d..b07c67b 100644
>> --- a/hw/char/stm32f2xx_usart.c
>> +++ b/hw/char/stm32f2xx_usart.c
>> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj)
>>  sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);
>>
>>  memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s,
>> -  TYPE_STM32F2XX_USART, 0x2000);
>> +  TYPE_STM32F2XX_USART, 0x200);
>>  sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
>>  }
>>
>> Thanks,
>>
>> Alistair
>
>

Re: [Qemu-devel] [PATCH v2 1/1] block: add gluster ifdef guard checks for SEEK_DATA/SEEK_HOLE support

[Eric Blake]

On 10/07/2016 04:48 PM, Jeff Cody wrote:
> Add checks to see if the system compiling QEMU has support for
> SEEK_HOLE/SEEK_DATA.  If the system does not, we will flag that seek
> data is unsupported in gluster.
> 
> Note: this is not a check on whether the gluster server itself supports
> SEEK_DATA (that is already done during runtime), but rather if the
> compilation environment supports SEEK_DATA.
> 
> Reviewed-by: Eric Blake 
> Signed-off-by: Jeff Cody 
> ---
> 
> Changes from v1:
> - Fixed undefined variable warnings by moving variable declarations
> - Add a bit more whitespace to improve readability
> 
> 
>  block/gluster.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)

Tested-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v2 1/1] block: add gluster ifdef guard checks for SEEK_DATA/SEEK_HOLE support

[Jeff Cody]

Add checks to see if the system compiling QEMU has support for
SEEK_HOLE/SEEK_DATA.  If the system does not, we will flag that seek
data is unsupported in gluster.

Note: this is not a check on whether the gluster server itself supports
SEEK_DATA (that is already done during runtime), but rather if the
compilation environment supports SEEK_DATA.

Reviewed-by: Eric Blake 
Signed-off-by: Jeff Cody 
---

Changes from v1:
- Fixed undefined variable warnings by moving variable declarations
- Add a bit more whitespace to improve readability


 block/gluster.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/block/gluster.c b/block/gluster.c
index e7bd13c..4796bcb 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -672,7 +672,10 @@ static void qemu_gluster_parse_flags(int bdrv_flags, int 
*open_flags)
  */
 static bool qemu_gluster_test_seek(struct glfs_fd *fd)
 {
-off_t ret, eof;
+off_t ret = 0;
+
+#if defined SEEK_HOLE && defined SEEK_DATA
+off_t eof;
 
 eof = glfs_lseek(fd, 0, SEEK_END);
 if (eof < 0) {
@@ -682,6 +685,8 @@ static bool qemu_gluster_test_seek(struct glfs_fd *fd)
 
 /* this should always fail with ENXIO if SEEK_DATA is supported */
 ret = glfs_lseek(fd, eof, SEEK_DATA);
+#endif
+
 return (ret < 0) && (errno == ENXIO);
 }
 
@@ -1182,12 +1187,14 @@ static int find_allocation(BlockDriverState *bs, off_t 
start,
off_t *data, off_t *hole)
 {
 BDRVGlusterState *s = bs->opaque;
-off_t offs;
 
 if (!s->supports_seek_data) {
-return -ENOTSUP;
+goto exit;
 }
 
+#if defined SEEK_HOLE && defined SEEK_DATA
+off_t offs;
+
 /*
  * SEEK_DATA cases:
  * D1. offs == start: start is in data
@@ -1251,6 +1258,10 @@ static int find_allocation(BlockDriverState *bs, off_t 
start,
 
 /* D1 and H1 */
 return -EBUSY;
+#endif
+
+exit:
+return -ENOTSUP;
 }
 
 /*
-- 
2.7.4

[Qemu-devel] [PATCH v6 3/3] target-i386: Return runnability information on query-cpu-definitions

[Eduardo Habkost]

Fill the "unavailable-features" field on the x86 implementation
of query-cpu-definitions.

Cc: Jiri Denemark 
Cc: libvir-l...@redhat.com
Signed-off-by: Eduardo Habkost 
---
Changes v5 -> v6:
* Call x86_cpu_filter_features(), now that x86_cpu_load_features()
  won't run it automatically

Changes v4 -> v5:
* (none)

Changes v3 -> v4:
* Handle missing XSAVE components cleanly, but looking up
  the original feature that required it
* Use x86_cpu_load_features() function

Changes v2 -> v3:
* Create a x86_cpu_feature_name() function, to
  isolate the code that returns the property name

Changes v1 -> v2:
* Updated to the new schema: no @runnable field, and
  always report @unavailable-features as present
---
 target-i386/cpu.c | 76 +++
 1 file changed, 76 insertions(+)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 23cc19b..63330ce 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1945,6 +1945,27 @@ static inline void feat2prop(char *s)
 }
 }
 
+/* Return the feature property name for a feature flag bit */
+static const char *x86_cpu_feature_name(FeatureWord w, int bitnr)
+{
+/* XSAVE components are automatically enabled by other features,
+ * so return the original feature name instead
+ */
+if (w == FEAT_XSAVE_COMP_LO || w == FEAT_XSAVE_COMP_HI) {
+int comp = (w == FEAT_XSAVE_COMP_HI) ? bitnr + 32 : bitnr;
+
+if (comp < ARRAY_SIZE(x86_ext_save_areas) &&
+x86_ext_save_areas[comp].bits) {
+w = x86_ext_save_areas[comp].feature;
+bitnr = ctz32(x86_ext_save_areas[comp].bits);
+}
+}
+
+assert(bitnr < 32);
+assert(w < FEATURE_WORDS);
+return feature_word_info[w].feat_names[bitnr];
+}
+
 /* Compatibily hack to maintain legacy +-feat semantic,
  * where +-feat overwrites any feature set by
  * feat=on|feat even if the later is parsed after +-feat
@@ -2030,6 +2051,59 @@ static void x86_cpu_parse_featurestr(const char 
*typename, char *features,
 }
 }
 
+static void x86_cpu_load_features(X86CPU *cpu, Error **errp);
+static int x86_cpu_filter_features(X86CPU *cpu);
+
+/* Check for missing features that may prevent the CPU class from
+ * running using the current machine and accelerator.
+ */
+static void x86_cpu_class_check_missing_features(X86CPUClass *xcc,
+ strList **missing_feats)
+{
+X86CPU *xc;
+FeatureWord w;
+Error *err = NULL;
+strList **next = missing_feats;
+
+if (xcc->kvm_required && !kvm_enabled()) {
+strList *new = g_new0(strList, 1);
+new->value = g_strdup("kvm");;
+*missing_feats = new;
+return;
+}
+
+xc = X86_CPU(object_new(object_class_get_name(OBJECT_CLASS(xcc;
+
+x86_cpu_load_features(xc, &err);
+if (err) {
+/* Errors at x86_cpu_load_features should never happen,
+ * but in case it does, just report the model as not
+ * runnable at all using the "type" property.
+ */
+strList *new = g_new0(strList, 1);
+new->value = g_strdup("type");
+*next = new;
+next = &new->next;
+}
+
+x86_cpu_filter_features(xc);
+
+for (w = 0; w < FEATURE_WORDS; w++) {
+uint32_t filtered = xc->filtered_features[w];
+int i;
+for (i = 0; i < 32; i++) {
+if (filtered & (1UL << i)) {
+strList *new = g_new0(strList, 1);
+new->value = g_strdup(x86_cpu_feature_name(w, i));
+*next = new;
+next = &new->next;
+}
+}
+}
+
+object_unref(OBJECT(xc));
+}
+
 /* Print all cpuid feature names in featureset
  */
 static void listflags(FILE *f, fprintf_function print, const char **featureset)
@@ -2122,6 +2196,8 @@ static void x86_cpu_definition_entry(gpointer data, 
gpointer user_data)
 
 info = g_malloc0(sizeof(*info));
 info->name = x86_cpu_class_get_model_name(cc);
+x86_cpu_class_check_missing_features(cc, &info->unavailable_features);
+info->has_unavailable_features = true;
 
 entry = g_malloc0(sizeof(*entry));
 entry->value = info;
-- 
2.7.4

[Qemu-devel] [PATCH v6 0/3] Add runnability info to query-cpu-definitions

[Eduardo Habkost]

This series extends query-cpu-definitions to include an extra
field: "unavailable-features". The new field can be used to find
out reasons that prevent the CPU model from running in the
current host.

This will return information based on the current machine and
accelerator only. In the future we may extend these mechanisms to
allow querying other machines and other accelerators without
restarting QEMU, but it will require some reorganization of
QEMU's main code.

To be able to implement this more cleanly, the series rework some
of the feature/property name code.

This series can be seen in the git branch at:
  https://github.com/ehabkost/qemu-hacks.git 
work/query-cpu-definitions-runnable-info

The series is based on my x86-next branch:
   https://github.com/ehabkost/qemu.git x86-next

Changes v5 -> v6:
* Rebased to x86-next, that already has 8 of the previous patches
  from v5 applied
* Removed x86_cpu_filter_features() from x86_cpu_load_features(),
  because some of the commands in the CPU model query API need
  info about CPU models before filtering
* Recovered v3 of
  "target-i386: Move warning code outside x86_cpu_filter_features()"
  because now we can keep the simpler logic that checked
  the return value of x86_cpu_filter_features()

Diff v5 -> v6:

  diff --git a/target-i386/cpu.c b/target-i386/cpu.c
  index d53e711..63330ce 100644
  --- a/target-i386/cpu.c
  +++ b/target-i386/cpu.c
  @@ -2052,6 +2052,7 @@ static void x86_cpu_parse_featurestr(const char 
*typename, char *features,
   }

   static void x86_cpu_load_features(X86CPU *cpu, Error **errp);
  +static int x86_cpu_filter_features(X86CPU *cpu);

   /* Check for missing features that may prevent the CPU class from
* running using the current machine and accelerator.
  @@ -2085,6 +2086,8 @@ static void 
x86_cpu_class_check_missing_features(X86CPUClass *xcc,
   next = &new->next;
   }

  +x86_cpu_filter_features(xc);
  +
   for (w = 0; w < FEATURE_WORDS; w++) {
   uint32_t filtered = xc->filtered_features[w];
   int i;
  @@ -2234,11 +2237,14 @@ static uint32_t 
x86_cpu_get_supported_feature_word(FeatureWord w,

   /*
* Filters CPU feature words based on host availability of each feature.
  + *
  + * Returns: 0 if all flags are supported by the host, non-zero otherwise.
*/
  -static void x86_cpu_filter_features(X86CPU *cpu)
  +static int x86_cpu_filter_features(X86CPU *cpu)
   {
   CPUX86State *env = &cpu->env;
   FeatureWord w;
  +int rv = 0;

   for (w = 0; w < FEATURE_WORDS; w++) {
   uint32_t host_feat =
  @@ -2246,22 +2252,21 @@ static void x86_cpu_filter_features(X86CPU *cpu)
   uint32_t requested_features = env->features[w];
   env->features[w] &= host_feat;
   cpu->filtered_features[w] = requested_features & ~env->features[w];
  +if (cpu->filtered_features[w]) {
  +rv = 1;
  +}
   }
  +
  +return rv;
   }

  -/* Report list of filtered features to stderr.
  - * Returns true if some features were found to be filtered, false otherwise
  - */
  -static bool x86_cpu_report_filtered_features(X86CPU *cpu)
  +static void x86_cpu_report_filtered_features(X86CPU *cpu)
   {
   FeatureWord w;
  -uint32_t filtered = 0;

   for (w = 0; w < FEATURE_WORDS; w++) {
  -filtered |= cpu->filtered_features[w];
   report_unavailable_features(w, cpu->filtered_features[w]);
   }
  -return filtered;
   }

   static void x86_cpu_apply_props(X86CPU *cpu, PropValue *props)
  @@ -3136,8 +3141,6 @@ static void x86_cpu_load_features(X86CPU *cpu, Error 
**errp)
   env->cpuid_xlevel2 = env->cpuid_min_xlevel2;
   }

  -x86_cpu_filter_features(cpu);
  -
   out:
   if (local_err != NULL) {
   error_propagate(errp, local_err);
  @@ -3176,8 +3179,12 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
   goto out;
   }

  -if (cpu->check_cpuid || cpu->enforce_cpuid) {
  -if (x86_cpu_report_filtered_features(cpu) && cpu->enforce_cpuid) {
  +x86_cpu_filter_features(cpu);
  +
  +if (x86_cpu_filter_features(cpu) &&
  +(cpu->check_cpuid || cpu->enforce_cpuid)) {
  +x86_cpu_report_filtered_features(cpu);
  +if (cpu->enforce_cpuid) {
   error_setg(&local_err,
  kvm_enabled() ?
  "Host doesn't support requested features" :

Changes v4 -> v5:
* New patch: "target-i386: Register aliases for feature names with underscores"
* On patch: "tests: Add test case for x86 feature parsing compatibility":
  * Fix typo on commit message
Reported-by: Jonathan Neuschäfer 
  * Add comment noting that the "[+-]feature" compatibility mode
will be removed soon
* On patch: "target-i386: Make plus_features/minus_features QOM-based":
  * Removed feat2prop() call on , as we now have property aliases
for the old names containing underscores
* On patch: "target-i386: Remo

[Qemu-devel] [PATCH v6 2/3] target-i386: x86_cpu_load_features() function

[Eduardo Habkost]

When probing for CPU model information, we need to reuse the code
that initializes CPUID fields, but not the remaining side-effects
of x86_cpu_realizefn(). Move that code to a separate function
that can be reused later.

Signed-off-by: Eduardo Habkost 
---
Changes v5 -> v6:
* Move x86_cpu_filter_features() outside x86_cpu_load_features(),
  as the CPU model querying API won't run
  x86_cpu_filter_features() on most cases

Changes v4 -> v5:
* Fix typo on x86_cpu_load_features() comment
  Reported-by: Paolo Bonzini 

Changes series v3 -> v4:
* New patch added to series
---
 target-i386/cpu.c | 67 +++
 1 file changed, 43 insertions(+), 24 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 1e8127b..23cc19b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2993,34 +2993,13 @@ static void x86_cpu_enable_xsave_components(X86CPU *cpu)
 env->features[FEAT_XSAVE_COMP_HI] = mask >> 32;
 }
 
-#define IS_INTEL_CPU(env) ((env)->cpuid_vendor1 == CPUID_VENDOR_INTEL_1 && \
-   (env)->cpuid_vendor2 == CPUID_VENDOR_INTEL_2 && \
-   (env)->cpuid_vendor3 == CPUID_VENDOR_INTEL_3)
-#define IS_AMD_CPU(env) ((env)->cpuid_vendor1 == CPUID_VENDOR_AMD_1 && \
- (env)->cpuid_vendor2 == CPUID_VENDOR_AMD_2 && \
- (env)->cpuid_vendor3 == CPUID_VENDOR_AMD_3)
-static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
+/* Load CPUID data based on configured features */
+static void x86_cpu_load_features(X86CPU *cpu, Error **errp)
 {
-CPUState *cs = CPU(dev);
-X86CPU *cpu = X86_CPU(dev);
-X86CPUClass *xcc = X86_CPU_GET_CLASS(dev);
 CPUX86State *env = &cpu->env;
-Error *local_err = NULL;
-static bool ht_warned;
 FeatureWord w;
 GList *l;
-
-if (xcc->kvm_required && !kvm_enabled()) {
-char *name = x86_cpu_class_get_model_name(xcc);
-error_setg(&local_err, "CPU model '%s' requires KVM", name);
-g_free(name);
-goto out;
-}
-
-if (cpu->apic_id == UNASSIGNED_APIC_ID) {
-error_setg(errp, "apic-id property was not initialized properly");
-return;
-}
+Error *local_err = NULL;
 
 /*TODO: cpu->host_features incorrectly overwrites features
  * set using "feat=on|off". Once we fix this, we can convert
@@ -3086,6 +3065,46 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 env->cpuid_xlevel2 = env->cpuid_min_xlevel2;
 }
 
+out:
+if (local_err != NULL) {
+error_propagate(errp, local_err);
+}
+}
+
+#define IS_INTEL_CPU(env) ((env)->cpuid_vendor1 == CPUID_VENDOR_INTEL_1 && \
+   (env)->cpuid_vendor2 == CPUID_VENDOR_INTEL_2 && \
+   (env)->cpuid_vendor3 == CPUID_VENDOR_INTEL_3)
+#define IS_AMD_CPU(env) ((env)->cpuid_vendor1 == CPUID_VENDOR_AMD_1 && \
+ (env)->cpuid_vendor2 == CPUID_VENDOR_AMD_2 && \
+ (env)->cpuid_vendor3 == CPUID_VENDOR_AMD_3)
+static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
+{
+CPUState *cs = CPU(dev);
+X86CPU *cpu = X86_CPU(dev);
+X86CPUClass *xcc = X86_CPU_GET_CLASS(dev);
+CPUX86State *env = &cpu->env;
+Error *local_err = NULL;
+static bool ht_warned;
+
+if (xcc->kvm_required && !kvm_enabled()) {
+char *name = x86_cpu_class_get_model_name(xcc);
+error_setg(&local_err, "CPU model '%s' requires KVM", name);
+g_free(name);
+goto out;
+}
+
+if (cpu->apic_id == UNASSIGNED_APIC_ID) {
+error_setg(errp, "apic-id property was not initialized properly");
+return;
+}
+
+x86_cpu_load_features(cpu, &local_err);
+if (local_err) {
+goto out;
+}
+
+x86_cpu_filter_features(cpu);
+
 if (x86_cpu_filter_features(cpu) &&
 (cpu->check_cpuid || cpu->enforce_cpuid)) {
 x86_cpu_report_filtered_features(cpu);
-- 
2.7.4

[Qemu-devel] [PATCH v6 1/3] target-i386: Move warning code outside x86_cpu_filter_features()

[Eduardo Habkost]

x86_cpu_filter_features() will be reused by code that shouldn't
print any warning. Move the warning code to a new
x86_cpu_report_filtered_features() function, and call it from
x86_cpu_realizefn().

Signed-off-by: Eduardo Habkost 
---
Changes v5 -> v6:
* Recovered v3 of patch, because x86_cpu_load_features()
  won't call x86_cpu_filter_features() anymore and we can keep
  the previous logic in x86_cpu_realizefn() that checked
  x86_cpu_filter_features() return value

Changes v4 -> v5:
* (none)

Changes v3 -> v4:
* Made x86_cpu_filter_features() void, make
  x86_cpu_report_filtered_features() return true if
  some features were filtered
---
 target-i386/cpu.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 61240dd..1e8127b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2177,9 +2177,6 @@ static int x86_cpu_filter_features(X86CPU *cpu)
 env->features[w] &= host_feat;
 cpu->filtered_features[w] = requested_features & ~env->features[w];
 if (cpu->filtered_features[w]) {
-if (cpu->check_cpuid || cpu->enforce_cpuid) {
-report_unavailable_features(w, cpu->filtered_features[w]);
-}
 rv = 1;
 }
 }
@@ -2187,6 +2184,15 @@ static int x86_cpu_filter_features(X86CPU *cpu)
 return rv;
 }
 
+static void x86_cpu_report_filtered_features(X86CPU *cpu)
+{
+FeatureWord w;
+
+for (w = 0; w < FEATURE_WORDS; w++) {
+report_unavailable_features(w, cpu->filtered_features[w]);
+}
+}
+
 static void x86_cpu_apply_props(X86CPU *cpu, PropValue *props)
 {
 PropValue *pv;
@@ -3080,12 +3086,16 @@ static void x86_cpu_realizefn(DeviceState *dev, Error 
**errp)
 env->cpuid_xlevel2 = env->cpuid_min_xlevel2;
 }
 
-if (x86_cpu_filter_features(cpu) && cpu->enforce_cpuid) {
-error_setg(&local_err,
-   kvm_enabled() ?
-   "Host doesn't support requested features" :
-   "TCG doesn't support requested features");
-goto out;
+if (x86_cpu_filter_features(cpu) &&
+(cpu->check_cpuid || cpu->enforce_cpuid)) {
+x86_cpu_report_filtered_features(cpu);
+if (cpu->enforce_cpuid) {
+error_setg(&local_err,
+   kvm_enabled() ?
+   "Host doesn't support requested features" :
+   "TCG doesn't support requested features");
+goto out;
+}
 }
 
 /* On AMD CPUs, some CPUID[8000_0001].EDX bits must match the bits on
-- 
2.7.4

Re: [Qemu-devel] [PATCH v5 11/12] qmp: Add runnability information to query-cpu-definitions

[Eduardo Habkost]

On Fri, Sep 30, 2016 at 03:49:45PM -0300, Eduardo Habkost wrote:
> Add a new optional field to query-cpu-definitions schema:
> "unavailable-features". It will contain a list of QOM properties
> that prevent the CPU model from running in the current host.
> 
> Cc: David Hildenbrand 
> Cc: Michael Mueller 
> Cc: Christian Borntraeger 
> Cc: Cornelia Huck 
> Cc: Jiri Denemark 
> Cc: libvir-l...@redhat.com
> Reviewed-by: Eric Blake 
> Signed-off-by: Eduardo Habkost 

Applied this to x86-next.

-- 
Eduardo

Re: [Qemu-devel] [PATCH 22/22] specs/qcow2: do not use wording 'bitmap header'

[Eric Blake]

On 09/30/2016 05:53 AM, Vladimir Sementsov-Ogievskiy wrote:
> For now bitmap directory entry some times called 'bitmap header'. This

Awkward wording; maybe:

A bitmap directory entry is sometimes called a 'bitmap header'.

> patch leaves only one name - 'bitmap directory entry'. The name 'bitmap
> header' creates misunderstandings with 'qcow2 header' and 'qcow2 bitmap
> header extension' (which is extension of qcow2 header)
> 

Doc touchup patches like this are fairly uncontroversial, and could be
moved earlier in the series so that they can be merged rather than
having to be rebased multiple times.

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 21/22] specs/qcow2: fix bitmap granularity qemu-specific note

[Eric Blake]

On 09/30/2016 05:53 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  docs/specs/qcow2.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> index 80cdfd0..d3e292f 100644
> --- a/docs/specs/qcow2.txt
> +++ b/docs/specs/qcow2.txt
> @@ -472,8 +472,7 @@ Structure of a bitmap directory entry:
>   17:granularity_bits
>  Granularity bits. Valid values: 0 - 63.

Can we really theoretically go as low as 0, or are we constrained by the
fact that cluster_bits must be at least 9?

>  
> -Note: Qemu currently doesn't support granularity_bits
> -greater than 31.
> +Note: Qemu currently support only values 9 - 31.

s/support/supports/

>  
>  Granularity is calculated as
>  granularity = 1 << granularity_bits
> 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 15/22] qcow2-bitmap: add autoclear bit

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> Add autoclear bit for handling rewriting image by old qemu version.

"Add support for the autoclear bit [...]"?

> 
> If autoclear bit is not set, but bitmaps extension is found it
> would not be loaded and warning will be generated.

"If the autoclear bit is not set, but the bitmaps extension is found,
the bitmaps will not be loaded and a warning will be generated."

> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2-bitmap.c |  4 
>  block/qcow2.c| 12 ++--
>  block/qcow2.h|  9 +
>  3 files changed, 23 insertions(+), 2 deletions(-)

Apart from the above, the patch looks good, but why does it come so late
in the series?

So with the commit message fixed:

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear

[Seth K]

I applied that patch, made qemu and ran my code, I didn't see a change.

According to the STM32F20xxx memory map, the memory range seems to be 0x400
-- UART 1 is listed as 0x4001 - 0x400103FF. Should that memory region
be set to 0x400?

I tried that too, no change yet, but maybe I should look at the other
memory settings.

I also tried making these changes in another branch where I made this chip
have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6.

On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis 
wrote:

> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis 
> wrote:
> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K  wrote:
> >> The only machine I saw listed in the help output is "netduino2." I
> pulled
> >> QEMU from github, was that the right thing to do?
> >>
> >> I found the specifications for the stm32f2xx and some similar chips and
> >> verified the addresses and interrupts are correct.
> >
> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support.
> >
> > I think we should move this conversation to the bug report as well, I
> > was hoping that replying to the email would update the bug report but
> > it doesn't look like it.
> >
> >>
> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are
> coded
> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting
> >> serial_hds to 4, and I don't know why. I am considering submitting a
> patch.
> >
> > I'm not sure why we have that limit, you can submit a patch and see
> > what everyone says.
> >
> >>
> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and
> >> output them to sockets. However writes to UARTs 2 and 3 just disappear.
> They
> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like
> they
> >> are being intercepted somewhere, and unfortunately my knowledge of QEMU
> is
> >> too low to know where to look. Any pointers would be greatly
> appreciated.
> >
> > Strange. There could be something else addressed there. If you run
> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to see
> > the memory map of the system.
>
> Hey Seth,
>
> What if you try this diff? Does that help?
>
> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
> index 4c6640d..b07c67b 100644
> --- a/hw/char/stm32f2xx_usart.c
> +++ b/hw/char/stm32f2xx_usart.c
> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj)
>  sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);
>
>  memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s,
> -  TYPE_STM32F2XX_USART, 0x2000);
> +  TYPE_STM32F2XX_USART, 0x200);
>  sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
>  }
>
> Thanks,
>
> Alistair
>

Re: [Qemu-devel] [PATCH 14/22] qcow2: delete bitmaps on truncate

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> This will not touch loaded bitmaps, as they are alredy removed from the
> image.

Well, yes, and I don't think that's ideal. :-)

I think marking them in_use instead of deleting them would be better.

Also, I'm not so sure whether this patch is an improvement at all.
Wouldn't it be better to have a qemu-img tool (and/or QMP interface) for
bitmap management and then making the user delete all the bitmaps before
the image can be resized?

Max

> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2-bitmap.c | 38 ++
>  block/qcow2.c|  9 ++---
>  block/qcow2.h|  2 ++
>  3 files changed, 46 insertions(+), 3 deletions(-)
> 
> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index 1c3abea..2642afe 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -624,6 +624,44 @@ out:
>  return ret;
>  }
>  
> +
> +int qcow2_delete_bitmaps(BlockDriverState *bs)
> +{
> +int ret;
> +BDRVQcow2State *s = bs->opaque;
> +uint8_t *dir;
> +uint64_t dir_size;
> +Qcow2BitmapDirEntry *e;
> +
> +if (s->nb_bitmaps == 0) {
> +/* No bitmaps - nothing to do */
> +return 0;
> +}
> +
> +dir_size = s->bitmap_directory_size;
> +dir = directory_read(bs, s->bitmap_directory_offset,
> + s->bitmap_directory_size, NULL);
> +if (dir == NULL) {
> +ret = -EINVAL;
> +goto out;
> +}
> +
> +ret = directory_update(bs, NULL, 0, 0);
> +if (ret < 0) {
> +goto out;
> +}
> +
> +/* to be consistent, free bitmap only after successfull directory update 
> */
> +for_each_bitmap_dir_entry(e, dir, dir_size) {
> +free_bitmap_clusters(bs, e);
> +}
> +
> +out:
> +g_free(dir);
> +
> +return ret;
> +}
> +
>  /* store_bitmap_data()
>   * Store bitmap to image, filling bitamp table accordingly.
>   */
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 8238205..aa967ed 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -2592,9 +2592,12 @@ static int qcow2_truncate(BlockDriverState *bs, 
> int64_t offset)
>  
>  /* cannot proceed if image has bitmaps */
>  if (s->nb_bitmaps) {
> -/* FIXME */
> -error_report("Can't resize an image which has bitmaps");
> -return -ENOTSUP;
> +/* FIXME: not loaded bitmaps will be lost */
> +ret = qcow2_delete_bitmaps(bs);
> +if (ret < 0) {
> +error_report("Can't remove bitmaps from qcow2 on truncate");
> +return ret;
> +}
>  }
>  
>  /* shrinking is currently not supported */
> diff --git a/block/qcow2.h b/block/qcow2.h
> index dfcf4c6..af18efc 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -606,6 +606,8 @@ int qcow2_read_snapshots(BlockDriverState *bs);
>  /* qcow2-bitmap.c functions */
>  int qcow2_read_bitmaps(BlockDriverState *bs, Error **errp);
>  
> +int qcow2_delete_bitmaps(BlockDriverState *bs);
> +
>  /* qcow2-cache.c functions */
>  Qcow2Cache *qcow2_cache_create(BlockDriverState *bs, int num_tables);
>  int qcow2_cache_destroy(BlockDriverState* bs, Qcow2Cache *c);
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 13/22] qcow2-bitmap: check constraints

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> Check bitmap header constraints as specified in docs/specs/qcow2.txt
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2-bitmap.c | 39 +++
>  1 file changed, 39 insertions(+)

I'd pull this patch to some previous point in the series because the
previous patches would already require you to check these constraints
(which you just haven't done until now).

> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index 8cf40f0..1c3abea 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -154,6 +154,34 @@ static inline void bitmap_directory_to_be(uint8_t *dir, 
> size_t size)
>  }
>  }
>  
> +static int check_constraints(BlockDriverState *bs, Qcow2BitmapDirEntry *h)
> +{
> +BDRVQcow2State *s = bs->opaque;
> +uint64_t phys_bitmap_bytes =
> +(uint64_t)h->bitmap_table_size * s->cluster_size;
> +uint64_t max_virtual_bits = (phys_bitmap_bytes * 8) << 
> h->granularity_bits;
> +int64_t nb_sectors = bdrv_nb_sectors(bs);
> +
> +if (nb_sectors < 0) {
> +return nb_sectors;
> +}
> +
> +int fail =
> +((h->bitmap_table_size == 0) != (h->bitmap_table_offset == 0)) ||
> +(h->bitmap_table_offset % s->cluster_size) ||
> +(h->bitmap_table_size > BME_MAX_TABLE_SIZE) ||
> +(phys_bitmap_bytes > BME_MAX_PHYS_SIZE) ||
> +(h->bitmap_table_offset != 0 &&
> +(nb_sectors << BDRV_SECTOR_BITS) > max_virtual_bits) ||
> +(h->granularity_bits > BME_MAX_GRANULARITY_BITS) ||
> +(h->granularity_bits < BME_MIN_GRANULARITY_BITS) ||
> +(h->flags & BME_RESERVED_FLAGS) ||
> +(h->name_size > BME_MAX_NAME_SIZE) ||
> +(h->type != BT_DIRTY_TRACKING_BITMAP);
> +
> +return fail ? -EINVAL : 0;
> +}
> +
>  static void clear_bitmap_table(BlockDriverState *bs, uint64_t *bitmap_table,
> uint32_t bitmap_table_size)
>  {
> @@ -372,6 +400,12 @@ static uint8_t *directory_read(BlockDriverState *bs,
> bdrv_get_device_or_node_name(bs));
>  goto fail;
>  }
> +
> +ret = check_constraints(bs, e);
> +if (ret < 0) {
> +error_setg(errp, "Bitmap doesn't satisfy the constraints.");

I think I'd at least mention the name of the bitmap; also, no full stop
at the end of error messages.

> +goto fail;
> +}
>  }
>  
>  assert((uint8_t *)e == dir_end);
> @@ -713,6 +747,11 @@ static int store_bitmap(BlockDriverState *bs,
>  entry->extra_data_size = 0;
>  memcpy(entry + 1, bm_name, entry->name_size);
>  
> +ret = check_constraints(bs, entry);
> +if (ret < 0) {
> +goto fail;
> +}
> +

As I said in my second reply to patch 9, I think it's a bit too late if
we detect that the bitmap is actually invalid at this point. We really
should notice earlier.

Apart from what would actually better for the user, it is actually too
late to check the constraints here, as you have already written the
bitmap data to disk. You should always check the constraints before
reading and also before writing, not afterwards.

Max

>  return 0;
>  
>  fail:
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 17/22] qmp: add autoload parameter to block-dirty-bitmap-add

[Eric Blake]

On 09/30/2016 05:53 AM, Vladimir Sementsov-Ogievskiy wrote:
> Optional. Default is false.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Signed-off-by: Denis V. Lunev 
> ---
>  blockdev.c   | 22 --
>  qapi/block-core.json |  7 ++-
>  qmp-commands.hx  |  5 -
>  3 files changed, 30 insertions(+), 4 deletions(-)

> +++ b/qapi/block-core.json
> @@ -1239,11 +1239,16 @@
>  #  corresponding block device on it's close. Default is false.
>  #  For block-dirty-bitmap-add. (Since 2.8)
>  #
> +# @autoload: #optional the bitmap will be autoloaded on it's storage image

s/it's/its/

> +#open. This flag is only for persistent bitmap and needed to 
> inform

s/bitmap/bitmaps,/
s/needed/is needed/

> +#block driver that bitmap should be autoloaded on the next image

s/block/the block/
s/bitmap/the bitmap/


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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 16/22] qmp: add persistent flag to block-dirty-bitmap-add

[Eric Blake]

On 09/30/2016 05:53 AM, Vladimir Sementsov-Ogievskiy wrote:
> Add optional 'persistent' flag to qmp command block-dirty-bitmap-add.
> Default is false.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Signed-off-by: Denis V. Lunev 
> ---
>  blockdev.c   | 12 +++-
>  qapi/block-core.json |  7 ++-
>  qmp-commands.hx  |  5 -

This and later patches have conflicts with recent changes in the tree
that removed qmp-commands.hx; hopefully shouldn't impact review of this
series too badly.

> +++ b/qapi/block-core.json
> @@ -1235,10 +1235,15 @@
>  # @granularity: #optional the bitmap granularity, default is 64k for
>  #   block-dirty-bitmap-add
>  #
> +# @persistent: #optional the bitmap is persistent, i.e. it will be saved to
> +#  corresponding block device on it's close. Default is false.

s/corresponding/the corresponding/
s/it's/its/

("it's" is only appropriate if you can substitute "it is" or "it has")


> @@ -1458,6 +1458,9 @@ Arguments:
>  - "node": device/node on which to create dirty bitmap (json-string)
>  - "name": name of the new dirty bitmap (json-string)
>  - "granularity": granularity to track writes with (int, optional)
> +- "persistent": bitmap will be saved to corresponding block device
> +on it's close. Block driver should maintain persistent 
> bitmaps

One nice benefit of rebasing on top of qmp-commands.hx being removed is
that you don't have to repeat yourself :)

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 12/22] qcow2-bitmap: add IN_USE flag

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> This flag means that the bitmap is now in use by the software or was not
> successfully saved. In any way, with this flag set the bitmap data must
> be considered inconsistent and should not be loaded.
> 
> With current implementation this flag is never set, as we just remove
> bitmaps from the image after loading. But it defined in qcow2 spec and
> must be handled. Also, it can be used in future, if async schemes of
> bitmap loading/saving are implemented.
> 
> We also remove in-use bitmaps from the image on open.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2-bitmap.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)

Don't you want to make use of this flag? It would appear useful to me if
you just marked autoload bitmaps as in_use instead of deleting them from
the image when it's opened and then overwrite them when the image is closed.

> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index a5be25a..8cf40f0 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -28,6 +28,7 @@
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
>  #include "qemu/cutils.h"
> +#include "exec/log.h"
>  
>  #include "block/block_int.h"
>  #include "block/qcow2.h"
> @@ -44,7 +45,8 @@
>  #define BME_MAX_NAME_SIZE 1023
>  
>  /* Bitmap directory entry flags */
> -#define BME_RESERVED_FLAGS 0xfffd
> +#define BME_RESERVED_FLAGS 0xfffc
> +#define BME_FLAG_IN_USE 1

This should be (1U << 0) to be consistent with the definition of
BME_FLAG_AUTO.

>  #define BME_FLAG_AUTO   (1U << 1)
>  
>  /* bits [1, 8] U [56, 63] are reserved */
> @@ -287,6 +289,11 @@ static BdrvDirtyBitmap *load_bitmap(BlockDriverState *bs,
>  BdrvDirtyBitmap *bitmap = NULL;
>  char *name = g_strndup(dir_entry_name_notcstr(entry), entry->name_size);
>  
> +if (entry->flags & BME_FLAG_IN_USE) {
> +error_setg(errp, "Bitmap '%s' is in use", name);
> +goto fail;
> +}
> +
>  ret = bitmap_table_load(bs, entry, &bitmap_table);
>  if (ret < 0) {
>  error_setg_errno(errp, -ret,
> @@ -533,6 +540,14 @@ int qcow2_read_bitmaps(BlockDriverState *bs, Error 
> **errp)
>  for_each_bitmap_dir_entry(e, dir, dir_size) {
>  uint32_t fl = e->flags;
>  
> +if (fl & BME_FLAG_IN_USE) {
> +qemu_log("qcow2 warning: "
> + "removing in_use bitmap '%.*s' for image %s.\n",
> + e->name_size, (char *)(e + 1), 
> bdrv_get_device_or_node_name(bs));

I'm not sure whether qemu_log() is the right way to do this. I think
fprintf() to stderr might actually be more appropriate. qemu_log() looks
like it's mostly used for debugging purposes.

Also, this is not a warning. You are just doing it. You are not warning
someone about a cliff when he's already fallen off.

But you can actually make it a warning: Just leave the bitmap in the
image (maybe someone can do something with it?) and instead let qemu-img
check clean it up. The warning should then just be "Warning: Ignoring
in_use bitmap %.*s, use qemu-img check -r all to delete it".

Max

> +
> +continue;
> +}
> +
>  if (fl & BME_FLAG_AUTO) {
>  BdrvDirtyBitmap *bitmap = load_bitmap(bs, e, errp);
>  if (bitmap == NULL) {
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 09/22] block: introduce persistent dirty bitmaps

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> New field BdrvDirtyBitmap.persistent means, that bitmap should be saved
> on bdrv_close, using format driver. Format driver should maintain bitmap
> storing.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block.c  | 30 ++
>  block/dirty-bitmap.c | 27 +++
>  block/qcow2-bitmap.c |  1 +
>  include/block/block.h|  2 ++
>  include/block/block_int.h|  2 ++
>  include/block/dirty-bitmap.h |  6 ++
>  6 files changed, 68 insertions(+)

[...]

> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
> index 623e1d1..0314581 100644
> --- a/block/dirty-bitmap.c
> +++ b/block/dirty-bitmap.c

[...]

> @@ -555,3 +559,26 @@ bool bdrv_dirty_bitmap_get_autoload(const 
> BdrvDirtyBitmap *bitmap)
>  {
>  return bitmap->autoload;
>  }
> +
> +void bdrv_dirty_bitmap_set_persistance(BdrvDirtyBitmap *bitmap,
> +bool persistent)
> +{
> +bitmap->persistent = persistent;

After some thinking, I think this function should be more complex: It
should check whether the node the bitmap is attached to actually can
handle persistent bitmaps and whether it would actually support storing
*this* bitmap.

For instance, a qcow2 node would not support writing overly large
bitmaps (limited by BME_MAX_TABLE_SIZE and BME_MAX_PHYS_SIZE) or bitmaps
with overly large granularities (BME_MAX_GRANULARITY_BITS) or bitmaps
whose name is already occupied by some bitmap that is already stored in
the file but has not been loaded.

Checking this here will trivially prevent users from creating such
bitmaps and will also preempt detection of such failures during
bdrv_close() when they cannot be handled gracefully.

Max

> +}



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 07/22] qcow2-bitmap: introduce auto-loading bitmaps

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> Auto loading bitmaps are bitmaps in Qcow2, with AUTO flag set. They are
> loaded at image open and becomes BdrvDirtyBitmap's for corresponding
> drive. These bitmaps are deleted from Qcow2 image after loading to avoid
> conflicts.
> 
> Extra data in bitmaps is not supported for now.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2-bitmap.c | 518 
> ++-
>  block/qcow2.c|   5 +
>  block/qcow2.h|   3 +
>  3 files changed, 525 insertions(+), 1 deletion(-)
> 
> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index cd18b07..760a047 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c

[...]

> +static int directory_update(BlockDriverState *bs, uint8_t *new_dir,
> +size_t new_size, uint32_t new_nb_bitmaps)
> +{
> +BDRVQcow2State *s = bs->opaque;
> +int ret;
> +int64_t new_offset = 0;
> +uint64_t old_offset = s->bitmap_directory_offset;
> +uint64_t old_size = s->bitmap_directory_size;
> +uint32_t old_nb_bitmaps = s->nb_bitmaps;
> +uint64_t old_autocl = s->autoclear_features;
> +
> +if (new_size > QCOW_MAX_DIRTY_BITMAP_DIRECTORY_SIZE) {
> +return -EINVAL;
> +}
> +
> +if ((new_size == 0) != (new_nb_bitmaps == 0)) {
> +return -EINVAL;
> +}
> +
> +if (new_nb_bitmaps > 0) {
> +new_offset = directory_write(bs, new_dir, new_size);
> +if (new_offset < 0) {
> +return new_offset;
> +}
> +
> +ret = bdrv_flush(bs);
> +if (ret < 0) {
> +goto fail;
> +}
> +}
> +s->bitmap_directory_offset = new_offset;
> +s->bitmap_directory_size = new_size;
> +s->nb_bitmaps = new_nb_bitmaps;
> +
> +ret = update_header_sync(bs);
> +if (ret < 0) {
> +goto fail;
> +}
> +
> +if (old_size) {
> +qcow2_free_clusters(bs, old_offset, old_size, QCOW2_DISCARD_ALWAYS);
> +}
> +
> +return 0;
> +
> +fail:
> +if (new_offset > 0) {
> +qcow2_free_clusters(bs, new_offset, new_size, QCOW2_DISCARD_ALWAYS);
> +s->bitmap_directory_offset = old_offset;
> +s->bitmap_directory_size = old_size;
> +s->nb_bitmaps = old_nb_bitmaps;
> +s->autoclear_features = old_autocl;

What if bdrv_flush() in update_header_sync() failed? Then you cannot be
sure what bitmap directory the header is actually pointing to. In that
case, it would be wrong to assume it's still pointing to the old one and
freeing the new one.

Max

> +}
> +
> +return ret;
> +}



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 11/22] qcow2-bitmap: add qcow2_store_persistent_bitmaps()

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> Realize block bitmap stroing interface, to allow qcow2 images store
> persistent bitmaps.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2-bitmap.c | 241 
> +++
>  block/qcow2.c|   2 +
>  block/qcow2.h|   2 +
>  3 files changed, 245 insertions(+)
> 
> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index 81520cd..a5be25a 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -27,6 +27,7 @@
>  
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
> +#include "qemu/cutils.h"
>  
>  #include "block/block_int.h"
>  #include "block/qcow2.h"
> @@ -96,6 +97,15 @@ static inline void bitmap_table_to_cpu(uint64_t 
> *bitmap_table, size_t size)
>  }
>  }
>  
> +static inline void bitmap_table_to_be(uint64_t *bitmap_table, size_t size)
> +{
> +size_t i;
> +
> +for (i = 0; i < size; ++i) {
> +cpu_to_be64s(&bitmap_table[i]);
> +}
> +}
> +
>  static inline int calc_dir_entry_size(size_t name_size, size_t 
> extra_data_size)
>  {
>  return align_offset(sizeof(Qcow2BitmapDirEntry) +
> @@ -564,3 +574,234 @@ out:
>  
>  return ret;
>  }
> +
> +/* store_bitmap_data()
> + * Store bitmap to image, filling bitamp table accordingly.

s/bitamp/bitmap/

> + */
> +static int store_bitmap_data(BlockDriverState *bs, BdrvDirtyBitmap *bitmap,
> + uint64_t *bitmap_table, uint32_t 
> bitmap_table_size)
> +{
> +int ret;
> +BDRVQcow2State *s = bs->opaque;
> +uint64_t sector, dsc;
> +uint64_t bm_size = bdrv_dirty_bitmap_size(bitmap);
> +int cl_size = s->cluster_size;

Once more, I don't think this variable is necessary, and I feel like it
makes reading the code more difficult for no gain.

> +uint8_t *buf = NULL;
> +uint32_t tb_size =
> +size_to_clusters(s,
> +bdrv_dirty_bitmap_serialization_size(bitmap, 0, bm_size));

Should be uint64_t or you might accidentally get a truncation here. I'm
not sure how you would get such huge bitmaps but it's trivial to use
uint64_t.

> +
> +BdrvDirtyBitmapIter *dbi;
> +
> +if (tb_size != bitmap_table_size) {
> +return -EINVAL;
> +}
> +
> +memset(bitmap_table, 0, bitmap_table_size * sizeof(bitmap_table[0]));

On 32 bit machines, this multiplication can overflow. There should at
least be an assertion to prevent this. Other than that, of course, there
needs to be some place which limits bitmap_table_size to some sane value
and emits a real error if it exceeds that value.

> +
> +dbi = bdrv_dirty_iter_new(bitmap, 0);
> +buf = g_malloc(cl_size);
> +dsc = dirty_sectors_in_cluster(s, bitmap);
> +
> +while ((sector = bdrv_dirty_iter_next(dbi)) != -1) {

sector should be int64_t instead of uint64_t, then.

> +uint64_t cluster = sector / dsc;
> +sector = cluster * dsc;

Our coding style does not allow interleaving declarations and
non-declarations.

> +uint64_t end = MIN(bm_size, sector + dsc);
> +uint64_t write_size =
> +bdrv_dirty_bitmap_serialization_size(bitmap, sector, end - 
> sector);
> +
> +int64_t off = qcow2_alloc_clusters(bs, cl_size);
> +if (off < 0) {
> +ret = off;
> +goto finish;
> +}
> +bitmap_table[cluster] = off;
> +
> +bdrv_dirty_bitmap_serialize_part(bitmap, buf, sector, end);

s/end/end - sector/?

> +if (write_size < cl_size) {
> +memset(buf + write_size, 0, cl_size - write_size);
> +}
> +

I guess there should be a metadata overlap check here.

> +ret = bdrv_pwrite(bs->file, off, buf, cl_size);
> +if (ret < 0) {
> +goto finish;
> +}
> +
> +if (end >= bm_size) {
> +break;
> +}
> +
> +bdrv_set_dirty_iter(dbi, end);
> +}
> +ret = 0; /* writes */

What is that comment supposed to mean?

> +
> +finish:
> +if (ret < 0) {
> +clear_bitmap_table(bs, bitmap_table, bitmap_table_size);
> +}
> +g_free(buf);
> +bdrv_dirty_iter_free(dbi);
> +
> +return ret;

In case you decide to keep BME_MAX_PHYS_SIZE, this function should check
somewhere that the physical size of the bitmap does not exceed that value.

> +}
> +
> +/* store_bitmap()
> + * Store bitmap to qcow2 and set bitmap_table. bitmap_table itself is not
> + * stored to qcow2.

First of all, there is no parameter called "bitmap_table", and second,
yes, the bitmap table is written to the qcow2 file.

> + */
> +static int store_bitmap(BlockDriverState *bs,
> +BdrvDirtyBitmap *bitmap,
> +Qcow2BitmapDirEntry *entry)
> +{
> +int ret;
> +BDRVQcow2State *s = bs->opaque;
> +uint64_t bm_size = bdrv_dirty_bitmap_size(bitmap);
> +const char *bm_name = bdrv_dirty_bitmap_name(bitmap);
> +
> +uint64_t *tb;
> +int64_t tb_offset;
> +ui

Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Fri, 7 Oct 2016 10:46:22 +0530
Kirti Wankhede  wrote:

> Ping..
> 
> Pulling the questions at the top.
> 
> >> Will libvirt report 'description' RO attribute, its output would be
> >> string, so that user could be able to see the configuration of that
> >> profile?
> >>  
> >
> > Daniel,
> > Waiting for your input on this.
> >  
> >> We can have 'class' as optional attribute. So Intel don't have to
> >> provide 'class' attribute and they don't have to specify mandatory
> >> attributes of that class. We would provide 'class' attribute and provide
> >> mandatory attributes.  

Hi Kirti,

I would proceed with your design and posting, this is not a
sufficiently significant issue to delay a new version.  The next
posting will likely not be the last, more feedback will come.

Personally I don't see an issue.  We should have a small number
of mandatory sysfs interfaces for mdev devices, essentially just
enough to manage the life cycle of a device, even if it requires
vendor specific knowledge to understand the exact composition of
that device.  Some sort of human readable description seems like
a reasonable optional feature for a userspace tool like libvirt
to take advantage of.  A class definition with an available set
of attributes per class would clearly enhance the ability of a
userspace tool to understand the device, but does not seem
strictly required for managing the device.  Thanks,

Alex

[Qemu-devel] [PATCH 2/4] target-ppc: implement vnegw/d instructions

[Nikunj A Dadhania]

Vector Integer Negate Instructions:

vnegw: Vector Negate Word
vnegd: Vector Negate Doubleword

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/helper.h |  2 ++
 target-ppc/int_helper.c | 12 
 target-ppc/translate/vmx-impl.inc.c |  2 ++
 target-ppc/translate/vmx-ops.inc.c  |  2 ++
 4 files changed, 18 insertions(+)

diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index 04c6421..5fcc546 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -272,6 +272,8 @@ DEF_HELPER_2(vextsh2w, void, avr, avr)
 DEF_HELPER_2(vextsb2d, void, avr, avr)
 DEF_HELPER_2(vextsh2d, void, avr, avr)
 DEF_HELPER_2(vextsw2d, void, avr, avr)
+DEF_HELPER_2(vnegw, void, avr, avr)
+DEF_HELPER_2(vnegd, void, avr, avr)
 DEF_HELPER_2(vupkhpx, void, avr, avr)
 DEF_HELPER_2(vupklpx, void, avr, avr)
 DEF_HELPER_2(vupkhsb, void, avr, avr)
diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
index b393c30..76cf9b8 100644
--- a/target-ppc/int_helper.c
+++ b/target-ppc/int_helper.c
@@ -1949,6 +1949,18 @@ VEXT_SIGNED(vextsh2d, s64, UINT16_MAX, int16_t, int64_t)
 VEXT_SIGNED(vextsw2d, s64, UINT32_MAX, int32_t, int64_t)
 #undef VEXT_SIGNED
 
+#define VNEG(name, element, mask)   \
+void helper_##name(ppc_avr_t *r, ppc_avr_t *b)  \
+{   \
+int i;  \
+VECTOR_FOR_INORDER_I(i, element) {  \
+r->element[i] = (~(b->element[i]) + 1) & mask;  \
+}   \
+}
+VNEG(vnegw, s32, UINT32_MAX)
+VNEG(vnegd, s64, UINT64_MAX)
+#undef VNEG
+
 #define VSPLTI(suffix, element, splat_type) \
 void helper_vspltis##suffix(ppc_avr_t *r, uint32_t splat)   \
 {   \
diff --git a/target-ppc/translate/vmx-impl.inc.c 
b/target-ppc/translate/vmx-impl.inc.c
index c8998f3..563f101 100644
--- a/target-ppc/translate/vmx-impl.inc.c
+++ b/target-ppc/translate/vmx-impl.inc.c
@@ -815,6 +815,8 @@ GEN_VXFORM_NOA(vclzb, 1, 28)
 GEN_VXFORM_NOA(vclzh, 1, 29)
 GEN_VXFORM_NOA(vclzw, 1, 30)
 GEN_VXFORM_NOA(vclzd, 1, 31)
+GEN_VXFORM_NOA_2(vnegw, 1, 24, 6)
+GEN_VXFORM_NOA_2(vnegd, 1, 24, 7)
 GEN_VXFORM_NOA_2(vextsb2w, 1, 24, 16)
 GEN_VXFORM_NOA_2(vextsh2w, 1, 24, 17)
 GEN_VXFORM_NOA_2(vextsb2d, 1, 24, 24)
diff --git a/target-ppc/translate/vmx-ops.inc.c 
b/target-ppc/translate/vmx-ops.inc.c
index 68cba3e..ab64ab2 100644
--- a/target-ppc/translate/vmx-ops.inc.c
+++ b/target-ppc/translate/vmx-ops.inc.c
@@ -215,6 +215,8 @@ GEN_VXFORM_DUAL_INV(vspltish, vinserth, 6, 13, 0x, 
0x10,
 GEN_VXFORM_DUAL_INV(vspltisw, vinsertw, 6, 14, 0x, 0x10,
PPC_ALTIVEC),
 GEN_VXFORM_300_EXT(vinsertd, 6, 15, 0x10),
+GEN_VXFORM_300_EO(vnegw, 0x01, 0x18, 0x06),
+GEN_VXFORM_300_EO(vnegd, 0x01, 0x18, 0x07),
 GEN_VXFORM_300_EO(vextsb2w, 0x01, 0x18, 0x10),
 GEN_VXFORM_300_EO(vextsh2w, 0x01, 0x18, 0x11),
 GEN_VXFORM_300_EO(vextsb2d, 0x01, 0x18, 0x18),
-- 
2.7.4

[Qemu-devel] [PATCH 4/4] target-ppc: Add xscmp[eq, gt, ge, ne]dp instructions

[Nikunj A Dadhania]

From: Sandipan Das 

xscmpeqdp: VSX Scalar Compare Equal Double-Precision
xscmpgedp: VSX Scalar Compare Greater Than or Equal Double-Precision
xscmpgtdp: VSX Scalar Compare Greater Than Double-Precision
xscmpnedp: VSX Scalar Compare Not Equal Double-Precision

Signed-off-by: Sandipan Das 
[ Fix LE case using msr_le ]
Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/fpu_helper.c | 48 +
 target-ppc/helper.h |  4 
 target-ppc/translate/vsx-impl.inc.c |  4 
 target-ppc/translate/vsx-ops.inc.c  |  4 
 4 files changed, 60 insertions(+)

diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
index b0760f0..87c17d9 100644
--- a/target-ppc/fpu_helper.c
+++ b/target-ppc/fpu_helper.c
@@ -2362,6 +2362,54 @@ VSX_MADD(xvnmaddmsp, 4, float32, VsrW(i), NMADD_FLGS, 0, 
0, 0)
 VSX_MADD(xvnmsubasp, 4, float32, VsrW(i), NMSUB_FLGS, 1, 0, 0)
 VSX_MADD(xvnmsubmsp, 4, float32, VsrW(i), NMSUB_FLGS, 0, 0, 0)
 
+/* VSX_SCALAR_CMP_DP - VSX scalar floating point compare double precision
+ *   op- instruction mnemonic
+ *   cmp   - comparison operation
+ *   exp   - expected result of comparison
+ *   svxvc - set VXVC bit
+ */
+#define VSX_SCALAR_CMP_DP(op, cmp, exp, svxvc)\
+void helper_##op(CPUPPCState *env, uint32_t opcode)   \
+{ \
+ppc_vsr_t xt, xa, xb; \
+  \
+getVSR(xA(opcode), &xa, env); \
+getVSR(xB(opcode), &xb, env); \
+getVSR(xT(opcode), &xt, env); \
+  \
+if (unlikely(float64_is_any_nan(xa.VsrD(0)) ||\
+ float64_is_any_nan(xb.VsrD(0 {   \
+if (float64_is_signaling_nan(xa.VsrD(0), &env->fp_status) ||  \
+float64_is_signaling_nan(xb.VsrD(0), &env->fp_status)) {  \
+float_invalid_op_excp(env, POWERPC_EXCP_FP_VXSNAN, 0);\
+} \
+if (svxvc) {  \
+float_invalid_op_excp(env, POWERPC_EXCP_FP_VXVC, 0);  \
+} \
+} else {  \
+if (float64_##cmp(xb.VsrD(0), xa.VsrD(0), &env->fp_status) == exp) {  \
+if (msr_le) { \
+xt.VsrD(0) = 0;   \
+xt.VsrD(1) = -1;  \
+} else {  \
+xt.VsrD(0) = -1;  \
+xt.VsrD(1) = 0;   \
+} \
+} else {  \
+xt.VsrD(0) = 0;   \
+xt.VsrD(1) = 0;   \
+} \
+} \
+  \
+putVSR(xT(opcode), &xt, env); \
+helper_float_check_status(env);   \
+}
+
+VSX_SCALAR_CMP_DP(xscmpeqdp, eq, 1, 0)
+VSX_SCALAR_CMP_DP(xscmpgedp, le, 1, 1)
+VSX_SCALAR_CMP_DP(xscmpgtdp, lt, 1, 1)
+VSX_SCALAR_CMP_DP(xscmpnedp, eq, 0, 0)
+
 #define VSX_SCALAR_CMP(op, ordered)  \
 void helper_##op(CPUPPCState *env, uint32_t opcode)  \
 {\
diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index 5fcc546..0337292 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -389,6 +389,10 @@ DEF_HELPER_2(xsnmaddadp, void, env, i32)
 DEF_HELPER_2(xsnmaddmdp, void, env, i32)
 DEF_HELPER_2(xsnmsubadp, void, env, i32)
 DEF_HELPER_2(xsnmsubmdp, void, env, i32)
+DEF_HELPER_2(xscmpeqdp, void, env, i32)
+DEF_HELPER_2(xscmpgtdp, void, env, i32)
+DEF_HELPER_2(xscmpgedp, void, env, i32)
+DEF_HELPER_2(xscmpnedp, void, env, i32)
 DEF_HELPER_2(xscmpodp, void, env, i32)
 DEF_HELPER_2(xscmpudp, void, env, 

[Qemu-devel] [PATCH 3/4] target-ppc: implement xxbr[qdwh] instruction

[Nikunj A Dadhania]

Add required helpers (GEN_XX2FORM_EO) for supporting this instruction.

xxbrh: VSX Vector Byte-Reverse Halfword
xxbrw: VSX Vector Byte-Reverse Word
xxbrd: VSX Vector Byte-Reverse Doubleword
xxbrq: VSX Vector Byte-Reverse Quadword

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/translate.c  | 32 
 target-ppc/translate/vsx-impl.inc.c | 74 +
 target-ppc/translate/vsx-ops.inc.c  |  8 
 3 files changed, 114 insertions(+)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index dab8f19..94989b2 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -376,6 +376,9 @@ GEN_OPCODE2(name, onam, opc1, opc2, opc3, inval, type, 
type2)
 #define GEN_HANDLER_E_2(name, opc1, opc2, opc3, opc4, inval, type, type2) \
 GEN_OPCODE3(name, opc1, opc2, opc3, opc4, inval, type, type2)
 
+#define GEN_HANDLER2_E_2(name, onam, opc1, opc2, opc3, opc4, inval, typ, typ2) 
\
+GEN_OPCODE4(name, onam, opc1, opc2, opc3, opc4, inval, typ, typ2)
+
 typedef struct opcode_t {
 unsigned char opc1, opc2, opc3, opc4;
 #if HOST_LONG_BITS == 64 /* Explicitly align to 64 bits */
@@ -662,6 +665,21 @@ EXTRACT_HELPER(IMM8, 11, 8);
 },\
 .oname = stringify(name), \
 }
+#define GEN_OPCODE4(name, onam, op1, op2, op3, op4, invl, _typ, _typ2)\
+{ \
+.opc1 = op1,  \
+.opc2 = op2,  \
+.opc3 = op3,  \
+.opc4 = op4,  \
+.handler = {  \
+.inval1  = invl,  \
+.type = _typ, \
+.type2 = _typ2,   \
+.handler = &gen_##name,   \
+.oname = onam,\
+},\
+.oname = onam,\
+}
 #else
 #define GEN_OPCODE(name, op1, op2, op3, invl, _typ, _typ2)\
 { \
@@ -720,6 +738,20 @@ EXTRACT_HELPER(IMM8, 11, 8);
 },\
 .oname = stringify(name), \
 }
+#define GEN_OPCODE4(name, onam, op1, op2, op3, op4, invl, _typ, _typ2)\
+{ \
+.opc1 = op1,  \
+.opc2 = op2,  \
+.opc3 = op3,  \
+.opc4 = op4,  \
+.handler = {  \
+.inval1  = invl,  \
+.type = _typ, \
+.type2 = _typ2,   \
+.handler = &gen_##name,   \
+},\
+.oname = onam,\
+}
 #endif
 
 /* SPR load/store helpers */
diff --git a/target-ppc/translate/vsx-impl.inc.c 
b/target-ppc/translate/vsx-impl.inc.c
index 23ec1e1..d510842 100644
--- a/target-ppc/translate/vsx-impl.inc.c
+++ b/target-ppc/translate/vsx-impl.inc.c
@@ -132,6 +132,22 @@ static void gen_bswap16x8(TCGv_i64 outh, TCGv_i64 outl,
 tcg_temp_free_i64(mask);
 }
 
+static void gen_bswap32x4(TCGv_i64 outh, TCGv_i64 outl,
+  TCGv_i64 inh, TCGv_i64 inl)
+{
+TCGv_i64 hi = tcg_temp_new_i64();
+TCGv_i64 lo = tcg_temp_new_i64();
+
+tcg_gen_bswap64_i64(hi, inh);
+tcg_gen_bswap64_i64(lo, inl);
+tcg_gen_shri_i64(outh, hi, 32);
+tcg_gen_deposit_i64(outh, outh, hi, 32, 32);
+tcg_gen_shri_i64(outl, lo, 32);
+tcg_gen_deposit_i64(outl, outl, lo, 32, 32);
+
+tcg_temp_free_i64(hi);
+tcg_temp_free_i64(lo);
+}
 static void gen_lxvh8x(DisasContext *ctx)
 {
 TCGv EA;
@@ -717,6 +733,64 @@ GEN_VSX_HELPER_2(xvrspim, 0x12, 0x0B, 0, PPC2_VSX)
 GEN_VSX_HELPER_2(xvrspip, 0x12, 0x0A, 0, PPC2_VSX)
 GEN_VSX_HELPER_2

[Qemu-devel] [PATCH 1/4] target-ppc: implement vexts[bh]2w and vexts[bhw]2d

[Nikunj A Dadhania]

Vector Extend Sign Instructions:

vextsb2w: Vector Extend Sign Byte To Word
vextsh2w: Vector Extend Sign Halfword To Word
vextsb2d: Vector Extend Sign Byte To Doubleword
vextsh2d: Vector Extend Sign Halfword To Doubleword
vextsw2d: Vector Extend Sign Word To Doubleword

Signed-off-by: Nikunj A Dadhania 
---
 target-ppc/helper.h |  5 +
 target-ppc/int_helper.c | 15 +++
 target-ppc/translate/vmx-impl.inc.c |  5 +
 target-ppc/translate/vmx-ops.inc.c  |  5 +
 4 files changed, 30 insertions(+)

diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index 796ad45..04c6421 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -267,6 +267,11 @@ DEF_HELPER_3(vinsertb, void, avr, avr, i32)
 DEF_HELPER_3(vinserth, void, avr, avr, i32)
 DEF_HELPER_3(vinsertw, void, avr, avr, i32)
 DEF_HELPER_3(vinsertd, void, avr, avr, i32)
+DEF_HELPER_2(vextsb2w, void, avr, avr)
+DEF_HELPER_2(vextsh2w, void, avr, avr)
+DEF_HELPER_2(vextsb2d, void, avr, avr)
+DEF_HELPER_2(vextsh2d, void, avr, avr)
+DEF_HELPER_2(vextsw2d, void, avr, avr)
 DEF_HELPER_2(vupkhpx, void, avr, avr)
 DEF_HELPER_2(vupklpx, void, avr, avr)
 DEF_HELPER_2(vupkhsb, void, avr, avr)
diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
index 202854f..b393c30 100644
--- a/target-ppc/int_helper.c
+++ b/target-ppc/int_helper.c
@@ -1934,6 +1934,21 @@ VEXTRACT(uw, u32)
 VEXTRACT(d, u64)
 #undef VEXTRACT
 
+#define VEXT_SIGNED(name, element, mask, cast, recast)  \
+void helper_##name(ppc_avr_t *r, ppc_avr_t *b)  \
+{   \
+int i;  \
+VECTOR_FOR_INORDER_I(i, element) {  \
+r->element[i] = (recast)((cast)(b->element[i] & mask)); \
+}   \
+}
+VEXT_SIGNED(vextsb2w, s32, UINT8_MAX, char, int32_t)
+VEXT_SIGNED(vextsb2d, s64, UINT8_MAX, char, int64_t)
+VEXT_SIGNED(vextsh2w, s32, UINT16_MAX, int16_t, int32_t)
+VEXT_SIGNED(vextsh2d, s64, UINT16_MAX, int16_t, int64_t)
+VEXT_SIGNED(vextsw2d, s64, UINT32_MAX, int32_t, int64_t)
+#undef VEXT_SIGNED
+
 #define VSPLTI(suffix, element, splat_type) \
 void helper_vspltis##suffix(ppc_avr_t *r, uint32_t splat)   \
 {   \
diff --git a/target-ppc/translate/vmx-impl.inc.c 
b/target-ppc/translate/vmx-impl.inc.c
index 25cd073..c8998f3 100644
--- a/target-ppc/translate/vmx-impl.inc.c
+++ b/target-ppc/translate/vmx-impl.inc.c
@@ -815,6 +815,11 @@ GEN_VXFORM_NOA(vclzb, 1, 28)
 GEN_VXFORM_NOA(vclzh, 1, 29)
 GEN_VXFORM_NOA(vclzw, 1, 30)
 GEN_VXFORM_NOA(vclzd, 1, 31)
+GEN_VXFORM_NOA_2(vextsb2w, 1, 24, 16)
+GEN_VXFORM_NOA_2(vextsh2w, 1, 24, 17)
+GEN_VXFORM_NOA_2(vextsb2d, 1, 24, 24)
+GEN_VXFORM_NOA_2(vextsh2d, 1, 24, 25)
+GEN_VXFORM_NOA_2(vextsw2d, 1, 24, 26)
 GEN_VXFORM_NOA_2(vctzb, 1, 24, 28)
 GEN_VXFORM_NOA_2(vctzh, 1, 24, 29)
 GEN_VXFORM_NOA_2(vctzw, 1, 24, 30)
diff --git a/target-ppc/translate/vmx-ops.inc.c 
b/target-ppc/translate/vmx-ops.inc.c
index ac1dc9b..68cba3e 100644
--- a/target-ppc/translate/vmx-ops.inc.c
+++ b/target-ppc/translate/vmx-ops.inc.c
@@ -215,6 +215,11 @@ GEN_VXFORM_DUAL_INV(vspltish, vinserth, 6, 13, 0x, 
0x10,
 GEN_VXFORM_DUAL_INV(vspltisw, vinsertw, 6, 14, 0x, 0x10,
PPC_ALTIVEC),
 GEN_VXFORM_300_EXT(vinsertd, 6, 15, 0x10),
+GEN_VXFORM_300_EO(vextsb2w, 0x01, 0x18, 0x10),
+GEN_VXFORM_300_EO(vextsh2w, 0x01, 0x18, 0x11),
+GEN_VXFORM_300_EO(vextsb2d, 0x01, 0x18, 0x18),
+GEN_VXFORM_300_EO(vextsh2d, 0x01, 0x18, 0x19),
+GEN_VXFORM_300_EO(vextsw2d, 0x01, 0x18, 0x1A),
 GEN_VXFORM_300_EO(vctzb, 0x01, 0x18, 0x1C),
 GEN_VXFORM_300_EO(vctzh, 0x01, 0x18, 0x1D),
 GEN_VXFORM_300_EO(vctzw, 0x01, 0x18, 0x1E),
-- 
2.7.4

[Qemu-devel] [PATCH 0/4] POWER9 TCG enablements - part6

[Nikunj A Dadhania]

This series contains 15 new instructions for POWER9 ISA3.0
   Vector Extend Sign
   Vector Integer Negate 
   VSX Scalar Compare
   Vector Byte-Reverse

Patches:
01:
vextsb2w: Vector Extend Sign Byte To Word
vextsh2w: Vector Extend Sign Halfword To Word
vextsb2d: Vector Extend Sign Byte To Doubleword
vextsh2d: Vector Extend Sign Halfword To Doubleword
vextsw2d: Vector Extend Sign Word To Doubleword
02:
vnegw: Vector Negate Word
vnegd: Vector Negate Doubleword
03:
xxbrh: VSX Vector Byte-Reverse Halfword
xxbrw: VSX Vector Byte-Reverse Word
xxbrd: VSX Vector Byte-Reverse Doubleword
xxbrq: VSX Vector Byte-Reverse Quadword
04:
xscmpeqdp: VSX Scalar Compare Equal Double-Precision
xscmpgedp: VSX Scalar Compare Greater Than or Equal Double-Precision
xscmpgtdp: VSX Scalar Compare Greater Than Double-Precision
xscmpnedp: VSX Scalar Compare Not Equal Double-Precision

Nikunj A Dadhania (3):
  target-ppc: implement vexts[bh]2w and vexts[bhw]2d
  target-ppc: implement vnegw/d instructions
  target-ppc: implement xxbr[qdwh] instruction

Sandipan Das (1):
  target-ppc: Add xscmp[eq,gt,ge,ne]dp instructions

 target-ppc/fpu_helper.c | 48 +++
 target-ppc/helper.h | 11 ++
 target-ppc/int_helper.c | 27 +
 target-ppc/translate.c  | 32 +++
 target-ppc/translate/vmx-impl.inc.c |  7 
 target-ppc/translate/vmx-ops.inc.c  |  7 
 target-ppc/translate/vsx-impl.inc.c | 78 +
 target-ppc/translate/vsx-ops.inc.c  | 12 ++
 8 files changed, 222 insertions(+)

-- 
2.7.4

Re: [Qemu-devel] [PATCH v5 00/12] Add runnability info to query-cpu-definitions

[Eduardo Habkost]

On Fri, Sep 30, 2016 at 03:49:34PM -0300, Eduardo Habkost wrote:
[...]
> Eduardo Habkost (12):
>   tests: Add test case for x86 feature parsing compatibility
>   target-i386: List CPU models using subclass list
>   target-i386: Disable VME by default with TCG
>   target-i386: Register aliases for feature names with underscores
>   target-i386: Make plus_features/minus_features QOM-based
>   target-i386: Remove underscores from feat_names arrays
>   target-i386: Register properties for feature aliases manually
>   target-i386: xsave: Add FP and SSE bits to x86_ext_save_areas

Patches 1-8 (above) were applied to x86-next. I will send v6 of
9-12 (below), with a small change.

>   target-i386: Move warning code outside x86_cpu_filter_features()
>   target-i386: x86_cpu_load_features() function
>   qmp: Add runnability information to query-cpu-definitions
>   target-i386: Return runnability information on query-cpu-definitions
> 
>  qapi-schema.json  |  23 +-
>  target-i386/cpu-qom.h |   4 +
>  target-i386/cpu.c | 510 
> ++
>  tests/test-x86-cpuid-compat.c |  44 
>  4 files changed, 388 insertions(+), 193 deletions(-)
> 
-- 
Eduardo

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 3/6] migration: extend VMStateInfo

[Dr. David Alan Gilbert]

* Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> 
> 
> On 10/07/2016 05:08 AM, Dr. David Alan Gilbert wrote:
> > * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> >> Current migration code cannot handle some data structures such as
> >> QTAILQ in qemu/queue.h. Here we extend the signatures of put/get
> >> in VMStateInfo so that customized handling is supported.
> >>
> >> Signed-off-by: Jianjun Duan 
> >> ---
> >>  hw/net/vmxnet3.c| 18 ++---
> >>  hw/nvram/eeprom93xx.c   |  6 ++-
> >>  hw/nvram/fw_cfg.c   |  6 ++-
> >>  hw/pci/msix.c   |  6 ++-
> >>  hw/pci/pci.c| 12 --
> >>  hw/pci/shpc.c   |  5 ++-
> >>  hw/scsi/scsi-bus.c  |  6 ++-
> >>  hw/timer/twl92230.c |  6 ++-
> >>  hw/usb/redirect.c   | 18 ++---
> >>  hw/virtio/virtio-pci.c  |  6 ++-
> >>  hw/virtio/virtio.c  |  6 ++-
> >>  include/migration/vmstate.h | 10 +++--
> >>  migration/savevm.c  |  5 ++-
> >>  migration/vmstate.c | 95 
> >> -
> >>  target-alpha/machine.c  |  5 ++-
> >>  target-arm/machine.c| 12 --
> >>  target-i386/machine.c   | 21 ++
> >>  target-mips/machine.c   | 10 +++--
> >>  target-ppc/machine.c| 10 +++--
> >>  target-sparc/machine.c  |  5 ++-
> >>  20 files changed, 171 insertions(+), 97 deletions(-)
> >>
> > 
> > 
> > 
> >> diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
> >> index 444672a..2ca4b46 100644
> >> --- a/hw/usb/redirect.c
> >> +++ b/hw/usb/redirect.c
> >> @@ -2154,7 +2154,8 @@ static int usbredir_post_load(void *priv, int 
> >> version_id)
> >>  }
> >>  
> >>  /* For usbredirparser migration */
> >> -static void usbredir_put_parser(QEMUFile *f, void *priv, size_t unused)
> >> +static void usbredir_put_parser(QEMUFile *f, void *priv, size_t unused,
> >> +void *opaque, QJSON *vmdesc)
> >>  {
> >>  USBRedirDevice *dev = priv;
> >>  uint8_t *data;
> >> @@ -2174,7 +2175,8 @@ static void usbredir_put_parser(QEMUFile *f, void 
> >> *priv, size_t unused)
> >>  free(data);
> >>  }
> >>  
> >> -static int usbredir_get_parser(QEMUFile *f, void *priv, size_t unused)
> >> +static int usbredir_get_parser(QEMUFile *f, void *priv, size_t unused,
> >> +   void *opaque)
> > 
> > Neither of these built for me; I had to change those to VMStateField rather 
> > than void *;
> > 
> > also is this series tested ontop of Halil's patches - because without them
> > I'm finding I also had to fix up most of the other virtio devices.
> > 
> > Dave
> 
> I built it on top of ppc-for-2.8 without problems. Is Hail's patch in
> ppc-for-2.8 yet?

I don't know about ppc-for-2.8;  patches for inclusion should work on the 
current
head unless stated otherwise.
Also, make sure you have the usbredir libraries installed and as much else as 
possible
to make sure you cover all the .get/.put functions - they're all over!

Dave

> Thanks,
> Jianjun
> 
> > 
> > 
> >>  USBRedirDevice *dev = priv;
> >>  uint8_t *data;
> >> @@ -2217,7 +2219,8 @@ static const VMStateInfo 
> >> usbredir_parser_vmstate_info = {
> >>  
> >>  
> >>  /* For buffered packets (iso/irq) queue migration */
> >> -static void usbredir_put_bufpq(QEMUFile *f, void *priv, size_t unused)
> >> +static void usbredir_put_bufpq(QEMUFile *f, void *priv, size_t unused,
> >> +   VMStateField *field, QJSON *vmdesc)
> >>  {
> >>  struct endp_data *endp = priv;
> >>  USBRedirDevice *dev = endp->dev;
> >> @@ -2237,7 +2240,8 @@ static void usbredir_put_bufpq(QEMUFile *f, void 
> >> *priv, size_t unused)
> >>  assert(i == endp->bufpq_size);
> >>  }
> >>  
> >> -static int usbredir_get_bufpq(QEMUFile *f, void *priv, size_t unused)
> >> +static int usbredir_get_bufpq(QEMUFile *f, void *priv, size_t unused,
> >> +  VMStateField *field)
> >>  {
> >>  struct endp_data *endp = priv;
> >>  USBRedirDevice *dev = endp->dev;
> >> @@ -2340,7 +2344,8 @@ static const VMStateDescription usbredir_ep_vmstate 
> >> = {
> >>  
> >>  
> >>  /* For PacketIdQueue migration */
> >> -static void usbredir_put_packet_id_q(QEMUFile *f, void *priv, size_t 
> >> unused)
> >> +static void usbredir_put_packet_id_q(QEMUFile *f, void *priv, size_t 
> >> unused,
> >> + VMStateField *field, QJSON *vmdesc)
> >>  {
> >>  struct PacketIdQueue *q = priv;
> >>  USBRedirDevice *dev = q->dev;
> >> @@ -2356,7 +2361,8 @@ static void usbredir_put_packet_id_q(QEMUFile *f, 
> >> void *priv, size_t unused)
> >>  assert(remain == 0);
> >>  }
> >>  
> >> -static int usbredir_get_packet_id_q(QEMUFile *f, void *priv, size_t 
> >> unused)
> >> +static int usbredir_get_packet_id_q(QEMUFile *f, void *priv, size_t 
> >> unused,
> >> +VMStateField *field)
> >>  {
> >>  struct PacketIdQueue *q = priv;
> >>

Re: [Qemu-devel] [PATCH v2 10/11] blockjob: refactor backup_start as backup_job_create

[John Snow]

On 09/30/2016 06:00 PM, John Snow wrote:

Refactor backup_start as backup_job_create, which only creates the job,
but does not automatically start it. The old interface, 'backup_start',
is not kept in favor of limiting the number of nearly-identical iterfaces
that would have to be edited to keep up with QAPI changes in the future.

Callers that wish to synchronously start the backup_block_job can
instead just call block_job_start immediately after calling
backup_job_create.

Transactions are updated to use the new interface, calling block_job_start
only during the .commit phase, which helps prevent race conditions where
jobs may finish before we even finish building the transaction. This may
happen, for instance, during empty block backup jobs.



Sadly for me, I realized this patch has a potential problem. When we 
were adding the bitmap operations, it became clear that the atomicity 
point was during .prepare, not .commit.


e.g. the bitmap is cleared or created during prepare, and backup_run 
installs its Write Notifier at that point in time, too.


By changing BlockJobs to only run on commit, we've severed the atomicity 
point such that some actions will take effect during prepare, and others 
at commit.


I still think it's the correct thing to do to delay the BlockJobs until 
the commit phase, so I will start auditing the code to see how hard it 
is to shift the atomicity point to commit instead. If it's possible to 
do that, I think from the POV of the managing application, having the 
atomicity point be


Feel free to chime in with suggestions and counterpoints until then.

--js


Reported-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: John Snow 
---
 block/backup.c| 26 ---
 block/replication.c   | 11 ---
 blockdev.c| 81 +++
 include/block/block_int.h | 21 ++--
 4 files changed, 86 insertions(+), 53 deletions(-)

diff --git a/block/backup.c b/block/backup.c
index 7294169..aad69eb 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -527,7 +527,7 @@ static const BlockJobDriver backup_job_driver = {
 .attached_aio_context   = backup_attached_aio_context,
 };

-void backup_start(const char *job_id, BlockDriverState *bs,
+BlockJob *backup_job_create(const char *job_id, BlockDriverState *bs,
   BlockDriverState *target, int64_t speed,
   MirrorSyncMode sync_mode, BdrvDirtyBitmap *sync_bitmap,
   bool compress,
@@ -546,52 +546,52 @@ void backup_start(const char *job_id, BlockDriverState 
*bs,

 if (bs == target) {
 error_setg(errp, "Source and target cannot be the same");
-return;
+return NULL;
 }

 if (!bdrv_is_inserted(bs)) {
 error_setg(errp, "Device is not inserted: %s",
bdrv_get_device_name(bs));
-return;
+return NULL;
 }

 if (!bdrv_is_inserted(target)) {
 error_setg(errp, "Device is not inserted: %s",
bdrv_get_device_name(target));
-return;
+return NULL;
 }

 if (compress && target->drv->bdrv_co_pwritev_compressed == NULL) {
 error_setg(errp, "Compression is not supported for this drive %s",
bdrv_get_device_name(target));
-return;
+return NULL;
 }

 if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_BACKUP_SOURCE, errp)) {
-return;
+return NULL;
 }

 if (bdrv_op_is_blocked(target, BLOCK_OP_TYPE_BACKUP_TARGET, errp)) {
-return;
+return NULL;
 }

 if (sync_mode == MIRROR_SYNC_MODE_INCREMENTAL) {
 if (!sync_bitmap) {
 error_setg(errp, "must provide a valid bitmap name for "
  "\"incremental\" sync mode");
-return;
+return NULL;
 }

 /* Create a new bitmap, and freeze/disable this one. */
 if (bdrv_dirty_bitmap_create_successor(bs, sync_bitmap, errp) < 0) {
-return;
+return NULL;
 }
 } else if (sync_bitmap) {
 error_setg(errp,
"a sync_bitmap was provided to backup_run, "
"but received an incompatible sync_mode (%s)",
MirrorSyncMode_lookup[sync_mode]);
-return;
+return NULL;
 }

 len = bdrv_getlength(bs);
@@ -638,8 +638,8 @@ void backup_start(const char *job_id, BlockDriverState *bs,
 bdrv_op_block_all(target, job->common.blocker);
 job->common.len = len;
 block_job_txn_add_job(txn, &job->common);
-block_job_start(&job->common);
-return;
+
+return &job->common;

  error:
 if (sync_bitmap) {
@@ -649,4 +649,6 @@ void backup_start(const char *job_id, BlockDriverState *bs,
 blk_unref(job->target);
 block_job_unref(&job->common);
 }
+
+return NULL;
 }
diff --git a/block/replication.c b/block/replication.c
index b604b93..d9cdc36 100644
--- a/block/replication

[Qemu-devel] [PULL v2 02/11] qapi: Fix crash when 'any' or 'null' parameter is missing

[Markus Armbruster]

From: Marc-André Lureau 

Unlike the other visit methods, visit_type_any() and visit_type_null()
neglect to check whether qmp_input_get_object() succeeded.  They crash
when it fails.  Reproducer:

{ "execute": "qom-set",
  "arguments": { "path": "/machine", "property": "rtc-time" } }

Will crash with:

qapi/qapi-visit-core.c:277: visit_type_any: Assertion `!err != !*obj'
failed

Broken in commit 5c678ee.  Fix by adding the missing error checks.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Eric Blake 
Message-Id: <20160922203927.28241-3-marcandre.lur...@redhat.com>
Reviewed-by: Markus Armbruster 
[Commit message rephrased]
Signed-off-by: Markus Armbruster 
---
 qapi/qmp-input-visitor.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index 64dd392..fc91e74 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -338,6 +338,12 @@ static void qmp_input_type_any(Visitor *v, const char 
*name, QObject **obj,
 QmpInputVisitor *qiv = to_qiv(v);
 QObject *qobj = qmp_input_get_object(qiv, name, true);
 
+if (!qobj) {
+error_setg(errp, QERR_MISSING_PARAMETER, name ? name : "null");
+*obj = NULL;
+return;
+}
+
 qobject_incref(qobj);
 *obj = qobj;
 }
@@ -347,6 +353,11 @@ static void qmp_input_type_null(Visitor *v, const char 
*name, Error **errp)
 QmpInputVisitor *qiv = to_qiv(v);
 QObject *qobj = qmp_input_get_object(qiv, name, true);
 
+if (!qobj) {
+error_setg(errp, QERR_MISSING_PARAMETER, name ? name : "null");
+return;
+}
+
 if (qobject_type(qobj) != QTYPE_QNULL) {
 error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "null",
"null");
-- 
2.5.5

[Qemu-devel] [PULL v2 06/11] qapi: return a 'missing parameter' error

[Markus Armbruster]

From: Marc-André Lureau 

The 'old' dispatch code returned a QERR_MISSING_PARAMETER for missing
parameters, but the qapi qmp_dispatch() code uses
QERR_INVALID_PARAMETER_TYPE.

Improve qapi code to return QERR_MISSING_PARAMETER where
appropriate.

Fix expected error message in iotests.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Alberto Garcia 
Reviewed-by: Eric Blake 
Message-Id: <20160930095948.3154-4-marcandre.lur...@redhat.com>
[Drop incorrect error_setg() from qmp_input_type_any() and
qmp_input_type_null()]
Reviewed-by: Markus Armbruster 
Signed-off-by: Markus Armbruster 
---
 qapi/qmp-input-visitor.c   | 67 +-
 tests/qemu-iotests/087.out |  2 +-
 2 files changed, 49 insertions(+), 20 deletions(-)

diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index fe097c9..37a8e1f 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -56,7 +56,7 @@ static QmpInputVisitor *to_qiv(Visitor *v)
 
 static QObject *qmp_input_get_object(QmpInputVisitor *qiv,
  const char *name,
- bool consume)
+ bool consume, Error **errp)
 {
 StackObject *tos;
 QObject *qobj;
@@ -80,6 +80,9 @@ static QObject *qmp_input_get_object(QmpInputVisitor *qiv,
 bool removed = g_hash_table_remove(tos->h, name);
 assert(removed);
 }
+if (!ret) {
+error_setg(errp, QERR_MISSING_PARAMETER, name);
+}
 } else {
 assert(qobject_type(qobj) == QTYPE_QLIST);
 assert(!name);
@@ -165,13 +168,16 @@ static void qmp_input_start_struct(Visitor *v, const char 
*name, void **obj,
size_t size, Error **errp)
 {
 QmpInputVisitor *qiv = to_qiv(v);
-QObject *qobj = qmp_input_get_object(qiv, name, true);
+QObject *qobj = qmp_input_get_object(qiv, name, true, errp);
 Error *err = NULL;
 
 if (obj) {
 *obj = NULL;
 }
-if (!qobj || qobject_type(qobj) != QTYPE_QDICT) {
+if (!qobj) {
+return;
+}
+if (qobject_type(qobj) != QTYPE_QDICT) {
 error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "null",
"QDict");
 return;
@@ -193,10 +199,13 @@ static void qmp_input_start_list(Visitor *v, const char 
*name,
  GenericList **list, size_t size, Error **errp)
 {
 QmpInputVisitor *qiv = to_qiv(v);
-QObject *qobj = qmp_input_get_object(qiv, name, true);
+QObject *qobj = qmp_input_get_object(qiv, name, true, errp);
 const QListEntry *entry;
 
-if (!qobj || qobject_type(qobj) != QTYPE_QLIST) {
+if (!qobj) {
+return;
+}
+if (qobject_type(qobj) != QTYPE_QLIST) {
 if (list) {
 *list = NULL;
 }
@@ -234,11 +243,10 @@ static void qmp_input_start_alternate(Visitor *v, const 
char *name,
   bool promote_int, Error **errp)
 {
 QmpInputVisitor *qiv = to_qiv(v);
-QObject *qobj = qmp_input_get_object(qiv, name, false);
+QObject *qobj = qmp_input_get_object(qiv, name, false, errp);
 
 if (!qobj) {
 *obj = NULL;
-error_setg(errp, QERR_MISSING_PARAMETER, name ? name : "null");
 return;
 }
 *obj = g_malloc0(size);
@@ -252,8 +260,13 @@ static void qmp_input_type_int64(Visitor *v, const char 
*name, int64_t *obj,
  Error **errp)
 {
 QmpInputVisitor *qiv = to_qiv(v);
-QInt *qint = qobject_to_qint(qmp_input_get_object(qiv, name, true));
+QObject *qobj = qmp_input_get_object(qiv, name, true, errp);
+QInt *qint;
 
+if (!qobj) {
+return;
+}
+qint = qobject_to_qint(qobj);
 if (!qint) {
 error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "null",
"integer");
@@ -268,8 +281,13 @@ static void qmp_input_type_uint64(Visitor *v, const char 
*name, uint64_t *obj,
 {
 /* FIXME: qobject_to_qint mishandles values over INT64_MAX */
 QmpInputVisitor *qiv = to_qiv(v);
-QInt *qint = qobject_to_qint(qmp_input_get_object(qiv, name, true));
+QObject *qobj = qmp_input_get_object(qiv, name, true, errp);
+QInt *qint;
 
+if (!qobj) {
+return;
+}
+qint = qobject_to_qint(qobj);
 if (!qint) {
 error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "null",
"integer");
@@ -283,8 +301,13 @@ static void qmp_input_type_bool(Visitor *v, const char 
*name, bool *obj,
 Error **errp)
 {
 QmpInputVisitor *qiv = to_qiv(v);
-QBool *qbool = qobject_to_qbool(qmp_input_get_object(qiv, name, true));
+QObject *qobj = qmp_input_get_object(qiv, name, true, errp);
+QBool *qbool;
 
+if (!qobj) {
+return;
+}
+qbool = qobject_to_qbool(qobj);
 if (!qbool) {
 error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name

[Qemu-devel] [PULL v2 09/11] qmp: Disable query-cpu-* commands when they're unavailable

[Markus Armbruster]

From: Eduardo Habkost 

Instead of requiring clients to actually call the query-cpu-*
commands to find out if they are implemented, remove them from
the output of "query-commands", so clients know they are not
available.

This is implemented by extending the existing hack at
qmp_unregister_commands_hack(). I wish I could avoid adding even
more #ifdefs to that code, but that's the solution we have today.

Signed-off-by: Eduardo Habkost 
Message-Id: <1475696941-8056-1-git-send-email-ehabk...@redhat.com>
Reviewed-by: Eric Blake 
Reviewed-by: Markus Armbruster 
Signed-off-by: Markus Armbruster 
---
 monitor.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/monitor.c b/monitor.c
index 83c4edf..4ff74b7 100644
--- a/monitor.c
+++ b/monitor.c
@@ -992,6 +992,15 @@ static void qmp_unregister_commands_hack(void)
 #ifndef TARGET_ARM
 qmp_unregister_command("query-gic-capabilities");
 #endif
+#if !defined(TARGET_S390X)
+qmp_unregister_command("query-cpu-model-expansion");
+qmp_unregister_command("query-cpu-model-baseline");
+qmp_unregister_command("query-cpu-model-comparison");
+#endif
+#if !defined(TARGET_PPC) && !defined(TARGET_ARM) && !defined(TARGET_I386) \
+&& !defined(TARGET_S390X)
+qmp_unregister_command("query-cpu-definitions");
+#endif
 }
 
 static void qmp_init_marshal(void)
-- 
2.5.5

[Qemu-devel] [PULL v2 05/11] qapi: assert list entry has a value

[Markus Armbruster]

From: Marc-André Lureau 

This helps to figure out the expectations.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Eric Blake 
Message-Id: <20160930095948.3154-3-marcandre.lur...@redhat.com>
Reviewed-by: Markus Armbruster 
Signed-off-by: Markus Armbruster 
---
 qapi/qmp-input-visitor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index c7deca9..fe097c9 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -84,6 +84,7 @@ static QObject *qmp_input_get_object(QmpInputVisitor *qiv,
 assert(qobject_type(qobj) == QTYPE_QLIST);
 assert(!name);
 ret = qlist_entry_obj(tos->entry);
+assert(ret);
 if (consume) {
 tos->entry = qlist_next(tos->entry);
 }
-- 
2.5.5

[Qemu-devel] [PULL v2 00/11] QAPI patches for 2016-10-07

[Markus Armbruster]

The following changes since commit a65b6f27ce65e2e4f771f69d549ffa455a4d543a:

  Merge remote-tracking branch 'remotes/dgilbert/tags/pull-hmp-20161004' into 
staging (2016-10-04 18:57:12 +0100)

are available in the git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2016-10-07

for you to fetch changes up to 77a6da267c37781331c2dc8c4ac7f68d46a2a461:

  docs: Belatedly update for move of QMP/* to docs/ (2016-10-07 19:22:11 +0200)


QAPI patches for 2016-10-07


Eduardo Habkost (1):
  qmp: Disable query-cpu-* commands when they're unavailable

Marc-André Lureau (5):
  qmp: fix object-add assert() without props
  qapi: Fix crash when 'any' or 'null' parameter is missing
  qapi: add assert about root value
  qapi: assert list entry has a value
  qapi: return a 'missing parameter' error

Markus Armbruster (5):
  tests/test-qmp-input-strict: Cover missing struct members
  MAINTAINERS: Pass the HMP staff from Luiz to David
  MAINTAINERS: Pass the QObject staff from Luiz to Markus
  docs: Belatedly update for move of qmp-commands.txt
  docs: Belatedly update for move of QMP/* to docs/

 MAINTAINERS |  9 +++--
 docs/qmp-commands.txt   |  2 +-
 docs/writing-qmp-commands.txt   |  4 +--
 docs/xen-save-devices-state.txt |  2 +-
 monitor.c   |  9 +
 qapi/qmp-input-visitor.c| 75 -
 qmp.c   |  8 +++--
 tests/qemu-iotests/087.out  |  2 +-
 tests/test-qmp-input-strict.c   | 46 +
 9 files changed, 129 insertions(+), 28 deletions(-)

-- 
2.5.5

Re: [Qemu-devel] [PULL 00/12] QAPI patches for 2016-10-07

[Markus Armbruster]

Peter Maydell  writes:

> On 7 October 2016 at 13:09, Markus Armbruster  wrote:
>> The following changes since commit a65b6f27ce65e2e4f771f69d549ffa455a4d543a:
>>
>>   Merge remote-tracking branch 'remotes/dgilbert/tags/pull-hmp-20161004' 
>> into staging (2016-10-04 18:57:12 +0100)
>>
>> are available in the git repository at:
>>
>>   git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2016-10-07
>>
>> for you to fetch changes up to 61fee8886034a5d983f4ae4aa74ddd947dfada1d:
>>
>>   docs: Belatedly update for move of QMP/* to docs/ (2016-10-07 11:07:59 
>> +0200)
>>
>> 
>> QAPI patches for 2016-10-07
>>
>
> Fails 'make check', all builds:
>
> TEST: tests/qmp-test... (pid=3799)
> qemu-system-aarch64: -machine accel=qtest: No machine specified, and
> there is no default
> Use -machine help to list supported machines
> socket_accept failed: Resource temporarily unavailable
> **
> ERROR:/home/petmay01/qemu/tests/libqtest.c:197:qtest_init: assertion
> failed: (s->fd >= 0 && s->qmp_fd >= 0)
> FAIL: tests/qmp-test
> make: *** [check-qtest-aarch64] Error 1

Uh, sorry.  v2 on its way.

[Qemu-devel] [PULL v2 08/11] MAINTAINERS: Pass the QObject staff from Luiz to Markus

[Markus Armbruster]

QObject is fairly tightly coupled to QAPI these days, and I've been
effectively maintaining it together with QAPI for a while.  Update
MAINTAINERS to reflect that.

Signed-off-by: Markus Armbruster 
Message-Id: <1475084022-30117-3-git-send-email-arm...@redhat.com>
Acked-by: Luiz Capitulino 
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 851cda7..5355a5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1245,8 +1245,8 @@ F: qapi/*.json
 T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QObject
-M: Luiz Capitulino 
-S: Maintained
+M: Markus Armbruster 
+S: Supported
 F: qobject/
 F: include/qapi/qmp/
 X: include/qapi/qmp/dispatch.h
@@ -1256,7 +1256,7 @@ F: tests/check-qint.c
 F: tests/check-qjson.c
 F: tests/check-qlist.c
 F: tests/check-qstring.c
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
+T: git git://repo.or.cz/qemu/armbru.git qapi-next
 
 QEMU Guest Agent
 M: Michael Roth 
-- 
2.5.5

[Qemu-devel] [PULL v2 01/11] qmp: fix object-add assert() without props

[Markus Armbruster]

From: Marc-André Lureau 

Since commit ad739706bbadee49, user_creatable_add_type() expects to be
given a qdict. However, if object-add is called without props, you reach
the assert: "qemu/qom/object_interfaces.c:115: user_creatable_add_type:
Assertion `qdict' failed.", because the qdict isn't created in this
case (it's optional).

Furthermore, qmp_input_visitor_new() is not meant to be called without a
dict, and a further commit will assert in this situation.

If none given, create an empty qdict in qmp to avoid the
user_creatable_add_type() assert(qdict).

Signed-off-by: Marc-André Lureau 
Reviewed-by: Eric Blake 
Message-Id: <20160922203927.28241-2-marcandre.lur...@redhat.com>
Tested-by: Xiao Long Jiang 
Reviewed-by: Markus Armbruster 
Signed-off-by: Markus Armbruster 
---
 qmp.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/qmp.c b/qmp.c
index 621f6ae..b3ba9ef 100644
--- a/qmp.c
+++ b/qmp.c
@@ -660,7 +660,7 @@ void qmp_add_client(const char *protocol, const char 
*fdname,
 void qmp_object_add(const char *type, const char *id,
 bool has_props, QObject *props, Error **errp)
 {
-const QDict *pdict = NULL;
+QDict *pdict;
 Visitor *v;
 Object *obj;
 
@@ -670,14 +670,18 @@ void qmp_object_add(const char *type, const char *id,
 error_setg(errp, QERR_INVALID_PARAMETER_TYPE, "props", "dict");
 return;
 }
+QINCREF(pdict);
+} else {
+pdict = qdict_new();
 }
 
-v = qmp_input_visitor_new(props, true);
+v = qmp_input_visitor_new(QOBJECT(pdict), true);
 obj = user_creatable_add_type(type, id, pdict, v, errp);
 visit_free(v);
 if (obj) {
 object_unref(obj);
 }
+QDECREF(pdict);
 }
 
 void qmp_object_del(const char *id, Error **errp)
-- 
2.5.5

[Qemu-devel] [PULL v2 11/11] docs: Belatedly update for move of QMP/* to docs/

[Markus Armbruster]

Missed in commit 7537fe0 and commit 9b89b6a.

Signed-off-by: Markus Armbruster 
Message-Id: <1475766600-7273-1-git-send-email-arm...@redhat.com>
Reviewed-by: Eric Blake 
---
 docs/qmp-commands.txt | 2 +-
 docs/writing-qmp-commands.txt | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/qmp-commands.txt b/docs/qmp-commands.txt
index e0adceb..b289391 100644
--- a/docs/qmp-commands.txt
+++ b/docs/qmp-commands.txt
@@ -20,7 +20,7 @@ Also, the following notation is used to denote data flow:
 -> data issued by the Client
 <- Server data response
 
-Please, refer to the QMP specification (QMP/qmp-spec.txt) for detailed
+Please, refer to the QMP specification (docs/qmp-spec.txt) for detailed
 information on the Server command and response formats.
 
 NOTE: This document is temporary and will be replaced soon.
diff --git a/docs/writing-qmp-commands.txt b/docs/writing-qmp-commands.txt
index cfa6fe7..44c14db 100644
--- a/docs/writing-qmp-commands.txt
+++ b/docs/writing-qmp-commands.txt
@@ -7,8 +7,8 @@ This document doesn't discuss QMP protocol level details, nor 
does it dive
 into the QAPI framework implementation.
 
 For an in-depth introduction to the QAPI framework, please refer to
-docs/qapi-code-gen.txt. For documentation about the QMP protocol, please
-check the files in QMP/.
+docs/qapi-code-gen.txt. For documentation about the QMP protocol,
+start with docs/qmp-intro.txt.
 
 == Overview ==
 
-- 
2.5.5

[Qemu-devel] [PULL v2 10/11] docs: Belatedly update for move of qmp-commands.txt

[Markus Armbruster]

Missed in commit d076a2a and commit bd6092e.

Signed-off-by: Markus Armbruster 
Message-Id: <1474546563-16332-1-git-send-email-arm...@redhat.com>
Reviewed-by: Marc-André Lureau 
---
 docs/xen-save-devices-state.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/xen-save-devices-state.txt b/docs/xen-save-devices-state.txt
index 92e08db..a72ecc8 100644
--- a/docs/xen-save-devices-state.txt
+++ b/docs/xen-save-devices-state.txt
@@ -9,7 +9,7 @@ however it is also possible to save the state of all devices to 
file,
 without saving the RAM or the block devices of the VM.
 
 This operation is called "xen-save-devices-state" (see
-QMP/qmp-commands.txt)
+qmp-commands.txt)
 
 
 The binary format used in the file is the following:
-- 
2.5.5

[Qemu-devel] [PULL v2 07/11] MAINTAINERS: Pass the HMP staff from Luiz to David

[Markus Armbruster]

David graciously volunteered to take this off Luiz's hands.

Signed-off-by: Markus Armbruster 
Message-Id: <1475084022-30117-2-git-send-email-arm...@redhat.com>
Reviewed-by: Dr. David Alan Gilbert 
Acked-by: Luiz Capitulino 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 76a0fdb..851cda7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1176,12 +1176,11 @@ F: qemu-timer.c
 F: vl.c
 
 Human Monitor (HMP)
-M: Luiz Capitulino 
+M: Dr. David Alan Gilbert 
 S: Maintained
 F: monitor.c
 F: hmp.c
 F: hmp-commands.hx
-T: git git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
 
 Network device backends
 M: Jason Wang 
-- 
2.5.5

[Qemu-devel] [PULL v2 04/11] qapi: add assert about root value

[Markus Armbruster]

From: Marc-André Lureau 

qiv->root should not be null, make that clearer with some assert.

Signed-off-by: Marc-André Lureau 
Reviewed-by: Eric Blake 
Message-Id: <20160930095948.3154-2-marcandre.lur...@redhat.com>
Reviewed-by: Markus Armbruster 
Signed-off-by: Markus Armbruster 
---
 qapi/qmp-input-visitor.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index fc91e74..c7deca9 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -64,6 +64,7 @@ static QObject *qmp_input_get_object(QmpInputVisitor *qiv,
 
 if (QSLIST_EMPTY(&qiv->stack)) {
 /* Starting at root, name is ignored. */
+assert(qiv->root);
 return qiv->root;
 }
 
@@ -395,6 +396,7 @@ Visitor *qmp_input_visitor_new(QObject *obj, bool strict)
 {
 QmpInputVisitor *v;
 
+assert(obj);
 v = g_malloc0(sizeof(*v));
 
 v->visitor.type = VISITOR_INPUT;
-- 
2.5.5

[Qemu-devel] [PULL v2 03/11] tests/test-qmp-input-strict: Cover missing struct members

[Markus Armbruster]

These tests would have caught the bug fixed by the previous commit.

Signed-off-by: Markus Armbruster 
Message-Id: <1475594630-24758-1-git-send-email-arm...@redhat.com>
---
 tests/test-qmp-input-strict.c | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/tests/test-qmp-input-strict.c b/tests/test-qmp-input-strict.c
index 814550a..d87f8b8 100644
--- a/tests/test-qmp-input-strict.c
+++ b/tests/test-qmp-input-strict.c
@@ -193,6 +193,50 @@ static void 
test_validate_fail_struct_nested(TestInputVisitorData *data,
 g_assert(!udp);
 }
 
+static void test_validate_fail_struct_missing(TestInputVisitorData *data,
+  const void *unused)
+{
+Error *err = NULL;
+Visitor *v;
+QObject *any;
+GenericAlternate *alt;
+bool present;
+int en;
+int64_t i64;
+uint32_t u32;
+int8_t i8;
+char *str;
+double dbl;
+
+v = validate_test_init(data, "{}");
+visit_start_struct(v, NULL, NULL, 0, &error_abort);
+visit_start_struct(v, "struct", NULL, 0, &err);
+error_free_or_abort(&err);
+visit_start_list(v, "list", NULL, 0, &err);
+error_free_or_abort(&err);
+visit_start_alternate(v, "alternate", &alt, sizeof(*alt), false, &err);
+error_free_or_abort(&err);
+visit_optional(v, "optional", &present);
+g_assert(!present);
+visit_type_enum(v, "enum", &en, EnumOne_lookup, &err);
+error_free_or_abort(&err);
+visit_type_int(v, "i64", &i64, &err);
+error_free_or_abort(&err);
+visit_type_uint32(v, "u32", &u32, &err);
+error_free_or_abort(&err);
+visit_type_int8(v, "i8", &i8, &err);
+error_free_or_abort(&err);
+visit_type_str(v, "i8", &str, &err);
+error_free_or_abort(&err);
+visit_type_number(v, "dbl", &dbl, &err);
+error_free_or_abort(&err);
+visit_type_any(v, "any", &any, &err);
+error_free_or_abort(&err);
+visit_type_null(v, "null", &err);
+error_free_or_abort(&err);
+visit_end_struct(v, NULL);
+}
+
 static void test_validate_fail_list(TestInputVisitorData *data,
  const void *unused)
 {
@@ -316,6 +360,8 @@ int main(int argc, char **argv)
   &testdata, test_validate_fail_struct);
 validate_test_add("/visitor/input-strict/fail/struct-nested",
   &testdata, test_validate_fail_struct_nested);
+validate_test_add("/visitor/input-strict/fail/struct-missing",
+  &testdata, test_validate_fail_struct_missing);
 validate_test_add("/visitor/input-strict/fail/list",
   &testdata, test_validate_fail_list);
 validate_test_add("/visitor/input-strict/fail/union-flat",
-- 
2.5.5

Re: [Qemu-devel] [PATCH v4 3/3] tests: start generic qemu-qmp tests

[Markus Armbruster]

Marc-André Lureau  writes:

> These 2 tests exhibit two qmp bugs fixed by the previous patches.
>
> Signed-off-by: Marc-André Lureau 
> Reviewed-by: Daniel P. Berrange 
> Reviewed-by: Eric Blake 

Fails make check, dropping from today's pull request.

Re: [Qemu-devel] [PATCH 10/22] block/dirty-bitmap: add bdrv_dirty_bitmap_next()

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/dirty-bitmap.c | 7 +++
>  include/block/dirty-bitmap.h | 3 +++
>  2 files changed, 10 insertions(+)

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v3 3/5] tests: use qtest_pc_boot()/qtest_shutdown() in virtio tests

[Laurent Vivier]

On 07/10/2016 18:38, Greg Kurz wrote:
> On Sat,  1 Oct 2016 20:56:02 +0200
> Laurent Vivier  wrote:
> 
>> This patch replaces calls to qtest_start() and qtest_end() by
>> calls to qtest_pc_boot() and qtest_shutdown().
>>
>> This allows to initialize memory allocator and PCI interface
>> functions. This will ease to enable virtio tests on other
>> architectures by only adding a specific qtest_XXX_boot() (like
>> qtest_spapr_boot()).
>>
>> Signed-off-by: Laurent Vivier 
>> Reviewed-by: Greg Kurz 
>> ---
> 
> Oops I had missed it during review but I have a single remark for the 9p
> test.
> 
> My R-b stands anyway.
> 
>>  tests/virtio-9p-test.c   |  51 +++-
>>  tests/virtio-blk-test.c  | 150 
>> ---
>>  tests/virtio-net-test.c  |  39 +---
>>  tests/virtio-scsi-test.c |  67 +
>>  4 files changed, 129 insertions(+), 178 deletions(-)
>>
>> diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
>> index e8b2196..7698014 100644
>> --- a/tests/virtio-9p-test.c
>> +++ b/tests/virtio-9p-test.c
>> @@ -10,62 +10,56 @@
>>  #include "qemu/osdep.h"
>>  #include "libqtest.h"
>>  #include "qemu-common.h"
>> -#include "libqos/pci-pc.h"
>> +#include "libqos/libqos-pc.h"
>>  #include "libqos/virtio.h"
>>  #include "libqos/virtio-pci.h"
>> -#include "libqos/malloc.h"
>> -#include "libqos/malloc-pc.h"
>>  #include "standard-headers/linux/virtio_ids.h"
>>  #include "standard-headers/linux/virtio_pci.h"
>>  
>>  static const char mount_tag[] = "qtest";
>>  static char *test_share;
>>  
>> -static void qvirtio_9p_start(void)
>> -{
>> -char *args;
>>  
>> +static QOSState *qvirtio_9p_start(void)
>> +{
>>  test_share = g_strdup("/tmp/qtest.XX");
>>  g_assert_nonnull(mkdtemp(test_share));
>> +const char *cmd = "-fsdev local,id=fsdev0,security_model=none,path=%s "
>> +  "-device virtio-9p-pci,fsdev=fsdev0,mount_tag=%s";
>>  
> 
> Even if C99 supports declarations within the code, I prefer the old school way
> of declaring variables followed by an empty line, at the top.

Yes, you're right, I prefer too...

I will resend the series next week.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH 09/22] block: introduce persistent dirty bitmaps

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> New field BdrvDirtyBitmap.persistent means, that bitmap should be saved
> on bdrv_close, using format driver. Format driver should maintain bitmap
> storing.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block.c  | 30 ++
>  block/dirty-bitmap.c | 27 +++
>  block/qcow2-bitmap.c |  1 +
>  include/block/block.h|  2 ++
>  include/block/block_int.h|  2 ++
>  include/block/dirty-bitmap.h |  6 ++
>  6 files changed, 68 insertions(+)
> 
> diff --git a/block.c b/block.c
> index 804e3d4..1cde03a 100644
> --- a/block.c
> +++ b/block.c
> @@ -2196,6 +2196,7 @@ void bdrv_reopen_abort(BDRVReopenState *reopen_state)
>  static void bdrv_close(BlockDriverState *bs)
>  {
>  BdrvAioNotifier *ban, *ban_next;
> +Error *local_err = NULL;
>  
>  assert(!bs->job);
>  assert(!bs->refcnt);
> @@ -2204,6 +2205,10 @@ static void bdrv_close(BlockDriverState *bs)
>  bdrv_flush(bs);
>  bdrv_drain(bs); /* in case flush left pending I/O */
>  
> +bdrv_store_persistent_bitmaps(bs, &local_err);
> +if (local_err != NULL) {
> +error_report_err(local_err);
> +}

That seems pretty wrong to me. If the persistent bitmaps cannot be
stored, the node should not be closed to avoid loss of data.

>  bdrv_release_named_dirty_bitmaps(bs);

Especially since the next function will just drop all the dirty bitmaps.

I see the issue that bdrv_close() is only called by bdrv_delete() which
in turn is only called by bdrv_unref(); and how are you supposed to
react to bdrv_unref() failing?

So I'm not sure how this issue should be addressed, but this is most
certainly not ideal. You should not just drop supposedly persistent
dirty bitmaps if they cannot be saved.

We really should to have some way to keep the bitmap around if it cannot
be saved, but I don't know how to do that either.

In any case, we should make sure that the node supports saving
persistent dirty bitmaps, because having persistent dirty bitmaps at a
node that does not support them is something we can and must prevent
beforehand.

But I don't know how to handle failure if writing the dirty bitmap
fails. I guess one could argue that it's the same as bdrv_flush()
failing and thus can be handled in the same way, i.e. ignore it. I'm not
happy with that, but I'd accept it if there's no other way.

>  assert(QLIST_EMPTY(&bs->dirty_bitmaps));
>  
> @@ -3969,3 +3974,28 @@ void bdrv_del_child(BlockDriverState *parent_bs, 
> BdrvChild *child, Error **errp)
>  
>  parent_bs->drv->bdrv_del_child(parent_bs, child, errp);
>  }
> +
> +void bdrv_store_persistent_bitmaps(BlockDriverState *bs, Error **errp)
> +{
> +BlockDriver *drv = bs->drv;
> +
> +if (!bdrv_has_persistent_bitmaps(bs)) {
> +return;
> +}
> +
> +if (!drv) {
> +error_setg_errno(errp, ENOMEDIUM,
> + "Can't store persistent bitmaps to %s",
> + bdrv_get_device_or_node_name(bs));
> +return;
> +}
> +
> +if (!drv->bdrv_store_persistent_bitmaps) {
> +error_setg_errno(errp, ENOTSUP,
> + "Can't store persistent bitmaps to %s",
> + bdrv_get_device_or_node_name(bs));
> +return;
> +}
> +
> +drv->bdrv_store_persistent_bitmaps(bs, errp);
> +}
> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
> index 623e1d1..0314581 100644
> --- a/block/dirty-bitmap.c
> +++ b/block/dirty-bitmap.c
> @@ -44,6 +44,7 @@ struct BdrvDirtyBitmap {
>  int64_t size;   /* Size of the bitmap (Number of sectors) */
>  bool disabled;  /* Bitmap is read-only */
>  int active_iterators;   /* How many iterators are active */
> +bool persistent;/* bitmap must be saved to owner disk image 
> */
>  bool autoload;  /* bitmap must be autoloaded on image 
> opening */
>  QLIST_ENTRY(BdrvDirtyBitmap) list;
>  };
> @@ -72,6 +73,7 @@ void bdrv_dirty_bitmap_make_anon(BdrvDirtyBitmap *bitmap)
>  g_free(bitmap->name);
>  bitmap->name = NULL;
>  
> +bitmap->persistent = false;
>  bitmap->autoload = false;
>  }
>  
> @@ -241,6 +243,8 @@ BdrvDirtyBitmap 
> *bdrv_dirty_bitmap_abdicate(BlockDriverState *bs,
>  bitmap->name = NULL;
>  successor->name = name;
>  bitmap->successor = NULL;
> +successor->persistent = bitmap->persistent;
> +bitmap->persistent = false;
>  successor->autoload = bitmap->autoload;
>  bitmap->autoload = false;
>  bdrv_release_dirty_bitmap(bs, bitmap);
> @@ -555,3 +559,26 @@ bool bdrv_dirty_bitmap_get_autoload(const 
> BdrvDirtyBitmap *bitmap)
>  {
>  return bitmap->autoload;
>  }
> +
> +void bdrv_dirty_bitmap_set_persistance(BdrvDirtyBitmap *bitmap,
> +bool persistent)

The second parameter should be aligned to the op

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 4/6] migration: migrate QTAILQ

[Jianjun Duan]

On 10/07/2016 10:34 AM, Dr. David Alan Gilbert wrote:
> * Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
>>
>>
>> On 10/07/2016 09:32 AM, Paolo Bonzini wrote:
>>>
>>>
>>> On 07/10/2016 18:31, Jianjun Duan wrote:


 On 10/07/2016 07:34 AM, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>>
>>
>> On 06/10/2016 21:01, Dr. David Alan Gilbert wrote:
>> +} else if (field->flags & VMS_LINKED) {
>> +ret = field->info->get(f, addr, size, field);
>>  } else {
>>  ret = field->info->get(f, addr, size, NULL);
>>  
>> @@ -193,6 +197,8 @@ static const char 
>> *vmfield_get_type_name(VMStateField *field)
>>  
>>  if (field->flags & VMS_STRUCT) {
>>  type = "struct";
>> +} else if (field->flags & VMS_LINKED) {
>> +type = "linked";
>>  } else if (field->info->name) {
>>  type = field->info->name;
>>  }
>> @@ -327,6 +333,8 @@ void vmstate_save_state(QEMUFile *f, const 
>> VMStateDescription *vmsd,
>>  }
>>  if (field->flags & VMS_STRUCT) {
>>  vmstate_save_state(f, field->vmsd, addr, 
>> vmdesc_loop);
>> +} else if  (field->flags & VMS_LINKED) {
>> +field->info->put(f, addr, size, field, 
>> vmdesc_loop);
>>  } else {
>>  field->info->put(f, addr, size, NULL, NULL);
>>  }
>>
>> Is VMS_LINKED needed at all, since the fields are unused for every
>> VMStateInfo except qtailq?
>
> No, I think you could easily drop the VMS_LINKED and just always pass 
> them in.

 It is needed if we want to use vmdesc_loop.
>>>
>>> Just always pass it in, can't you?
>>>
>> Could that lead to repetition of array elements? I know it depends on
>> individual put details.
> 
> I don't think so; Paolo is just suggesting replacing:
> 
>  +} else if  (field->flags & VMS_LINKED) {
>  +field->info->put(f, addr, size, field, vmdesc_loop);
>   } else {
>   field->info->put(f, addr, size, NULL, NULL);
>   }
> 
> by:
> 
>   } else {
>  -field->info->put(f, addr, size, NULL, NULL);
>  +field->info->put(f, addr, size, field, vmdesc_loop);
>   }
> 
> most get/put won't use the field/vmdesc_loop so it wont matter.
> 
> Dave
> 

Even though most put/get have no issues now, when somebody writes a new
put, he or she could run into issues if only checking the type
signature. It makes the code more readable.

I am OK either way.

Thanks,
Jianjun
>>
>> Thanks,
>> Jianjun
>>> Paolo
>>>
>>
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> 

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 4/6] migration: migrate QTAILQ

[Jianjun Duan]

On 10/07/2016 09:32 AM, Paolo Bonzini wrote:
> 
> 
> On 07/10/2016 18:31, Jianjun Duan wrote:
>>
>>
>> On 10/07/2016 07:34 AM, Dr. David Alan Gilbert wrote:
>>> * Paolo Bonzini (pbonz...@redhat.com) wrote:


 On 06/10/2016 21:01, Dr. David Alan Gilbert wrote:
 +} else if (field->flags & VMS_LINKED) {
 +ret = field->info->get(f, addr, size, field);
  } else {
  ret = field->info->get(f, addr, size, NULL);
  
 @@ -193,6 +197,8 @@ static const char 
 *vmfield_get_type_name(VMStateField *field)
  
  if (field->flags & VMS_STRUCT) {
  type = "struct";
 +} else if (field->flags & VMS_LINKED) {
 +type = "linked";
  } else if (field->info->name) {
  type = field->info->name;
  }
 @@ -327,6 +333,8 @@ void vmstate_save_state(QEMUFile *f, const 
 VMStateDescription *vmsd,
  }
  if (field->flags & VMS_STRUCT) {
  vmstate_save_state(f, field->vmsd, addr, 
 vmdesc_loop);
 +} else if  (field->flags & VMS_LINKED) {
 +field->info->put(f, addr, size, field, 
 vmdesc_loop);
  } else {
  field->info->put(f, addr, size, NULL, NULL);
  }

 Is VMS_LINKED needed at all, since the fields are unused for every
 VMStateInfo except qtailq?
>>>
>>> No, I think you could easily drop the VMS_LINKED and just always pass them 
>>> in.
>>
>> It is needed if we want to use vmdesc_loop.
> 
> Just always pass it in, can't you?
> 
Could that lead to repetition of array elements? I know it depends on
individual put details.

Thanks,
Jianjun
> Paolo
> 

Re: [Qemu-devel] [PATCH] block: Remove "options" indirection from blockdev-add

[Eric Blake]

On 10/07/2016 10:38 AM, Kevin Wolf wrote:
> Now that QAPI supports boxed types, we can have unions at the top level
> of a command, so let's put our real options directly there for
> blockdev-add instead of having a single "options" dict that contains the
> real arguments.
> 
> blockdev-add is still experimental and we already made substantial
> changes to the API recently, so we're free to make changes like this
> one, too.

I like it, and it needs to make 2.8.  Max was correct that there are
some doc changes missing, so looking forward to v2.

> 
> Signed-off-by: Kevin Wolf 
> ---
> 
> Yes, that's right. Ignoring the test cases, this is a one-liner in
> the schema without any C code changes. :-)

Yay! My qapi refactoring work is paying dividends.

The lack of C code changes is because we convert everything to QDict and
then manually parse it using QemuOpts, rather than sticking to the nicer
qapi structs.  Someday, it would be nice to use the actual qapi structs
all the way, but that doesn't have to be today.

> +++ b/qapi/block-core.json
> @@ -2321,7 +2321,7 @@
>  #
>  # Since: 1.7
>  ##
> -{ 'command': 'blockdev-add', 'data': { 'options': 'BlockdevOptions' } }
> +{ 'command': 'blockdev-add', 'data': 'BlockdevOptions', 'boxed': true }

Eventually, when we rename x-blockdev-del, we'll want some sort of doc
note here that even though this command has existed since 1.7, it is
fundamentally different in 2.8 and should not be used in anger unless
blockdev-del is also defined.

> +++ b/tests/qemu-iotests/041
> @@ -194,10 +194,9 @@ class TestSingleBlockdev(TestSingleDrive):
>  def setUp(self):
>  TestSingleDrive.setUp(self)
>  qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' % 
> backing_img, target_img)
> -args = {'options':
> -{'driver': iotests.imgfmt,
> - 'node-name': self.qmp_target,
> - 'file': { 'filename': target_img, 'driver': 'file' } } }
> +args = {'driver': iotests.imgfmt,
> +'node-name': self.qmp_target,
> +'file': { 'filename': target_img, 'driver': 'file' } }

Less nesting is indeed a bit easier to read :)

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PULL 00/20] Tracing patches

[Lluís Vilanova]

Daniel P Berrange writes:

> On Fri, Oct 07, 2016 at 03:46:27PM +0200, Lluís Vilanova wrote:
>> Peter Maydell writes:
>> 
>> > On 7 October 2016 at 11:09, Stefan Hajnoczi  wrote:
>> >> The following changes since commit 
>> >> e902754e3d0890945ddcc1b33748ed73762ddb8d:
>> >> 
>> >> Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.8-20161006' 
>> >> into staging (2016-10-06 13:34:00 +0100)
>> >> 
>> >> are available in the git repository at:
>> >> 
>> >> git://github.com/stefanha/qemu.git tags/tracing-pull-request
>> >> 
>> >> for you to fetch changes up to bcdc1363dcb9adb5f7ea016a4d0b41f0357c8182:
>> >> 
>> >> trace: Add missing execution mode of guest events (2016-10-07 09:17:49 
>> >> +0100)
>> >> 
>> >> 
>> >> 
>> >> 
>> 
>> > This makes all the linux-user binaries dump core on startup:
>> 
>> > $ gdb --args 
>> > /home/petmay01/linaro/qemu-for-merges/build/all-linux-static/x86_64-linux-user/qemu-x86_64
>> > /bin/ls
>> > (gdb) r
>> > Starting program:
>> > /home/petmay01/linaro/qemu-for-merges/build/all-linux-static/x86_64-linux-user/qemu-x86_64
>> > /bin/ls
>> > [Thread debugging using libthread_db enabled]
>> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> > [New Thread 0x77ffa700 (LWP 14965)]
>> 
>> > Thread 1 "qemu-x86_64" received signal SIGABRT, Aborted.
>> > 0x6019fbe8 in raise ()
>> > (gdb) bt
>> > #0  0x6019fbe8 in raise ()
>> > #1  0x601a030a in abort ()
>> > #2  0x600bdd02 in bitmap_new (nbits=0)
>> > at /home/petmay01/linaro/qemu-for-merges/include/qemu/bitmap.h:99
>> > #3  0x600be99f in cpu_common_initfn (obj=0x625f6340)
>> > at /home/petmay01/linaro/qemu-for-merges/qom/cpu.c:360
>> > #4  0x600bfe97 in object_init_with_type (obj=0x625f6340, 
>> > ti=0x625eb9a0)
>> > at /home/petmay01/linaro/qemu-for-merges/qom/object.c:339
>> > #5  0x600bfe79 in object_init_with_type (obj=0x625f6340, 
>> > ti=0x625e2d80)
>> > at /home/petmay01/linaro/qemu-for-merges/qom/object.c:335
>> > #6  0x600bfe79 in object_init_with_type (obj=0x625f6340, 
>> > ti=0x625e78d0)
>> > at /home/petmay01/linaro/qemu-for-merges/qom/object.c:335
>> > #7  0x600c00aa in object_initialize_with_type
>> > (data=0x625f6340, size=38416, type=0x625e78d0)
>> > at /home/petmay01/linaro/qemu-for-merges/qom/object.c:370
>> > #8  0x600c0508 in object_new_with_type (type=0x625e78d0)
>> > at /home/petmay01/linaro/qemu-for-merges/qom/object.c:478
>> > #9  0x600c0542 in object_new (typename=0x625e2fe0 
>> > "qemu64-x86_64-cpu")
>> > at /home/petmay01/linaro/qemu-for-merges/qom/object.c:488
>> > #10 0x600be03f in cpu_generic_init (typename=0x6025ad54
>> > "x86_64-cpu", cpu_model=0x60247ca5 "qemu64")
>> > at /home/petmay01/linaro/qemu-for-merges/qom/cpu.c:76
>> > #11 0x60089438 in cpu_x86_init (cpu_model=0x60247ca5 "qemu64")
>> > at /home/petmay01/linaro/qemu-for-merges/target-i386/cpu.c:2266
>> > #12 0x60031031 in main (argc=2, argv=0x7fffe4b8,
>> > envp=0x7fffe4d0)
>> > at /home/petmay01/linaro/qemu-for-merges/linux-user/main.c:4253
>> 
>> Aha! I didn't take that abort into consideration during the review. The fix
>> should be on patch 13 of the series (trace: dynamically allocate 
>> trace_dstate in
>> CPUState):
>> 
>> diff --git a/qom/cpu.c b/qom/cpu.c
>> index 484c493..40f2eb1 100644
>> --- a/qom/cpu.c
>> +++ b/qom/cpu.c
>> @@ -356,12 +356,15 @@ static void cpu_common_initfn(Object *obj)
>> qemu_mutex_init(&cpu->work_mutex);
>> QTAILQ_INIT(&cpu->breakpoints);
>> QTAILQ_INIT(&cpu->watchpoints);
>> -bitmap_zero(cpu->trace_dstate, TRACE_VCPU_EVENT_COUNT);
>> +
>> +cpu->trace_dstate = bitmap_new(min(trace_get_vcpu_event_count(), 1);
>> }
>> 
>> static void cpu_common_finalize(Object *obj)
>> {
>> -cpu_exec_exit(CPU(obj));
>> +CPUState *cpu = CPU(obj);
>> +cpu_exec_exit(cpu);
>> +g_free(cpu->trace_dstate);
>> }
>> 
>> static int64_t cpu_common_get_arch_id(CPUState *cpu)

> No, this isn't what we want todo. The real problem is that we should
> have been registering the trace events in the linux-user/bsd-user
> programs. I sent a fix for that.

Well, that'll work as long as we keep at least one vcpu event :)

Cheers,
  Lluis

Re: [Qemu-devel] [QEMU PATCH v5 2/6] migration: spapr_drc: defined VMStateDescription struct

[Jianjun Duan]

On 10/06/2016 08:12 PM, David Gibson wrote:
> On Mon, Oct 03, 2016 at 11:24:53AM -0700, Jianjun Duan wrote:
>> To manage hotplug/unplug of dynamic resources such as PCI cards,
>> memory, and CPU on sPAPR guests, a firmware abstraction known as
>> a Dynamic Resource Connector (DRC) is used to assign a particular
>> dynamic resource to the guest, and provide an interface for the
>> guest to manage configuration/removal of the resource associated
>> with it.
>>
>> To migrate the hotplugged resources in migration, the
>> associated DRC state need be migrated. To migrate the DRC state,
>> we defined the VMStateDescription struct for spapr_drc to enable
>> the transmission of spapr_drc state in migration.
>>
>> Not all the elements in the DRC state are migrated. Only those
>> ones modifiable or needed by guest actions or device add/remove
>> operation are migrated. From the perspective of device
>> hotplugging, if we hotplug a device on the source, we need to
>> "coldplug" it on the target. The states across two hosts for the
>> same device are not the same. Ideally we want the states be same
>> after migration so that the device would function as hotplugged
>> on the target. For example we can unplug it. The minimum DRC
>> state we need to transfer should cover all the pieces changed by
>> hotplugging. Out of the elements of the DRC state, isolation_state,
>> allocation_sate, and configured are involved in the DR state
>> transition diagram from PAPR+ 2.7, 13.4. configured and signalled
>> are needed in attaching and detaching devices. indicator_state
>> provides users with hardware state information. These 6 elements
>> are migrated.
> 
> Hmm.. are you saying that the DRC state of a coldplugged device (after
> we've fully booted) is different from the DRC state of a hotplugged
> device (after all the hotplug operations have fully completed)?
> 
> If that's correct that sounds like a general bug in the DRC state
> management, not something only related to migration.
> 
> Looking at the code, though, that doesn't really seem to be what it's
> doing.
> 

After hotplugging a device, changes may be made to its DRC state on the
source. But on target the state is fresh. The possible changes are shown
in spapr_drc_needed function.
>> detach_cb in the DRC state is a function pointer that cannot be
>> migrated. We set it right after DRC state is migrated so that
>> a migrated hot-unplug event could finish its work.
>>
>> The instance_id is used to identify objects in migration. We set
>> instance_id of DRC using the unique index so that it is the same
>> across migration.
>>
>> Signed-off-by: Jianjun Duan 
>> ---
>>  hw/ppc/spapr_drc.c | 69 
>> ++
>>  hw/ppc/spapr_pci.c | 22 +++
>>  include/hw/ppc/spapr_drc.h |  9 ++
>>  3 files changed, 100 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
>> index 6e54fd4..369ec02 100644
>> --- a/hw/ppc/spapr_drc.c
>> +++ b/hw/ppc/spapr_drc.c
>> @@ -615,6 +615,71 @@ static void spapr_dr_connector_instance_init(Object 
>> *obj)
>>  NULL, NULL, NULL, NULL);
>>  }
>>  
>> +static bool spapr_drc_needed(void *opaque)
>> +{
>> +sPAPRDRConnector *drc = (sPAPRDRConnector *)opaque;
>> +sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
>> +bool rc = false;
>> +sPAPRDREntitySense value;
>> +
>> +drck->entity_sense(drc, &value);
>> +/* If no dev is plugged in there is no need to migrate the DRC state */
>> +if (value != SPAPR_DR_ENTITY_SENSE_PRESENT) {
>> +return false;
>> +}
>> +/*
>> + * If there is dev plugged in, we need to migrate the DRC state when
>> + * it is different from cold-plugged state
>> + */
>> +switch(drc->type) {
>> +/* for PCI type */
>> +case SPAPR_DR_CONNECTOR_TYPE_PCI:
>> +rc = !((drc->isolation_state == 
>> SPAPR_DR_ISOLATION_STATE_UNISOLATED) &&
>> +   (drc->allocation_state == SPAPR_DR_ALLOCATION_STATE_USABLE) 
>> &&
>> +   drc->configured && drc->signalled && !drc->awaiting_release);
>> +break;
>> +/* for LMB type */
>> +case SPAPR_DR_CONNECTOR_TYPE_LMB:
>> +rc = !((drc->isolation_state == SPAPR_DR_ISOLATION_STATE_ISOLATED) 
>> &&
>> +   (drc->allocation_state == 
>> SPAPR_DR_ALLOCATION_STATE_UNUSABLE) &&
>> +   drc->configured && drc->signalled && !drc->awaiting_release);
>> +break;
> 
> What about CPU type?z

For CPU Type, those states don't change from source to host.

>> +default:
>> +;
>> +}
>> +
>> +return rc;
>> +}
>> +
>> +/* detach_cb needs be set since it is not migrated */
>> +static void postmigrate_set_detach_cb(sPAPRDRConnector *drc,
>> +  spapr_drc_detach_cb *detach_cb)
>> +{
>> +drc->detach_cb = detach_cb;
>> +}
>> +
>> +/* return the unique drc index as instance_id for qom interfaces*/
>> +static int get

[Qemu-devel] [PULL 37/39] qemu-tech: reorganize content

[Paolo Bonzini]

Split more parts into separate chapters, place comparison last,
rename "Introduction" to "CPU emulation".

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi | 171 +
 1 file changed, 74 insertions(+), 97 deletions(-)

diff --git a/qemu-tech.texi b/qemu-tech.texi
index adfb53b..2e499a7 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -29,27 +29,29 @@
 @top
 
 @menu
-* Introduction::
-* QEMU Internals::
+* CPU emulation::
+* Translator Internals::
+* Device emulation::
+* QEMU compared to other emulators::
+* Bibliography::
 @end menu
 @end ifnottex
 
 @contents
 
-@node Introduction
-@chapter Introduction
+@node CPU emulation
+@chapter CPU emulation
 
 @menu
-* intro_x86_emulation::x86 and x86-64 emulation
-* intro_arm_emulation::ARM emulation
-* intro_mips_emulation::   MIPS emulation
-* intro_ppc_emulation::PowerPC emulation
-* intro_sparc_emulation::  Sparc32 and Sparc64 emulation
-* intro_xtensa_emulation:: Xtensa emulation
-* intro_other_emulation::  Other CPU emulation
+* x86:: x86 and x86-64 emulation
+* ARM:: ARM emulation
+* MIPS::MIPS emulation
+* PPC:: PowerPC emulation
+* SPARC::   Sparc32 and Sparc64 emulation
+* Xtensa::  Xtensa emulation
 @end menu
 
-@node intro_x86_emulation
+@node x86
 @section x86 and x86-64 emulation
 
 QEMU x86 target features:
@@ -84,7 +86,7 @@ normal use.
 
 @end itemize
 
-@node intro_arm_emulation
+@node ARM
 @section ARM emulation
 
 @itemize
@@ -97,7 +99,7 @@ normal use.
 
 @end itemize
 
-@node intro_mips_emulation
+@node MIPS
 @section MIPS emulation
 
 @itemize
@@ -124,7 +126,7 @@ Current QEMU limitations:
 
 @end itemize
 
-@node intro_ppc_emulation
+@node PPC
 @section PowerPC emulation
 
 @itemize
@@ -136,7 +138,7 @@ FPU and MMU.
 
 @end itemize
 
-@node intro_sparc_emulation
+@node SPARC
 @section Sparc32 and Sparc64 emulation
 
 @itemize
@@ -164,7 +166,7 @@ Current QEMU limitations:
 
 @end itemize
 
-@node intro_xtensa_emulation
+@node Xtensa
 @section Xtensa emulation
 
 @itemize
@@ -189,94 +191,18 @@ may be created from overlay with minimal amount of 
hand-written code.
 
 @end itemize
 
-@node intro_other_emulation
-@section Other CPU emulation
-
-In addition to the above, QEMU supports emulation of other CPUs with
-varying levels of success. These are:
-
-@itemize
-
-@item
-Alpha
-@item
-CRIS
-@item
-M68k
-@item
-SH4
-@end itemize
-
-@node QEMU Internals
-@chapter QEMU Internals
+@node Translator Internals
+@chapter Translator Internals
 
 @menu
-* QEMU compared to other emulators::
-* Portable dynamic translation::
 * CPU state optimisations::
 * Translation cache::
 * Direct block chaining::
 * Self-modifying code and translated code invalidation::
 * Exception support::
 * MMU emulation::
-* Device emulation::
-* Bibliography::
 @end menu
 
-@node QEMU compared to other emulators
-@section QEMU compared to other emulators
-
-Like bochs [1], QEMU emulates an x86 CPU. But QEMU is much faster than
-bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC
-emulation while QEMU can emulate several processors.
-
-Like Valgrind [2], QEMU does user space emulation and dynamic
-translation. Valgrind is mainly a memory debugger while QEMU has no
-support for it (QEMU could be used to detect out of bound memory
-accesses as Valgrind, but it has no support to track uninitialised data
-as Valgrind does). The Valgrind dynamic translator generates better code
-than QEMU (in particular it does register allocation) but it is closely
-tied to an x86 host and target and has no support for precise exceptions
-and system emulation.
-
-EM86 [3] is the closest project to user space QEMU (and QEMU still uses
-some of its code, in particular the ELF file loader). EM86 was limited
-to an alpha host and used a proprietary and slow interpreter (the
-interpreter part of the FX!32 Digital Win32 code translator [4]).
-
-TWIN from Willows Software was a Windows API emulator like Wine. It is less
-accurate than Wine but includes a protected mode x86 interpreter to launch
-x86 Windows executables. Such an approach has greater potential because most
-of the Windows API is executed natively but it is far more difficult to
-develop because all the data structures and function parameters exchanged
-between the API and the x86 code must be converted.
-
-User mode Linux [5] was the only solution before QEMU to launch a
-Linux kernel as a process while not needing any host kernel
-patches. However, user mode Linux requires heavy kernel patches while
-QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is
-slower.
-
-The Plex86 [6] PC virtualizer is done in the same spirit as the now
-obsolete qemu-fast system emulator. It requires a patched Linux kernel
-to work (you cannot launch the same kernel on your PC), but the
-patches are really small. As it is a PC virtualizer (no emulation is
-done except for some privileged instructions), it has the pot

Re: [Qemu-devel] [Qemu-ppc] [QEMU PATCH v5 4/6] migration: migrate QTAILQ

[Dr. David Alan Gilbert]

* Jianjun Duan (du...@linux.vnet.ibm.com) wrote:
> 
> 
> On 10/07/2016 09:32 AM, Paolo Bonzini wrote:
> > 
> > 
> > On 07/10/2016 18:31, Jianjun Duan wrote:
> >>
> >>
> >> On 10/07/2016 07:34 AM, Dr. David Alan Gilbert wrote:
> >>> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> 
> 
>  On 06/10/2016 21:01, Dr. David Alan Gilbert wrote:
>  +} else if (field->flags & VMS_LINKED) {
>  +ret = field->info->get(f, addr, size, field);
>   } else {
>   ret = field->info->get(f, addr, size, NULL);
>   
>  @@ -193,6 +197,8 @@ static const char 
>  *vmfield_get_type_name(VMStateField *field)
>   
>   if (field->flags & VMS_STRUCT) {
>   type = "struct";
>  +} else if (field->flags & VMS_LINKED) {
>  +type = "linked";
>   } else if (field->info->name) {
>   type = field->info->name;
>   }
>  @@ -327,6 +333,8 @@ void vmstate_save_state(QEMUFile *f, const 
>  VMStateDescription *vmsd,
>   }
>   if (field->flags & VMS_STRUCT) {
>   vmstate_save_state(f, field->vmsd, addr, 
>  vmdesc_loop);
>  +} else if  (field->flags & VMS_LINKED) {
>  +field->info->put(f, addr, size, field, 
>  vmdesc_loop);
>   } else {
>   field->info->put(f, addr, size, NULL, NULL);
>   }
> 
>  Is VMS_LINKED needed at all, since the fields are unused for every
>  VMStateInfo except qtailq?
> >>>
> >>> No, I think you could easily drop the VMS_LINKED and just always pass 
> >>> them in.
> >>
> >> It is needed if we want to use vmdesc_loop.
> > 
> > Just always pass it in, can't you?
> > 
> Could that lead to repetition of array elements? I know it depends on
> individual put details.

I don't think so; Paolo is just suggesting replacing:

 +} else if  (field->flags & VMS_LINKED) {
 +field->info->put(f, addr, size, field, vmdesc_loop);
  } else {
  field->info->put(f, addr, size, NULL, NULL);
  }

by:

  } else {
 -field->info->put(f, addr, size, NULL, NULL);
 +field->info->put(f, addr, size, field, vmdesc_loop);
  }

most get/put won't use the field/vmdesc_loop so it wont matter.

Dave

> 
> Thanks,
> Jianjun
> > Paolo
> > 
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PULL 34/39] qemu-tech: document lazy condition code evaluation in cpu.h

[Paolo Bonzini]

Unlike the other sections, they are pretty specific to a particular CPU.

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi | 25 -
 target-cris/cpu.h  |  7 +++
 target-i386/cpu.h  |  7 +++
 target-m68k/cpu.h  |  8 
 target-s390x/cpu.h |  7 +++
 target-sparc/cpu.h |  5 +
 6 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 082b62c..75ceea4 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -214,7 +214,6 @@ SH4
 @menu
 * QEMU compared to other emulators::
 * Portable dynamic translation::
-* Condition code optimisations::
 * CPU state optimisations::
 * Translation cache::
 * Direct block chaining::
@@ -290,30 +289,6 @@ performances.
 QEMU's dynamic translation backend is called TCG, for "Tiny Code
 Generator". For more information, please take a look at @code{tcg/README}.
 
-@node Condition code optimisations
-@section Condition code optimisations
-
-Lazy evaluation of CPU condition codes (@code{EFLAGS} register on x86)
-is important for CPUs where every instruction sets the condition
-codes. It tends to be less important on conventional RISC systems
-where condition codes are only updated when explicitly requested. On
-Sparc64, costly update of both 32 and 64 bit condition codes can be
-avoided with lazy evaluation.
-
-Instead of computing the condition codes after each x86 instruction,
-QEMU just stores one operand (called @code{CC_SRC}), the result
-(called @code{CC_DST}) and the type of operation (called
-@code{CC_OP}). When the condition codes are needed, the condition
-codes can be calculated using this information. In addition, an
-optimized calculation can be performed for some instruction types like
-conditional branches.
-
-@code{CC_OP} is almost never explicitly set in the generated code
-because it is known at translation time.
-
-The lazy condition code evaluation is used on x86, m68k, cris and
-Sparc. ARM uses a simplified variant for the N and Z flags.
-
 @node CPU state optimisations
 @section CPU state optimisations
 
diff --git a/target-cris/cpu.h b/target-cris/cpu.h
index 7d7fe6e..43d5f9d 100644
--- a/target-cris/cpu.h
+++ b/target-cris/cpu.h
@@ -223,6 +223,13 @@ int cpu_cris_signal_handler(int host_signum, void *pinfo,
 void cris_initialize_tcg(void);
 void cris_initialize_crisv10_tcg(void);
 
+/* Instead of computing the condition codes after each CRIS instruction,
+ * QEMU just stores one operand (called CC_SRC), the result
+ * (called CC_DEST) and the type of operation (called CC_OP). When the
+ * condition codes are needed, the condition codes can be calculated
+ * using this information. Condition codes are not generated if they
+ * are only needed for conditional branches.
+ */
 enum {
 CC_OP_DYNAMIC, /* Use env->cc_op  */
 CC_OP_FLAGS,
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1cb32ae..e645698 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -698,6 +698,13 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 /* Use a clearer name for this.  */
 #define CPU_INTERRUPT_INIT  CPU_INTERRUPT_RESET
 
+/* Instead of computing the condition codes after each x86 instruction,
+ * QEMU just stores one operand (called CC_SRC), the result
+ * (called CC_DST) and the type of operation (called CC_OP). When the
+ * condition codes are needed, the condition codes can be calculated
+ * using this information. Condition codes are not generated if they
+ * are only needed for conditional branches.
+ */
 typedef enum {
 CC_OP_DYNAMIC, /* must use dynamic code to get cc_op */
 CC_OP_EFLAGS,  /* all cc are explicitly computed, CC_SRC = flags */
diff --git a/target-m68k/cpu.h b/target-m68k/cpu.h
index c2d40cb..471f490 100644
--- a/target-m68k/cpu.h
+++ b/target-m68k/cpu.h
@@ -154,6 +154,14 @@ int cpu_m68k_signal_handler(int host_signum, void *pinfo,
void *puc);
 void cpu_m68k_flush_flags(CPUM68KState *, int);
 
+
+/* Instead of computing the condition codes after each m68k instruction,
+ * QEMU just stores one operand (called CC_SRC), the result
+ * (called CC_DEST) and the type of operation (called CC_OP). When the
+ * condition codes are needed, the condition codes can be calculated
+ * using this information. Condition codes are not generated if they
+ * are only needed for conditional branches.
+ */
 enum {
 CC_OP_DYNAMIC, /* Use env->cc_op  */
 CC_OP_FLAGS, /* CC_DEST = CVZN, CC_SRC = unused */
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 4fb34b5..4e58cde 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -671,6 +671,13 @@ ObjectClass *s390_cpu_class_by_name(const char *name);
 
 /* CC optimization */
 
+/* Instead of computing the condition codes after each x86 instruction,
+ * QEMU just stores the result (called CC_DST), the type of operation
+ * (called CC_OP) and whatever operands are needed (CC_SRC and possibly
+ * CC_VR). When the condition codes are needed, the

Re: [Qemu-devel] [PATCH 08/22] block/dirty-bitmap: add autoload field to BdrvDirtyBitmap

[Max Reitz]

On 30.09.2016 12:53, Vladimir Sementsov-Ogievskiy wrote:
> Mirror AUTO flag from Qcow2 bitmap in BdrvDirtyBitmap. This will be
> needed in future, to save this flag back to Qcow2 for persistent
> bitmaps.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/dirty-bitmap.c | 15 +++
>  block/qcow2-bitmap.c |  2 ++
>  include/block/dirty-bitmap.h |  2 ++
>  3 files changed, 19 insertions(+)
> 
> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
> index 90af372..623e1d1 100644
> --- a/block/dirty-bitmap.c
> +++ b/block/dirty-bitmap.c
> @@ -44,6 +44,7 @@ struct BdrvDirtyBitmap {
>  int64_t size;   /* Size of the bitmap (Number of sectors) */
>  bool disabled;  /* Bitmap is read-only */
>  int active_iterators;   /* How many iterators are active */
> +bool autoload;  /* bitmap must be autoloaded on image 
> opening */

I think a note that this is for persistent dirty bitmaps would be
useful, e.g.:

"/* For persistent bitmaps: Bitmap must be autoloaded [...] */"

Up to you, though, so however you decide:

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 39/39] qemu-doc: merge qemu-tech and qemu-doc

[Paolo Bonzini]

Merge what is left of qemu-tech into the main manual as an appendix.
Ultimately we should have a new internals manual built from docs/, and
then the "Translator Internals" parts of qemu-tech could move to docs/
as well.  The bits on limitation and features of CPU emulation should
remain in qemu-doc.

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 .gitignore |  2 --
 Makefile   | 13 ++---
 qemu-doc.texi  |  3 +++
 qemu-tech.texi | 56 
 qemu.nsi   |  3 ---
 ui/cocoa.m |  9 -
 6 files changed, 21 insertions(+), 65 deletions(-)

diff --git a/.gitignore b/.gitignore
index c91d018..c88ebf9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,9 +39,7 @@
 /qmp-introspect.[ch]
 /qmp-marshal.c
 /qemu-doc.html
-/qemu-tech.html
 /qemu-doc.info
-/qemu-tech.info
 /qemu-img
 /qemu-nbd
 /qemu-options.def
diff --git a/Makefile b/Makefile
index f103616..f148077 100644
--- a/Makefile
+++ b/Makefile
@@ -93,7 +93,7 @@ LIBS+=-lz $(LIBS_TOOLS)
 HELPERS-$(CONFIG_LINUX) = qemu-bridge-helper$(EXESUF)
 
 ifdef BUILD_DOCS
-DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 qemu-ga.8
+DOCS=qemu-doc.html qemu.1 qemu-img.1 qemu-nbd.8 qemu-ga.8
 ifdef CONFIG_VIRTFS
 DOCS+=fsdev/virtfs-proxy-helper.1
 endif
@@ -398,7 +398,6 @@ distclean: clean
rm -f qemu-doc.vr
rm -f config.log
rm -f linux-headers/asm
-   rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi 
qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf 
qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr
for d in $(TARGET_DIRS); do \
rm -rf $$d || exit 1 ; \
 done
@@ -434,7 +433,7 @@ endif
 
 install-doc: $(DOCS)
$(INSTALL_DIR) "$(DESTDIR)$(qemu_docdir)"
-   $(INSTALL_DATA) qemu-doc.html  qemu-tech.html "$(DESTDIR)$(qemu_docdir)"
+   $(INSTALL_DATA) qemu-doc.html "$(DESTDIR)$(qemu_docdir)"
$(INSTALL_DATA) $(SRC_PATH)/docs/qmp-commands.txt 
"$(DESTDIR)$(qemu_docdir)"
 ifdef CONFIG_POSIX
$(INSTALL_DIR) "$(DESTDIR)$(mandir)/man1"
@@ -592,10 +591,10 @@ qemu-ga.8: qemu-ga.texi
  $(POD2MAN) --section=8 --center=" " --release=" " qemu-ga.pod > $@, \
  "  GEN   $@")
 
-dvi: qemu-doc.dvi qemu-tech.dvi
-html: qemu-doc.html qemu-tech.html
-info: qemu-doc.info qemu-tech.info
-pdf: qemu-doc.pdf qemu-tech.pdf
+dvi: qemu-doc.dvi
+html: qemu-doc.html
+info: qemu-doc.info
+pdf: qemu-doc.pdf
 
 qemu-doc.dvi qemu-doc.html qemu-doc.info qemu-doc.pdf: \
qemu-img.texi qemu-nbd.texi qemu-options.texi qemu-option-trace.texi \
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 227c2b0..023c140 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -35,6 +35,7 @@
 * QEMU PC System emulator::
 * QEMU System emulator for non PC targets::
 * QEMU User space emulator::
+* Implementation notes::
 * License::
 * Index::
 @end menu
@@ -2949,6 +2950,8 @@ Run the emulation in single step mode.
 @end table
 
 
+@include qemu-tech.texi
+
 @node License
 @appendix License
 
diff --git a/qemu-tech.texi b/qemu-tech.texi
index b418a41..52a56ae 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -1,32 +1,5 @@
-\input texinfo @c -*- texinfo -*-
-@c %**start of header
-@setfilename qemu-tech.info
-
-@documentlanguage en
-@documentencoding UTF-8
-
-@settitle QEMU Internals
-@exampleindent 0
-@paragraphindent 0
-@c %**end of header
-
-@ifinfo
-@direntry
-* QEMU Internals: (qemu-tech).   The QEMU Emulator Internals.
-@end direntry
-@end ifinfo
-
-@iftex
-@titlepage
-@sp 7
-@center @titlefont{QEMU Internals}
-@sp 3
-@end titlepage
-@end iftex
-
-@ifnottex
-@node Top
-@top
+@node Implementation notes
+@appendix Implementation notes
 
 @menu
 * CPU emulation::
@@ -34,12 +7,9 @@
 * QEMU compared to other emulators::
 * Bibliography::
 @end menu
-@end ifnottex
-
-@contents
 
 @node CPU emulation
-@chapter CPU emulation
+@section CPU emulation
 
 @menu
 * x86:: x86 and x86-64 emulation
@@ -51,7 +21,7 @@
 @end menu
 
 @node x86
-@section x86 and x86-64 emulation
+@subsection x86 and x86-64 emulation
 
 QEMU x86 target features:
 
@@ -86,7 +56,7 @@ normal use.
 @end itemize
 
 @node ARM
-@section ARM emulation
+@subsection ARM emulation
 
 @itemize
 
@@ -99,7 +69,7 @@ normal use.
 @end itemize
 
 @node MIPS
-@section MIPS emulation
+@subsection MIPS emulation
 
 @itemize
 
@@ -126,7 +96,7 @@ Current QEMU limitations:
 @end itemize
 
 @node PPC
-@section PowerPC emulation
+@subsection PowerPC emulation
 
 @itemize
 
@@ -138,7 +108,7 @@ FPU and MMU.
 @end itemize
 
 @node SPARC
-@section Sparc32 and Sparc64 emulation
+@subsection Sparc32 and Sparc64 emulation
 
 @itemize
 
@@ -166,7 +136,7 @@ Current QEMU limitations:
 @end itemize
 
 @node Xtensa
-@section Xtensa emulation
+@subsection Xtensa emulation
 
 @itemize
 
@@ -191,7 +161,7 @@ may be created from overlay with minimal amount of 
hand-written code.
 @end itemize
 
 @node Translator Internals
-@chapter Translator Internals
+@section Translat

Re: [Qemu-devel] [PATCH 4/4] qga: add vsock-listen method

[Michael Roth]

Quoting Stefan Hajnoczi (2016-10-06 11:40:18)
> Add AF_VSOCK (virtio-vsock) support as an alternative to virtio-serial.
> 
>   $ qemu-system-x86_64 -device vhost-vsock-pci,guest-cid=3 ...
>   (guest)# qemu-ga -m vsock-listen -p 3:1234
> 
> Signed-off-by: Stefan Hajnoczi 

Reviewed-by: Michael Roth 

I still need to get a vsock environment set up to test with, but looks
good other than minor comments in patch 3.

> ---
>  qga/channel-posix.c | 25 +
>  qga/channel.h   |  1 +
>  qga/main.c  |  6 --
>  3 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/qga/channel-posix.c b/qga/channel-posix.c
> index 579891d..71582e0 100644
> --- a/qga/channel-posix.c
> +++ b/qga/channel-posix.c
> @@ -193,6 +193,31 @@ static gboolean ga_channel_open(GAChannel *c, const 
> gchar *path, GAChannelMethod
>  ga_channel_listen_add(c, fd, true);
>  break;
>  }
> +case GA_CHANNEL_VSOCK_LISTEN: {
> +Error *local_err = NULL;
> +SocketAddress *addr;
> +char *addr_str;
> +int fd;
> +
> +addr_str = g_strdup_printf("vsock:%s", path);
> +addr = socket_parse(addr_str, &local_err);
> +g_free(addr_str);
> +if (local_err != NULL) {
> +g_critical("%s", error_get_pretty(local_err));
> +error_free(local_err);
> +return false;
> +}
> +
> +fd = socket_listen(addr, &local_err);
> +qapi_free_SocketAddress(addr);
> +if (local_err != NULL) {
> +g_critical("%s", error_get_pretty(local_err));
> +error_free(local_err);
> +return false;
> +}
> +ga_channel_listen_add(c, fd, true);
> +break;
> +}
>  default:
>  g_critical("error binding/listening to specified socket");
>  return false;
> diff --git a/qga/channel.h b/qga/channel.h
> index ae8cf0f..8fd0c8f 100644
> --- a/qga/channel.h
> +++ b/qga/channel.h
> @@ -19,6 +19,7 @@ typedef enum {
>  GA_CHANNEL_VIRTIO_SERIAL,
>  GA_CHANNEL_ISA_SERIAL,
>  GA_CHANNEL_UNIX_LISTEN,
> +GA_CHANNEL_VSOCK_LISTEN,
>  } GAChannelMethod;
> 
>  typedef gboolean (*GAChannelCallback)(GIOCondition condition, gpointer 
> opaque);
> diff --git a/qga/main.c b/qga/main.c
> index 0b9d04e..6caf215 100644
> --- a/qga/main.c
> +++ b/qga/main.c
> @@ -190,8 +190,8 @@ static void usage(const char *cmd)
>  "Usage: %s [-m  -p ] []\n"
>  "QEMU Guest Agent %s\n"
>  "\n"
> -"  -m, --method  transport method: one of unix-listen, virtio-serial, 
> or\n"
> -"isa-serial (virtio-serial is the default)\n"
> +"  -m, --method  transport method: one of unix-listen, virtio-serial,\n"
> +"isa-serial, or vsock-listen (virtio-serial is the 
> default)\n"
>  "  -p, --pathdevice/socket path (the default for virtio-serial is:\n"
>  "%s,\n"
>  "the default for isa-serial is:\n"
> @@ -659,6 +659,8 @@ static gboolean channel_init(GAState *s, const gchar 
> *method, const gchar *path)
>  channel_method = GA_CHANNEL_ISA_SERIAL;
>  } else if (strcmp(method, "unix-listen") == 0) {
>  channel_method = GA_CHANNEL_UNIX_LISTEN;
> +} else if (strcmp(method, "vsock-listen") == 0) {
> +channel_method = GA_CHANNEL_VSOCK_LISTEN;
>  } else {
>  g_critical("unsupported channel method/type: %s", method);
>  return false;
> -- 
> 2.7.4
> 

[Qemu-devel] [PULL 36/39] qemu-tech: move TCG test documentation to tests/tcg/README

[Paolo Bonzini]

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi   | 35 --
 tests/tcg/README | 76 
 2 files changed, 76 insertions(+), 35 deletions(-)
 create mode 100644 tests/tcg/README

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 16780a1..adfb53b 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -31,7 +31,6 @@
 @menu
 * Introduction::
 * QEMU Internals::
-* Regression Tests::
 @end menu
 @end ifnottex
 
@@ -464,38 +463,4 @@ QEMU-SystemC, a hardware co-simulator.
 
 @end table
 
-@node Regression Tests
-@chapter Regression Tests
-
-In the directory @file{tests/}, various interesting testing programs
-are available. They are used for regression testing.
-
-@menu
-* test-i386::
-* linux-test::
-@end menu
-
-@node test-i386
-@section @file{test-i386}
-
-This program executes most of the 16 bit and 32 bit x86 instructions and
-generates a text output. It can be compared with the output obtained with
-a real CPU or another emulator. The target @code{make test} runs this
-program and a @code{diff} on the generated output.
-
-The Linux system call @code{modify_ldt()} is used to create x86 selectors
-to test some 16 bit addressing and 32 bit with segmentation cases.
-
-The Linux system call @code{vm86()} is used to test vm86 emulation.
-
-Various exceptions are raised to test most of the x86 user space
-exception reporting.
-
-@node linux-test
-@section @file{linux-test}
-
-This program tests various Linux system calls. It is used to verify
-that the system call parameters are correctly converted between target
-and host CPUs.
-
 @bye
diff --git a/tests/tcg/README b/tests/tcg/README
new file mode 100644
index 000..5dcfb48
--- /dev/null
+++ b/tests/tcg/README
@@ -0,0 +1,76 @@
+This directory contains various interesting programs for
+regression testing.
+
+The target "make test" runs the programs and, if applicable,
+runs "diff" to detect mismatches between output on the host and
+output on QEMU.
+
+i386
+
+
+test-i386
+-
+
+This program executes most of the 16 bit and 32 bit x86 instructions and
+generates a text output, for comparison with the output obtained with
+a real CPU or another emulator.
+
+The Linux system call modify_ldt() is used to create x86 selectors
+to test some 16 bit addressing and 32 bit with segmentation cases.
+
+The Linux system call vm86() is used to test vm86 emulation.
+
+Various exceptions are raised to test most of the x86 user space
+exception reporting.
+
+linux-test
+--
+
+This program tests various Linux system calls. It is used to verify
+that the system call parameters are correctly converted between target
+and host CPUs.
+
+test-i386-fprem
+---
+
+runcom
+--
+
+test-mmap
+-
+
+sha1
+
+
+hello-i386
+--
+
+
+ARM
+===
+
+hello-arm
+-
+
+test-arm-iwmmxt
+---
+
+MIPS
+
+
+hello-mips
+--
+
+hello-mipsel
+
+
+CRIS
+
+The testsuite for CRIS is in tests/tcg/cris.  You can run it
+with "make test-cris".
+
+LM32
+
+The testsuite for LM32 is in tests/tcg/cris.  You can run it
+with "make test-lm32".
+
-- 
2.7.4

[Qemu-devel] [PULL 32/39] qemu-doc: drop installation and compilation notes

[Paolo Bonzini]

These are in README or obsolete, and the detailed version can be on a
website instead.

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 README|   2 -
 qemu-doc.texi | 249 --
 2 files changed, 251 deletions(-)

diff --git a/README b/README
index f38193f..bd8060a 100644
--- a/README
+++ b/README
@@ -42,8 +42,6 @@ of other UNIX targets. The simple steps to build QEMU are:
   ../configure
   make
 
-Complete details of the process for building and configuring QEMU for
-all supported host platforms can be found in the qemu-tech.html file.
 Additional information can also be found online via the QEMU website:
 
   http://qemu-project.org/Hosts/Linux
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 9f75c9d..e60c46b 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -32,11 +32,9 @@
 
 @menu
 * Introduction::
-* Installation::
 * QEMU PC System emulator::
 * QEMU System emulator for non PC targets::
 * QEMU User space emulator::
-* compilation:: Compilation from the sources
 * License::
 * Index::
 @end menu
@@ -121,39 +119,6 @@ accelerator is required to use more than one host CPU for 
emulation.
 @end itemize
 
 
-@node Installation
-@chapter Installation
-
-If you want to compile QEMU yourself, see @ref{compilation}.
-
-@menu
-* install_linux::   Linux
-* install_windows:: Windows
-* install_mac:: Macintosh
-@end menu
-
-@node install_linux
-@section Linux
-@cindex installation (Linux)
-
-If a precompiled package is available for your distribution - you just
-have to install it. Otherwise, see @ref{compilation}.
-
-@node install_windows
-@section Windows
-@cindex installation (Windows)
-
-Download the experimental binary installer at
-@url{http://www.free.oszoo.org/@/download.html}.
-TODO (no longer available)
-
-@node install_mac
-@section Mac OS X
-
-Download the experimental binary installer at
-@url{http://www.free.oszoo.org/@/download.html}.
-TODO (no longer available)
-
 @node QEMU PC System emulator
 @chapter QEMU PC System emulator
 @cindex system emulation (PC)
@@ -2949,220 +2914,6 @@ Act as if the host page size was 'pagesize' bytes
 Run the emulation in single step mode.
 @end table
 
-@node compilation
-@chapter Compilation from the sources
-
-@menu
-* Linux/Unix::
-* Windows::
-* Cross compilation for Windows with Linux::
-* Mac OS X::
-* Make targets::
-@end menu
-
-@node Linux/Unix
-@section Linux/Unix
-
-@subsection Compilation
-
-First you must decompress the sources:
-@example
-cd /tmp
-tar zxvf qemu-x.y.z.tar.gz
-cd qemu-x.y.z
-@end example
-
-Then you configure QEMU and build it (usually no options are needed):
-@example
-./configure
-make
-@end example
-
-Then type as root user:
-@example
-make install
-@end example
-to install QEMU in @file{/usr/local}.
-
-@node Windows
-@section Windows
-
-@itemize
-@item Install the current versions of MSYS and MinGW from
-@url{http://www.mingw.org/}. You can find detailed installation
-instructions in the download section and the FAQ.
-
-@item Download
-the MinGW development library of SDL 1.2.x
-(@file{SDL-devel-1.2.x-@/mingw32.tar.gz}) from
-@url{http://www.libsdl.org}. Unpack it in a temporary place and
-edit the @file{sdl-config} script so that it gives the
-correct SDL directory when invoked.
-
-@item Install the MinGW version of zlib and make sure
-@file{zlib.h} and @file{libz.dll.a} are in
-MinGW's default header and linker search paths.
-
-@item Extract the current version of QEMU.
-
-@item Start the MSYS shell (file @file{msys.bat}).
-
-@item Change to the QEMU directory. Launch @file{./configure} and
-@file{make}.  If you have problems using SDL, verify that
-@file{sdl-config} can be launched from the MSYS command line.
-
-@item You can install QEMU in @file{Program Files/QEMU} by typing
-@file{make install}. Don't forget to copy @file{SDL.dll} in
-@file{Program Files/QEMU}.
-
-@end itemize
-
-@node Cross compilation for Windows with Linux
-@section Cross compilation for Windows with Linux
-
-@itemize
-@item
-Install the MinGW cross compilation tools available at
-@url{http://www.mingw.org/}.
-
-@item Download
-the MinGW development library of SDL 1.2.x
-(@file{SDL-devel-1.2.x-@/mingw32.tar.gz}) from
-@url{http://www.libsdl.org}. Unpack it in a temporary place and
-edit the @file{sdl-config} script so that it gives the
-correct SDL directory when invoked.  Set up the @code{PATH} environment
-variable so that @file{sdl-config} can be launched by
-the QEMU configuration script.
-
-@item Install the MinGW version of zlib and make sure
-@file{zlib.h} and @file{libz.dll.a} are in
-MinGW's default header and linker search paths.
-
-@item
-Configure QEMU for Windows cross compilation:
-@example
-PATH=/usr/i686-pc-mingw32/sys-root/mingw/bin:$PATH ./configure 
--cross-prefix='i686-pc-mingw32-'
-@end example
-The example assumes @file{sdl-config} is installed under 
@file{/usr/i686-pc-mingw32/sys-root/mingw/bin} and
-MinGW cross compilation tools have names like @file{i686

[Qemu-devel] [PULL 38/39] qemu-tech: rewrite some parts

[Paolo Bonzini]

Drop most the device emulation part and merge the rest into the description
of the MMU.  Make some bits more up-to-date.

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi | 124 +++--
 1 file changed, 42 insertions(+), 82 deletions(-)

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 2e499a7..b418a41 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -31,7 +31,6 @@
 @menu
 * CPU emulation::
 * Translator Internals::
-* Device emulation::
 * QEMU compared to other emulators::
 * Bibliography::
 @end menu
@@ -194,15 +193,6 @@ may be created from overlay with minimal amount of 
hand-written code.
 @node Translator Internals
 @chapter Translator Internals
 
-@menu
-* CPU state optimisations::
-* Translation cache::
-* Direct block chaining::
-* Self-modifying code and translated code invalidation::
-* Exception support::
-* MMU emulation::
-@end menu
-
 QEMU is a dynamic translator. When it first encounters a piece of code,
 it converts it to the host instruction set. Usually dynamic translators
 are very complicated and highly CPU dependent. QEMU uses some tricks
@@ -212,33 +202,23 @@ performances.
 QEMU's dynamic translation backend is called TCG, for "Tiny Code
 Generator". For more information, please take a look at @code{tcg/README}.
 
-@node CPU state optimisations
-@section CPU state optimisations
+Some notable features of QEMU's dynamic translator are:
 
+@table @strong
+
+@item CPU state optimisations:
 The target CPUs have many internal states which change the way it
 evaluates instructions. In order to achieve a good speed, the
 translation phase considers that some state information of the virtual
 CPU cannot change in it. The state is recorded in the Translation
 Block (TB). If the state changes (e.g. privilege level), a new TB will
 be generated and the previous TB won't be used anymore until the state
-matches the state recorded in the previous TB. For example, if the SS,
+matches the state recorded in the previous TB. The same idea can be applied
+to other aspects of the CPU state.  For example, on x86, if the SS,
 DS and ES segments have a zero base, then the translator does not even
 generate an addition for the segment base.
 
-[The FPU stack pointer register is not handled that way yet].
-
-@node Translation cache
-@section Translation cache
-
-A 32 MByte cache holds the most recently used translations. For
-simplicity, it is completely flushed when it is full. A translation unit
-contains just a single basic block (a block of x86 instructions
-terminated by a jump or by a virtual CPU state change which the
-translator cannot deduce statically).
-
-@node Direct block chaining
-@section Direct block chaining
-
+@item Direct block chaining:
 After each translated basic block is executed, QEMU uses the simulated
 Program Counter (PC) and other cpu state information (such as the CS
 segment base value) to find the next basic block.
@@ -252,18 +232,17 @@ it easier to make the jump target modification atomic. On 
some host
 architectures (such as x86 or PowerPC), the @code{JUMP} opcode is
 directly patched so that the block chaining has no overhead.
 
-@node Self-modifying code and translated code invalidation
-@section Self-modifying code and translated code invalidation
-
+@item Self-modifying code and translated code invalidation:
 Self-modifying code is a special challenge in x86 emulation because no
 instruction cache invalidation is signaled by the application when code
 is modified.
 
-When translated code is generated for a basic block, the corresponding
-host page is write protected if it is not already read-only. Then, if
-a write access is done to the page, Linux raises a SEGV signal. QEMU
-then invalidates all the translated code in the page and enables write
-accesses to the page.
+User-mode emulation marks a host page as write-protected (if it is
+not already read-only) every time translated code is generated for a
+basic block.  Then, if a write access is done to the page, Linux raises
+a SEGV signal. QEMU then invalidates all the translated code in the page
+and enables write accesses to the page.  For system emulation, write
+protection is achieved through the software MMU.
 
 Correct translated code invalidation is done efficiently by maintaining
 a linked list of every translated block contained in a given page. Other
@@ -275,63 +254,44 @@ necessary. However, QEMU still requires that the 
generated code always
 matches the target instructions in memory in order to handle
 exceptions correctly.
 
-@node Exception support
-@section Exception support
-
+@item Exception support:
 longjmp() is used when an exception such as division by zero is
 encountered.
 
 The host SIGSEGV and SIGBUS signal handlers are used to get invalid
-memory accesses. The simulated program counter is found by
-retranslating the corresponding basic block and by looking where the
-host program counter was at the exception poi

[Qemu-devel] [PULL 33/39] qemu-tech: move text from qemu-tech to tcg/README

[Paolo Bonzini]

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi | 12 ++--
 tcg/README |  5 +
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 2ab7cd4..082b62c 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -287,16 +287,8 @@ are very complicated and highly CPU dependent. QEMU uses 
some tricks
 which make it relatively easily portable and simple while achieving good
 performances.
 
-After the release of version 0.9.1, QEMU switched to a new method of
-generating code, Tiny Code Generator or TCG. TCG relaxes the
-dependency on the exact version of the compiler used. The basic idea
-is to split every target instruction into a couple of RISC-like TCG
-ops (see @code{target-i386/translate.c}). Some optimizations can be
-performed at this stage, including liveness analysis and trivial
-constant expression evaluation. TCG ops are then implemented in the
-host CPU back end, also known as TCG target (see
-@code{tcg/i386/tcg-target.inc.c}). For more information, please take a
-look at @code{tcg/README}.
+QEMU's dynamic translation backend is called TCG, for "Tiny Code
+Generator". For more information, please take a look at @code{tcg/README}.
 
 @node Condition code optimisations
 @section Condition code optimisations
diff --git a/tcg/README b/tcg/README
index 1d48aa9..ae31388 100644
--- a/tcg/README
+++ b/tcg/README
@@ -8,6 +8,11 @@ in the QOP code generator written by Paul Brook.
 
 2) Definitions
 
+TCG receives RISC-like "TCG ops" and performs some optimizations on them,
+including liveness analysis and trivial constant expression
+evaluation.  TCG ops are then implemented in the host CPU back end,
+also known as the TCG "target".
+
 The TCG "target" is the architecture for which we generate the
 code. It is of course not the same as the "target" of QEMU which is
 the emulated architecture. As TCG started as a generic C backend used
-- 
2.7.4

[Qemu-devel] [PULL 27/39] qht: simplify qht_reset_size

[Paolo Bonzini]

From: "Emilio G. Cota" 

Sometimes gcc doesn't pick up the fact that 'new' is properly
set if 'resize == true', which may generate an unnecessary
build warning.

Fix it by removing 'resize' and directly checking that 'new'
is non-NULL.

Signed-off-by: Emilio G. Cota 
Message-Id: <1475706880-10667-2-git-send-email-c...@braap.org>
Signed-off-by: Paolo Bonzini 
---
 util/qht.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/util/qht.c b/util/qht.c
index 571639d..4dd9be8 100644
--- a/util/qht.c
+++ b/util/qht.c
@@ -410,10 +410,9 @@ void qht_reset(struct qht *ht)
 
 bool qht_reset_size(struct qht *ht, size_t n_elems)
 {
-struct qht_map *new;
+struct qht_map *new = NULL;
 struct qht_map *map;
 size_t n_buckets;
-bool resize = false;
 
 n_buckets = qht_elems_to_buckets(n_elems);
 
@@ -421,18 +420,17 @@ bool qht_reset_size(struct qht *ht, size_t n_elems)
 map = ht->map;
 if (n_buckets != map->n_buckets) {
 new = qht_map_create(n_buckets);
-resize = true;
 }
 
 qht_map_lock_buckets(map);
 qht_map_reset__all_locked(map);
-if (resize) {
+if (new) {
 qht_do_resize(ht, new);
 }
 qht_map_unlock_buckets(map);
 qemu_mutex_unlock(&ht->lock);
 
-return resize;
+return !!new;
 }
 
 static inline
-- 
2.7.4

[Qemu-devel] [PULL 26/39] qemu-nbd: Shrink image size by specified offset

[Paolo Bonzini]

From: Tomáš Golembiovský 

When --offset is set the apparent device size has to be adjusted
accordingly. Otherwise client may request read/write beyond the file end
which would fail.

Signed-off-by: Tomáš Golembiovský 
Message-Id: 
<8a31654cb182932db78b95aae1e904fc2bd1c465.1475698895.git.tgole...@redhat.com>
Reviewed-by: Eric Blake 
Signed-off-by: Paolo Bonzini 
---
 qemu-nbd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index 99297a5..705b95e 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -901,6 +901,14 @@ int main(int argc, char **argv)
 exit(EXIT_FAILURE);
 }
 
+if (dev_offset >= fd_size) {
+error_report("Offset (%lld) has to be smaller than the image size "
+ "(%lld)",
+ (long long int)dev_offset, (long long int)fd_size);
+exit(EXIT_FAILURE);
+}
+fd_size -= dev_offset;
+
 if (partition != -1) {
 ret = find_partition(blk, partition, &dev_offset, &fd_size);
 if (ret < 0) {
-- 
2.7.4

[Qemu-devel] [PULL 30/39] qemu-tech: drop index

[Paolo Bonzini]

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-tech.texi | 5 -
 1 file changed, 5 deletions(-)

diff --git a/qemu-tech.texi b/qemu-tech.texi
index 1b048cb..be1c210 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -32,7 +32,6 @@
 * Introduction::
 * QEMU Internals::
 * Regression Tests::
-* Index::
 @end menu
 @end ifnottex
 
@@ -691,8 +690,4 @@ This program tests various Linux system calls. It is used 
to verify
 that the system call parameters are correctly converted between target
 and host CPUs.
 
-@node Index
-@chapter Index
-@printindex cp
-
 @bye
-- 
2.7.4

[Qemu-devel] [PULL 17/39] util/qht: atomically set b->hashes

[Paolo Bonzini]

From: Alex Bennée 

ThreadSanitizer detects a possible race between reading/writing the
hashes. The ordering semantics are already documented for QHT however
for true C11 compliance we should use relaxed atomic primitives for
accesses that are done across threads. On x86 this slightly changes to
the code to not do a load/compare in a single instruction leading to a
slight performance degradation.

Running 'taskset -c 0 tests/qht-bench -n 1 -d 10' (i.e. all lookups) 10
times, we get:

before the patch:
 $ ./mean.pl 34.04 34.24 34.38 34.25 34.18 34.51 34.46 34.44 34.29 34.08
 34.287 +- 0.160072900059109
after:
 $ ./mean.pl 33.94 34.00 33.52 33.46 33.55 33.71 34.27 34.06 34.28 34.58
 33.937 +- 0.374731014640279

Signed-off-by: Alex Bennée 
Reviewed-by: Emilio G. Cota 
Message-Id: <20160930213106.20186-10-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 util/qht.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/util/qht.c b/util/qht.c
index 16a8d79..571639d 100644
--- a/util/qht.c
+++ b/util/qht.c
@@ -379,7 +379,7 @@ static void qht_bucket_reset__locked(struct qht_bucket 
*head)
 if (b->pointers[i] == NULL) {
 goto done;
 }
-b->hashes[i] = 0;
+atomic_set(&b->hashes[i], 0);
 atomic_set(&b->pointers[i], NULL);
 }
 b = b->next;
@@ -444,7 +444,7 @@ void *qht_do_lookup(struct qht_bucket *head, 
qht_lookup_func_t func,
 
 do {
 for (i = 0; i < QHT_BUCKET_ENTRIES; i++) {
-if (b->hashes[i] == hash) {
+if (atomic_read(&b->hashes[i]) == hash) {
 /* The pointer is dereferenced before seqlock_read_retry,
  * so (unlike qht_insert__locked) we need to use
  * atomic_rcu_read here.
@@ -538,8 +538,8 @@ static bool qht_insert__locked(struct qht *ht, struct 
qht_map *map,
 if (new) {
 atomic_rcu_set(&prev->next, b);
 }
-b->hashes[i] = hash;
 /* smp_wmb() implicit in seqlock_write_begin.  */
+atomic_set(&b->hashes[i], hash);
 atomic_set(&b->pointers[i], p);
 seqlock_write_end(&head->sequence);
 return true;
@@ -607,10 +607,10 @@ qht_entry_move(struct qht_bucket *to, int i, struct 
qht_bucket *from, int j)
 qht_debug_assert(to->pointers[i]);
 qht_debug_assert(from->pointers[j]);
 
-to->hashes[i] = from->hashes[j];
+atomic_set(&to->hashes[i], from->hashes[j]);
 atomic_set(&to->pointers[i], from->pointers[j]);
 
-from->hashes[j] = 0;
+atomic_set(&from->hashes[j], 0);
 atomic_set(&from->pointers[j], NULL);
 }
 
-- 
2.7.4

[Qemu-devel] [PULL 31/39] qemu-doc: replace introduction with the one from the internals manual

[Paolo Bonzini]

The user manual has an obsolete introduction, and the one in
the internals manual lists QEMU's features quite nicely.
Drop the obsolete content and remove generic user-level
documentation from qemu-tech.

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-doc.texi  | 84 +--
 qemu-tech.texi | 88 --
 2 files changed, 44 insertions(+), 128 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index f37fd31..9f75c9d 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -57,65 +57,69 @@
 QEMU is a FAST! processor emulator using dynamic translation to
 achieve good emulation speed.
 
+@cindex operating modes
 QEMU has two operating modes:
 
 @itemize
-@cindex operating modes
-
-@item
 @cindex system emulation
-Full system emulation. In this mode, QEMU emulates a full system (for
+@item Full system emulation. In this mode, QEMU emulates a full system (for
 example a PC), including one or several processors and various
 peripherals. It can be used to launch different Operating Systems
 without rebooting the PC or to debug system code.
 
-@item
 @cindex user mode emulation
-User mode emulation. In this mode, QEMU can launch
+@item User mode emulation. In this mode, QEMU can launch
 processes compiled for one CPU on another CPU. It can be used to
 launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
 to ease cross-compilation and cross-debugging.
 
 @end itemize
 
-QEMU can run without a host kernel driver and yet gives acceptable
-performance.
+QEMU has the following features:
+
+@itemize
+@item QEMU can run without a host kernel driver and yet gives acceptable
+performance.  It uses dynamic translation to native code for reasonable speed,
+with support for self-modifying code and precise exceptions.
+
+@item It is portable to several operating systems (GNU/Linux, *BSD, Mac OS X,
+Windows) and architectures.
+
+@item It performs accurate software emulation of the FPU.
+@end itemize
 
-For system emulation, the following hardware targets are supported:
+QEMU user mode emulation has the following features:
 @itemize
-@cindex emulated target systems
-@cindex supported target systems
-@item PC (x86 or x86_64 processor)
-@item ISA PC (old style PC without PCI bus)
-@item PREP (PowerPC processor)
-@item G3 Beige PowerMac (PowerPC processor)
-@item Mac99 PowerMac (PowerPC processor, in progress)
-@item Sun4m/Sun4c/Sun4d (32-bit Sparc processor)
-@item Sun4u/Sun4v (64-bit Sparc processor, in progress)
-@item Malta board (32-bit and 64-bit MIPS processors)
-@item MIPS Magnum (64-bit MIPS processor)
-@item ARM Integrator/CP (ARM)
-@item ARM Versatile baseboard (ARM)
-@item ARM RealView Emulation/Platform baseboard (ARM)
-@item Spitz, Akita, Borzoi, Terrier and Tosa PDAs (PXA270 processor)
-@item Luminary Micro LM3S811EVB (ARM Cortex-M3)
-@item Luminary Micro LM3S6965EVB (ARM Cortex-M3)
-@item Freescale MCF5208EVB (ColdFire V2).
-@item Arnewsh MCF5206 evaluation board (ColdFire V2).
-@item Palm Tungsten|E PDA (OMAP310 processor)
-@item N800 and N810 tablets (OMAP2420 processor)
-@item MusicPal (MV88W8618 ARM processor)
-@item Gumstix "Connex" and "Verdex" motherboards (PXA255/270).
-@item Siemens SX1 smartphone (OMAP310 processor)
-@item AXIS-Devboard88 (CRISv32 ETRAX-FS).
-@item Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze).
-@item Avnet LX60/LX110/LX200 boards (Xtensa)
+@item Generic Linux system call converter, including most ioctls.
+
+@item clone() emulation using native CPU clone() to use Linux scheduler for 
threads.
+
+@item Accurate signal handling by remapping host signals to target signals.
+@end itemize
+
+QEMU full system emulation has the following features:
+@itemize
+@item
+QEMU uses a full software MMU for maximum portability.
+
+@item
+QEMU can optionally use an in-kernel accelerator, like kvm. The accelerators 
+execute most of the guest code natively, while
+continuing to emulate the rest of the machine.
+
+@item
+Various hardware devices can be emulated and in some cases, host
+devices (e.g. serial and parallel ports, USB, drives) can be used
+transparently by the guest Operating System. Host device passthrough
+can be used for talking to external physical peripherals (e.g. a
+webcam, modem or tape drive).
+
+@item
+Symmetric multiprocessing (SMP) support.  Currently, an in-kernel
+accelerator is required to use more than one host CPU for emulation.
+
 @end itemize
 
-@cindex supported user mode targets
-For user emulation, x86 (32 and 64 bit), PowerPC (32 and 64 bit),
-ARM, MIPS (32 bit only), Sparc (32 and 64 bit),
-Alpha, ColdFire(m68k), CRISv32 and MicroBlaze CPUs are supported.
 
 @node Installation
 @chapter Installation
diff --git a/qemu-tech.texi b/qemu-tech.texi
index be1c210..2ab7cd4 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -41,7 +41,6 @@
 @chapter Introduction
 
 @menu
-* intro_features:: Features
 * intro_x86_emulation::x

[Qemu-devel] [PULL 29/39] test-qht: perform lookups under rcu_read_lock

[Paolo Bonzini]

From: "Emilio G. Cota" 

qht_lookup is meant to be called from an RCU read-critical
section. Make sure we're in such a section in test-qht
when performing lookups, despite the fact that no races
in qht can be triggered by test-qht since it is single-threaded.

Note that rcu_register_thread is already called by the
rcu_after_fork hook, and therefore duplicating it here would
be a bug.

Signed-off-by: Emilio G. Cota 
Message-Id: <1475706880-10667-4-git-send-email-c...@braap.org>
Signed-off-by: Paolo Bonzini 
---
 tests/test-qht.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/test-qht.c b/tests/test-qht.c
index 46a64b6..9b7423a 100644
--- a/tests/test-qht.c
+++ b/tests/test-qht.c
@@ -6,6 +6,7 @@
  */
 #include "qemu/osdep.h"
 #include "qemu/qht.h"
+#include "qemu/rcu.h"
 
 #define N 5000
 
@@ -51,6 +52,7 @@ static void check(int a, int b, bool expected)
 struct qht_stats stats;
 int i;
 
+rcu_read_lock();
 for (i = a; i < b; i++) {
 void *p;
 uint32_t hash;
@@ -61,6 +63,8 @@ static void check(int a, int b, bool expected)
 p = qht_lookup(&ht, is_equal, &val, hash);
 g_assert_true(!!p == expected);
 }
+rcu_read_unlock();
+
 qht_statistics_init(&ht, &stats);
 if (stats.used_head_buckets) {
 g_assert_cmpfloat(qdist_avg(&stats.chain), >=, 1.0);
-- 
2.7.4

[Qemu-devel] [PULL 35/39] qemu-tech: move user mode emulation features from qemu-tech

[Paolo Bonzini]

These are interesting for users too, since nowadays most
qemu-user users are going to be somewhat technical rather than
just people that want to run Wine.  Some detail is lost, on
the other hand some of the information I removed (e.g. basic
block unchaining) was obsolete.

Reviewed-by: Emilio G. Cota 
Signed-off-by: Paolo Bonzini 
---
 qemu-doc.texi  | 34 
 qemu-tech.texi | 71 --
 2 files changed, 34 insertions(+), 71 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index e60c46b..227c2b0 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -2629,6 +2629,7 @@ so should only be used with trusted guest OS.
 
 @menu
 * Supported Operating Systems ::
+* Features::
 * Linux User space emulator::
 * BSD User space emulator ::
 @end menu
@@ -2645,6 +2646,39 @@ Linux (referred as qemu-linux-user)
 BSD (referred as qemu-bsd-user)
 @end itemize
 
+@node Features
+@section Features
+
+QEMU user space emulation has the following notable features:
+
+@table @strong
+@item System call translation:
+QEMU includes a generic system call translator.  This means that
+the parameters of the system calls can be converted to fix
+endianness and 32/64-bit mismatches between hosts and targets.
+IOCTLs can be converted too.
+
+@item POSIX signal handling:
+QEMU can redirect to the running program all signals coming from
+the host (such as @code{SIGALRM}), as well as synthesize signals from
+virtual CPU exceptions (for example @code{SIGFPE} when the program
+executes a division by zero).
+
+QEMU relies on the host kernel to emulate most signal system
+calls, for example to emulate the signal mask.  On Linux, QEMU
+supports both normal and real-time signals.
+
+@item Threading:
+On Linux, QEMU can emulate the @code{clone} syscall and create a real
+host thread (with a separate virtual CPU) for each emulated thread.
+Note that not all targets currently emulate atomic operations correctly.
+x86 and ARM use a global lock in order to preserve their semantics.
+@end table
+
+QEMU was conceived so that ultimately it can emulate itself. Although
+it is not very useful, it is an important test to show the power of the
+emulator.
+
 @node Linux User space emulator
 @section Linux User space emulator
 
diff --git a/qemu-tech.texi b/qemu-tech.texi
index 75ceea4..16780a1 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -221,8 +221,6 @@ SH4
 * Exception support::
 * MMU emulation::
 * Device emulation::
-* Hardware interrupts::
-* User emulation specific details::
 * Bibliography::
 @end menu
 
@@ -410,75 +408,6 @@ Usually the devices implement a reset method and register 
support for
 saving and loading of the device state. The devices can also use
 timers, especially together with the use of bottom halves (BHs).
 
-@node Hardware interrupts
-@section Hardware interrupts
-
-In order to be faster, QEMU does not check at every basic block if a
-hardware interrupt is pending. Instead, the user must asynchronously
-call a specific function to tell that an interrupt is pending. This
-function resets the chaining of the currently executing basic
-block. It ensures that the execution will return soon in the main loop
-of the CPU emulator. Then the main loop can test if the interrupt is
-pending and handle it.
-
-@node User emulation specific details
-@section User emulation specific details
-
-@subsection Linux system call translation
-
-QEMU includes a generic system call translator for Linux. It means that
-the parameters of the system calls can be converted to fix the
-endianness and 32/64 bit issues. The IOCTLs are converted with a generic
-type description system (see @file{ioctls.h} and @file{thunk.c}).
-
-QEMU supports host CPUs which have pages bigger than 4KB. It records all
-the mappings the process does and try to emulated the @code{mmap()}
-system calls in cases where the host @code{mmap()} call would fail
-because of bad page alignment.
-
-@subsection Linux signals
-
-Normal and real-time signals are queued along with their information
-(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt
-request is done to the virtual CPU. When it is interrupted, one queued
-signal is handled by generating a stack frame in the virtual CPU as the
-Linux kernel does. The @code{sigreturn()} system call is emulated to return
-from the virtual signal handler.
-
-Some signals (such as SIGALRM) directly come from the host. Other
-signals are synthesized from the virtual CPU exceptions such as SIGFPE
-when a division by zero is done (see @code{main.c:cpu_loop()}).
-
-The blocked signal mask is still handled by the host Linux kernel so
-that most signal system calls can be redirected directly to the host
-Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system
-calls need to be fully emulated (see @file{signal.c}).
-
-@subsection clone() system call and threads
-
-The Linux clone() system call is usually used to create a thread. QEMU
-us

[Qemu-devel] [PULL 24/39] util: Introduce qemu_get_pid_name

[Paolo Bonzini]

From: Michal Privoznik 

This is a small helper that tries to fetch binary name for given
PID.

Signed-off-by: Michal Privoznik 
Message-Id: 
<4d75d475c1884f8e94ee8b1e57273ddf3ed68bf7.1474987617.git.mpriv...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 include/qemu/osdep.h | 10 ++
 util/oslib-posix.c   | 27 +++
 util/oslib-win32.c   |  7 +++
 3 files changed, 44 insertions(+)

diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 9e9fa61..384bfe2 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -388,6 +388,16 @@ void os_mem_prealloc(int fd, char *area, size_t sz, Error 
**errp);
 int qemu_read_password(char *buf, int buf_size);
 
 /**
+ * qemu_get_pid_name:
+ * @pid: pid of a process
+ *
+ * For given @pid fetch its name. Caller is responsible for
+ * freeing the string when no longer needed.
+ * Returns allocated string on success, NULL on failure.
+ */
+char *qemu_get_pid_name(pid_t pid);
+
+/**
  * qemu_fork:
  *
  * A version of fork that avoids signal handler race
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index f2d4e9e..8c1e8d6 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -46,6 +46,7 @@
 
 #ifdef __FreeBSD__
 #include 
+#include 
 #endif
 
 #include "qemu/mmap-alloc.h"
@@ -430,6 +431,32 @@ int qemu_read_password(char *buf, int buf_size)
 }
 
 
+char *qemu_get_pid_name(pid_t pid)
+{
+char *name = NULL;
+
+#if defined(__FreeBSD__)
+/* BSDs don't have /proc, but they provide a nice substitute */
+struct kinfo_proc *proc = kinfo_getproc(pid);
+
+if (proc) {
+name = g_strdup(proc->ki_comm);
+free(proc);
+}
+#else
+/* Assume a system with reasonable procfs */
+char *pid_path;
+size_t len;
+
+pid_path = g_strdup_printf("/proc/%d/cmdline", pid);
+g_file_get_contents(pid_path, &name, &len, NULL);
+g_free(pid_path);
+#endif
+
+return name;
+}
+
+
 pid_t qemu_fork(Error **errp)
 {
 sigset_t oldmask, newmask;
diff --git a/util/oslib-win32.c b/util/oslib-win32.c
index 4c1dcf1..d09863c 100644
--- a/util/oslib-win32.c
+++ b/util/oslib-win32.c
@@ -575,6 +575,13 @@ int qemu_read_password(char *buf, int buf_size)
 }
 
 
+char *qemu_get_pid_name(pid_t pid)
+{
+/* XXX Implement me */
+abort();
+}
+
+
 pid_t qemu_fork(Error **errp)
 {
 errno = ENOSYS;
-- 
2.7.4

[Qemu-devel] [PULL 21/39] i8259: give ISA device when registering ISA ioports

[Paolo Bonzini]

From: Hervé Poussineau 

Signed-off-by: Hervé Poussineau 
Message-Id: <1475437467-22781-1-git-send-email-hpous...@reactos.org>
Signed-off-by: Paolo Bonzini 
---
 hw/intc/i8259_common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c
index 3a850b0..d9a5e8b 100644
--- a/hw/intc/i8259_common.c
+++ b/hw/intc/i8259_common.c
@@ -70,10 +70,11 @@ static int pic_dispatch_post_load(void *opaque, int 
version_id)
 static void pic_common_realize(DeviceState *dev, Error **errp)
 {
 PICCommonState *s = PIC_COMMON(dev);
+ISADevice *isa = ISA_DEVICE(dev);
 
-isa_register_ioport(NULL, &s->base_io, s->iobase);
+isa_register_ioport(isa, &s->base_io, s->iobase);
 if (s->elcr_addr != -1) {
-isa_register_ioport(NULL, &s->elcr_io, s->elcr_addr);
+isa_register_ioport(isa, &s->elcr_io, s->elcr_addr);
 }
 
 qdev_set_legacy_instance_id(dev, s->iobase, 1);
-- 
2.7.4

[Qemu-devel] [PULL 25/39] qemu_kill_report: Report PID name too

[Paolo Bonzini]

From: Michal Privoznik 

When qemu is being killed, its last words are:

2016-08-31T11:48:15.293587Z qemu-system-x86_64: terminating on signal 15 from 
pid 11180

That's nice, but what process is 11180? What if I told you we can
do better:

2016-08-31T11:48:15.293587Z qemu-system-x86_64: terminating on signal 15 from 
pid 11180 (/usr/sbin/libvirtd)

And that's exactly what this patch does.

Signed-off-by: Michal Privoznik 
Message-Id: 

Signed-off-by: Paolo Bonzini 
---
 vl.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index f3abd99..6c5a51c 100644
--- a/vl.c
+++ b/vl.c
@@ -1675,8 +1675,12 @@ static void qemu_kill_report(void)
  */
 error_report("terminating on signal %d", shutdown_signal);
 } else {
-error_report("terminating on signal %d from pid " FMT_pid,
- shutdown_signal, shutdown_pid);
+char *shutdown_cmd = qemu_get_pid_name(shutdown_pid);
+
+error_report("terminating on signal %d from pid " FMT_pid " (%s)",
+ shutdown_signal, shutdown_pid,
+ shutdown_cmd ? shutdown_cmd : "");
+g_free(shutdown_cmd);
 }
 shutdown_signal = -1;
 }
-- 
2.7.4

[Qemu-devel] [PULL 28/39] qht: fix unlock-after-free segfault upon resizing

[Paolo Bonzini]

From: "Emilio G. Cota" 

The old map's bucket locks are being unlocked *after*
that same old map has been passed to RCU for destruction.
This is a bug that can cause a segfault, since there's
no guarantee that the deletion will be deferred (e.g.
there may be no concurrent readers).

The segfault is easily triggered in RHEL6/CentOS6 with qht-test,
particularly on a single-core system or by pinning qht-test
to a single core.

Fix it by unlocking the map's bucket locks right after having
published the new map, and (crucially) before marking the map
for deletion via call_rcu().

While at it, expand qht_do_resize() to atomically do (1) a reset,
(2) a resize, or (3) a reset+resize. This simplifies the calling
code, since the new function (qht_do_resize_reset()) acquires
and releases the buckets' locks.

Note that no qht_do_reset inline is provided, since it would have
no users--qht_reset() already performs a reset without taking
ht->lock.

Reported-by: Peter Maydell 
Reported-by: Daniel P. Berrange 
Signed-off-by: Emilio G. Cota 
Message-Id: <1475706880-10667-3-git-send-email-c...@braap.org>
Signed-off-by: Paolo Bonzini 
---
 util/qht.c | 49 -
 1 file changed, 28 insertions(+), 21 deletions(-)

diff --git a/util/qht.c b/util/qht.c
index 4dd9be8..ff4d2e6 100644
--- a/util/qht.c
+++ b/util/qht.c
@@ -133,7 +133,8 @@ struct qht_map {
 /* trigger a resize when n_added_buckets > n_buckets / div */
 #define QHT_NR_ADDED_BUCKETS_THRESHOLD_DIV 8
 
-static void qht_do_resize(struct qht *ht, struct qht_map *new);
+static void qht_do_resize_reset(struct qht *ht, struct qht_map *new,
+bool reset);
 static void qht_grow_maybe(struct qht *ht);
 
 #ifdef QHT_DEBUG
@@ -408,6 +409,16 @@ void qht_reset(struct qht *ht)
 qht_map_unlock_buckets(map);
 }
 
+static inline void qht_do_resize(struct qht *ht, struct qht_map *new)
+{
+qht_do_resize_reset(ht, new, false);
+}
+
+static inline void qht_do_resize_and_reset(struct qht *ht, struct qht_map *new)
+{
+qht_do_resize_reset(ht, new, true);
+}
+
 bool qht_reset_size(struct qht *ht, size_t n_elems)
 {
 struct qht_map *new = NULL;
@@ -421,13 +432,7 @@ bool qht_reset_size(struct qht *ht, size_t n_elems)
 if (n_buckets != map->n_buckets) {
 new = qht_map_create(n_buckets);
 }
-
-qht_map_lock_buckets(map);
-qht_map_reset__all_locked(map);
-if (new) {
-qht_do_resize(ht, new);
-}
-qht_map_unlock_buckets(map);
+qht_do_resize_and_reset(ht, new);
 qemu_mutex_unlock(&ht->lock);
 
 return !!new;
@@ -559,9 +564,7 @@ static __attribute__((noinline)) void qht_grow_maybe(struct 
qht *ht)
 if (qht_map_needs_resize(map)) {
 struct qht_map *new = qht_map_create(map->n_buckets * 2);
 
-qht_map_lock_buckets(map);
 qht_do_resize(ht, new);
-qht_map_unlock_buckets(map);
 }
 qemu_mutex_unlock(&ht->lock);
 }
@@ -737,24 +740,31 @@ static void qht_map_copy(struct qht *ht, void *p, 
uint32_t hash, void *userp)
 }
 
 /*
- * Call with ht->lock and all bucket locks held.
- *
- * Creating the @new map here would add unnecessary delay while all the locks
- * are held--holding up the bucket locks is particularly bad, since no writes
- * can occur while these are held. Thus, we let callers create the new map,
- * hopefully without the bucket locks held.
+ * Atomically perform a resize and/or reset.
+ * Call with ht->lock held.
  */
-static void qht_do_resize(struct qht *ht, struct qht_map *new)
+static void qht_do_resize_reset(struct qht *ht, struct qht_map *new, bool 
reset)
 {
 struct qht_map *old;
 
 old = ht->map;
-g_assert_cmpuint(new->n_buckets, !=, old->n_buckets);
+qht_map_lock_buckets(old);
 
+if (reset) {
+qht_map_reset__all_locked(old);
+}
+
+if (new == NULL) {
+qht_map_unlock_buckets(old);
+return;
+}
+
+g_assert_cmpuint(new->n_buckets, !=, old->n_buckets);
 qht_map_iter__all_locked(ht, old, qht_map_copy, new);
 qht_map_debug__all_locked(new);
 
 atomic_rcu_set(&ht->map, new);
+qht_map_unlock_buckets(old);
 call_rcu(old, qht_map_destroy, rcu);
 }
 
@@ -766,12 +776,9 @@ bool qht_resize(struct qht *ht, size_t n_elems)
 qemu_mutex_lock(&ht->lock);
 if (n_buckets != ht->map->n_buckets) {
 struct qht_map *new;
-struct qht_map *old = ht->map;
 
 new = qht_map_create(n_buckets);
-qht_map_lock_buckets(old);
 qht_do_resize(ht, new);
-qht_map_unlock_buckets(old);
 ret = true;
 }
 qemu_mutex_unlock(&ht->lock);
-- 
2.7.4

[Qemu-devel] [PULL 16/39] cpu: atomically modify cpu->exit_request

[Paolo Bonzini]

From: Alex Bennée 

ThreadSanitizer picks up potential races although we already use
barriers to ensure things are in the correct order when processing exit
requests. For true C11 defined behaviour across threads we need to use
relaxed atomic_set/atomic_read semantics to reassure tsan.

Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-9-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 cpu-exec.c | 8 
 qom/cpu.c  | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 8823d23..e114fcd 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -192,7 +192,7 @@ static inline tcg_target_ulong cpu_tb_exec(CPUState *cpu, 
TranslationBlock *itb)
 /* We were asked to stop executing TBs (probably a pending
  * interrupt. We've now stopped, so clear the flag.
  */
-cpu->tcg_exit_req = 0;
+atomic_set(&cpu->tcg_exit_req, 0);
 }
 return ret;
 }
@@ -490,8 +490,8 @@ static inline void cpu_handle_interrupt(CPUState *cpu,
 *last_tb = NULL;
 }
 }
-if (unlikely(cpu->exit_request || replay_has_interrupt())) {
-cpu->exit_request = 0;
+if (unlikely(atomic_read(&cpu->exit_request) || replay_has_interrupt())) {
+atomic_set(&cpu->exit_request, 0);
 cpu->exception_index = EXCP_INTERRUPT;
 cpu_loop_exit(cpu);
 }
@@ -503,7 +503,7 @@ static inline void cpu_loop_exec_tb(CPUState *cpu, 
TranslationBlock *tb,
 {
 uintptr_t ret;
 
-if (unlikely(cpu->exit_request)) {
+if (unlikely(atomic_read(&cpu->exit_request))) {
 return;
 }
 
diff --git a/qom/cpu.c b/qom/cpu.c
index ef905da..e765bc0 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -120,10 +120,10 @@ void cpu_reset_interrupt(CPUState *cpu, int mask)
 
 void cpu_exit(CPUState *cpu)
 {
-cpu->exit_request = 1;
+atomic_set(&cpu->exit_request, 1);
 /* Ensure cpu_exec will see the exit request after TCG has exited.  */
 smp_wmb();
-cpu->tcg_exit_req = 1;
+atomic_set(&cpu->tcg_exit_req, 1);
 }
 
 int cpu_write_elf32_qemunote(WriteCoreDumpFunction f, CPUState *cpu,
-- 
2.7.4

[Qemu-devel] [PULL 15/39] qom/cpu: atomically clear the tb_jmp_cache

[Paolo Bonzini]

From: Alex Bennée 

The ThreadSanitizer rightly complains that something initialised with a
normal access is later updated and read atomically.

Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-8-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 qom/cpu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/qom/cpu.c b/qom/cpu.c
index 484c493..ef905da 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -253,6 +253,7 @@ void cpu_reset(CPUState *cpu)
 static void cpu_common_reset(CPUState *cpu)
 {
 CPUClass *cc = CPU_GET_CLASS(cpu);
+int i;
 
 if (qemu_loglevel_mask(CPU_LOG_RESET)) {
 qemu_log("CPU Reset (CPU %d)\n", cpu->cpu_index);
@@ -268,7 +269,10 @@ static void cpu_common_reset(CPUState *cpu)
 cpu->can_do_io = 1;
 cpu->exception_index = -1;
 cpu->crash_occurred = false;
-memset(cpu->tb_jmp_cache, 0, TB_JMP_CACHE_SIZE * sizeof(void *));
+
+for (i = 0; i < TB_JMP_CACHE_SIZE; ++i) {
+atomic_set(&cpu->tb_jmp_cache[i], NULL);
+}
 }
 
 static bool cpu_common_has_work(CPUState *cs)
-- 
2.7.4

[Qemu-devel] [PULL 18/39] linux-user/syscall: extend lock around cpu-list

[Paolo Bonzini]

From: Alex Bennée 

There is a potential race if several threads exit at once. To serialise
the exits extend the lock above the initial checking of the CPU list.

Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-11-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 linux-user/syscall.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 0815f30..fa559be 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -7476,13 +7476,16 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 break;
 }
 
+cpu_list_lock();
+
 if (CPU_NEXT(first_cpu)) {
 TaskState *ts;
 
-cpu_list_lock();
 /* Remove the CPU from the list.  */
 QTAILQ_REMOVE(&cpus, cpu, node);
+
 cpu_list_unlock();
+
 ts = cpu->opaque;
 if (ts->child_tidptr) {
 put_user_u32(0, ts->child_tidptr);
@@ -7495,6 +7498,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 rcu_unregister_thread();
 pthread_exit(NULL);
 }
+
+cpu_list_unlock();
 #ifdef TARGET_GPROF
 _mcleanup();
 #endif
-- 
2.7.4

[Qemu-devel] [PULL 23/39] char: update read handler in all cases

[Paolo Bonzini]

From: Marc-André Lureau 

In commit ac1b84dd1 (rhbz#1027181), a check was added to only update the
"read handler" when the front-end is opened, because the read callbacks
were not restored when a device is plugged. However, this seems not
correct, the handler is correctly set back on hotplug (in
virtconsole_realize) and the bug can no longer be reproduced.

Calling chr_update_read_handler() allows to fix the mux driver to stop
calling the child handlers (which may be going to be destroyed).

Signed-off-by: Marc-André Lureau 
Message-Id: <20161003094704.18087-2-marcandre.lur...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 qemu-char.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qemu-char.c b/qemu-char.c
index 7a85b1f..4b330ea 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -469,7 +469,7 @@ void qemu_chr_add_handlers_full(CharDriverState *s,
 s->chr_read = fd_read;
 s->chr_event = fd_event;
 s->handler_opaque = opaque;
-if (fe_open && s->chr_update_read_handler) {
+if (s->chr_update_read_handler) {
 s->chr_update_read_handler(s, context);
 }
 
-- 
2.7.4

[Qemu-devel] [PULL 20/39] .travis.yml: add gcc sanitizer build

[Paolo Bonzini]

From: Alex Bennée 

As it seems easy to break the ThreadSanitizer build we should defend it to
ensure that fixes get applied when it breaks. We use the Ubuntu GCC PPA
to get the latest GCC goodness.

As we need to use the -fuse-ld=gold work around we have to disable the
linux-user targets as these trip up the linker.

The make check run is also disabled for Travis but this can be
re-enabled once the check targets have been fixed.

Signed-off-by: Alex Bennée 

Message-Id: <20160930213106.20186-13-alex.ben...@linaro.org>
---
 .travis.yml | 45 +
 1 file changed, 45 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index f30b10e..9916178 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -9,6 +9,7 @@ cache: ccache
 addons:
   apt:
 packages:
+  # Build dependencies
   - libaio-dev
   - libattr1-dev
   - libbrlapi-dev
@@ -89,6 +90,7 @@ matrix:
 - env: CONFIG=""
   os: osx
   compiler: clang
+# Plain Trusty Build
 - env: CONFIG=""
   sudo: required
   addons:
@@ -99,3 +101,46 @@ matrix:
 - sudo apt-get build-dep -qq qemu
 - wget -O - 
http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz | tar -xvJ
 - git submodule update --init --recursive
+# Using newer GCC with sanitizers
+- addons:
+apt:
+  sources:
+# PPAs for newer toolchains
+- ubuntu-toolchain-r-test
+  packages:
+# Extra toolchains
+- gcc-5
+- g++-5
+# Build dependencies
+- libaio-dev
+- libattr1-dev
+- libbrlapi-dev
+- libcap-ng-dev
+- libgnutls-dev
+- libgtk-3-dev
+- libiscsi-dev
+- liblttng-ust-dev
+- libnfs-dev
+- libncurses5-dev
+- libnss3-dev
+- libpixman-1-dev
+- libpng12-dev
+- librados-dev
+- libsdl1.2-dev
+- libseccomp-dev
+- libspice-protocol-dev
+- libspice-server-dev
+- libssh2-1-dev
+- liburcu-dev
+- libusb-1.0-0-dev
+- libvte-2.90-dev
+- sparse
+- uuid-dev
+  language: generic
+  compiler: none
+  env:
+- COMPILER_NAME=gcc CXX=g++-5 CC=gcc-5
+- CONFIG="--cc=gcc-5 --cxx=g++-5 --disable-pie --disable-linux-user 
--with-coroutine=gthread"
+- TEST_CMD=""
+  before_script:
+- ./configure ${CONFIG} --extra-cflags="-g3 -O0 -fsanitize=thread 
-fuse-ld=gold" || cat config.log
-- 
2.7.4

[Qemu-devel] [PULL 14/39] qom/object: update class cache atomically

[Paolo Bonzini]

From: Alex Bennée 

The idiom CPU_GET_CLASS(cpu) is fairly extensively used in various
threads and trips of ThreadSanitizer due to the fact it updates
obj->class->object_cast_cache behind the scenes. As this is just a
fast-path cache there is no need to lock updates.

However to ensure defined C11 behaviour across threads we need to use
the plain atomic_read/set primitives and keep the sanitizer happy.

Signed-off-by: Alex Bennée 
Reviewed-by: Marc-André Lureau 
Message-Id: <20160930213106.20186-7-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 qom/object.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/qom/object.c b/qom/object.c
index 8166b7d..7a05e35 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -614,7 +614,7 @@ Object *object_dynamic_cast_assert(Object *obj, const char 
*typename,
 Object *inst;
 
 for (i = 0; obj && i < OBJECT_CLASS_CAST_CACHE; i++) {
-if (obj->class->object_cast_cache[i] == typename) {
+if (atomic_read(&obj->class->object_cast_cache[i]) == typename) {
 goto out;
 }
 }
@@ -631,10 +631,10 @@ Object *object_dynamic_cast_assert(Object *obj, const 
char *typename,
 
 if (obj && obj == inst) {
 for (i = 1; i < OBJECT_CLASS_CAST_CACHE; i++) {
-obj->class->object_cast_cache[i - 1] =
-obj->class->object_cast_cache[i];
+atomic_set(&obj->class->object_cast_cache[i - 1],
+   atomic_read(&obj->class->object_cast_cache[i]));
 }
-obj->class->object_cast_cache[i - 1] = typename;
+atomic_set(&obj->class->object_cast_cache[i - 1], typename);
 }
 
 out:
@@ -704,7 +704,7 @@ ObjectClass *object_class_dynamic_cast_assert(ObjectClass 
*class,
 int i;
 
 for (i = 0; class && i < OBJECT_CLASS_CAST_CACHE; i++) {
-if (class->class_cast_cache[i] == typename) {
+if (atomic_read(&class->class_cast_cache[i]) == typename) {
 ret = class;
 goto out;
 }
@@ -725,9 +725,10 @@ ObjectClass *object_class_dynamic_cast_assert(ObjectClass 
*class,
 #ifdef CONFIG_QOM_CAST_DEBUG
 if (class && ret == class) {
 for (i = 1; i < OBJECT_CLASS_CAST_CACHE; i++) {
-class->class_cast_cache[i - 1] = class->class_cast_cache[i];
+atomic_set(&class->class_cast_cache[i - 1],
+   atomic_read(&class->class_cast_cache[i]));
 }
-class->class_cast_cache[i - 1] = typename;
+atomic_set(&class->class_cast_cache[i - 1], typename);
 }
 out:
 #endif
-- 
2.7.4

[Qemu-devel] [PULL 11/39] atomic.h: comment on use of atomic_read/set

[Paolo Bonzini]

From: Alex Bennée 

Add some notes on the use of the relaxed atomic access helpers and their
importance for defined behaviour in C11's multi-threaded memory model.

Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-3-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 include/qemu/atomic.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index c493f89..c4f6950 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -92,6 +92,12 @@
 /* Weak atomic operations prevent the compiler moving other
  * loads/stores past the atomic operation load/store. However there is
  * no explicit memory barrier for the processor.
+ *
+ * The C11 memory model says that variables that are accessed from
+ * different threads should at least be done with __ATOMIC_RELAXED
+ * primitives or the result is undefined. Generally this has little to
+ * no effect on the generated code but not using the atomic primitives
+ * will get flagged by sanitizers as a violation.
  */
 #define atomic_read(ptr)  \
 ({\
-- 
2.7.4

[Qemu-devel] [PULL 22/39] char: use a fixed idx for child muxed chr

[Paolo Bonzini]

From: Marc-André Lureau 

mux_chr_update_read_handler() is adding a new mux_cnt each time
mux_chr_update_read_handler() is called, it's not possible to actually
update the "child" chr callbacks that were set previously. This may lead
to crashes if the "child" chr is destroyed:

valgrind x86_64-softmmu/qemu-system-x86_64 -chardev
stdio,mux=on,id=char0 -mon chardev=char0,mode=control,default

when quitting:

==4306== Invalid read of size 8
==4306==at 0x8061D3: json_lexer_destroy (json-lexer.c:385)
==4306==by 0x7E39F8: json_message_parser_destroy (json-streamer.c:134)
==4306==by 0x3447F6: monitor_qmp_event (monitor.c:3908)
==4306==by 0x480153: mux_chr_send_event (qemu-char.c:630)
==4306==by 0x480694: mux_chr_event (qemu-char.c:734)
==4306==by 0x47F1E9: qemu_chr_be_event (qemu-char.c:205)
==4306==by 0x481207: fd_chr_close (qemu-char.c:1114)
==4306==by 0x481659: qemu_chr_close_stdio (qemu-char.c:1221)
==4306==by 0x486F07: qemu_chr_free (qemu-char.c:4146)
==4306==by 0x486F97: qemu_chr_delete (qemu-char.c:4154)
==4306==by 0x487E66: qemu_chr_cleanup (qemu-char.c:4678)
==4306==by 0x495A98: main (vl.c:4675)
==4306==  Address 0x28439e90 is 112 bytes inside a block of size 240 free'd
==4306==at 0x4C2CD5A: free (vg_replace_malloc.c:530)
==4306==by 0x1E4CBF2D: g_free (in /usr/lib64/libglib-2.0.so.0.4800.2)
==4306==by 0x344DE9: monitor_cleanup (monitor.c:4058)
==4306==by 0x495A93: main (vl.c:4674)
==4306==  Block was alloc'd at
==4306==at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==4306==by 0x1E4CBE18: g_malloc (in /usr/lib64/libglib-2.0.so.0.4800.2)
==4306==by 0x344BF8: monitor_init (monitor.c:4021)
==4306==by 0x49063C: mon_init_func (vl.c:2417)
==4306==by 0x7FC6DE: qemu_opts_foreach (qemu-option.c:1116)
==4306==by 0x4954E0: main (vl.c:4473)

Instead, keep the "child" chr associated with a particular idx so its
handlers can be updated and removed to avoid the crash.

Signed-off-by: Marc-André Lureau 
Message-Id: <20161003094704.18087-3-marcandre.lur...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 include/sysemu/char.h |  1 +
 qemu-char.c   | 22 +++---
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index 0d0465a..4593576 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -92,6 +92,7 @@ struct CharDriverState {
 int explicit_be_open;
 int avail_connections;
 int is_mux;
+int mux_idx;
 guint fd_in_tag;
 QemuOpts *opts;
 bool replay;
diff --git a/qemu-char.c b/qemu-char.c
index fb456ce..7a85b1f 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -165,6 +165,7 @@ CharDriverState *qemu_chr_alloc(ChardevCommon *backend, 
Error **errp)
 CharDriverState *chr = g_malloc0(sizeof(CharDriverState));
 qemu_mutex_init(&chr->chr_write_lock);
 
+chr->mux_idx = -1;
 if (backend->has_logfile) {
 int flags = O_WRONLY | O_CREAT;
 if (backend->has_logappend &&
@@ -738,17 +739,25 @@ static void mux_chr_update_read_handler(CharDriverState 
*chr,
 GMainContext *context)
 {
 MuxDriver *d = chr->opaque;
+int idx;
 
 if (d->mux_cnt >= MAX_MUX) {
 fprintf(stderr, "Cannot add I/O handlers, MUX array is full\n");
 return;
 }
-d->ext_opaque[d->mux_cnt] = chr->handler_opaque;
-d->chr_can_read[d->mux_cnt] = chr->chr_can_read;
-d->chr_read[d->mux_cnt] = chr->chr_read;
-d->chr_event[d->mux_cnt] = chr->chr_event;
+
+if (chr->mux_idx == -1) {
+chr->mux_idx = d->mux_cnt++;
+}
+
+idx = chr->mux_idx;
+d->ext_opaque[idx] = chr->handler_opaque;
+d->chr_can_read[idx] = chr->chr_can_read;
+d->chr_read[idx] = chr->chr_read;
+d->chr_event[idx] = chr->chr_event;
+
 /* Fix up the real driver with mux routines */
-if (d->mux_cnt == 0) {
+if (d->mux_cnt == 1) {
 qemu_chr_add_handlers_full(d->drv, mux_chr_can_read,
mux_chr_read,
mux_chr_event,
@@ -757,8 +766,7 @@ static void mux_chr_update_read_handler(CharDriverState 
*chr,
 if (d->focus != -1) {
 mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_OUT);
 }
-d->focus = d->mux_cnt;
-d->mux_cnt++;
+d->focus = idx;
 mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_IN);
 }
 
-- 
2.7.4

[Qemu-devel] [PULL 09/39] intc: make HMP 'info irq' and 'info pic' commands available on all targets

[Paolo Bonzini]

From: Hervé Poussineau 

Signed-off-by: Hervé Poussineau 
Message-Id: <1474921408-24710-7-git-send-email-hpous...@reactos.org>
Signed-off-by: Paolo Bonzini 
---
 hmp-commands-info.hx | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index 6a7c476..55d50c4 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -172,8 +172,6 @@ STEXI
 Show the command line history.
 ETEXI
 
-#if defined(TARGET_I386) || defined(TARGET_PPC) || defined(TARGET_MIPS) || \
-defined(TARGET_LM32) || (defined(TARGET_SPARC) && !defined(TARGET_SPARC64))
 {
 .name   = "irq",
 .args_type  = "",
@@ -192,10 +190,9 @@ ETEXI
 .name   = "pic",
 .args_type  = "",
 .params = "",
-.help   = "show i8259 (PIC) state",
+.help   = "show PIC state",
 .cmd= hmp_info_pic,
 },
-#endif
 
 STEXI
 @item info pic
-- 
2.7.4

[Qemu-devel] [PULL 13/39] seqlock: use atomic writes for the sequence

[Paolo Bonzini]

There is a data race if the sequence is written concurrently to the
read.  In C11 this has undefined behavior.  Use atomic_set; the
read side is already using atomic_read.

Reported-by: Alex Bennée 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-6-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 include/qemu/seqlock.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/qemu/seqlock.h b/include/qemu/seqlock.h
index 2e2be4c..8dee11d 100644
--- a/include/qemu/seqlock.h
+++ b/include/qemu/seqlock.h
@@ -31,7 +31,7 @@ static inline void seqlock_init(QemuSeqLock *sl)
 /* Lock out other writers and update the count.  */
 static inline void seqlock_write_begin(QemuSeqLock *sl)
 {
-++sl->sequence;
+atomic_set(&sl->sequence, sl->sequence + 1);
 
 /* Write sequence before updating other fields.  */
 smp_wmb();
@@ -42,7 +42,7 @@ static inline void seqlock_write_end(QemuSeqLock *sl)
 /* Write other fields before finalizing sequence.  */
 smp_wmb();
 
-++sl->sequence;
+atomic_set(&sl->sequence, sl->sequence + 1);
 }
 
 static inline unsigned seqlock_read_begin(QemuSeqLock *sl)
-- 
2.7.4

[Qemu-devel] [PULL 12/39] tcg/optimize: move default return out of if statement

[Paolo Bonzini]

From: Alex Bennée 

This is to appease sanitizer builds which complain that:

  "error: control reaches end of non-void function"

Signed-off-by: Alex Bennée 
Reviewed-by: Marc-André Lureau 
Message-Id: <20160930213106.20186-5-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 tcg/optimize.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index 9998ac7..0f13490 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -468,9 +468,8 @@ static TCGArg do_constant_folding_cond(TCGOpcode op, TCGArg 
x,
 default:
 return 2;
 }
-} else {
-return 2;
 }
+return 2;
 }
 
 /* Return 2 if the condition can't be simplified, and the result
-- 
2.7.4

[Qemu-devel] [PULL 19/39] qga/command: use QEMU atomic primitives

[Paolo Bonzini]

From: Alex Bennée 

The guest client's use of the glib's g_atomic primitives causes newer
GCC's to barf when built on Travis. As QEMU has its own primitives with
well understood semantics we might as well use them.

The use of atomics was a little inconsistent so I've also ensure the
values are correctly set with atomic primitives at the same time.

I also made the usage of bool consistent while I was at it.

Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-12-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 qga/commands.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/qga/commands.c b/qga/commands.c
index 50fd26a..edd3e83 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -16,6 +16,7 @@
 #include "qapi/qmp/qerror.h"
 #include "qemu/base64.h"
 #include "qemu/cutils.h"
+#include "qemu/atomic.h"
 
 /* Maximum captured guest-exec out_data/err_data - 16MB */
 #define GUEST_EXEC_MAX_OUTPUT (16*1024*1024)
@@ -82,7 +83,7 @@ struct GuestExecIOData {
 guchar *data;
 gsize size;
 gsize length;
-gint closed;
+bool closed;
 bool truncated;
 const char *name;
 };
@@ -93,7 +94,7 @@ struct GuestExecInfo {
 int64_t pid_numeric;
 gint status;
 bool has_output;
-gint finished;
+bool finished;
 GuestExecIOData in;
 GuestExecIOData out;
 GuestExecIOData err;
@@ -156,13 +157,13 @@ GuestExecStatus *qmp_guest_exec_status(int64_t pid, Error 
**err)
 
 ges = g_new0(GuestExecStatus, 1);
 
-bool finished = g_atomic_int_get(&gei->finished);
+bool finished = atomic_mb_read(&gei->finished);
 
 /* need to wait till output channels are closed
  * to be sure we captured all output at this point */
 if (gei->has_output) {
-finished = finished && g_atomic_int_get(&gei->out.closed);
-finished = finished && g_atomic_int_get(&gei->err.closed);
+finished = finished && atomic_mb_read(&gei->out.closed);
+finished = finished && atomic_mb_read(&gei->err.closed);
 }
 
 ges->exited = finished;
@@ -264,7 +265,7 @@ static void guest_exec_child_watch(GPid pid, gint status, 
gpointer data)
 (int32_t)gpid_to_int64(pid), (uint32_t)status);
 
 gei->status = status;
-gei->finished = true;
+atomic_mb_set(&gei->finished, true);
 
 g_spawn_close_pid(pid);
 }
@@ -320,7 +321,7 @@ static gboolean guest_exec_input_watch(GIOChannel *ch,
 done:
 g_io_channel_shutdown(ch, true, NULL);
 g_io_channel_unref(ch);
-g_atomic_int_set(&p->closed, 1);
+atomic_mb_set(&p->closed, true);
 g_free(p->data);
 
 return false;
@@ -374,7 +375,7 @@ static gboolean guest_exec_output_watch(GIOChannel *ch,
 close:
 g_io_channel_shutdown(ch, true, NULL);
 g_io_channel_unref(ch);
-g_atomic_int_set(&p->closed, 1);
+atomic_mb_set(&p->closed, true);
 return false;
 }
 
-- 
2.7.4

[Qemu-devel] [PULL 08/39] intc: make HMP 'info irq' and 'info pic' commands use InterruptStatsProvider interface

[Paolo Bonzini]

From: Hervé Poussineau 

Signed-off-by: Hervé Poussineau 
Message-Id: <1474921408-24710-6-git-send-email-hpous...@reactos.org>
Signed-off-by: Paolo Bonzini 
---
 hmp-commands-info.hx   | 12 -
 hmp.c  | 65 ++
 hmp.h  |  2 ++
 hw/intc/i8259.c| 36 -
 hw/intc/lm32_pic.c | 31 --
 hw/intc/slavio_intctl.c| 32 ---
 hw/sparc/sun4m.c   | 15 +--
 include/hw/i386/pc.h   |  2 --
 include/hw/lm32/lm32_pic.h |  3 ---
 include/hw/sparc/sun4m.h   |  8 --
 monitor.c  |  6 -
 11 files changed, 68 insertions(+), 144 deletions(-)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index 19729e5..6a7c476 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -179,13 +179,7 @@ ETEXI
 .args_type  = "",
 .params = "",
 .help   = "show the interrupts statistics (if available)",
-#ifdef TARGET_SPARC
-.cmd= sun4m_hmp_info_irq,
-#elif defined(TARGET_LM32)
-.cmd= lm32_hmp_info_irq,
-#else
 .cmd= hmp_info_irq,
-#endif
 },
 
 STEXI
@@ -199,13 +193,7 @@ ETEXI
 .args_type  = "",
 .params = "",
 .help   = "show i8259 (PIC) state",
-#ifdef TARGET_SPARC
-.cmd= sun4m_hmp_info_pic,
-#elif defined(TARGET_LM32)
-.cmd= lm32_hmp_info_pic,
-#else
 .cmd= hmp_info_pic,
-#endif
 },
 #endif
 
diff --git a/hmp.c b/hmp.c
index 336e7bf..a79e7f9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -36,6 +36,7 @@
 #include "qemu-io.h"
 #include "qemu/cutils.h"
 #include "qemu/error-report.h"
+#include "hw/intc/intc.h"
 
 #ifdef CONFIG_SPICE
 #include 
@@ -787,6 +788,70 @@ static void hmp_info_pci_device(Monitor *mon, const 
PciDeviceInfo *dev)
 }
 }
 
+static int hmp_info_irq_foreach(Object *obj, void *opaque)
+{
+InterruptStatsProvider *intc;
+InterruptStatsProviderClass *k;
+Monitor *mon = opaque;
+
+if (object_dynamic_cast(obj, TYPE_INTERRUPT_STATS_PROVIDER)) {
+intc = INTERRUPT_STATS_PROVIDER(obj);
+k = INTERRUPT_STATS_PROVIDER_GET_CLASS(obj);
+uint64_t *irq_counts;
+unsigned int nb_irqs, i;
+if (k->get_statistics &&
+k->get_statistics(intc, &irq_counts, &nb_irqs)) {
+if (nb_irqs > 0) {
+monitor_printf(mon, "IRQ statistics for %s:\n",
+   object_get_typename(obj));
+for (i = 0; i < nb_irqs; i++) {
+if (irq_counts[i] > 0) {
+monitor_printf(mon, "%2d: %" PRId64 "\n", i,
+   irq_counts[i]);
+}
+}
+}
+} else {
+monitor_printf(mon, "IRQ statistics not available for %s.\n",
+   object_get_typename(obj));
+}
+}
+
+return 0;
+}
+
+void hmp_info_irq(Monitor *mon, const QDict *qdict)
+{
+object_child_foreach_recursive(object_get_root(),
+   hmp_info_irq_foreach, mon);
+}
+
+static int hmp_info_pic_foreach(Object *obj, void *opaque)
+{
+InterruptStatsProvider *intc;
+InterruptStatsProviderClass *k;
+Monitor *mon = opaque;
+
+if (object_dynamic_cast(obj, TYPE_INTERRUPT_STATS_PROVIDER)) {
+intc = INTERRUPT_STATS_PROVIDER(obj);
+k = INTERRUPT_STATS_PROVIDER_GET_CLASS(obj);
+if (k->print_info) {
+k->print_info(intc, mon);
+} else {
+monitor_printf(mon, "Interrupt controller information not 
available for %s.\n",
+   object_get_typename(obj));
+}
+}
+
+return 0;
+}
+
+void hmp_info_pic(Monitor *mon, const QDict *qdict)
+{
+object_child_foreach_recursive(object_get_root(),
+   hmp_info_pic_foreach, mon);
+}
+
 void hmp_info_pci(Monitor *mon, const QDict *qdict)
 {
 PciInfoList *info_list, *info;
diff --git a/hmp.h b/hmp.h
index 0876ec0..184769c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -36,6 +36,8 @@ void hmp_info_blockstats(Monitor *mon, const QDict *qdict);
 void hmp_info_vnc(Monitor *mon, const QDict *qdict);
 void hmp_info_spice(Monitor *mon, const QDict *qdict);
 void hmp_info_balloon(Monitor *mon, const QDict *qdict);
+void hmp_info_irq(Monitor *mon, const QDict *qdict);
+void hmp_info_pic(Monitor *mon, const QDict *qdict);
 void hmp_info_pci(Monitor *mon, const QDict *qdict);
 void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
 void hmp_info_tpm(Monitor *mon, const QDict *qdict);
diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c
index 75c8d22..fe9ecd6 100644
--- a/hw/intc/i8259.c
+++ b/hw/intc/i8259.c
@@ -461,42 +461,6 @@ static void pic_realize(DeviceState *dev, Error **errp)
 pc->parent_realize(dev, errp);
 }
 
-void hmp_info_pic(Monitor *mon, const QDict *qdict)
-{

[Qemu-devel] [PULL 06/39] intc/slavio_intctl: implement InterruptStatsProvider interface

[Paolo Bonzini]

From: Hervé Poussineau 

Acked-by: Artyom Tarasenko 
Signed-off-by: Hervé Poussineau 
Message-Id: <1474921408-24710-4-git-send-email-hpous...@reactos.org>
Signed-off-by: Paolo Bonzini 
---
 hw/intc/slavio_intctl.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/hw/intc/slavio_intctl.c b/hw/intc/slavio_intctl.c
index e82e893..a9acb64 100644
--- a/hw/intc/slavio_intctl.c
+++ b/hw/intc/slavio_intctl.c
@@ -26,6 +26,7 @@
 #include "hw/sparc/sun4m.h"
 #include "monitor/monitor.h"
 #include "hw/sysbus.h"
+#include "hw/intc/intc.h"
 #include "trace.h"
 
 //#define DEBUG_IRQ_COUNT
@@ -418,6 +419,31 @@ static void slavio_intctl_reset(DeviceState *d)
 slavio_check_interrupts(s, 0);
 }
 
+#ifdef DEBUG_IRQ_COUNT
+static bool slavio_intctl_get_statistics(InterruptStatsProvider *obj,
+ uint64_t **irq_counts,
+ unsigned int *nb_irqs)
+{
+SLAVIO_INTCTLState *s = SLAVIO_INTCTL(obj);
+*irq_counts = s->irq_count;
+*nb_irqs = ARRAY_SIZE(s->irq_count);
+return true;
+}
+#endif
+
+static void slavio_intctl_print_info(InterruptStatsProvider *obj, Monitor *mon)
+{
+SLAVIO_INTCTLState *s = SLAVIO_INTCTL(obj);
+int i;
+
+for (i = 0; i < MAX_CPUS; i++) {
+monitor_printf(mon, "per-cpu %d: pending 0x%08x\n", i,
+   s->slaves[i].intreg_pending);
+}
+monitor_printf(mon, "master: pending 0x%08x, disabled 0x%08x\n",
+   s->intregm_pending, s->intregm_disabled);
+}
+
 static void slavio_intctl_init(Object *obj)
 {
 DeviceState *dev = DEVICE(obj);
@@ -449,9 +475,14 @@ static void slavio_intctl_init(Object *obj)
 static void slavio_intctl_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
+InterruptStatsProviderClass *ic = INTERRUPT_STATS_PROVIDER_CLASS(klass);
 
 dc->reset = slavio_intctl_reset;
 dc->vmsd = &vmstate_intctl;
+#ifdef DEBUG_IRQ_COUNT
+ic->get_statistics = slavio_intctl_get_statistics;
+#endif
+ic->print_info = slavio_intctl_print_info;
 }
 
 static const TypeInfo slavio_intctl_info = {
@@ -460,6 +491,10 @@ static const TypeInfo slavio_intctl_info = {
 .instance_size = sizeof(SLAVIO_INTCTLState),
 .instance_init = slavio_intctl_init,
 .class_init= slavio_intctl_class_init,
+.interfaces = (InterfaceInfo[]) {
+{ TYPE_INTERRUPT_STATS_PROVIDER },
+{ }
+},
 };
 
 static void slavio_intctl_register_types(void)
-- 
2.7.4

[Qemu-devel] [PULL 03/39] hw/misc/edu: support MSI interrupt

[Paolo Bonzini]

From: Peter Xu 

So now edu device can support both line or msi interrupt, depending on
how user configures it.

Signed-off-by: Peter Xu 
Message-Id: <1475067819-21413-1-git-send-email-pet...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 docs/specs/edu.txt |  7 ++-
 hw/misc/edu.c  | 18 --
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/docs/specs/edu.txt b/docs/specs/edu.txt
index 7f81467..0876310 100644
--- a/docs/specs/edu.txt
+++ b/docs/specs/edu.txt
@@ -52,7 +52,7 @@ size == 8 for the rest.
 
 0x20 (RW) : status register, bitwise OR
0x01 -- computing factorial (RO)
-   0x80 -- raise interrupt 0x01 after finishing factorial computation
+   0x80 -- raise interrupt after finishing factorial computation
 
 0x24 (RO) : interrupt status register
It contains values which raised the interrupt (see interrupt raise
@@ -87,6 +87,11 @@ An IRQ is generated when written to the interrupt raise 
register. The value
 appears in interrupt status register when the interrupt is raised and has to
 be written to the interrupt acknowledge register to lower it.
 
+The device supports both INTx and MSI interrupt. By default, INTx is
+used. Even if the driver disabled INTx and only uses MSI, it still
+needs to update the acknowledge register at the end of the IRQ handler
+routine.
+
 DMA controller
 --
 One has to specify, source, destination, size, and start the transfer. One
diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index 888ba49..401039c 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -24,6 +24,7 @@
 
 #include "qemu/osdep.h"
 #include "hw/pci/pci.h"
+#include "hw/pci/msi.h"
 #include "qemu/timer.h"
 #include "qemu/main-loop.h" /* iothread mutex */
 #include "qapi/visitor.h"
@@ -69,11 +70,20 @@ typedef struct {
 uint64_t dma_mask;
 } EduState;
 
+static bool edu_msi_enabled(EduState *edu)
+{
+return msi_enabled(&edu->pdev);
+}
+
 static void edu_raise_irq(EduState *edu, uint32_t val)
 {
 edu->irq_status |= val;
 if (edu->irq_status) {
-pci_set_irq(&edu->pdev, 1);
+if (edu_msi_enabled(edu)) {
+msi_notify(&edu->pdev, 0);
+} else {
+pci_set_irq(&edu->pdev, 1);
+}
 }
 }
 
@@ -81,7 +91,7 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
 {
 edu->irq_status &= ~val;
 
-if (!edu->irq_status) {
+if (!edu->irq_status && !edu_msi_enabled(edu)) {
 pci_set_irq(&edu->pdev, 0);
 }
 }
@@ -342,6 +352,10 @@ static void pci_edu_realize(PCIDevice *pdev, Error **errp)
 
 pci_config_set_interrupt_pin(pci_conf, 1);
 
+if (msi_init(pdev, 0, 1, true, false, errp)) {
+return;
+}
+
 memory_region_init_io(&edu->mmio, OBJECT(edu), &edu_mmio_ops, edu,
 "edu-mmio", 1 << 20);
 pci_register_bar(pdev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &edu->mmio);
-- 
2.7.4

[Qemu-devel] [PULL 10/39] atomic.h: fix __SANITIZE_THREAD__ build

[Paolo Bonzini]

From: Alex Bennée 

Only very modern GCC's actually set this define when building with the
ThreadSanitizer so this little typo slipped though.

Signed-off-by: Alex Bennée 
Message-Id: <20160930213106.20186-2-alex.ben...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 include/qemu/atomic.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index 0cce246..c493f89 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -82,7 +82,7 @@
  */
 #if defined(__SANITIZE_THREAD__)
 #define smp_read_barrier_depends() ({ barrier(); 
__atomic_thread_fence(__ATOMIC_CONSUME); })
-#elsif defined(__alpha__)
+#elif defined(__alpha__)
 #define smp_read_barrier_depends()   asm volatile("mb":::"memory")
 #else
 #define smp_read_barrier_depends()   barrier()
-- 
2.7.4