Re: [Qemu-devel] [PATCH v10 29/30] cpu: Convert CpuInfo into flat union

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> On 11/09/2015 08:22 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> When qapi type CpuInfo was originally created for 0.14, we had
>>> no notion of a flat union, and instead just listed a bunch of
>>> optional fields with documentation about the mutually-exclusive
>>> choice of which instruction pointer field(s) would be provided
>>> for a given architecture.  But now that we have flat unions and
>>> introspection, it is better to segregate off which fields will
>>> be provided according to the actual architecture.  With this in
>>> place, we no longer need the fields to be optional, because the
>>> choice of the discriminator serves that role.
>>>
>>> This has an additional benefit: the old all-in-one struct was
>>> the only place in the code base that had a case-sensitive
>>> naming of members 'pc' vs. 'PC'.  Separating these spellings
>>> into different branches of the flat union will allow us to add
>>> restrictions against future case-insensitive collisions, and
>>> make it possible for a future qemu to decide whether to enable
>>> case-insensitive QMP.
>
>>>  ##
>>>  # @query-cpus:
>> 
>> CpuInfo is only used as return type of query-cpus.
>> 
>> If I understand the change correctly, the value of query-cpus is not
>> changed at all.  Its introspection, however, is.
>
> Almost. The output of query-cpus gains a new 'arch':'FOO' string per
> cpu, saying which branch of the flat union is in use.  But as it is
> output-only, adding a new output field shouldn't break any existing
> clients (because QMP already documents that clients should ignore new
> fields); and since the struct is output-only, it can't break any input
> fields.

Understood.

> I probably can spell that out better in the commit message, though.

Yes, please

> Oh, and I need to update qmp-commands.hx, as part of my v11 spin.

Yes, please.

>> Do we need this to make 2.5?
>
> It's true that the introspection will change (instead of seeing flat
> optional members, you now have to chase down variants).  But I don't
> think it is pressing enough to rush into 2.5; the change is
> backwards-compatible no matter when we do it, and introspection clients
> are going to have to get used to the idea of chasing down different
> paths to find all members of a struct (that is, if we don't change this
> until 2.6, I'm sure it won't be the last case of introspection changing
> while keeping QMP wire format back-compatible as formerly non-variant
> fields become variant).

We can mess with the schema as long as the QMP wire format stays
compatible.

With introspection, schema changes get exposed in QMP that weren't
exposed before.  Begs the question whether the ABI promise extends to
the introspection value.

I think we don't want to extend it, at least for now.  In other words,
we refuse to put additional constraints on schema changes to keep the
introspection value stable.  Makes introspection a bit harder to use.
Not ideal, but better than committing to constraints we don't even fully
understand, yet.

I think we should spell this out introspection documentation.

Our only example so far is converting between optional members and flat
unions.  Can we think of others?  Hmm, you found one below.

>> Any other messy optionals that should really be (flat) unions?
>> 
>
> Possibly.
> /me goes and audits all 0.14 interfaces...
>
> add_client is an input command, but it would be nicer as a flat union
> (we can't do that until commands can take unions; but that happens as
> part of my pending queue for netdev_add), so that's not going to make 2.5.

Since the command parameters are just an object type, this is merely
another case of converting between optional members and flat unions.

> client_migrate_info looks odd, since it requires 'protocol':'str' to be
> the value 'spice'.  Probably several functions that take or produce a
> finite set of strings that should be using enums, but conversion from
> 'str' to 'enum' is backwards-compatible according to QMP wire format.
> Doing it sooner rather than later makes introspection nicer.

This is another example: converting between string and enum.  Going from
string to enum only adds information, and should be easy enough for
clients.  Going the other way removes information, and probably should
not be done.

> But I didn't spot any other obvious commands from that far back with
> mutually-exclusive optional parameters, and certainly nothing else with
> case clashes.

Okay.  I guess finding all the examples that matter may take a few
development cycles.  Perhaps we want to commit to some additional
compatibility promises for introspection then.



Re: [Qemu-devel] [PATCH v5 0/8] e1000: Various fixes and registers' implementation

2015-11-11 Thread Jason Wang


On 11/11/2015 04:06 PM, Leonid Bloch wrote:
> On Wed, Nov 11, 2015 at 5:22 AM, Jason Wang  wrote:
>> >
>> >
>> > On 11/10/2015 09:19 PM, Leonid Bloch wrote:
>>> >> On Tue, Nov 10, 2015 at 3:01 PM, Jason Wang  wrote:
 >>>
 >>> On 11/10/2015 07:39 PM, Leonid Bloch wrote:
>  On Tue, Nov 10, 2015 at 8:21 AM, Jason Wang  
>  wrote:
>> > On 11/09/2015 10:59 PM, Leonid Bloch wrote:
>>> >> This series fixes issues with packet/octet counting in e1000's 
>>> >> Statistic
>>> >> registers, fixes a bug in the packet address filtering 
>>> >> procedure, and
>>> >> implements many MAC registers that were absent before, some 
>>> >> Statistic
>>> >> counters among them.
>>> >>
>>> >> Besides this, the series introduces a parameter which, if set to 
>>> >> "on"
>>> >> (default), will cause the entire MAC registers' array to migrate 
>>> >> during
>>> >> live migration (please see patch #2 for details). The rational 
>>> >> behind
>>> >> this is the ability to implement additional MAC registers in the 
>>> >> future,
>>> >> without worrying about migration compatibility between future 
>>> >> versions.
>>> >> For compatibility with previous versions, the above mentioned 
>>> >> parameter
>>> >> can be set to "off".
>>> >>
>>> >> Also, a new array is introduced to control the access to the 
>>> >> various MAC
>>> >> registers. This takes care of situations when a MAC register 
>>> >> requires a
>>> >> certain parameter to be accessed, or is partially implemented, 
>>> >> and
>>> >> requires a debug warning to be printed on access attempts.
>>> >>
>>> >> Additionally, several cosmetic changes are made.
>>> >>
>>> >> Differences v1-2:
>>> >> 
>>> >> * Wording of several commit messages corrected.
>>> >> * For trivially implemented Diagnostic registers, a debug 
>>> >> message is
>>> >>   added on read/write attempts, alerting of incomplete 
>>> >> implementation.
>>> >> * Following testing on a physical device, only the lower 16 bits 
>>> >> can now
>>> >>   be read from AIT, and only the lower 4 - from FFMT*.
>>> >> * The grow_8reg_if_not_full function is rewritten.
>>> >> * inc_tx_bcast_or_mcast_count and increase_size_stats are now 
>>> >> called
>>> >>   from within e1000_send_packet, to avoid code duplication.
>>> >>
>>> >> Differences v2-3:
>>> >> 
>>> >> * Minor rewordings of some commit messages (0002, 0003).
>>> >> * Live migration capability is added to the newly implemented 
>>> >> registers.
>>> >>
>>> >> Differences v3-4:
>>> >> 
>>> >> * Introduction of the "full_mac_registers" parameter (see above).
>>> >> * Reversion of the live migration handling introduced in v3.
>>> >> * Small alignment changes in patch #1 to correspond with the 
>>> >> following
>>> >>   patches.
>>> >>
>>> >> Differences v4-v5:
>>> >> 
>>> >> * Introduction of an array to control the access to the MAC 
>>> >> registers.
>>> >> * Removal of the specific functions that warned of partial
>>> >>   implementation on read/write from patch 4.
>>> >> * Adequate changes to patches 4 and 8: mainly adding the 
>>> >> registers
>>> >>   introduced there to the new array.
>>> >>
>>> >> The majority of these changes result from Jason Wang's review - 
>>> >> thank
>>> >> you, Jason!
>> > Thanks a lot for the patches. Almost done with two minor concerns:
>> >
>> > 1) to unbreak bisection we'd better enable the extra_mac_registers 
>> > (and
>> > compatibility stuffs) in patch 8 or patch 9
>  Do you mean by that changing patch 2, so that the compatibility would
>  be "on" by default, and setting it to "off" by default only in patch
>  8, or an additional patch 9?
 >>> I mean do not introduce the property "extra_mac_registers" until patch 
 >>> 8
 >>> and 9. In this case all function will be enabled completely at that 
 >>> time
 >>> instead of partially patch by patch in this series.
>>> >> But won't there be compatibility issues between the patches if done
>>> >> like that?
>> >
>> > Looks not, all new mac registers and mac array migration will be
>> > functional or used only in last patch. We don't have any compatibility
>> > issue since E1000_FLAG_MAC can only be set for the last patch since the
>> > meaning of it 

Re: [Qemu-devel] [PULL 0/4] ppc-next queue 20151111

2015-11-11 Thread Peter Maydell
On 11 November 2015 at 02:34, David Gibson <da...@gibson.dropbear.id.au> wrote:
> The following changes since commit a77067f6ac9b17beefea506ce5f514072fe3fcf4:
>
>   Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20151110' 
> into staging (2015-11-10 17:49:39 +)
>
> are available in the git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-next-2015
>
> for you to fetch changes up to b41d320fef705289d2b73f4949731eb2e189161d:
>
>   spapr: Handle failure of KVM_PPC_ALLOCATE_HTAB ioctl (2015-11-11 13:29:04 
> +1100)
>
> A handful of ppc updates I think are reasonable to squeeze in before
> the hard freeze.  There's one or two more patches I might send,
> depending on feedback, but if they miss the cut-off well, too bad.
>
> 
> ppc patch queue - 2015-11-11
>
> Highlights:
>   - Updated SLOF version for "pseries machine
>   - Bugfix / cleanup for KVM hash page table allocation
>

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH v2 2/5] target-i386/kvm: Hyper-V SynIC MSR's support

2015-11-11 Thread Andrey Smetanin



On 11/10/2015 04:14 PM, Paolo Bonzini wrote:



On 10/11/2015 13:52, Andrey Smetanin wrote:

This patch does Hyper-V Synthetic interrupt
controller(Hyper-V SynIC) MSR's support and
migration. Hyper-V SynIC is enabled by cpu's
'hv-synic' option.

This patch does not allow cpu creation if
'hv-synic' option specified but kernel
doesn't support Hyper-V SynIC.

Changes v2:
* activate Hyper-V SynIC by enabling corresponding vcpu cap
* reject cpu initialization if user requested Hyper-V SynIC
   but kernel does not support Hyper-V SynIC

Signed-off-by: Andrey Smetanin 
Reviewed-by: Roman Kagan 
Signed-off-by: Denis V. Lunev 
CC: Paolo Bonzini 
CC: Richard Henderson 
CC: Eduardo Habkost 
CC: "Andreas Färber" 
CC: Marcelo Tosatti 
CC: Roman Kagan 
CC: Denis V. Lunev 
CC: k...@vger.kernel.org

---
  target-i386/cpu-qom.h |  1 +
  target-i386/cpu.c |  1 +
  target-i386/cpu.h |  5 
  target-i386/kvm.c | 67 ++-
  target-i386/machine.c | 39 ++
  5 files changed, 112 insertions(+), 1 deletion(-)

diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index e3bfe9d..7ea5b34 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -94,6 +94,7 @@ typedef struct X86CPU {
  bool hyperv_reset;
  bool hyperv_vpindex;
  bool hyperv_runtime;
+bool hyperv_synic;
  bool check_cpuid;
  bool enforce_cpuid;
  bool expose_kvm;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e5f1c5b..1462e19 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -3142,6 +3142,7 @@ static Property x86_cpu_properties[] = {
  DEFINE_PROP_BOOL("hv-reset", X86CPU, hyperv_reset, false),
  DEFINE_PROP_BOOL("hv-vpindex", X86CPU, hyperv_vpindex, false),
  DEFINE_PROP_BOOL("hv-runtime", X86CPU, hyperv_runtime, false),
+DEFINE_PROP_BOOL("hv-synic", X86CPU, hyperv_synic, false),
  DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
  DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
  DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index fc4a605..8cf33df 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -918,6 +918,11 @@ typedef struct CPUX86State {
  uint64_t msr_hv_tsc;
  uint64_t msr_hv_crash_params[HV_X64_MSR_CRASH_PARAMS];
  uint64_t msr_hv_runtime;
+uint64_t msr_hv_synic_control;
+uint64_t msr_hv_synic_version;
+uint64_t msr_hv_synic_evt_page;
+uint64_t msr_hv_synic_msg_page;
+uint64_t msr_hv_synic_sint[HV_SYNIC_SINT_COUNT];

  /* exception/interrupt handling */
  int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 2a9953b..cfcd01d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -86,6 +86,7 @@ static bool has_msr_hv_crash;
  static bool has_msr_hv_reset;
  static bool has_msr_hv_vpindex;
  static bool has_msr_hv_runtime;
+static bool has_msr_hv_synic;
  static bool has_msr_mtrr;
  static bool has_msr_xss;

@@ -521,7 +522,8 @@ static bool hyperv_enabled(X86CPU *cpu)
  cpu->hyperv_crash ||
  cpu->hyperv_reset ||
  cpu->hyperv_vpindex ||
-cpu->hyperv_runtime);
+cpu->hyperv_runtime ||
+cpu->hyperv_synic);
  }

  static Error *invtsc_mig_blocker;
@@ -610,6 +612,14 @@ int kvm_arch_init_vcpu(CPUState *cs)
  if (cpu->hyperv_runtime && has_msr_hv_runtime) {
  c->eax |= HV_X64_MSR_VP_RUNTIME_AVAILABLE;
  }
+if (cpu->hyperv_synic) {
+if (!has_msr_hv_synic ||
+kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_SYNIC, 0)) {
+fprintf(stderr, "Hyper-V SynIC is not supported by kernel\n");
+return -ENOSYS;
+}
+c->eax |= HV_X64_MSR_SYNIC_AVAILABLE;
+}
  c = _data.entries[cpuid_i++];
  c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
  if (cpu->hyperv_relaxed_timing) {
@@ -950,6 +960,10 @@ static int kvm_get_supported_msrs(KVMState *s)
  has_msr_hv_runtime = true;
  continue;
  }
+if (kvm_msr_list->indices[i] == HV_X64_MSR_SCONTROL) {
+has_msr_hv_synic = true;
+continue;
+}
  }
  }

@@ -1511,6 +1525,31 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
  kvm_msr_entry_set([n++], HV_X64_MSR_VP_RUNTIME,
env->msr_hv_runtime);
  }
+if (cpu->hyperv_synic) {
+int j;
+
+if (!env->msr_hv_synic_version) {
+/* First time initialization */
+env->msr_hv_synic_version = HV_SYNIC_VERSION_1;
+for (j 

Re: [Qemu-devel] [PATCH v10 23/30] qapi: Check for qapi collisions of flat union branches

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> On 11/09/2015 10:16 PM, Eric Blake wrote:
>
>>> We have tests covering attempts to do the former
>>> (struct-cycle-direct.json, struct-cycle-indirect.json).  As far as I can
>>> see, we don't have tests covering the latter.  Do we catch it?
>> 
>> Yes, at least by virtue of the ad hoc tests: attempting to reuse a base
>> type of the flat union as a variant member will cause the qapi members
>> of the base type to appear more than once in the JSON object (that is,
>> the checks that reject flat-union-clash-member.json would also reject
>> this scenario). To test:
>> 
>> diff --git i/tests/qapi-schema/qapi-schema-test.json
>> w/tests/qapi-schema/qapi-schema-test.json
>> index 44638da..16b2ffb 100644
>> --- i/tests/qapi-schema/qapi-schema-test.json
>> +++ w/tests/qapi-schema/qapi-schema-test.json
>> @@ -67,7 +67,7 @@
>>'discriminator': 'enum1',
>>'data': { 'value1' : 'UserDefA',
>>  'value2' : 'UserDefB',
>> -'value3' : 'UserDefB' } }
>> +'value3' : 'UserDefUnionBase' } }
>
> Another test I just tried is creating a flat union with:
>
> empty -> base -> union
>
> then use empty as one of the union branches.  In that case, there is no
> conflict (although base is included twice, neither inclusion adds
> members to the JSON object; and the inclusion is not circular so things
> compile just fine).  So probably not worth adding a test for it.

Member name clashes occur because:

1. Two separately defined members happen to have a clashing name.

   Whether the members are local or inherited, variant or non-variant
   doesn't matter.

2. The same type gets spliced in twice, and conflict.

   By "spliced", I mean the members get included.  A bit like unboxed,
   but also "unwrapped".

   Base types and variant types get spliced in.  Variant types don't
   conflict with each other.  Empty type can't conflict (outlawing it
   anyway would be pointless).  Therefore, the only conflicting splice
   is a non-empty type occuring both as (base type of the) base type and
   as (base type of a) variant type.

   We detect this kind of clash exactly like 1.  That's fine, because
   the resulting error messages are plainly good enough.

3. Type contains itself.

   The type gets spliced into itself, or has itself as unboxed member.

   We don't unbox object members so far.  That leaves the spliced ones:
   base types and variants.  Thus, a type contains itself if it's its
   own base or one of its own variants, or a direct or indirect base of
   either.

   We detect this kind of clash separately, when we guard against
   infinite check() recursion.  Reporting it right there will be
   easiest.

We want to cover all this with tests.  I guess we're lacking only 3.



Re: [Qemu-devel] [PATCH V3 3/6] KVM: add support for any length io eventfd

2015-11-11 Thread Paolo Bonzini


On 06/11/2015 09:02, Jason Wang wrote:
> Signed-off-by: Jason Wang 
> ---
>  include/sysemu/kvm.h | 8 
>  kvm-all.c| 4 
>  kvm-stub.c   | 1 +
>  3 files changed, 13 insertions(+)
> 
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index 4ac6176..b31f325 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -53,6 +53,7 @@ extern bool kvm_gsi_routing_allowed;
>  extern bool kvm_gsi_direct_mapping;
>  extern bool kvm_readonly_mem_allowed;
>  extern bool kvm_direct_msi_allowed;
> +extern bool kvm_ioeventfd_any_length_allowed;
>  
>  #if defined CONFIG_KVM || !defined NEED_CPU_H
>  #define kvm_enabled()   (kvm_allowed)
> @@ -153,6 +154,12 @@ extern bool kvm_direct_msi_allowed;
>   */
>  #define kvm_direct_msi_enabled() (kvm_direct_msi_allowed)
>  
> +/**
> + * kvm_ioeventfd_any_length_enabled:
> + * Returns: true if KVM allows any length io eventfd.
> + */
> +#define kvm_ioeventfd_any_length_enabled() (kvm_ioeventfd_any_length_allowed)
> +
>  #else
>  #define kvm_enabled()   (0)
>  #define kvm_irqchip_in_kernel() (false)
> @@ -166,6 +173,7 @@ extern bool kvm_direct_msi_allowed;
>  #define kvm_gsi_direct_mapping() (false)
>  #define kvm_readonly_mem_enabled() (false)
>  #define kvm_direct_msi_enabled() (false)
> +#define kvm_ioeventfd_any_length_enabled() (false)
>  #endif
>  
>  struct kvm_run;
> diff --git a/kvm-all.c b/kvm-all.c
> index 1bc1273..f4e2cf0 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -109,6 +109,7 @@ bool kvm_allowed;
>  bool kvm_readonly_mem_allowed;
>  bool kvm_vm_attributes_allowed;
>  bool kvm_direct_msi_allowed;
> +bool kvm_ioeventfd_any_length_allowed;
>  
>  static const KVMCapabilityInfo kvm_required_capabilites[] = {
>  KVM_CAP_INFO(USER_MEMORY),
> @@ -1612,6 +1613,9 @@ static int kvm_init(MachineState *ms)
>  kvm_vm_attributes_allowed =
>  (kvm_check_extension(s, KVM_CAP_VM_ATTRIBUTES) > 0);
>  
> +kvm_ioeventfd_any_length_allowed =
> +(kvm_check_extension(s, KVM_CAP_IOEVENTFD_ANY_LENGTH) > 0);
> +
>  ret = kvm_arch_init(ms, s);
>  if (ret < 0) {
>  goto err;
> diff --git a/kvm-stub.c b/kvm-stub.c
> index a5051f7..dc97a5e 100644
> --- a/kvm-stub.c
> +++ b/kvm-stub.c
> @@ -30,6 +30,7 @@ bool kvm_gsi_routing_allowed;
>  bool kvm_gsi_direct_mapping;
>  bool kvm_allowed;
>  bool kvm_readonly_mem_allowed;
> +bool kvm_ioeventfd_any_length_allowed;
>  
>  int kvm_init_vcpu(CPUState *cpu)
>  {
> 

Acked-by: Paolo Bonzini 



Re: [Qemu-devel] [PATCH 3/4] hw/s390x: Remove superfluous return statements

2015-11-11 Thread Cornelia Huck
On Tue, 10 Nov 2015 21:16:10 +0100
Thomas Huth  wrote:

> The "return;" statements at the end of functions do not make
> much sense, so let's remove them.
> 
> Cc: Cornelia Huck 
> Cc: Christian Borntraeger 
> Cc: Alexander Graf 
> Cc: Richard Henderson 
> Signed-off-by: Thomas Huth 
> ---
>  hw/s390x/css.c|  1 -
>  hw/s390x/event-facility.c | 21 ++---
>  hw/s390x/s390-pci-bus.c   |  4 
>  3 files changed, 6 insertions(+), 20 deletions(-)
> 

Ack for the css and pci parts.

The sclp parts, however, switch from "one point of exit" to "immediate
exit", and I'm not sure I like that; not sure enough anyway to apply
this patch.




Re: [Qemu-devel] [PATCH] include/hw: field 'offset' in struct Property should be ptrdiff_t as int causes overflow

2015-11-11 Thread Markus Armbruster
Peter Maydell  writes:

> On 25 August 2015 at 15:17, Markus Armbruster  wrote:
>> Stumbled over this while throwing away old mail.  Andreas, what do you
>> think?
>
> Seems right to me -- I suspect the original properties code was
> written with the assumption that the property field would be
> inside the device struct (and so offsets are small). The array
> properties code breaks that assumption by allocating a separate
> lump of memory with the properties in it; so now there's no
> guarantee that the two pointers being subtracted will be
> within 4G of each other.
>
> Reviewed-by: Peter Maydell 
>
> Arguably for consistency the 'arrayoffset' struct member should
> also be a ptrdiff_t, though our current uses of it are such
> that it'll always be within int range.

Andreas?



Re: [Qemu-devel] SMM error in 2.4 changelog

2015-11-11 Thread Paolo Bonzini


On 10/11/2015 21:32, William Dauchy wrote:
> On Tue, Nov 3, 2015 at 10:01 AM, Paolo Bonzini  wrote:
>> Yes, this is correct.  Thanks!
> 
> The mistake seems to be still present in changelog.

Fixed now, thanks for reminding.

Paolo



[Qemu-devel] [PATCH v13 08/13] vfio: add check host bus reset is support or not

2015-11-11 Thread Cao jin
From: Chen Fan 

when init vfio devices done, we should test all the devices supported
aer whether conflict with others. For each one, get the hot reset
info for the affected device list.  For each affected device, all
should attach to the VM and on/below the same bus. also, we should test
all of the non-AER supporting vfio-pci devices on or below the target
bus to verify they have a reset mechanism.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 210 --
 hw/vfio/pci.h |   1 +
 2 files changed, 204 insertions(+), 7 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 2d34edf..31ffd44 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1806,6 +1806,190 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, 
uint8_t pos)
 return 0;
 }
 
+static bool vfio_pci_host_match(PCIHostDeviceAddress *host1,
+PCIHostDeviceAddress *host2)
+{
+return (host1->domain == host2->domain && host1->bus == host2->bus &&
+host1->slot == host2->slot && host1->function == host2->function);
+}
+
+struct VFIODeviceFind {
+PCIDevice *pdev;
+bool found;
+};
+
+static void vfio_check_device_noreset(PCIBus *bus, PCIDevice *pdev,
+  void *opaque)
+{
+DeviceState *dev = DEVICE(pdev);
+DeviceClass *dc = DEVICE_GET_CLASS(dev);
+VFIOPCIDevice *vdev;
+struct VFIODeviceFind *find = opaque;
+
+if (find->found) {
+return;
+}
+
+if (!object_dynamic_cast(OBJECT(dev), "vfio-pci")) {
+if (!dc->reset) {
+goto found;
+}
+return;
+}
+vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
+if (!(vdev->features & VFIO_FEATURE_ENABLE_AER) &&
+!vdev->vbasedev.reset_works) {
+goto found;
+}
+
+return;
+found:
+find->pdev = pdev;
+find->found = true;
+}
+
+static void device_find(PCIBus *bus, PCIDevice *pdev, void *opaque)
+{
+struct VFIODeviceFind *find = opaque;
+
+if (find->found) {
+return;
+}
+
+if (pdev == find->pdev) {
+find->found = true;
+}
+}
+
+static int vfio_check_host_bus_reset(VFIOPCIDevice *vdev)
+{
+PCIBus *bus = vdev->pdev.bus;
+struct vfio_pci_hot_reset_info *info = NULL;
+struct vfio_pci_dependent_device *devices;
+VFIOGroup *group;
+struct VFIODeviceFind find;
+int ret, i;
+
+ret = vfio_get_hot_reset_info(vdev, );
+if (ret) {
+error_report("vfio: Cannot get hot reset info");
+goto out;
+}
+
+/* List all affected devices by bus reset */
+devices = >devices[0];
+
+/* Verify that we have all the groups required */
+for (i = 0; i < info->count; i++) {
+PCIHostDeviceAddress host;
+VFIOPCIDevice *tmp;
+VFIODevice *vbasedev_iter;
+bool found = false;
+
+host.domain = devices[i].segment;
+host.bus = devices[i].bus;
+host.slot = PCI_SLOT(devices[i].devfn);
+host.function = PCI_FUNC(devices[i].devfn);
+
+/* Skip the current device */
+if (vfio_pci_host_match(, >host)) {
+continue;
+}
+
+/* Ensure we own the group of the affected device */
+QLIST_FOREACH(group, _group_list, next) {
+if (group->groupid == devices[i].group_id) {
+break;
+}
+}
+
+if (!group) {
+error_report("vfio: Cannot enable AER for device %s, "
+ "depends on group %d which is not owned.",
+ vdev->vbasedev.name, devices[i].group_id);
+ret = -1;
+goto out;
+}
+
+/* Ensure affected devices for reset on/blow the bus */
+QLIST_FOREACH(vbasedev_iter, >device_list, next) {
+if (vbasedev_iter->type != VFIO_DEVICE_TYPE_PCI) {
+continue;
+}
+tmp = container_of(vbasedev_iter, VFIOPCIDevice, vbasedev);
+if (vfio_pci_host_match(, >host)) {
+PCIDevice *pci = PCI_DEVICE(tmp);
+
+find.pdev = pci;
+find.found = false;
+pci_for_each_device(bus, pci_bus_num(bus),
+device_find, );
+if (!find.found) {
+error_report("vfio: Cannot enable AER for device %s, "
+ "the dependent device %s is not under the 
same bus",
+ vdev->vbasedev.name, tmp->vbasedev.name);
+ret = -1;
+goto out;
+}
+found = true;
+break;
+}
+}
+
+/* Ensure all affected devices assigned to VM */
+if (!found) {
+error_report("vfio: Cannot enable AER for device %s, "
+ "the dependent device %04x:%02x:%02x.%x "
+ 

[Qemu-devel] [PATCH v13 12/13] vfio-pci: pass the aer error to guest

2015-11-11 Thread Cao jin
From: Chen Fan 

when the vfio device encounters an uncorrectable error in host,
the vfio_pci driver will signal the eventfd registered by this
vfio device, the results in the qemu eventfd handler getting
invoked.

this patch is to pass the error to guest and have the guest driver
recover from the error.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 45 +++--
 1 file changed, 39 insertions(+), 6 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 90df393..c593876 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2523,18 +2523,51 @@ static void vfio_put_device(VFIOPCIDevice *vdev)
 static void vfio_err_notifier_handler(void *opaque)
 {
 VFIOPCIDevice *vdev = opaque;
+PCIDevice *dev = >pdev;
+PCIEAERMsg msg = {
+.severity = 0,
+.source_id = (pci_bus_num(dev->bus) << 8) | dev->devfn,
+};
 
 if (!event_notifier_test_and_clear(>err_notifier)) {
 return;
 }
 
 /*
- * TBD. Retrieve the error details and decide what action
- * needs to be taken. One of the actions could be to pass
- * the error to the guest and have the guest driver recover
- * from the error. This requires that PCIe capabilities be
- * exposed to the guest. For now, we just terminate the
- * guest to contain the error.
+ * in case the real hardware configration has been changed,
+ * here we should recheck the bus reset capability.
+ */
+if ((vdev->features & VFIO_FEATURE_ENABLE_AER) &&
+vfio_check_host_bus_reset(vdev)) {
+goto stop;
+}
+/*
+ * we should read the error details from the real hardware
+ * configuration spaces, here we only need to do is signaling
+ * to guest an uncorrectable error has occurred.
+ */
+if ((vdev->features & VFIO_FEATURE_ENABLE_AER) &&
+dev->exp.aer_cap) {
+uint8_t *aer_cap = dev->config + dev->exp.aer_cap;
+uint32_t uncor_status;
+bool isfatal;
+
+uncor_status = vfio_pci_read_config(dev,
+   dev->exp.aer_cap + PCI_ERR_UNCOR_STATUS, 4);
+
+isfatal = uncor_status & pci_get_long(aer_cap + PCI_ERR_UNCOR_SEVER);
+
+msg.severity = isfatal ? PCI_ERR_ROOT_CMD_FATAL_EN :
+ PCI_ERR_ROOT_CMD_NONFATAL_EN;
+
+pcie_aer_msg(dev, );
+return;
+}
+
+stop:
+/*
+ * If the aer capability is not exposed to the guest. we just
+ * terminate the guest to contain the error.
  */
 
 error_report("%s(%04x:%02x:%02x.%x) Unrecoverable error detected.  "
-- 
1.9.3




[Qemu-devel] [PATCH v13 03/13] pcie: modify the capability size assert

2015-11-11 Thread Cao jin
From: Chen Fan 

 Device's Offset and size can reach PCIE_CONFIG_SPACE_SIZE,
 fix the corresponding assert.

Signed-off-by: Chen Fan 
Reviewed-by: Marcel Apfelbaum 
---
 hw/pci/pcie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 0eab29d..8f4c0e5 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -607,7 +607,7 @@ void pcie_add_capability(PCIDevice *dev,
 
 assert(offset >= PCI_CONFIG_SPACE_SIZE);
 assert(offset < offset + size);
-assert(offset + size < PCIE_CONFIG_SPACE_SIZE);
+assert(offset + size <= PCIE_CONFIG_SPACE_SIZE);
 assert(size >= 8);
 assert(pci_is_express(dev));
 
-- 
1.9.3




[Qemu-devel] [PATCH v13 05/13] vfio: add pcie extanded capability support

2015-11-11 Thread Cao jin
From: Chen Fan 

For vfio pcie device, we could expose the extended capability on
PCIE bus. in order to avoid config space broken, we introduce
a copy config for parsing extended caps. and rebuild the pcie
extended config space.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 70 ++-
 1 file changed, 69 insertions(+), 1 deletion(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index e305cda..4bc2b51 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1481,6 +1481,21 @@ static uint8_t vfio_std_cap_max_size(PCIDevice *pdev, 
uint8_t pos)
 return next - pos;
 }
 
+
+static uint16_t vfio_ext_cap_max_size(const uint8_t *config, uint16_t pos)
+{
+uint16_t tmp, next = PCIE_CONFIG_SPACE_SIZE;
+
+for (tmp = PCI_CONFIG_SPACE_SIZE; tmp;
+tmp = PCI_EXT_CAP_NEXT(pci_get_long(config + tmp))) {
+if (tmp > pos && tmp < next) {
+next = tmp;
+}
+}
+
+return next - pos;
+}
+
 static void vfio_set_word_bits(uint8_t *buf, uint16_t val, uint16_t mask)
 {
 pci_set_word(buf, (pci_get_word(buf) & ~mask) | val);
@@ -1791,16 +1806,69 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, 
uint8_t pos)
 return 0;
 }
 
+static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
+{
+PCIDevice *pdev = >pdev;
+uint32_t header;
+uint16_t cap_id, next, size;
+uint8_t cap_ver;
+uint8_t *config;
+
+/*
+ * In order to avoid breaking config space, create a copy to
+ * use for parsing extended capabilities.
+ */
+config = g_memdup(pdev->config, vdev->config_size);
+
+for (next = PCI_CONFIG_SPACE_SIZE; next;
+ next = PCI_EXT_CAP_NEXT(pci_get_long(config + next))) {
+header = pci_get_long(config + next);
+cap_id = PCI_EXT_CAP_ID(header);
+cap_ver = PCI_EXT_CAP_VER(header);
+
+/*
+ * If it becomes important to configure extended capabilities to their
+ * actual size, use this as the default when it's something we don't
+ * recognize. Since QEMU doesn't actually handle many of the config
+ * accesses, exact size doesn't seem worthwhile.
+ */
+size = vfio_ext_cap_max_size(config, next);
+
+pcie_add_capability(pdev, cap_id, cap_ver, next, size);
+pci_set_long(dev->config + next, PCI_EXT_CAP(cap_id, cap_ver, 0));
+
+/* Use emulated next pointer to allow dropping extended caps */
+pci_long_test_and_set_mask(vdev->emulated_config_bits + next,
+   PCI_EXT_CAP_NEXT_MASK);
+}
+
+g_free(config);
+return 0;
+}
+
 static int vfio_add_capabilities(VFIOPCIDevice *vdev)
 {
 PCIDevice *pdev = >pdev;
+int ret;
 
 if (!(pdev->config[PCI_STATUS] & PCI_STATUS_CAP_LIST) ||
 !pdev->config[PCI_CAPABILITY_LIST]) {
 return 0; /* Nothing to add */
 }
 
-return vfio_add_std_cap(vdev, pdev->config[PCI_CAPABILITY_LIST]);
+ret = vfio_add_std_cap(vdev, pdev->config[PCI_CAPABILITY_LIST]);
+if (ret) {
+return ret;
+}
+
+/* on PCI bus, it doesn't make sense to expose extended capabilities. */
+if (!pci_is_express(pdev) ||
+!pci_bus_is_express(pdev->bus) ||
+!pci_get_long(pdev->config + PCI_CONFIG_SPACE_SIZE)) {
+return 0;
+}
+
+return vfio_add_ext_cap(vdev);
 }
 
 static void vfio_pci_pre_reset(VFIOPCIDevice *vdev)
-- 
1.9.3




[Qemu-devel] [PATCH v13 04/13] vfio: make the 4 bytes aligned for capability size

2015-11-11 Thread Cao jin
From: Chen Fan 

this function search the capability from the end, the last
size should 0x100 - pos, not 0xff - pos.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index f333dfc..e305cda 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1468,7 +1468,8 @@ static void vfio_unmap_bars(VFIOPCIDevice *vdev)
  */
 static uint8_t vfio_std_cap_max_size(PCIDevice *pdev, uint8_t pos)
 {
-uint8_t tmp, next = 0xff;
+uint8_t tmp;
+uint16_t next = PCI_CONFIG_SPACE_SIZE;
 
 for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp;
  tmp = pdev->config[tmp + 1]) {
-- 
1.9.3




[Qemu-devel] [PATCH v13 06/13] aer: impove pcie_aer_init to support vfio device

2015-11-11 Thread Cao jin
From: Chen Fan 

pcie_aer_init was used to emulate an aer capability for pcie device,
but for vfio device, the aer config space size is mutable and is not
always equal to PCI_ERR_SIZEOF(0x48). it depends on where the TLP Prefix
register required, so here we add a size argument.

Signed-off-by: Chen Fan 
---
 hw/pci-bridge/ioh3420.c| 2 +-
 hw/pci-bridge/xio3130_downstream.c | 2 +-
 hw/pci-bridge/xio3130_upstream.c   | 2 +-
 hw/pci/pcie_aer.c  | 4 ++--
 include/hw/pci/pcie_aer.h  | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index cce2fdd..4d9cd3f 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -129,7 +129,7 @@ static int ioh3420_initfn(PCIDevice *d)
 goto err_pcie_cap;
 }
 pcie_cap_root_init(d);
-rc = pcie_aer_init(d, IOH_EP_AER_OFFSET);
+rc = pcie_aer_init(d, IOH_EP_AER_OFFSET, PCI_ERR_SIZEOF);
 if (rc < 0) {
 goto err;
 }
diff --git a/hw/pci-bridge/xio3130_downstream.c 
b/hw/pci-bridge/xio3130_downstream.c
index b3a6479..9737041 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -92,7 +92,7 @@ static int xio3130_downstream_initfn(PCIDevice *d)
 goto err_pcie_cap;
 }
 pcie_cap_arifwd_init(d);
-rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
+rc = pcie_aer_init(d, XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
 if (rc < 0) {
 goto err;
 }
diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c
index eada582..4d7f894 100644
--- a/hw/pci-bridge/xio3130_upstream.c
+++ b/hw/pci-bridge/xio3130_upstream.c
@@ -81,7 +81,7 @@ static int xio3130_upstream_initfn(PCIDevice *d)
 }
 pcie_cap_flr_init(d);
 pcie_cap_deverr_init(d);
-rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
+rc = pcie_aer_init(d, XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
 if (rc < 0) {
 goto err;
 }
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 98d2c18..45f351b 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -94,12 +94,12 @@ static void aer_log_clear_all_err(PCIEAERLog *aer_log)
 aer_log->log_num = 0;
 }
 
-int pcie_aer_init(PCIDevice *dev, uint16_t offset)
+int pcie_aer_init(PCIDevice *dev, uint16_t offset, uint16_t size)
 {
 PCIExpressDevice *exp;
 
 pcie_add_capability(dev, PCI_EXT_CAP_ID_ERR, PCI_ERR_VER,
-offset, PCI_ERR_SIZEOF);
+offset, size);
 exp = >exp;
 exp->aer_cap = offset;
 
diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
index 2fb8388..156acb0 100644
--- a/include/hw/pci/pcie_aer.h
+++ b/include/hw/pci/pcie_aer.h
@@ -87,7 +87,7 @@ struct PCIEAERErr {
 
 extern const VMStateDescription vmstate_pcie_aer_log;
 
-int pcie_aer_init(PCIDevice *dev, uint16_t offset);
+int pcie_aer_init(PCIDevice *dev, uint16_t offset, uint16_t size);
 void pcie_aer_exit(PCIDevice *dev);
 void pcie_aer_write_config(PCIDevice *dev,
uint32_t addr, uint32_t val, int len);
-- 
1.9.3




Re: [Qemu-devel] [PULL 33/44] block: New option to define the intervals for collecting I/O statistics

2015-11-11 Thread Alberto Garcia
On Tue 10 Nov 2015 06:23:36 PM CET, Eric Blake  wrote:

>> +# @stats-intervals: #optional colon-separated list of intervals for
>> +#   collecting I/O statistics, in seconds (default: none)
>> +#   (Since 2.5)
>
> Eww. Sorry for not noticing this sooner, but can we please fix this to
>be:
>
> '*stats-intervals':['int']

No problem, I'll send a follow-up patch asap.

I was actually expecting that there would be some debate about this; in
the series description I mentioned that I considered an alternate API,
although rather than ['int'] it was ['BlockdevStatsInterval'], with
BlockdevStatsInterval being a struct with a sole member 'length': 'int'.

  stats-intervals.0.length=60,
  stats-intervals.1.length=3600,
  stats-intervals.2.length=86400

It's more future proof than just having a list of integers, but I
honestly don't know if there's any use case for additional parameters of
the intervals.

https://lists.gnu.org/archive/html/qemu-block/2015-10/msg01068.html

Berto



[Qemu-devel] [PATCH v13 02/13] vfio: squeeze out vfio_pci_do_hot_reset for support bus reset

2015-11-11 Thread Cao jin
From: Chen Fan 

squeeze out vfio_pci_do_hot_reset to do host bus reset when AER recovery.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 75 +++
 1 file changed, 44 insertions(+), 31 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 464e6b7..f333dfc 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1673,6 +1673,48 @@ error:
 return ret;
 }
 
+static int vfio_pci_do_hot_reset(VFIOPCIDevice *vdev,
+ struct vfio_pci_hot_reset_info *info)
+{
+VFIOGroup *group;
+struct vfio_pci_hot_reset *reset;
+int32_t *fds;
+int ret, i, count;
+struct vfio_pci_dependent_device *devices;
+
+/* Determine how many group fds need to be passed */
+count = 0;
+devices = >devices[0];
+QLIST_FOREACH(group, _group_list, next) {
+for (i = 0; i < info->count; i++) {
+if (group->groupid == devices[i].group_id) {
+count++;
+break;
+}
+}
+}
+
+reset = g_malloc0(sizeof(*reset) + (count * sizeof(*fds)));
+reset->argsz = sizeof(*reset) + (count * sizeof(*fds));
+fds = >group_fds[0];
+
+/* Fill in group fds */
+QLIST_FOREACH(group, _group_list, next) {
+for (i = 0; i < info->count; i++) {
+if (group->groupid == devices[i].group_id) {
+fds[reset->count++] = group->fd;
+break;
+}
+}
+}
+
+/* Bus reset! */
+ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_PCI_HOT_RESET, reset);
+g_free(reset);
+
+return ret;
+}
+
 static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos)
 {
 PCIDevice *pdev = >pdev;
@@ -1814,9 +1856,7 @@ static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool 
single)
 VFIOGroup *group;
 struct vfio_pci_hot_reset_info *info = NULL;
 struct vfio_pci_dependent_device *devices;
-struct vfio_pci_hot_reset *reset;
-int32_t *fds;
-int ret, i, count;
+int ret, i;
 bool multi = false;
 
 trace_vfio_pci_hot_reset(vdev->vbasedev.name, single ? "one" : "multi");
@@ -1895,34 +1935,7 @@ static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool 
single)
 goto out_single;
 }
 
-/* Determine how many group fds need to be passed */
-count = 0;
-QLIST_FOREACH(group, _group_list, next) {
-for (i = 0; i < info->count; i++) {
-if (group->groupid == devices[i].group_id) {
-count++;
-break;
-}
-}
-}
-
-reset = g_malloc0(sizeof(*reset) + (count * sizeof(*fds)));
-reset->argsz = sizeof(*reset) + (count * sizeof(*fds));
-fds = >group_fds[0];
-
-/* Fill in group fds */
-QLIST_FOREACH(group, _group_list, next) {
-for (i = 0; i < info->count; i++) {
-if (group->groupid == devices[i].group_id) {
-fds[reset->count++] = group->fd;
-break;
-}
-}
-}
-
-/* Bus reset! */
-ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_PCI_HOT_RESET, reset);
-g_free(reset);
+ret = vfio_pci_do_hot_reset(vdev, info);
 
 trace_vfio_pci_hot_reset_result(vdev->vbasedev.name,
 ret ? "%m" : "Success");
-- 
1.9.3




[Qemu-devel] [PATCH v13 01/13] vfio: extract vfio_get_hot_reset_info as a single function

2015-11-11 Thread Cao jin
From: Chen Fan 

the function is used to get affected devices by bus reset.
so here extract it, and can used for aer soon.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 66 +++
 1 file changed, 48 insertions(+), 18 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 8fadbcf..464e6b7 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1628,6 +1628,51 @@ static void vfio_check_af_flr(VFIOPCIDevice *vdev, 
uint8_t pos)
 }
 }
 
+/*
+ * return negative with errno, return 0 on success.
+ * if success, the point of ret_info fill with the affected device reset info.
+ *
+ */
+static int vfio_get_hot_reset_info(VFIOPCIDevice *vdev,
+   struct vfio_pci_hot_reset_info **ret_info)
+{
+struct vfio_pci_hot_reset_info *info;
+int ret, count;
+
+*ret_info = NULL;
+
+info = g_malloc0(sizeof(*info));
+info->argsz = sizeof(*info);
+
+ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO, info);
+if (ret && errno != ENOSPC) {
+ret = -errno;
+goto error;
+}
+
+count = info->count;
+
+info = g_realloc(info, sizeof(*info) +
+ (count * sizeof(struct vfio_pci_dependent_device)));
+info->argsz = sizeof(*info) +
+  (count * sizeof(struct vfio_pci_dependent_device));
+
+ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO, info);
+if (ret) {
+ret = -errno;
+error_report("vfio: hot reset info failed: %m");
+goto error;
+}
+
+*ret_info = info;
+info = NULL;
+
+return 0;
+error:
+g_free(info);
+return ret;
+}
+
 static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos)
 {
 PCIDevice *pdev = >pdev;
@@ -1767,7 +1812,7 @@ static bool vfio_pci_host_match(PCIHostDeviceAddress 
*host1,
 static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool single)
 {
 VFIOGroup *group;
-struct vfio_pci_hot_reset_info *info;
+struct vfio_pci_hot_reset_info *info = NULL;
 struct vfio_pci_dependent_device *devices;
 struct vfio_pci_hot_reset *reset;
 int32_t *fds;
@@ -1779,12 +1824,8 @@ static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool 
single)
 vfio_pci_pre_reset(vdev);
 vdev->vbasedev.needs_reset = false;
 
-info = g_malloc0(sizeof(*info));
-info->argsz = sizeof(*info);
-
-ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO, info);
-if (ret && errno != ENOSPC) {
-ret = -errno;
+ret = vfio_get_hot_reset_info(vdev, );
+if (ret) {
 if (!vdev->has_pm_reset) {
 error_report("vfio: Cannot reset device %04x:%02x:%02x.%x, "
  "no available reset mechanism.", vdev->host.domain,
@@ -1793,18 +1834,7 @@ static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool 
single)
 goto out_single;
 }
 
-count = info->count;
-info = g_realloc(info, sizeof(*info) + (count * sizeof(*devices)));
-info->argsz = sizeof(*info) + (count * sizeof(*devices));
 devices = >devices[0];
-
-ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO, info);
-if (ret) {
-ret = -errno;
-error_report("vfio: hot reset info failed: %m");
-goto out_single;
-}
-
 trace_vfio_pci_hot_reset_has_dep_devices(vdev->vbasedev.name);
 
 /* Verify that we have all the groups required */
-- 
1.9.3




[Qemu-devel] [PATCH v13 00/13] vfio-pci: pass the aer error to guest

2015-11-11 Thread Cao jin
From: Chen Fan 

For now, for vfio pci passthough devices when qemu receives
an error from host aer report, currentlly just terminate the guest,
but usually user want to know what error occurred but stopping the
guest, so this patches add aer capability support for vfio device,
and pass the error to guest, and have guest driver to recover
from the error.

v12-v13:
   1. since support multifuncion hotplug, here add callback to enable aer.
   2. add pci device pre+post reset for aer host reset.


Chen Fan (13):
  vfio: extract vfio_get_hot_reset_info as a single function
  vfio: squeeze out vfio_pci_do_hot_reset for support bus reset
  pcie: modify the capability size assert
  vfio: make the 4 bytes aligned for capability size
  vfio: add pcie extanded capability support
  aer: impove pcie_aer_init to support vfio device
  vfio: add aer support for vfio device
  vfio: add check host bus reset is support or not
  add check reset mechanism when hotplug vfio device
  pci: add pci device pre-post reset callbacks for host bus reset
  pcie_aer: expose pcie_aer_msg() interface
  vfio-pci: pass the aer error to guest
  vfio: add 'aer' property to expose aercap

 hw/pci-bridge/ioh3420.c|   2 +-
 hw/pci-bridge/xio3130_downstream.c |   2 +-
 hw/pci-bridge/xio3130_upstream.c   |   2 +-
 hw/pci/pci.c   |  47 +++
 hw/pci/pci_bridge.c|   9 +
 hw/pci/pcie.c  |   2 +-
 hw/pci/pcie_aer.c  |   6 +-
 hw/vfio/pci.c  | 592 +
 hw/vfio/pci.h  |   8 +
 include/hw/pci/pci.h   |   7 +
 include/hw/pci/pci_bus.h   |   5 +
 include/hw/pci/pcie_aer.h  |   3 +-
 12 files changed, 613 insertions(+), 72 deletions(-)

-- 
1.9.3




Re: [Qemu-devel] ARM NEON function call tracing

2015-11-11 Thread Alex Bennée

Peter Maydell  writes:

> On 11 November 2015 at 07:51, Junaid Shuja  
> wrote:
>> Hi,
>> I am working on ARM/NEON instructions. I want to know which neon helper
>> function corresponds to the neon instructions. As a test case, I have a
>> source file with loads of vadd.i32 instructions. I want to trace which neon
>> helper functions is called. I used a very crude approach: printf in
>> neon_add_u16 funtion and compiled source again. But no printf showed on
>> program execution. I need help regarding tracing of neon helpers.
>
> Integer addition is a simple operation so we can do it directly
> in the generated code; we don't need a helper for it, even as a
> Neon instruction. Generally we only have helper functions for
> operations that are too complicated to do directly inline.
> So there isn't a simple "one neon instruction, one helper function"
> mapping. Where we do have a helper function, the helper
> may work on one "lane" of Neon data (meaning it gets called
> more than once for each instruction) or it may work on several
> lanes at once.
>
> To find out how we handle a particular Neon instruction, you need
> to look at disas_neon_data_insn and see what it does with the
> insn (it may be easiest to do this by putting a breakpoint on
> it and stepping through with a debugger). Where this code calls
> gen_helper_* functions, it is emitting generated code which will
> later call the relevant helper at runtime.

Random musing: I wonder how easy it would be to emit the helper function
name in the out_asm dump?

>
> thanks
> -- PMM


-- 
Alex Bennée



Re: [Qemu-devel] [PATCH v3 2/5] target-i386/kvm: Hyper-V SynIC MSR's support

2015-11-11 Thread Paolo Bonzini


On 11/11/2015 11:18, Andrey Smetanin wrote:
> This patch does Hyper-V Synthetic interrupt
> controller(Hyper-V SynIC) MSR's support and
> migration. Hyper-V SynIC is enabled by cpu's
> 'hv-synic' option.
> 
> This patch does not allow cpu creation if
> 'hv-synic' option specified but kernel
> doesn't support Hyper-V SynIC.
> 
> Changes v3:
> * removed 'msr_hv_synic_version' migration because
> it's value always the same
> * moved SynIC msr's initialization into kvm_arch_init_vcpu
> 
> Signed-off-by: Andrey Smetanin 
> Reviewed-by: Roman Kagan 
> Signed-off-by: Denis V. Lunev 
> CC: Paolo Bonzini 
> CC: Richard Henderson 
> CC: Eduardo Habkost 
> CC: "Andreas Färber" 
> CC: Marcelo Tosatti 
> CC: Roman Kagan 
> CC: Denis V. Lunev 
> CC: k...@vger.kernel.org

Thanks, pushed to uq/hyperv.  The new kernel patches work with APICv,
and I'll push them as soon as the merge window ends to kvm/queue.

Paolo



Re: [Qemu-devel] [PATCH v2 0/8] Add system_powerdown support on ARM for ACPI and DT

2015-11-11 Thread Peter Maydell
On 11 November 2015 at 01:29, Shannon Zhao  wrote:
> On 2015/11/11 4:56, Wei Huang wrote:
>> I found this was caused by the change of "_HID" name for GPIO device. It
>> was changed from "LNRO0009" (v1) to "ARMH0061" (v2), which doesn't match
>> with my stock guest kernel PL061 driver. After changing the guest
>> kernel, it is working again. So:

> Thanks very much for your help. The reason why I change the _HID is
> based on the _HID 0f PL011 which is ARMH0011. About the _HID of ARM
> company's devices, I have to say that I didn't see which _HID they
> should be at any public place. I heard(maybe it's not correct) there is
> a _HID list of ARM devices. If so, I think ARM should publish them in
> public, otherwise the only thing we can do is to guess or refer to
> existing _HID.

Please confirm for definite the right _HID values; don't guess
them. If you say you don't know the right HID values and mark
a patchset as RFC we can go and try to find out the right
answers. If you just put guesses into a patchset we could
easily end up committing the patch with the wrong info...

thanks
-- PMM



Re: [Qemu-devel] [PATCH v2 2/5] target-i386/kvm: Hyper-V SynIC MSR's support

2015-11-11 Thread Paolo Bonzini


On 11/11/2015 10:25, Andrey Smetanin wrote:
> In this case I'll remove migration of msr_hv_synic_version and make
> first time initialization inside  kvm_arch_init_vcpu() - inside section
> where SynIC availability cpuid bit is set.

Thanks!

Paolo



Re: [Qemu-devel] ARM NEON function call tracing

2015-11-11 Thread Peter Maydell
On 11 November 2015 at 07:51, Junaid Shuja  wrote:
> Hi,
> I am working on ARM/NEON instructions. I want to know which neon helper
> function corresponds to the neon instructions. As a test case, I have a
> source file with loads of vadd.i32 instructions. I want to trace which neon
> helper functions is called. I used a very crude approach: printf in
> neon_add_u16 funtion and compiled source again. But no printf showed on
> program execution. I need help regarding tracing of neon helpers.

Integer addition is a simple operation so we can do it directly
in the generated code; we don't need a helper for it, even as a
Neon instruction. Generally we only have helper functions for
operations that are too complicated to do directly inline.
So there isn't a simple "one neon instruction, one helper function"
mapping. Where we do have a helper function, the helper
may work on one "lane" of Neon data (meaning it gets called
more than once for each instruction) or it may work on several
lanes at once.

To find out how we handle a particular Neon instruction, you need
to look at disas_neon_data_insn and see what it does with the
insn (it may be easiest to do this by putting a breakpoint on
it and stepping through with a debugger). Where this code calls
gen_helper_* functions, it is emitting generated code which will
later call the relevant helper at runtime.

thanks
-- PMM



[Qemu-devel] [PATCH v3 2/5] target-i386/kvm: Hyper-V SynIC MSR's support

2015-11-11 Thread Andrey Smetanin
This patch does Hyper-V Synthetic interrupt
controller(Hyper-V SynIC) MSR's support and
migration. Hyper-V SynIC is enabled by cpu's
'hv-synic' option.

This patch does not allow cpu creation if
'hv-synic' option specified but kernel
doesn't support Hyper-V SynIC.

Changes v3:
* removed 'msr_hv_synic_version' migration because
it's value always the same
* moved SynIC msr's initialization into kvm_arch_init_vcpu

Signed-off-by: Andrey Smetanin 
Reviewed-by: Roman Kagan 
Signed-off-by: Denis V. Lunev 
CC: Paolo Bonzini 
CC: Richard Henderson 
CC: Eduardo Habkost 
CC: "Andreas Färber" 
CC: Marcelo Tosatti 
CC: Roman Kagan 
CC: Denis V. Lunev 
CC: k...@vger.kernel.org

---
 target-i386/cpu-qom.h |  1 +
 target-i386/cpu.c |  1 +
 target-i386/cpu.h |  5 
 target-i386/kvm.c | 66 ++-
 target-i386/machine.c | 37 +
 5 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index e3bfe9d..7ea5b34 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -94,6 +94,7 @@ typedef struct X86CPU {
 bool hyperv_reset;
 bool hyperv_vpindex;
 bool hyperv_runtime;
+bool hyperv_synic;
 bool check_cpuid;
 bool enforce_cpuid;
 bool expose_kvm;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e5f1c5b..1462e19 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -3142,6 +3142,7 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_BOOL("hv-reset", X86CPU, hyperv_reset, false),
 DEFINE_PROP_BOOL("hv-vpindex", X86CPU, hyperv_vpindex, false),
 DEFINE_PROP_BOOL("hv-runtime", X86CPU, hyperv_runtime, false),
+DEFINE_PROP_BOOL("hv-synic", X86CPU, hyperv_synic, false),
 DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
 DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
 DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index fc4a605..8cf33df 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -918,6 +918,11 @@ typedef struct CPUX86State {
 uint64_t msr_hv_tsc;
 uint64_t msr_hv_crash_params[HV_X64_MSR_CRASH_PARAMS];
 uint64_t msr_hv_runtime;
+uint64_t msr_hv_synic_control;
+uint64_t msr_hv_synic_version;
+uint64_t msr_hv_synic_evt_page;
+uint64_t msr_hv_synic_msg_page;
+uint64_t msr_hv_synic_sint[HV_SYNIC_SINT_COUNT];
 
 /* exception/interrupt handling */
 int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 2a9953b..3f2ea90 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -86,6 +86,7 @@ static bool has_msr_hv_crash;
 static bool has_msr_hv_reset;
 static bool has_msr_hv_vpindex;
 static bool has_msr_hv_runtime;
+static bool has_msr_hv_synic;
 static bool has_msr_mtrr;
 static bool has_msr_xss;
 
@@ -521,7 +522,8 @@ static bool hyperv_enabled(X86CPU *cpu)
 cpu->hyperv_crash ||
 cpu->hyperv_reset ||
 cpu->hyperv_vpindex ||
-cpu->hyperv_runtime);
+cpu->hyperv_runtime ||
+cpu->hyperv_synic);
 }
 
 static Error *invtsc_mig_blocker;
@@ -610,6 +612,21 @@ int kvm_arch_init_vcpu(CPUState *cs)
 if (cpu->hyperv_runtime && has_msr_hv_runtime) {
 c->eax |= HV_X64_MSR_VP_RUNTIME_AVAILABLE;
 }
+if (cpu->hyperv_synic) {
+int sint;
+
+if (!has_msr_hv_synic ||
+kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_SYNIC, 0)) {
+fprintf(stderr, "Hyper-V SynIC is not supported by kernel\n");
+return -ENOSYS;
+}
+
+c->eax |= HV_X64_MSR_SYNIC_AVAILABLE;
+env->msr_hv_synic_version = HV_SYNIC_VERSION_1;
+for (sint = 0; sint < ARRAY_SIZE(env->msr_hv_synic_sint); sint++) {
+env->msr_hv_synic_sint[sint] = HV_SYNIC_SINT_MASKED;
+}
+}
 c = _data.entries[cpuid_i++];
 c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
 if (cpu->hyperv_relaxed_timing) {
@@ -950,6 +967,10 @@ static int kvm_get_supported_msrs(KVMState *s)
 has_msr_hv_runtime = true;
 continue;
 }
+if (kvm_msr_list->indices[i] == HV_X64_MSR_SCONTROL) {
+has_msr_hv_synic = true;
+continue;
+}
 }
 }
 
@@ -1511,6 +1532,23 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_set([n++], HV_X64_MSR_VP_RUNTIME,
   env->msr_hv_runtime);
 }
+if (cpu->hyperv_synic) {
+int j;
+
+kvm_msr_entry_set([n++], HV_X64_MSR_SCONTROL,
+  

[Qemu-devel] ARM NEON function call tracing

2015-11-11 Thread Junaid Shuja
Hi,
I am working on ARM/NEON instructions. I want to know which neon helper
function corresponds to the neon instructions. As a test case, I have a
source file with loads of vadd.i32 instructions. I want to trace which neon
helper functions is called. I used a very crude approach: printf in
neon_add_u16 funtion and compiled source again. But no printf showed on
program execution. I need help regarding tracing of neon helpers.

-- 
Junaid Shuja
WHA130039
PhD Student, FSKTM
University of Malaya


Re: [Qemu-devel] [PULL 04/05] seccomp: add setuid, setgid, chroot and setgroups to whitelist

2015-11-11 Thread Eduardo Otubo
On Mon, Nov 02, 2015 at 08=51=26AM +0100, Paolo Bonzini wrote:
> 
> 
> On 30/10/2015 14:44, Eduardo Otubo wrote:
> > From: Namsun Ch'o 
> > 
> > The seccomp sandbox doesn't whitelist setuid, setgid, or setgroups, which 
> > are
> > needed for -runas to work. It also doesn't whitelist chroot, which is needed
> > for the -chroot option. Unfortunately, QEMU enables seccomp before it drops
> > privileges or chroots, so without these whitelisted, -runas and -chroot 
> > cause
> > QEMU to be killed with -sandbox on. This patch adds those syscalls.
> 
> I think this patch should not be applied, because it completely defeats
> the purpose of the sandbox.  With these syscalls whitelisted, -runas and
> -chroot have absolutely no effect against an attacker, even with
> -sandbox on.
> 

Also, Namsun's emails are bouncing back. Don't know if it's worth to
merge them with no valid author's contact.

-- 
Eduardo Otubo
ProfitBricks GmbH


signature.asc
Description: Digital signature


Re: [Qemu-devel] [PATCH v2 7/8] hw/arm/virt: Add QEMU powerdown notifier and hook it to GPIO Pin 3

2015-11-11 Thread Peter Maydell
On 11 November 2015 at 06:57, Wei Huang  wrote:
>
>
> On 10/29/2015 09:27 AM, Shannon Zhao wrote:
>> Currently mach-virt model doesn't support powerdown request. Guest VM
>> doesn't react to system_powerdown from monitor console (or QMP) because
>> there is no communication mechanism for such requests. This patch registers
>> GPIO Pin 3 with powerdown notification. So guest VM can receive notification
>> when such powerdown request is triggered.
>>
>> Signed-off-by: Wei Huang 
>> Signed-off-by: Shannon Zhao 
>> Signed-off-by: Shannon Zhao 
>> ---
>>  hw/arm/virt.c | 17 -
>>  1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 5c505a4..6f1b9d6 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -540,6 +540,18 @@ static void create_rtc(const VirtBoardInfo *vbi, 
>> qemu_irq *pic)
>>  g_free(nodename);
>>  }
>>
>> +static DeviceState *pl061_dev;
>> +static void virt_powerdown_req(Notifier *n, void *opaque)
>> +{
>> +/* use gpio Pin 3 for power button event */
>> +qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 0);
>> +qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1);
>
> This pull-down and then pull-up is for extra safety, right? It actually
> also works with only pull-up call. But I am OK with your design here;
> please add additional comments to explain the design.

It's a bit weird though. Usually you use qemu_pulse_irq,
which does a 0->1 then 1->0 transition, if the thing you're
signalling needs an edge. If the thing you're signalling
only cares about level then you just need to set the
level to 1.

thanks
-- PMM



Re: [Qemu-devel] [POC]colo-proxy in qemu

2015-11-11 Thread Dr. David Alan Gilbert
* Jason Wang (jasow...@redhat.com) wrote:
> 
> 
> On 11/10/2015 05:41 PM, Dr. David Alan Gilbert wrote:
> > * Jason Wang (jasow...@redhat.com) wrote:
> >>
> >> On 11/10/2015 01:26 PM, Tkid wrote:
> >>> Hi,all
> >>>
> >>> We are planning to reimplement colo proxy in userspace (Here is in
> >>> qemu) to
> >>> cache and compare net packets.This module is one of the important
> >>> components
> >>> of COLO project and now it is still in early stage, so any comments and
> >>> feedback are warmly welcomed,thanks in advance.
> >>>
> >>> ## Background
> >>> COLO FT/HA (COarse-grain LOck-stepping Virtual Machines for Non-stop
> >>> Service)
> >>> project is a high availability solution. Both Primary VM (PVM) and
> >>> Secondary VM
> >>> (SVM) run in parallel. They receive the same request from client, and
> >>> generate
> >>> responses in parallel too. If the response packets from PVM and SVM are
> >>> identical, they are released immediately. Otherwise, a VM checkpoint
> >>> (on demand)
> >>> is conducted.
> >>> Paper:
> >>> http://www.socc2013.org/home/program/a3-dong.pdf?attredirects=0
> >>> COLO on Xen:
> >>> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
> >>> COLO on Qemu/KVM:
> >>> http://wiki.qemu.org/Features/COLO
> >>>
> >>> By the needs of capturing response packets from PVM and SVM and
> >>> finding out
> >>> whether they are identical, we introduce a new module to qemu
> >>> networking called
> >>> colo-proxy.
> >>>
> >>> This document describes the design of the colo-proxy module
> >>>
> >>> ## Glossary
> >>>   PVM - Primary VM, which provides services to clients.
> >>>   SVM - Secondary VM, a hot standby and replication of PVM.
> >>>   PN - Primary Node, the host which PVM runs on
> >>>   SN - Secondary Node, the host which SVM runs on
> >>>
> >>> ## Our Idea ##
> >>>
> >>> COLO-Proxy
> >>> COLO-Proxy is a part of COLO,based on qemu net filter and it's a
> >>> plugin for
> >>> qemu net filter.the function keep SVM connect normal to PVM and compare
> >>> PVM's packets to SVM's packets.if difference,notify COLO do checkpoint.
> >>>
> >>> == Workflow ==
> >>>
> >>>
> >>> +--+  +--+
> >>> |PN|  |SN|
> >>> +---+ +---+
> >>> | +---+ | | +---+ |
> >>> | |   | | | |   | |
> >>> | |PVM| | | |SVM| |
> >>> | |   | | | |   | |
> >>> | +--+-^--+ | | +-^++ |
> >>> || || |   ||  |
> >>> || | ++ | | +---+ ||  |
> >>> || | |COLO| |(socket) | |COLO   | ||  |
> >>> || | | CheckPoint +-> CheckPoint| ||  |
> >>> || | || |  (6)| |   | ||  |
> >>> || | +-^--+ | | +---+ ||  |
> >>> || |   (5) || |   ||  |
> >>> || |   || |   ||  |
> >>> | +--v-+--+ | Forward(socket) | +-+v+ |
> >>> | |COLO Proxy  |  +---+(1)+->seq adjust(2)| | |
> >>> | |  +-+--+ | | +-+ | |
> >>> | |  | Compare(4) <---+(3)+-+ COLO Proxy| |
> >>> | +---+ | Forward(socket) | +---+ |
> >>> ++Qemu+-+ ++Qemu+-+
> >>>| ^
> >>>| |
> >>>| |
> >>>   +v-++
> >>>   |   |
> >>>   |  Client   |
> >>>   |   |
> >>>   +---+
> >>>
> >>>
> >>>
> >>>
> >>> (1)When PN receive client packets,PN COLO-Proxy copy and forward
> >>> packets to
> >>> SN COLO-Proxy.
> >>> (2)SN COLO-Proxy record PVM's packet inital seq & adjust client's ack,send
> >>> adjusted packets to SVM
> >>> (3)SN Qemu COLO-Proxy recieve SVM's packets and forward to PN Qemu
> >>> COLO-Proxy.
> >>> (4)PN Qemu COLO-Proxy enqueue SVM's packets and enqueue PVM's packets,then
> >>> compare PVM's packets data with SVM's packets data. If packets is
> >>> different, compare
> >>> module notify COLO CheckPoint module to do a checkpoint then send
> >>> PVM's packets to
> >>> client and drop SVM's packets, otherwise, just send PVM's packets to
> >>> client and
> >>> drop SVM's packets.
> >>> (5)notify COLO-Checkpoint module checkpoint is needed
> >>> (6)Do COLO-Checkpoint
> >>>
> >>> ### QEMU space TCP/IP stack(Based on SLIRP) ###
> >>> We need a QEMU space TCP/IP stack to help us to analysis packet. After
> >>> looking
> >>> into QEMU, we found that SLIRP
> >>>
> >>> 

Re: [Qemu-devel] [PATCH v2 0/8] Add system_powerdown support on ARM for ACPI and DT

2015-11-11 Thread Shannon Zhao


On 2015/11/11 16:36, Peter Maydell wrote:
> On 11 November 2015 at 01:29, Shannon Zhao  wrote:
>> On 2015/11/11 4:56, Wei Huang wrote:
>>> I found this was caused by the change of "_HID" name for GPIO device. It
>>> was changed from "LNRO0009" (v1) to "ARMH0061" (v2), which doesn't match
>>> with my stock guest kernel PL061 driver. After changing the guest
>>> kernel, it is working again. So:
> 
>> Thanks very much for your help. The reason why I change the _HID is
>> based on the _HID 0f PL011 which is ARMH0011. About the _HID of ARM
>> company's devices, I have to say that I didn't see which _HID they
>> should be at any public place. I heard(maybe it's not correct) there is
>> a _HID list of ARM devices. If so, I think ARM should publish them in
>> public, otherwise the only thing we can do is to guess or refer to
>> existing _HID.
> 
> Please confirm for definite the right _HID values; don't guess
> them. If you say you don't know the right HID values and mark
> a patchset as RFC we can go and try to find out the right
> answers. If you just put guesses into a patchset we could
> easily end up committing the patch with the wrong info...
> 
Of course I will try to find the right _HID and tried before. But what I
want to say is why ARM doesn't publish these _HIDs if there is really a
list( I don't think this is a secret). And if there is not a list, ARM
should create one since these devices belong to ARM.

Thanks,
-- 
Shannon




Re: [Qemu-devel] [PULL 0/2] VFIO updates 2015-11-10

2015-11-11 Thread Peter Maydell
On 10 November 2015 at 20:08, Alex Williamson
 wrote:
> The following changes since commit a1a88589dc982f9f8b6c717c2ac98dd71dd4353d:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20151110' into staging (2015-11-10 
> 13:55:07 +)
>
> are available in the git repository at:
>
>
>   git://github.com/awilliam/qemu-vfio.git tags/vfio-update-20151110.0
>
> for you to fetch changes up to bdd81addf4033ce26e6cd180b060f63095f3ded9:
>
>   vfio: Use g_new() & friends where that makes obvious sense (2015-11-10 
> 12:11:08 -0700)
>
> 
> VFIO updates 2015-11-10
>
>  - Make Windows happy with vfio-pci devices exposed on conventional
>PCI buses on q35 by hiding PCIe capability (Alex Williamson)
>  - Convert to g_new() where appropriate (Markus Armbruster)
>
> 
> Alex Williamson (1):
>   vfio/pci: Hide device PCIe capability on non-express buses for PCIe VMs
>
> Markus Armbruster (1):
>   vfio: Use g_new() & friends where that makes obvious sense

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH qemu v4] monitor/target-ppc: Define target_get_monitor_def

2015-11-11 Thread Paolo Bonzini


On 11/11/2015 03:27, David Gibson wrote:
> Meaning one which adds the hook to the monitor, and another which
> implements it for ppc?  Maybe.
> 
> I'd like to take this, but I'm not sure whether it's reasonable for
> the small generic monitor change to go through the ppc tree.  Peter,
> Paolo, opinion?

I'm not a monitor maintainer, but I think it's okay since there is
none. :)

We probably should replace target_monitor_defs() with an implementation
of target_get_monitor_def on all targets.  It can just pass a MonitorDef
array to a common function, i.e.

int lookup_monitor_def(MonitorDef *def, void *base, const char *name, uint64_t 
*pval)

static int target_get_monitor_def(CPUState *cs, const char *name, uint64_t 
*pval)
{
return lookup_monitor_def(monitor_defs, cs->env_ptr, name, pval);
}

I don't want you to do it now, but we should add it to the wiki
BiteSizedTasks so we don't forget.

Paolo



[Qemu-devel] [PATCH v13 13/13] vfio: add 'aer' property to expose aercap

2015-11-11 Thread Cao jin
From: Chen Fan 

add 'aer' property to let user able to decide whether expose
the aer capability. by default we should disable aer feature,
because it needs configuration restrictions.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index c593876..d2efbb0 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3069,6 +3069,8 @@ static Property vfio_pci_dev_properties[] = {
sub_vendor_id, PCI_ANY_ID),
 DEFINE_PROP_UINT32("x-pci-sub-device-id", VFIOPCIDevice,
sub_device_id, PCI_ANY_ID),
+DEFINE_PROP_BIT("aer", VFIOPCIDevice, features,
+VFIO_FEATURE_ENABLE_AER_BIT, false),
 /*
  * TODO - support passed fds... is this necessary?
  * DEFINE_PROP_STRING("vfiofd", VFIOPCIDevice, vfiofd_name),
-- 
1.9.3




[Qemu-devel] [PATCH v13 10/13] pci: add pci device pre-post reset callbacks for host bus reset

2015-11-11 Thread Cao jin
From: Chen Fan 

Particularly, For vfio devices, Once need to recovery devices
by bus reset such as AER, we always need to reset the host bus
to recovery the devices under the bus, so we need to add pci device
callbacks to specify to do host bus reset.

Signed-off-by: Chen Fan 
---
 hw/pci/pci.c | 18 ++
 hw/pci/pci_bridge.c  |  9 +
 hw/vfio/pci.c| 26 ++
 hw/vfio/pci.h|  2 ++
 include/hw/pci/pci.h |  7 +++
 5 files changed, 62 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index f6ca6ef..64fa2cc 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -247,6 +247,24 @@ static void pci_do_device_reset(PCIDevice *dev)
 msix_reset(dev);
 }
 
+void pci_device_pre_reset(PCIBus *bus, PCIDevice *dev, void *unused)
+{
+PCIDeviceClass *dc = PCI_DEVICE_GET_CLASS(dev);
+
+if (dc->pre_reset) {
+dc->pre_reset(dev);
+}
+}
+
+void pci_device_post_reset(PCIBus *bus, PCIDevice *dev, void *unused)
+{
+PCIDeviceClass *dc = PCI_DEVICE_GET_CLASS(dev);
+
+if (dc->post_reset) {
+dc->post_reset(dev);
+}
+}
+
 /*
  * This function is called on #RST and FLR.
  * FLR if PCI_EXP_DEVCTL_BCR_FLR is set
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 40c97b1..ddb76ab 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -267,8 +267,17 @@ void pci_bridge_write_config(PCIDevice *d,
 
 newctl = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
 if (~oldctl & newctl & PCI_BRIDGE_CTL_BUS_RESET) {
+/*
+ * Notify all vfio-pci devices under the bus
+ * should do physical bus reset.
+ */
+PCIBus *sec_bus = pci_bridge_get_sec_bus(s);
+pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
+pci_device_pre_reset, NULL);
 /* Trigger hot reset on 0->1 transition. */
 qbus_reset_all(>sec_bus.qbus);
+pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
+pci_device_post_reset, NULL);
 }
 }
 
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index e619998..90df393 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -39,6 +39,7 @@
 
 static void vfio_disable_interrupts(VFIOPCIDevice *vdev);
 static void vfio_mmap_set_enabled(VFIOPCIDevice *vdev, bool enabled);
+static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool single);
 
 /*
  * Disabling BAR mmaping can be slow, but toggling it around INTx can
@@ -1879,6 +1880,8 @@ static int vfio_check_host_bus_reset(VFIOPCIDevice *vdev)
 /* List all affected devices by bus reset */
 devices = >devices[0];
 
+vdev->single_depend_dev = (info->count == 1);
+
 /* Verify that we have all the groups required */
 for (i = 0; i < info->count; i++) {
 PCIHostDeviceAddress host;
@@ -2003,10 +2006,26 @@ static int vfio_check_bus_reset(NotifierWithReturn *n, 
void *opaque)
 return vfio_check_host_bus_reset(vdev);
 }
 
+static void vfio_aer_pre_reset(PCIDevice *pdev)
+{
+VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
+
+vdev->aer_reset = true;
+vfio_pci_hot_reset(vdev, vdev->single_depend_dev);
+}
+
+static void vfio_aer_post_reset(PCIDevice *pdev)
+{
+VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
+
+vdev->aer_reset = false;
+}
+
 static int vfio_setup_aer(VFIOPCIDevice *vdev, uint8_t cap_ver,
   int pos, uint16_t size)
 {
 PCIDevice *pdev = >pdev;
+PCIDeviceClass *dc = PCI_DEVICE_GET_CLASS(pdev);
 PCIDevice *dev_iter;
 uint8_t type;
 uint32_t errcap;
@@ -2060,6 +2079,9 @@ static int vfio_setup_aer(VFIOPCIDevice *vdev, uint8_t 
cap_ver,
 vdev->hotplug_notifier.notify = vfio_check_bus_reset;
 pci_bus_add_hotplug_notifier(pdev->bus, >hotplug_notifier);
 
+dc->pre_reset = vfio_aer_pre_reset;
+dc->post_reset = vfio_aer_post_reset;
+
 return 0;
 
 error:
@@ -2953,6 +2975,10 @@ static void vfio_pci_reset(DeviceState *dev)
 
 trace_vfio_pci_reset(vdev->vbasedev.name);
 
+if (vdev->aer_reset) {
+return;
+}
+
 vfio_pci_pre_reset(vdev);
 
 if (vdev->resetfn && !vdev->resetfn(vdev)) {
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index b385f07..1b89b83 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -144,6 +144,8 @@ typedef struct VFIOPCIDevice {
 bool no_kvm_msix;
 
 NotifierWithReturn hotplug_notifier;
+bool aer_reset;
+bool single_depend_dev;
 } VFIOPCIDevice;
 
 uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 379b6e1..6b1f2d4 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -105,6 +105,9 @@ typedef void PCIMapIORegionFunc(PCIDevice *pci_dev, int 
region_num,
 pcibus_t addr, pcibus_t size, int type);
 typedef void PCIUnregisterFunc(PCIDevice *pci_dev);
 
+typedef void PCIPreResetFunc(PCIDevice *pci_dev);

[Qemu-devel] [PATCH v13 11/13] pcie_aer: expose pcie_aer_msg() interface

2015-11-11 Thread Cao jin
From: Chen Fan 

For vfio device, we need to propagate the aer error to
Guest OS. we use the pcie_aer_msg() to send aer error
to guest.

Signed-off-by: Chen Fan 
---
 hw/pci/pcie_aer.c | 2 +-
 include/hw/pci/pcie_aer.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 45f351b..fbbd7d2 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -370,7 +370,7 @@ static void pcie_aer_msg_root_port(PCIDevice *dev, const 
PCIEAERMsg *msg)
  *
  * Walk up the bus tree from the device, propagate the error message.
  */
-static void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg)
+void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg)
 {
 uint8_t type;
 
diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
index 156acb0..c2ee4e2 100644
--- a/include/hw/pci/pcie_aer.h
+++ b/include/hw/pci/pcie_aer.h
@@ -102,5 +102,6 @@ void pcie_aer_root_write_config(PCIDevice *dev,
 
 /* error injection */
 int pcie_aer_inject_error(PCIDevice *dev, const PCIEAERErr *err);
+void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg);
 
 #endif /* QEMU_PCIE_AER_H */
-- 
1.9.3




[Qemu-devel] [PATCH v13 07/13] vfio: add aer support for vfio device

2015-11-11 Thread Cao jin
From: Chen Fan 

Calling pcie_aer_init to initilize aer related registers for
vfio device, then reload physical related registers to expose
device capability.

Signed-off-by: Chen Fan 
---
 hw/vfio/pci.c | 82 ---
 hw/vfio/pci.h |  3 +++
 2 files changed, 82 insertions(+), 3 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 4bc2b51..2d34edf 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1806,6 +1806,68 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t 
pos)
 return 0;
 }
 
+static int vfio_setup_aer(VFIOPCIDevice *vdev, uint8_t cap_ver,
+  int pos, uint16_t size)
+{
+PCIDevice *pdev = >pdev;
+PCIDevice *dev_iter;
+uint8_t type;
+uint32_t errcap;
+int ret;
+
+if (!(vdev->features & VFIO_FEATURE_ENABLE_AER)) {
+pcie_add_capability(pdev, PCI_EXT_CAP_ID_ERR,
+cap_ver, pos, size);
+return 0;
+}
+
+dev_iter = pci_bridge_get_device(pdev->bus);
+if (!dev_iter) {
+goto error;
+}
+
+while (dev_iter) {
+type = pcie_cap_get_type(dev_iter);
+if ((type != PCI_EXP_TYPE_ROOT_PORT &&
+ type != PCI_EXP_TYPE_UPSTREAM &&
+ type != PCI_EXP_TYPE_DOWNSTREAM)) {
+goto error;
+}
+
+if (!dev_iter->exp.aer_cap) {
+goto error;
+}
+
+dev_iter = pci_bridge_get_device(dev_iter->bus);
+}
+
+errcap = vfio_pci_read_config(pdev, pdev->exp.aer_cap + PCI_ERR_CAP, 4);
+/*
+ * The ability to record multiple headers is depending on
+ * the state of the Multiple Header Recording Capable bit and
+ * enabled by the Multiple Header Recording Enable bit.
+ */
+if ((errcap & PCI_ERR_CAP_MHRC) &&
+(errcap & PCI_ERR_CAP_MHRE)) {
+pdev->exp.aer_log.log_max = PCIE_AER_LOG_MAX_DEFAULT;
+} else {
+pdev->exp.aer_log.log_max = 0;
+}
+
+pcie_cap_deverr_init(pdev);
+ret = pcie_aer_init(pdev, pos, size);
+if (ret) {
+return ret;
+}
+
+return 0;
+
+error:
+error_report("vfio: Unable to enable AER for device %s, parent bus "
+ "does not support AER signaling", vdev->vbasedev.name);
+return -1;
+}
+
 static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
 {
 PCIDevice *pdev = >pdev;
@@ -1813,6 +1875,7 @@ static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
 uint16_t cap_id, next, size;
 uint8_t cap_ver;
 uint8_t *config;
+int ret = 0;
 
 /*
  * In order to avoid breaking config space, create a copy to
@@ -1834,16 +1897,29 @@ static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
  */
 size = vfio_ext_cap_max_size(config, next);
 
-pcie_add_capability(pdev, cap_id, cap_ver, next, size);
-pci_set_long(dev->config + next, PCI_EXT_CAP(cap_id, cap_ver, 0));
+switch (cap_id) {
+case PCI_EXT_CAP_ID_ERR:
+ret = vfio_setup_aer(vdev, cap_ver, next, size);
+break;
+default:
+pcie_add_capability(pdev, cap_id, cap_ver, next, size);
+break;
+}
+
+if (ret) {
+goto out;
+}
+
+pci_set_long(pdev->config + next, PCI_EXT_CAP(cap_id, cap_ver, 0));
 
 /* Use emulated next pointer to allow dropping extended caps */
 pci_long_test_and_set_mask(vdev->emulated_config_bits + next,
PCI_EXT_CAP_NEXT_MASK);
 }
 
+out:
 g_free(config);
-return 0;
+return ret;
 }
 
 static int vfio_add_capabilities(VFIOPCIDevice *vdev)
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index f004d52..48c1f69 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -15,6 +15,7 @@
 #include "qemu-common.h"
 #include "exec/memory.h"
 #include "hw/pci/pci.h"
+#include "hw/pci/pci_bridge.h"
 #include "hw/vfio/vfio-common.h"
 #include "qemu/event_notifier.h"
 #include "qemu/queue.h"
@@ -127,6 +128,8 @@ typedef struct VFIOPCIDevice {
 #define VFIO_FEATURE_ENABLE_VGA (1 << VFIO_FEATURE_ENABLE_VGA_BIT)
 #define VFIO_FEATURE_ENABLE_REQ_BIT 1
 #define VFIO_FEATURE_ENABLE_REQ (1 << VFIO_FEATURE_ENABLE_REQ_BIT)
+#define VFIO_FEATURE_ENABLE_AER_BIT 2
+#define VFIO_FEATURE_ENABLE_AER (1 << VFIO_FEATURE_ENABLE_AER_BIT)
 int32_t bootindex;
 uint8_t pm_cap;
 bool has_vga;
-- 
1.9.3




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

2015-11-11 Thread Peter Maydell
On 11 November 2015 at 07:34, Stefan Hajnoczi  wrote:
> v2:
>  * Fixed missing log.py file when merging "trace: convert stderr backend to 
> log" [Peter]
>
> The following changes since commit a77067f6ac9b17beefea506ce5f514072fe3fcf4:
>
>   Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20151110' 
> into staging (2015-11-10 17:49:39 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/tracing-pull-request
>
> for you to fetch changes up to 8b7034c1e0bdce2c3dd38e8445d2040449afa15c:
>
>   log: add "-d trace:PATTERN" (2015-11-11 06:52:32 +)
>

Fails to build on all platforms :-(

/home/petmay01/linaro/qemu-for-merges/target-arm/translate-a64.c: In
function ‘gen_intermediate_code_a64’:
/home/petmay01/linaro/qemu-for-merges/target-arm/translate-a64.c:11229:9:
error: implicit declaration of function ‘lookup_symbol’
[-Werror=implicit-function-declaration]
 qemu_log("IN: %s\n", lookup_symbol(pc_start));
 ^
/home/petmay01/linaro/qemu-for-merges/target-arm/translate-a64.c:11229:9:
error: nested extern declaration of ‘lookup_symbol’
[-Werror=nested-externs]
/home/petmay01/linaro/qemu-for-merges/target-arm/translate-a64.c:11229:9:
error: format ‘%s’ expects argument of type ‘char *’, but argument 2
has type ‘int’ [-Werror=format=]
/home/petmay01/linaro/qemu-for-merges/target-arm/translate-a64.c:11230:9:
error: implicit declaration of function ‘log_target_disas’
[-Werror=implicit-function-declaration]
 log_target_disas(cs, pc_start, dc->pc - pc_start,
 ^
/home/petmay01/linaro/qemu-for-merges/target-arm/translate-a64.c:11230:9:
error: nested extern declaration of ‘log_target_disas’
[-Werror=nested-externs]
cc1: all warnings being treated as errors

thanks
-- PMM



Re: [Qemu-devel] [PATCH for-2.5 00/15] s390x patches for 2.5

2015-11-11 Thread Christian Borntraeger
Am 09.11.2015 um 16:56 schrieb Cornelia Huck:
> Hopefully last big batch of s390x patches, including:
> - bugfixes for LE host and for pci translation
> - MAINTAINERS update
> - hugetlbfs enablement (kernel patches pending)
> - boot from El Torito iso images on virtio-blk
>   (boot from scsi pending)
> - cleanup in the ipl device code
> 
> There's also a helper function for resetting busless devices in the
> qdev core in there.
> 
> Christian Borntraeger (1):
>   s390: deprecate the non-ccw machine in 2.5
> 
> Cornelia Huck (4):
>   s390x/css: sense data endianness
>   MAINTAINERS: update s390 file patterns
>   MAINTAINERS: update virtio-ccw/s390 git tree
>   pc-bios/s390-ccw: rebuild image
> 
> David Hildenbrand (3):
>   qdev: provide qdev_reset_all_fn()
>   s390x/ipl: clean up qom definitions and turn into TYPE_DEVICE
>   s390x/ipl: switch error reporting to error_setg
> 
> Dominik Dingel (2):
>   s390x: switch to memory_region_allocate_system_memory
>   s390x/kvm: don't enable CMMA when hugetlbfs will be used
> 
> Maxim Samoylov (4):
>   pc-bios/s390-ccw: Always adjust virtio sector count
>   pc-bios/s390-ccw: ISO-9660 El Torito boot implementation
>   pc-bios/s390-ccw: El Torito s390x boot entry check
>   pc-bios/s390-ccw: El Torito 16-bit boot image size field workaround
> 
> Yi Min Zhao (1):
>   s390x/pci : fix up s390 pci iommu translation function
> 
>  MAINTAINERS|  20 +++--
>  hw/core/qdev.c |   5 ++
>  hw/s390x/css.c |   6 ++
>  hw/s390x/ipl.c |  68 ---
>  hw/s390x/ipl.h |  25 ++
>  hw/s390x/s390-pci-bus.c|   8 +-
>  hw/s390x/s390-virtio-ccw.c |   3 +-
>  hw/s390x/s390-virtio.c |  16 ++--
>  include/hw/qdev-core.h |   1 +
>  pc-bios/s390-ccw.img   | Bin 13856 -> 17760 bytes
>  pc-bios/s390-ccw/bootmap.c | 206 
> +
>  pc-bios/s390-ccw/bootmap.h | 206 
> +
>  pc-bios/s390-ccw/virtio.c  |   7 ++
>  pc-bios/s390-ccw/virtio.h  |   8 +-
>  target-s390x/kvm.c |   4 +-
>  15 files changed, 506 insertions(+), 77 deletions(-)
> 

Series looks good for 2.5.




[Qemu-devel] [PATCH 1/3] Finish non-postcopiable iterative devices before package

2015-11-11 Thread Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" 

Where we have iterable, but non-postcopiable devices (e.g. htab
or block migration), complete them before forming the 'package'
but with the CPUs stopped.  This stops them filling up the package.

Signed-off-by: Dr. David Alan Gilbert 
---
 include/sysemu/sysemu.h |  2 +-
 migration/migration.c   | 10 --
 migration/savevm.c  | 10 --
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index f992494..3bb8897 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -112,7 +112,7 @@ void qemu_savevm_state_header(QEMUFile *f);
 int qemu_savevm_state_iterate(QEMUFile *f, bool postcopy);
 void qemu_savevm_state_cleanup(void);
 void qemu_savevm_state_complete_postcopy(QEMUFile *f);
-void qemu_savevm_state_complete_precopy(QEMUFile *f);
+void qemu_savevm_state_complete_precopy(QEMUFile *f, bool iterable_only);
 void qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size,
uint64_t *res_non_postcopiable,
uint64_t *res_postcopiable);
diff --git a/migration/migration.c b/migration/migration.c
index c5c977e..5df490a 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1429,6 +1429,12 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
 }
 
 /*
+ * Cause any non-postcopiable, but iterative devices to
+ * send out their final data.
+ */
+qemu_savevm_state_complete_precopy(ms->file, true);
+
+/*
  * in Finish migrate and with the io-lock held everything should
  * be quiet, but we've potentially still got dirty pages and we
  * need to tell the destination to throw any pages it's already received
@@ -1471,7 +1477,7 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
  */
 qemu_savevm_send_postcopy_listen(fb);
 
-qemu_savevm_state_complete_precopy(fb);
+qemu_savevm_state_complete_precopy(fb, false);
 qemu_savevm_send_ping(fb, 3);
 
 qemu_savevm_send_postcopy_run(fb);
@@ -1538,7 +1544,7 @@ static void migration_completion(MigrationState *s, int 
current_active_state,
 ret = vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
 if (ret >= 0) {
 qemu_file_set_rate_limit(s->file, INT64_MAX);
-qemu_savevm_state_complete_precopy(s->file);
+qemu_savevm_state_complete_precopy(s->file, false);
 }
 }
 qemu_mutex_unlock_iothread();
diff --git a/migration/savevm.c b/migration/savevm.c
index be52314..d90e228 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1026,7 +1026,7 @@ void qemu_savevm_state_complete_postcopy(QEMUFile *f)
 qemu_fflush(f);
 }
 
-void qemu_savevm_state_complete_precopy(QEMUFile *f)
+void qemu_savevm_state_complete_precopy(QEMUFile *f, bool iterable_only)
 {
 QJSON *vmdesc;
 int vmdesc_len;
@@ -1041,9 +1041,11 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f)
 QTAILQ_FOREACH(se, _state.handlers, entry) {
 if (!se->ops ||
 (in_postcopy && se->ops->save_live_complete_postcopy) ||
+(in_postcopy && !iterable_only) ||
 !se->ops->save_live_complete_precopy) {
 continue;
 }
+
 if (se->ops && se->ops->is_active) {
 if (!se->ops->is_active(se->opaque)) {
 continue;
@@ -1062,6 +1064,10 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f)
 }
 }
 
+if (iterable_only) {
+return;
+}
+
 vmdesc = qjson_new();
 json_prop_int(vmdesc, "page_size", TARGET_PAGE_SIZE);
 json_start_array(vmdesc, "devices");
@@ -1176,7 +1182,7 @@ static int qemu_savevm_state(QEMUFile *f, Error **errp)
 
 ret = qemu_file_get_error(f);
 if (ret == 0) {
-qemu_savevm_state_complete_precopy(f);
+qemu_savevm_state_complete_precopy(f, false);
 ret = qemu_file_get_error(f);
 }
 qemu_savevm_state_cleanup();
-- 
2.5.0




[Qemu-devel] [PATCH 3/3] migrate-start-postcopy: Improve text

2015-11-11 Thread Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" 

Improve the text in both the qapi-schema and hmp help to point out
you need to set the postcopy-ram capability prior to issuing
migrate-start-postcopy.

Signed-off-by: Dr. David Alan Gilbert 
---
 hmp-commands.hx  | 4 +++-
 qapi-schema.json | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 8939b98..3316ee3 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1011,7 +1011,9 @@ ETEXI
 .name   = "migrate_start_postcopy",
 .args_type  = "",
 .params = "",
-.help   = "Switch migration to postcopy mode",
+.help   = "Switch current migration to postcopy mode; "
+  "the x-postcopy-ram capability must be set before"
+  " issuing this command.",
 .mhandler.cmd = hmp_migrate_start_postcopy,
 },
 
diff --git a/qapi-schema.json b/qapi-schema.json
index 8c3a42a..2d1845a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -706,7 +706,8 @@
 ##
 # @migrate-start-postcopy
 #
-# Switch migration to postcopy mode
+# Switch current migration to postcopy mode; the x-postcopy-ram capability
+# must be set before issuing this command.
 #
 # Since: 2.5
 { 'command': 'migrate-start-postcopy' }
-- 
2.5.0




Re: [Qemu-devel] [PATCH v11 18/28] qerror: more error_setg() usage

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) have snuck in
> since c6bd8c706.  Nuke them.

Doesn't really belong to this series, but that's okay.

> Signed-off-by: Eric Blake 
>
> ---
> v11: new patch
> ---
>  block.c   |  3 +--
>  docs/writing-qmp-commands.txt | 20 +---
>  hw/i386/pc.c  |  2 +-
>  hw/net/rocker/rocker.c|  6 ++
>  hw/net/rocker/rocker_of_dpa.c | 12 
>  qom/object.c  |  4 ++--
>  6 files changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/block.c b/block.c
> index e9f40dc..53a978a 100644
> --- a/block.c
> +++ b/block.c
> @@ -1795,8 +1795,7 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, 
> BlockReopenQueue *queue,
>
>  ret = bdrv_flush(reopen_state->bs);
>  if (ret) {
> -error_set(errp, ERROR_CLASS_GENERIC_ERROR, "Error (%s) flushing 
> drive",
> -  strerror(-ret));
> +error_setg_errno(errp, -ret, "Error flushing drive");
>  goto error;
>  }
>
> diff --git a/docs/writing-qmp-commands.txt b/docs/writing-qmp-commands.txt
> index 8647cac..59aa77a 100644
> --- a/docs/writing-qmp-commands.txt
> +++ b/docs/writing-qmp-commands.txt
> @@ -210,7 +210,7 @@ if you don't see these strings, then something went wrong.
>  === Errors ===
>
>  QMP commands should use the error interface exported by the error.h header
> -file. Basically, errors are set by calling the error_set() function.
> +file. Basically, most errors are set by calling the error_setg() function.
>
>  Let's say we don't accept the string "message" to contain the word "love". If
>  it does contain it, we want the "hello-world" command to return an error:
> @@ -219,8 +219,7 @@ void qmp_hello_world(bool has_message, const char 
> *message, Error **errp)
>  {
>  if (has_message) {
>  if (strstr(message, "love")) {
> -error_set(errp, ERROR_CLASS_GENERIC_ERROR,
> -  "the word 'love' is not allowed");
> +error_setg(errp, "the word 'love' is not allowed");
>  return;
>  }
>  printf("%s\n", message);
> @@ -229,10 +228,8 @@ void qmp_hello_world(bool has_message, const char 
> *message, Error **errp)
>  }
>  }
>
> -The first argument to the error_set() function is the Error pointer to 
> pointer,
> -which is passed to all QMP functions. The second argument is a ErrorClass
> -value, which should be ERROR_CLASS_GENERIC_ERROR most of the time (more
> -details about error classes are given below). The third argument is a human
> +The first argument to the error_setg() function is the Error pointer
> +to pointer, which is passed to all QMP functions. The next argument is a 
> human
>  description of the error, this is a free-form printf-like string.
>
>  Let's test the example above. Build qemu, run it as defined in the "Testing"
> @@ -249,8 +246,9 @@ The QMP server's response should be:
>  }
>  }
>
> -As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR. There
> -are two exceptions to this rule:
> +As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR
> +(done by default when using error_setg()). There are two exceptions to
> +this rule:
>
>   1. A non-generic ErrorClass value exists* for the failure you want to report
>  (eg. DeviceNotFound)
> @@ -259,8 +257,8 @@ are two exceptions to this rule:
>  want to report, hence you have to add a new ErrorClass value so that they
>  can check for it
>
> -If the failure you want to report doesn't fall in one of the two cases above,
> -just report ERROR_CLASS_GENERIC_ERROR.
> +If the failure you want to report falls into one of the two cases above,
> +use error_set() with a second argument of an ErrorClass value.
>
>   * All existing ErrorClass values are defined in the qapi-schema.json file
>

Thanks a lot for this doc update!

> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 0cb8afd..dfb57a8 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1795,7 +1795,7 @@ static void pc_machine_set_max_ram_below_4g(Object 
> *obj, Visitor *v,
>  return;
>  }
>  if (value > (1ULL << 32)) {
> -error_set(, ERROR_CLASS_GENERIC_ERROR,
> +error_setg(,
>"Machine option 'max-ram-below-4g=%"PRIu64
>"' expects size less than or equal to 4G", value);

Indentation is now off.  Can tidy up in my tree.

>  error_propagate(errp, error);
[Rest snipped, it looks good]



Re: [Qemu-devel] [PATCH v13 10/13] pci: add pci device pre-post reset callbacks for host bus reset

2015-11-11 Thread Michael S. Tsirkin
On Wed, Nov 11, 2015 at 06:34:28PM +0800, Cao jin wrote:
> From: Chen Fan 
> 
> Particularly, For vfio devices, Once need to recovery devices
> by bus reset such as AER, we always need to reset the host bus
> to recovery the devices under the bus, so we need to add pci device
> callbacks to specify to do host bus reset.
> 
> Signed-off-by: Chen Fan 


Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/pci/pci.c | 18 ++
>  hw/pci/pci_bridge.c  |  9 +
>  hw/vfio/pci.c| 26 ++
>  hw/vfio/pci.h|  2 ++
>  include/hw/pci/pci.h |  7 +++
>  5 files changed, 62 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index f6ca6ef..64fa2cc 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -247,6 +247,24 @@ static void pci_do_device_reset(PCIDevice *dev)
>  msix_reset(dev);
>  }
>  
> +void pci_device_pre_reset(PCIBus *bus, PCIDevice *dev, void *unused)
> +{
> +PCIDeviceClass *dc = PCI_DEVICE_GET_CLASS(dev);
> +
> +if (dc->pre_reset) {
> +dc->pre_reset(dev);
> +}
> +}
> +
> +void pci_device_post_reset(PCIBus *bus, PCIDevice *dev, void *unused)
> +{
> +PCIDeviceClass *dc = PCI_DEVICE_GET_CLASS(dev);
> +
> +if (dc->post_reset) {
> +dc->post_reset(dev);
> +}
> +}
> +
>  /*
>   * This function is called on #RST and FLR.
>   * FLR if PCI_EXP_DEVCTL_BCR_FLR is set
> diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
> index 40c97b1..ddb76ab 100644
> --- a/hw/pci/pci_bridge.c
> +++ b/hw/pci/pci_bridge.c
> @@ -267,8 +267,17 @@ void pci_bridge_write_config(PCIDevice *d,
>  
>  newctl = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
>  if (~oldctl & newctl & PCI_BRIDGE_CTL_BUS_RESET) {
> +/*
> + * Notify all vfio-pci devices under the bus
> + * should do physical bus reset.
> + */
> +PCIBus *sec_bus = pci_bridge_get_sec_bus(s);
> +pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
> +pci_device_pre_reset, NULL);
>  /* Trigger hot reset on 0->1 transition. */
>  qbus_reset_all(>sec_bus.qbus);
> +pci_for_each_device(sec_bus, pci_bus_num(sec_bus),
> +pci_device_post_reset, NULL);
>  }
>  }
>  
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index e619998..90df393 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -39,6 +39,7 @@
>  
>  static void vfio_disable_interrupts(VFIOPCIDevice *vdev);
>  static void vfio_mmap_set_enabled(VFIOPCIDevice *vdev, bool enabled);
> +static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool single);
>  
>  /*
>   * Disabling BAR mmaping can be slow, but toggling it around INTx can
> @@ -1879,6 +1880,8 @@ static int vfio_check_host_bus_reset(VFIOPCIDevice 
> *vdev)
>  /* List all affected devices by bus reset */
>  devices = >devices[0];
>  
> +vdev->single_depend_dev = (info->count == 1);
> +
>  /* Verify that we have all the groups required */
>  for (i = 0; i < info->count; i++) {
>  PCIHostDeviceAddress host;
> @@ -2003,10 +2006,26 @@ static int vfio_check_bus_reset(NotifierWithReturn 
> *n, void *opaque)
>  return vfio_check_host_bus_reset(vdev);
>  }
>  
> +static void vfio_aer_pre_reset(PCIDevice *pdev)
> +{
> +VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
> +
> +vdev->aer_reset = true;
> +vfio_pci_hot_reset(vdev, vdev->single_depend_dev);
> +}
> +
> +static void vfio_aer_post_reset(PCIDevice *pdev)
> +{
> +VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev);
> +
> +vdev->aer_reset = false;
> +}
> +
>  static int vfio_setup_aer(VFIOPCIDevice *vdev, uint8_t cap_ver,
>int pos, uint16_t size)
>  {
>  PCIDevice *pdev = >pdev;
> +PCIDeviceClass *dc = PCI_DEVICE_GET_CLASS(pdev);
>  PCIDevice *dev_iter;
>  uint8_t type;
>  uint32_t errcap;
> @@ -2060,6 +2079,9 @@ static int vfio_setup_aer(VFIOPCIDevice *vdev, uint8_t 
> cap_ver,
>  vdev->hotplug_notifier.notify = vfio_check_bus_reset;
>  pci_bus_add_hotplug_notifier(pdev->bus, >hotplug_notifier);
>  
> +dc->pre_reset = vfio_aer_pre_reset;
> +dc->post_reset = vfio_aer_post_reset;
> +
>  return 0;
>  
>  error:
> @@ -2953,6 +2975,10 @@ static void vfio_pci_reset(DeviceState *dev)
>  
>  trace_vfio_pci_reset(vdev->vbasedev.name);
>  
> +if (vdev->aer_reset) {
> +return;
> +}
> +
>  vfio_pci_pre_reset(vdev);
>  
>  if (vdev->resetfn && !vdev->resetfn(vdev)) {
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index b385f07..1b89b83 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -144,6 +144,8 @@ typedef struct VFIOPCIDevice {
>  bool no_kvm_msix;
>  
>  NotifierWithReturn hotplug_notifier;
> +bool aer_reset;
> +bool single_depend_dev;
>  } VFIOPCIDevice;
>  
>  uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int 

[Qemu-devel] [PULL for-2.5 01/15] s390x/css: sense data endianness

2015-11-11 Thread Cornelia Huck
We keep the device's sense data in a byte array (following the
architecture), but the ecws are an array of 32 bit values. If we
just blindly copy the values, the sense data will change from
de-facto BE data to de-facto cpu-endian data, which means we end
up doing an incorrect conversion on LE hosts.

Let's just explicitly convert to cpu-endianness while assembling
the irb.

Reported-by: Andy Lutomirski 
Tested-by: Andy Lutomirski 
Signed-off-by: Cornelia Huck 
Reviewed-by: Christian Borntraeger 
---
 hw/s390x/css.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index c033612..19851ce 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -892,8 +892,14 @@ int css_do_tsch_get_irb(SubchDev *sch, IRB *target_irb, 
int *irb_len)
 /* If a unit check is pending, copy sense data. */
 if ((s->dstat & SCSW_DSTAT_UNIT_CHECK) &&
 (p->chars & PMCW_CHARS_MASK_CSENSE)) {
+int i;
+
 irb.scsw.flags |= SCSW_FLAGS_MASK_ESWF | SCSW_FLAGS_MASK_ECTL;
+/* Attention: sense_data is already BE! */
 memcpy(irb.ecw, sch->sense_data, sizeof(sch->sense_data));
+for (i = 0; i < ARRAY_SIZE(irb.ecw); i++) {
+irb.ecw[i] = be32_to_cpu(irb.ecw[i]);
+}
 irb.esw[1] = 0x0100 | (sizeof(sch->sense_data) << 8);
 }
 }
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 04/15] MAINTAINERS: update virtio-ccw/s390 git tree

2015-11-11 Thread Cornelia Huck
Let's reference the git branch I actually use, and add Christian's
git tree.

Acked-by: Christian Borntraeger 
Signed-off-by: Cornelia Huck 
---
 MAINTAINERS | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9585a8b..9e1fa72 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -243,6 +243,8 @@ F: hw/intc/s390_flic.c
 F: hw/intc/s390_flic_kvm.c
 F: include/hw/s390x/s390_flic.h
 F: gdb-xml/s390*.xml
+T: git git://github.com/cohuck/qemu.git s390-next
+T: git git://github.com/borntraeger/qemu.git s390-next
 
 X86
 M: Paolo Bonzini 
@@ -645,7 +647,8 @@ X: hw/s390x/s390-virtio-bus.[ch]
 F: include/hw/s390x/
 F: pc-bios/s390-ccw/
 F: hw/watchdog/wdt_diag288.c
-T: git git://github.com/cohuck/qemu virtio-ccw-upstr
+T: git git://github.com/cohuck/qemu.git s390-next
+T: git git://github.com/borntraeger/qemu.git s390-next
 
 UniCore32 Machines
 -
@@ -872,7 +875,8 @@ M: Cornelia Huck 
 M: Christian Borntraeger 
 S: Supported
 F: hw/s390x/virtio-ccw.[hc]
-T: git git://github.com/cohuck/qemu virtio-ccw-upstr
+T: git git://github.com/cohuck/qemu.git s390-next
+T: git git://github.com/borntraeger/qemu.git s390-next
 
 virtio-input
 M: Gerd Hoffmann 
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 06/15] s390x/kvm: don't enable CMMA when hugetlbfs will be used

2015-11-11 Thread Cornelia Huck
From: Dominik Dingel 

On hugetlbfs CMMA will not be useful as every ESSA instruction will trap.
So don't offer CMMA to guests with a hugepages backing.

Signed-off-by: Dominik Dingel 
Acked-by: Christian Borntraeger 
Signed-off-by: Cornelia Huck 
---
 target-s390x/kvm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index c3be180..75a0e5d 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -258,7 +258,9 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 cap_mem_op = kvm_check_extension(s, KVM_CAP_S390_MEM_OP);
 cap_s390_irq = kvm_check_extension(s, KVM_CAP_S390_INJECT_IRQ);
 
-kvm_s390_enable_cmma(s);
+if (!mem_path) {
+kvm_s390_enable_cmma(s);
+}
 
 if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
 || !kvm_check_extension(s, KVM_CAP_S390_COW)) {
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 05/15] s390x: switch to memory_region_allocate_system_memory

2015-11-11 Thread Cornelia Huck
From: Dominik Dingel 

By replacing memory_region_init_ram with memory_region_allocate_system_memory
we gain goodies like mem-path backends. This will allow us to use hugetlbfs
once the kernel supports it.

Signed-off-by: Dominik Dingel 
Acked-by: Christian Borntraeger 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio-ccw.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 84221f4..5a52ff2 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -104,8 +104,7 @@ void s390_memory_init(ram_addr_t mem_size)
 MemoryRegion *ram = g_new(MemoryRegion, 1);
 
 /* allocate RAM for core */
-memory_region_init_ram(ram, NULL, "s390.ram", mem_size, _fatal);
-vmstate_register_ram_global(ram);
+memory_region_allocate_system_memory(ram, NULL, "s390.ram", mem_size);
 memory_region_add_subregion(sysmem, 0, ram);
 
 /* Initialize storage key device */
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 15/15] s390: deprecate the non-ccw machine in 2.5

2015-11-11 Thread Cornelia Huck
From: Christian Borntraeger 

The non-ccw machine for s390 (s390-virtio) is not very well maintained
and caused several issues in the past:
- aliases like virtio-blk did not work for s390
- virtio refactoring failed due to long standing bugs (e.g.see
commit cb927b8a "s390-virtio: Accommodate guests using virtqueues too early")
- some features like memory hotplug will cause trouble due to virtio storage
  being above guest memory
- the boot loader bios no longer seems to work. the source code of that
  loader is also no longer maintained

2.4 changed the default to the ccw machine, let's deprecate the old
machine for 2.5.

Signed-off-by: Christian Borntraeger 
Acked-by: David Hildenbrand 
Message-Id: <1446811645-25565-1-git-send-email-borntrae...@de.ibm.com>
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index cebebb1..51dc0a8 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -268,6 +268,10 @@ static void s390_init(MachineState *machine)
 hwaddr virtio_region_len;
 hwaddr virtio_region_start;
 
+error_printf("WARNING\n"
+ "The s390-virtio machine (non-ccw) is deprecated.\n"
+ "It will be removed in 2.6. Please use s390-ccw-virtio\n");
+
 if (machine->ram_slots) {
 error_report("Memory hotplug not supported by the selected machine.");
 exit(EXIT_FAILURE);
@@ -334,7 +338,7 @@ static void s390_machine_class_init(ObjectClass *oc, void 
*data)
 NMIClass *nc = NMI_CLASS(oc);
 
 mc->alias = "s390";
-mc->desc = "VirtIO based S390 machine";
+mc->desc = "VirtIO based S390 machine (deprecated)";
 mc->init = s390_init;
 mc->reset = s390_machine_reset;
 mc->block_default_type = IF_VIRTIO;
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 14/15] s390x/ipl: switch error reporting to error_setg

2015-11-11 Thread Cornelia Huck
From: David Hildenbrand 

Now that we can report errors in the realize function, let's replace
the fprintf's and hw_error's with error_setg.

Signed-off-by: David Hildenbrand 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/ipl.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index c75071d..b91fcc6 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -76,6 +76,7 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
 S390IPLState *ipl = S390_IPL(dev);
 uint64_t pentry = KERN_IMAGE_START;
 int kernel_size;
+Error *l_err = NULL;
 
 int bios_size;
 char *bios_filename;
@@ -93,7 +94,8 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
 
 bios_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
 if (bios_filename == NULL) {
-hw_error("could not find stage1 bootloader\n");
+error_setg(_err, "could not find stage1 bootloader\n");
+goto error;
 }
 
 bios_size = load_elf(bios_filename, bios_translate_addr, ,
@@ -111,7 +113,8 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
 g_free(bios_filename);
 
 if (bios_size == -1) {
-hw_error("could not load bootloader '%s'\n", bios_name);
+error_setg(_err, "could not load bootloader '%s'\n", bios_name);
+goto error;
 }
 
 /* default boot target is the bios */
@@ -125,8 +128,8 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
 kernel_size = load_image_targphys(ipl->kernel, 0, ram_size);
 }
 if (kernel_size < 0) {
-fprintf(stderr, "could not load kernel '%s'\n", ipl->kernel);
-exit(1);
+error_setg(_err, "could not load kernel '%s'\n", ipl->kernel);
+goto error;
 }
 /*
  * Is it a Linux kernel (starting at 0x1)? If yes, we fill in the
@@ -153,9 +156,8 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
 initrd_size = load_image_targphys(ipl->initrd, initrd_offset,
   ram_size - initrd_offset);
 if (initrd_size == -1) {
-fprintf(stderr, "qemu: could not load initrd '%s'\n",
-ipl->initrd);
-exit(1);
+error_setg(_err, "could not load initrd '%s'\n", 
ipl->initrd);
+goto error;
 }
 
 /*
@@ -167,6 +169,8 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
 }
 }
 qemu_register_reset(qdev_reset_all_fn, dev);
+error:
+error_propagate(errp, l_err);
 }
 
 static Property s390_ipl_properties[] = {
-- 
2.6.3




Re: [Qemu-devel] [PATCH for-2.5] qapi: Document introspection stability considerations

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> We are not ready (and might never be ready) to declare
> introspection stable between releases. Clients written to
> control multiple versions of qemu, and desiring to know
> whether a particular member is supported for a given
> command, must be prepared to locate that member in spite
> of qapi changes that may affect the member's location or
> type within the overall object, even though such changes
> did not break QMP wire back-compatibility.
>
> Signed-off-by: Eric Blake 

Looks good to me.  I'll take care to get it into 2.5.  Still plenty of
time for doc fixes, so I'll wait a few days to give others a chance to
review.



Re: [Qemu-devel] [PATCH v11 19/28] qapi: Change munging of CamelCase enum values

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> [hmm, wonder why scripts/get-maintainer.pl didn't loop in Gerd to the
> patch itself]
>
> On 11/11/2015 07:50 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> When munging enum values, the fact that we were passing the entire
>>> prefix + value through camel_to_upper() meant that enum values
>>> spelled with CamelCase could be turned into CAMEL_CASE.  However,
>>> this provides a potential collision (both OneTwo and One-Two would
>>> munge into ONE_TWO).  By changing the generation of enum constants
>>> to always be prefix + '_' + c_name(value).upper(), we can avoid
>>> any risk of collisions (if we can also ensure no case collisions,
>>> in the next patch) without having to think about what the
>>> heuristics in camel_to_upper() will actually do to the value.
>> 
>> This is the good part: the rules for clashes become much simpler.
>> 
>> Bonus: the implementation for detecting them will be simple, too.
>> 
>>> Thankfully, only two enums are affected: ErrorClass and InputButton.
>
> Visiting just InputButton in this email.
>
>> 
>> By convention (see CODING_STYLE), we use CamelCase for type names, and
>> nothing else.
>> 
>> Only enums violating this naming convention can be affected.  The bad
>> part: they exist.
>> 
>> InputButton has two camels: WheelUp and WheelDown.  The C enumeration
>> constants change from INPUT_BUTTON_WHEEL_UP/WHEEL_DOWN to
>> INPUT_BUTTON_WHEELUP/WHEELDOWN.  Not exactly an improvement, but one,
>> there are just 21 occurences in 11 files, and two, I think we can still
>> fix the enumeration to "lower case with dash", as it's only used by
>> x-input-send-event.
>
> The InputButton type has existed since 2.0; which is then part of the
> 'InputBtnEvent' struct, then the 'InputEvent' union, also since 2.0.  I
> can't easily tell if it was only used internally at that point, or if we
> exposed it through the command line (even if we didn't expose it through
> QMP);

As far as I can tell, we used it internally, and for tracing.

>   but I concur with your reading that in QMP it is only used via
> 'x-input-send-event' (since 2.2, but the x- prefix gives us freedom).
> [Oh, and I just spotted a typo; 'InputAxis' has a copy-and-paste doc
> typo calling it 'InputButton']
>
> If desired, I can prepare an alternate patch that adds the dash to the
> qapi enum definition, to see what we think.

If Gerd is fine with the rename, let's do it.

> But meanwhile, look at some of the lines in the patch:
>
>> diff --git a/ui/sdl.c b/ui/sdl.c
>> index 570cb99..2678611 100644
>> --- a/ui/sdl.c
>> +++ b/ui/sdl.c
>> @@ -469,8 +469,8 @@ static void sdl_send_mouse_event(int dx, int dy,
>> int x, int y, int state)
>>  [INPUT_BUTTON_LEFT] = SDL_BUTTON(SDL_BUTTON_LEFT),
>>  [INPUT_BUTTON_MIDDLE] = SDL_BUTTON(SDL_BUTTON_MIDDLE),
>>  [INPUT_BUTTON_RIGHT] = SDL_BUTTON(SDL_BUTTON_RIGHT),
>> -[INPUT_BUTTON_WHEEL_UP] = SDL_BUTTON(SDL_BUTTON_WHEELUP),
>> -[INPUT_BUTTON_WHEEL_DOWN] = SDL_BUTTON(SDL_BUTTON_WHEELDOWN),
>> +[INPUT_BUTTON_WHEELUP] = SDL_BUTTON(SDL_BUTTON_WHEELUP),
>> +[INPUT_BUTTON_WHEELDOWN] = SDL_BUTTON(SDL_BUTTON_WHEELDOWN),
>
> Since SDL already spells the names without space, it's not the end of
> the world if we do likewise.

Good point.

Even if we adopt SDL's spelling WHEELUP and WHEELDOWN, I'd still prefer
to downcase the QAPI names for consistency with the rest of QAPI.



[Qemu-devel] [PATCH 2/4] spapr: Register and handle HCALL to receive updated RTAS region

2015-11-11 Thread Aravinda Prasad
Receive updates from SLOF about the updated rtas-base.
A separate patch for SLOF [1] adds functionality to invoke
a private HCALL whenever OS issues instantiate-rtas with
a new rtas-base.

This is required as QEMU needs to know the updated rtas-base
as it allocates error reporting structure in RTAS space upon
a machine check exception.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html

Signed-off-by: Aravinda Prasad 
---
 hw/ppc/spapr_hcall.c   |8 
 include/hw/ppc/spapr.h |3 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 652ddf6..9703ed2 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -580,6 +580,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, 
sPAPRMachineState *spapr,
nret, rtas_r3 + 12 + 4*nargs);
 }
 
+static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPRMachineState *spapr,
+  target_ulong opcode, target_ulong *args)
+{
+spapr->rtas_addr = args[0];
+return 0;
+}
+
 static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPRMachineState *spapr,
target_ulong opcode, target_ulong *args)
 {
@@ -1008,6 +1015,7 @@ static void hypercall_register_types(void)
 
 /* qemu/KVM-PPC specific hcalls */
 spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
+spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
 
 spapr_register_hypercall(H_SET_MODE, h_set_mode);
 
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 91a61ab..b5cadd7 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -347,7 +347,8 @@ struct sPAPRMachineState {
 #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
 /* Client Architecture support */
 #define KVMPPC_H_CAS(KVMPPC_HCALL_BASE + 0x2)
-#define KVMPPC_HCALL_MAXKVMPPC_H_CAS
+#define KVMPPC_H_RTAS_UPDATE(KVMPPC_HCALL_BASE + 0x3)
+#define KVMPPC_HCALL_MAXKVMPPC_H_RTAS_UPDATE
 
 typedef struct sPAPRDeviceTreeUpdateHeader {
 uint32_t version_id;




[Qemu-devel] [PULL 0/1] error: More error_setg() usage

2015-11-11 Thread Markus Armbruster
The following changes since commit 3c07587d49458341510360557c849e93e9afaf59:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-next-2015' into 
staging (2015-11-11 09:34:18 +)

are available in the git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-error-2015-11-11

for you to fetch changes up to c9c8f7a7989ff8dcf36036ba47a96ef86a7763f5:

  error: More error_setg() usage (2015-11-11 18:18:52 +0100)


error: More error_setg() usage


Eric Blake (1):
  error: More error_setg() usage

 block.c   |  3 +--
 docs/writing-qmp-commands.txt | 20 +---
 hw/i386/pc.c  |  2 +-
 hw/net/rocker/rocker.c|  6 ++
 hw/net/rocker/rocker_of_dpa.c | 12 
 qom/object.c  |  4 ++--
 6 files changed, 19 insertions(+), 28 deletions(-)

-- 
2.4.3




[Qemu-devel] [PULL 1/1] gluster: allocate GlusterAIOCBs on the stack

2015-11-11 Thread Jeff Cody
From: Paolo Bonzini 

This is simpler now that the driver has been converted to coroutines.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Jeff Cody 
Reviewed-by: Kevin Wolf 
---
 block/gluster.c | 86 ++---
 1 file changed, 33 insertions(+), 53 deletions(-)

diff --git a/block/gluster.c b/block/gluster.c
index 1eb3a8c..0857c14 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -429,28 +429,23 @@ static coroutine_fn int 
qemu_gluster_co_write_zeroes(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors, BdrvRequestFlags flags)
 {
 int ret;
-GlusterAIOCB *acb = g_slice_new(GlusterAIOCB);
+GlusterAIOCB acb;
 BDRVGlusterState *s = bs->opaque;
 off_t size = nb_sectors * BDRV_SECTOR_SIZE;
 off_t offset = sector_num * BDRV_SECTOR_SIZE;
 
-acb->size = size;
-acb->ret = 0;
-acb->coroutine = qemu_coroutine_self();
-acb->aio_context = bdrv_get_aio_context(bs);
+acb.size = size;
+acb.ret = 0;
+acb.coroutine = qemu_coroutine_self();
+acb.aio_context = bdrv_get_aio_context(bs);
 
-ret = glfs_zerofill_async(s->fd, offset, size, _finish_aiocb, acb);
+ret = glfs_zerofill_async(s->fd, offset, size, gluster_finish_aiocb, );
 if (ret < 0) {
-ret = -errno;
-goto out;
+return -errno;
 }
 
 qemu_coroutine_yield();
-ret = acb->ret;
-
-out:
-g_slice_free(GlusterAIOCB, acb);
-return ret;
+return acb.ret;
 }
 
 static inline bool gluster_supports_zerofill(void)
@@ -541,35 +536,30 @@ static coroutine_fn int 
qemu_gluster_co_rw(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors, QEMUIOVector *qiov, int write)
 {
 int ret;
-GlusterAIOCB *acb = g_slice_new(GlusterAIOCB);
+GlusterAIOCB acb;
 BDRVGlusterState *s = bs->opaque;
 size_t size = nb_sectors * BDRV_SECTOR_SIZE;
 off_t offset = sector_num * BDRV_SECTOR_SIZE;
 
-acb->size = size;
-acb->ret = 0;
-acb->coroutine = qemu_coroutine_self();
-acb->aio_context = bdrv_get_aio_context(bs);
+acb.size = size;
+acb.ret = 0;
+acb.coroutine = qemu_coroutine_self();
+acb.aio_context = bdrv_get_aio_context(bs);
 
 if (write) {
 ret = glfs_pwritev_async(s->fd, qiov->iov, qiov->niov, offset, 0,
-_finish_aiocb, acb);
+gluster_finish_aiocb, );
 } else {
 ret = glfs_preadv_async(s->fd, qiov->iov, qiov->niov, offset, 0,
-_finish_aiocb, acb);
+gluster_finish_aiocb, );
 }
 
 if (ret < 0) {
-ret = -errno;
-goto out;
+return -errno;
 }
 
 qemu_coroutine_yield();
-ret = acb->ret;
-
-out:
-g_slice_free(GlusterAIOCB, acb);
-return ret;
+return acb.ret;
 }
 
 static int qemu_gluster_truncate(BlockDriverState *bs, int64_t offset)
@@ -600,26 +590,21 @@ static coroutine_fn int 
qemu_gluster_co_writev(BlockDriverState *bs,
 static coroutine_fn int qemu_gluster_co_flush_to_disk(BlockDriverState *bs)
 {
 int ret;
-GlusterAIOCB *acb = g_slice_new(GlusterAIOCB);
+GlusterAIOCB acb;
 BDRVGlusterState *s = bs->opaque;
 
-acb->size = 0;
-acb->ret = 0;
-acb->coroutine = qemu_coroutine_self();
-acb->aio_context = bdrv_get_aio_context(bs);
+acb.size = 0;
+acb.ret = 0;
+acb.coroutine = qemu_coroutine_self();
+acb.aio_context = bdrv_get_aio_context(bs);
 
-ret = glfs_fsync_async(s->fd, _finish_aiocb, acb);
+ret = glfs_fsync_async(s->fd, gluster_finish_aiocb, );
 if (ret < 0) {
-ret = -errno;
-goto out;
+return -errno;
 }
 
 qemu_coroutine_yield();
-ret = acb->ret;
-
-out:
-g_slice_free(GlusterAIOCB, acb);
-return ret;
+return acb.ret;
 }
 
 #ifdef CONFIG_GLUSTERFS_DISCARD
@@ -627,28 +612,23 @@ static coroutine_fn int 
qemu_gluster_co_discard(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors)
 {
 int ret;
-GlusterAIOCB *acb = g_slice_new(GlusterAIOCB);
+GlusterAIOCB acb;
 BDRVGlusterState *s = bs->opaque;
 size_t size = nb_sectors * BDRV_SECTOR_SIZE;
 off_t offset = sector_num * BDRV_SECTOR_SIZE;
 
-acb->size = 0;
-acb->ret = 0;
-acb->coroutine = qemu_coroutine_self();
-acb->aio_context = bdrv_get_aio_context(bs);
+acb.size = 0;
+acb.ret = 0;
+acb.coroutine = qemu_coroutine_self();
+acb.aio_context = bdrv_get_aio_context(bs);
 
-ret = glfs_discard_async(s->fd, offset, size, _finish_aiocb, acb);
+ret = glfs_discard_async(s->fd, offset, size, gluster_finish_aiocb, );
 if (ret < 0) {
-ret = -errno;
-goto out;
+return -errno;
 }
 
 qemu_coroutine_yield();
-ret = acb->ret;
-
-out:
-g_slice_free(GlusterAIOCB, acb);
-return ret;
+return acb.ret;
 }
 #endif
 
-- 
1.9.3




[Qemu-devel] [PULL v2 0/1] error: More error_setg() usage

2015-11-11 Thread Markus Armbruster
v2: Indentation touched up

The following changes since commit 3c07587d49458341510360557c849e93e9afaf59:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-next-2015' into 
staging (2015-11-11 09:34:18 +)

are available in the git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-error-2015-11-11

for you to fetch changes up to 455b0fde8c38a0794743e2e7c1a40018b7bee9f6:

  error: More error_setg() usage (2015-11-11 18:56:26 +0100)


error: More error_setg() usage


Eric Blake (1):
  error: More error_setg() usage

 block.c   |  3 +--
 docs/writing-qmp-commands.txt | 20 +---
 hw/i386/pc.c  |  6 +++---
 hw/net/rocker/rocker.c|  6 ++
 hw/net/rocker/rocker_of_dpa.c | 12 
 qom/object.c  |  4 ++--
 6 files changed, 21 insertions(+), 30 deletions(-)

Eric Blake (1):
  error: More error_setg() usage

 block.c   |  3 +--
 docs/writing-qmp-commands.txt | 20 +---
 hw/i386/pc.c  |  6 +++---
 hw/net/rocker/rocker.c|  6 ++
 hw/net/rocker/rocker_of_dpa.c | 12 
 qom/object.c  |  4 ++--
 6 files changed, 21 insertions(+), 30 deletions(-)

-- 
2.4.3




Re: [Qemu-devel] [PATCH 3/3] migrate-start-postcopy: Improve text

2015-11-11 Thread Eric Blake
On 11/11/2015 07:02 AM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Improve the text in both the qapi-schema and hmp help to point out
> you need to set the postcopy-ram capability prior to issuing
> migrate-start-postcopy.
> 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  hmp-commands.hx  | 4 +++-
>  qapi-schema.json | 3 ++-
>  2 files changed, 5 insertions(+), 2 deletions(-)

Does the bit have to be set before starting the migration, or are you
allowed to start the migration, then set the bit, then request the postcopy?

> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 8939b98..3316ee3 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -1011,7 +1011,9 @@ ETEXI
>  .name   = "migrate_start_postcopy",
>  .args_type  = "",
>  .params = "",
> -.help   = "Switch migration to postcopy mode",
> +.help   = "Switch current migration to postcopy mode; "
> +  "the x-postcopy-ram capability must be set before"
> +  " issuing this command.",

If the bit has to be set before the initial 'migrate' command, it might
read better as:

"Switch a migration that was started with the x-postcopy-ram capability
into postcopy mode"

> +++ b/qapi-schema.json
> @@ -706,7 +706,8 @@
>  ##
>  # @migrate-start-postcopy
>  #
> -# Switch migration to postcopy mode
> +# Switch current migration to postcopy mode; the x-postcopy-ram capability
> +# must be set before issuing this command.

Or maybe even:

"Followup to a migration command to switch the migration to postcopy
mode. The x-postcopy-ram capability must be set before the original
migration command."

But if the capability bit can be set in between the two migration
commands, then your wording is fine and you can add:
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 v13 03/13] pcie: modify the capability size assert

2015-11-11 Thread Michael S. Tsirkin
On Wed, Nov 11, 2015 at 06:34:21PM +0800, Cao jin wrote:
> From: Chen Fan 
> 
>  Device's Offset and size can reach PCIE_CONFIG_SPACE_SIZE,
>  fix the corresponding assert.
> 
> Signed-off-by: Chen Fan 
> Reviewed-by: Marcel Apfelbaum 

Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/pci/pcie.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> index 0eab29d..8f4c0e5 100644
> --- a/hw/pci/pcie.c
> +++ b/hw/pci/pcie.c
> @@ -607,7 +607,7 @@ void pcie_add_capability(PCIDevice *dev,
>  
>  assert(offset >= PCI_CONFIG_SPACE_SIZE);
>  assert(offset < offset + size);
> -assert(offset + size < PCIE_CONFIG_SPACE_SIZE);
> +assert(offset + size <= PCIE_CONFIG_SPACE_SIZE);
>  assert(size >= 8);
>  assert(pci_is_express(dev));
>  
> -- 
> 1.9.3



Re: [Qemu-devel] [PATCH v10 29/30] cpu: Convert CpuInfo into flat union

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> On 11/11/2015 03:19 AM, Markus Armbruster wrote:
>
 Do we need this to make 2.5?
>>>
>>> It's true that the introspection will change (instead of seeing flat
>>> optional members, you now have to chase down variants).  But I don't
>>> think it is pressing enough to rush into 2.5; the change is
>>> backwards-compatible no matter when we do it, and introspection clients
>>> are going to have to get used to the idea of chasing down different
>>> paths to find all members of a struct (that is, if we don't change this
>>> until 2.6, I'm sure it won't be the last case of introspection changing
>>> while keeping QMP wire format back-compatible as formerly non-variant
>>> fields become variant).
>> 
>> We can mess with the schema as long as the QMP wire format stays
>> compatible.
>> 
>> With introspection, schema changes get exposed in QMP that weren't
>> exposed before.  Begs the question whether the ABI promise extends to
>> the introspection value.
>> 
>> I think we don't want to extend it, at least for now.  In other words,
>> we refuse to put additional constraints on schema changes to keep the
>> introspection value stable.  Makes introspection a bit harder to use.
>> Not ideal, but better than committing to constraints we don't even fully
>> understand, yet.
>> 
>> I think we should spell this out introspection documentation.
>
> Sounds like I need to prep a doc patch for 2.5 then.

Yes, please!

>> Our only example so far is converting between optional members and flat
>> unions.  Can we think of others?  Hmm, you found one below.
>
> Converting from optional non-variant to variant, converting from string
> to enum, converting from single type to alternate.  Might be other
> conversions, and the set of conversions for input types may differ from
> those of output conversions.
>
>> Okay.  I guess finding all the examples that matter may take a few
>> development cycles.  Perhaps we want to commit to some additional
>> compatibility promises for introspection then.
>
> Maybe, but until clients are no longer worried about older clients, it
> may be several years before taking advantage of whatever we later
> document

That's life.

I fully expect the consumers of QMP introspection to get a few things
wrong initially, requiring their users to upgrade to fixed versions.
That's life, too.

>  (as it is, upstream libvirt is just now bumping minimum qemu
> support up to 0.12 [thanks to RHEL 6] and discarding older qemu from
> RHEL 5 - quite a few years behind upstream qemu 2.5, although it is
> finding a lot of code in libvirt that is no longer necessary).

In my opinion, attempting to support old versions of QEMU is a complete
waste of resources unless you actually test them to stop the bit-rot.

RHEL-6 0.12 is by now quite different from upstream 0.12.  Unlike
upstream 0.12, it's actually still relevant and useful today.

I encourage you to identify relevant upstream and downstream versions,
keep them tested, and drop support for the rest.



[Qemu-devel] [PATCH 1/4] spapr: Extend rtas-blob

2015-11-11 Thread Aravinda Prasad
Extend rtas-blob to accommodate error log. Error log
structure is saved in rtas space upon a machine check
exception.

Signed-off-by: Aravinda Prasad 
---
 hw/ppc/spapr.c |4 
 1 file changed, 4 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 05926a3..b7b9e09 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1556,6 +1556,10 @@ static void ppc_spapr_init(MachineState *machine)
 exit(1);
 }
 spapr->rtas_size = get_image_size(filename);
+
+/* Resize blob to accommodate error log. */
+spapr->rtas_size = TARGET_PAGE_ALIGN(spapr->rtas_size);
+
 spapr->rtas_blob = g_malloc(spapr->rtas_size);
 if (load_image_size(filename, spapr->rtas_blob, spapr->rtas_size) < 0) {
 error_report("Could not load LPAR rtas '%s'", filename);




[Qemu-devel] [PATCH 4/4] target-ppc: Handle NMI guest exit

2015-11-11 Thread Aravinda Prasad
Memory error such as bit flips that cannot be corrected
by hardware are passed on to the kernel for handling.
If the memory address in error belongs to guest then
guest kernel is responsible for taking suitable action.
Patch [1] enhances KVM to exit guest with exit reason
set to KVM_EXIT_NMI in such cases.

This patch handles KVM_EXIT_NMI exit. If the guest OS
has registered the machine check handling routine by
calling "ibm,nmi-register", then the handler builds
the error log and invokes the registered handler else
invokes the handler at 0x200.

[1] http://marc.info/?l=kvm-ppc=144726114408289

Signed-off-by: Aravinda Prasad 
---
 target-ppc/kvm.c |   69 +++
 target-ppc/kvm_ppc.h |   81 ++
 2 files changed, 150 insertions(+)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 110436d..e2e5170 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1665,6 +1665,11 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run 
*run)
 ret = 0;
 break;
 
+case KVM_EXIT_NMI:
+DPRINTF("handle NMI exception\n");
+ret = kvm_handle_nmi(cpu);
+break;
+
 default:
 fprintf(stderr, "KVM: unknown exit reason %d\n", run->exit_reason);
 ret = -1;
@@ -2484,3 +2489,67 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)
 {
 return data & 0x;
 }
+
+int kvm_handle_nmi(PowerPCCPU *cpu)
+{
+struct rtas_mc_log mc_log;
+CPUPPCState *env = >env;
+sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+
+cpu_synchronize_state(CPU(ppc_env_get_cpu(env)));
+
+/* Properly set bits in MSR before we invoke the handler */
+env->msr = 0;
+
+if (!(*pcc->interrupts_big_endian)(cpu)) {
+env->msr |= (1ULL << MSR_LE);
+}
+
+#ifdef TARGET_PPC64
+env->msr |= (1ULL << MSR_SF);
+#endif
+
+if (!spapr->guest_machine_check_addr) {
+/*
+ * If OS has not registered with "ibm,nmi-register"
+ * jump to 0x200
+ */
+env->nip = 0x200;
+return 0;
+}
+
+qemu_mutex_lock(>mc_in_progress);
+
+/* Set error log fields */
+mc_log.r3 = env->gpr[3];
+mc_log.err_log.byte0 = 0;
+mc_log.err_log.byte1 =
+(RTAS_SEVERITY_ERROR_SYNC << RTAS_ELOG_SEVERITY_SHIFT);
+mc_log.err_log.byte1 |=
+(RTAS_DISP_NOT_RECOVERED << RTAS_ELOG_DISPOSITION_SHIFT);
+mc_log.err_log.byte2 =
+(RTAS_INITIATOR_MEMORY << RTAS_ELOG_INITIATOR_SHIFT);
+mc_log.err_log.byte2 |= RTAS_TARGET_MEMORY;
+
+if (env->spr[SPR_DSISR] & P7_DSISR_MC_UE) {
+mc_log.err_log.byte3 = RTAS_TYPE_ECC_UNCORR;
+} else {
+mc_log.err_log.byte3 = 0;
+}
+
+/* Handle all Host/Guest LE/BE combinations */
+if (env->msr & (1ULL << MSR_LE)) {
+mc_log.r3 = cpu_to_le64(mc_log.r3);
+} else {
+mc_log.r3 = cpu_to_be64(mc_log.r3);
+}
+
+cpu_physical_memory_write(spapr->rtas_addr + RTAS_ERRLOG_OFFSET,
+  _log, sizeof(mc_log));
+
+env->nip = spapr->guest_machine_check_addr;
+env->gpr[3] = spapr->rtas_addr + RTAS_ERRLOG_OFFSET;
+
+return 0;
+}
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index 5c1d334..1172735 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -53,6 +53,87 @@ void kvmppc_hash64_free_pteg(uint64_t token);
 void kvmppc_hash64_write_pte(CPUPPCState *env, target_ulong pte_index,
  target_ulong pte0, target_ulong pte1);
 bool kvmppc_has_cap_fixup_hcalls(void);
+int kvm_handle_nmi(PowerPCCPU *cpu);
+
+/* Offset from rtas-base where error log is placed */
+#define RTAS_ERRLOG_OFFSET   (0x200)
+
+#define RTAS_ELOG_SEVERITY_SHIFT 0x5
+#define RTAS_ELOG_DISPOSITION_SHIFT  0x3
+#define RTAS_ELOG_INITIATOR_SHIFT0x4
+
+/*
+ * Only required RTAS event severity, disposition, initiator
+ * target and type are copied from arch/powerpc/include/asm/rtas.h
+ */
+
+/* RTAS event severity */
+#define RTAS_SEVERITY_ERROR_SYNC0x3
+
+/* RTAS event disposition */
+#define RTAS_DISP_NOT_RECOVERED 0x2
+
+/* RTAS event initiator */
+#define RTAS_INITIATOR_MEMORY   0x4
+
+/* RTAS event target */
+#define RTAS_TARGET_MEMORY  0x4
+
+/* RTAS event type */
+#define RTAS_TYPE_ECC_UNCORR0x09
+
+/*
+ * Currently KVM only passes on the uncorrected machine
+ * check memory error to guest. Other machine check errors
+ * such as SLB multi-hit and TLB multi-hit are recovered
+ * in KVM and are not passed on to guest.
+ *
+ * DSISR Bit for uncorrected machine check error. Based
+ * on arch/powerpc/include/asm/mce.h
+ */
+#define PPC_BIT(bit)(0x8000ULL >> bit)
+#define P7_DSISR_MC_UE  (PPC_BIT(48))  /* P8 too */
+
+/* Adopted from kernel source arch/powerpc/include/asm/rtas.h */
+struct rtas_error_log {
+/* Byte 0 */
+

[Qemu-devel] [PATCH 3/4] spapr: Handle "ibm, nmi-register" and "ibm, nmi-interlock" RTAS calls

2015-11-11 Thread Aravinda Prasad
This patch adds support in QEMU to handle "ibm,nmi-register"
and "ibm,nmi-interlock" RTAS calls.

The machine check notification address is saved when the
OS issues "ibm,nmi-register" RTAS call.

This patch also handles the case when multiple processors
experience machine check at or about the same time by
handling "ibm,nmi-interlock" call. In such cases, as per
PAPR, subsequent processors serialize waiting for the first
processor to issue the "ibm,nmi-interlock" call. The second
processor waits till the first processor, which also
received a machine check error, is done reading the error
log. The first processor issues "ibm,nmi-interlock" call
when the error log is consumed. This patch implements the
releasing part of the error-log while subsequent patch
(which builds error log) handles the locking part.

Signed-off-by: Aravinda Prasad 
---
 hw/ppc/spapr_rtas.c|   29 +
 include/hw/ppc/spapr.h |8 +++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 9869bc9..fd4d2af 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -597,6 +597,31 @@ out:
 rtas_st(rets, 0, rc);
 }
 
+static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
+  sPAPRMachineState *spapr,
+  uint32_t token, uint32_t nargs,
+  target_ulong args,
+  uint32_t nret, target_ulong rets)
+{
+qemu_mutex_init(>mc_in_progress);
+spapr->guest_machine_check_addr = rtas_ld(args, 1);
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+}
+
+static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
+   sPAPRMachineState *spapr,
+   uint32_t token, uint32_t nargs,
+   target_ulong args,
+   uint32_t nret, target_ulong rets)
+{
+/*
+ * VCPU issuing "ibm,nmi-interlock" is done with NMI handling,
+ * hence unlock mc_in_progress.
+ */
+qemu_mutex_unlock(>mc_in_progress);
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+}
+
 static struct rtas_call {
 const char *name;
 spapr_rtas_fn fn;
@@ -747,6 +772,10 @@ static void core_rtas_register_types(void)
 rtas_get_sensor_state);
 spapr_rtas_register(RTAS_IBM_CONFIGURE_CONNECTOR, 
"ibm,configure-connector",
 rtas_ibm_configure_connector);
+spapr_rtas_register(RTAS_IBM_NMI_REGISTER, "ibm,nmi-register",
+rtas_ibm_nmi_register);
+spapr_rtas_register(RTAS_IBM_NMI_INTERLOCK, "ibm,nmi-interlock",
+rtas_ibm_nmi_interlock);
 }
 
 type_init(core_rtas_register_types)
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index b5cadd7..0a31d15 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -74,6 +74,10 @@ struct sPAPRMachineState {
 /* RTAS state */
 QTAILQ_HEAD(, sPAPRConfigureConnectorState) ccs_list;
 
+/* State related to "ibm,nmi-register" and "ibm,nmi-interlock" calls */
+target_ulong guest_machine_check_addr;
+QemuMutex mc_in_progress;
+
 /*< public >*/
 char *kvm_type;
 };
@@ -458,8 +462,10 @@ int spapr_allocate_irq_block(int num, bool lsi, bool msi);
 #define RTAS_IBM_SET_SLOT_RESET (RTAS_TOKEN_BASE + 0x23)
 #define RTAS_IBM_CONFIGURE_PE   (RTAS_TOKEN_BASE + 0x24)
 #define RTAS_IBM_SLOT_ERROR_DETAIL  (RTAS_TOKEN_BASE + 0x25)
+#define RTAS_IBM_NMI_REGISTER   (RTAS_TOKEN_BASE + 0x26)
+#define RTAS_IBM_NMI_INTERLOCK  (RTAS_TOKEN_BASE + 0x27)
 
-#define RTAS_TOKEN_MAX  (RTAS_TOKEN_BASE + 0x26)
+#define RTAS_TOKEN_MAX  (RTAS_TOKEN_BASE + 0x28)
 
 /* RTAS ibm,get-system-parameter token values */
 #define RTAS_SYSPARM_SPLPAR_CHARACTERISTICS  20




Re: [Qemu-devel] CUDA has problems with Mac OS 10.4

2015-11-11 Thread Mark Cave-Ayland
On 11/11/15 15:15, Programmingkid wrote:

> I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 
> 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did 
> use the mac99 target. Here is the error message: 
> 
> panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND 
> ERROR
> 
> This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom 
> ~/tiger.iso  -prom-env boot-args=-v -usb -M mac99
> 
> I think there is still something wrong with CUDA. But we might not have to 
> "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is 
> what we are trying to emulate. My sources indicate that the PowerMac3,1 
> doesn't have a CUDA chip. This chip is used for ADB communications. Using it 
> only on the BeigeG3 target makes sense. 
> 
> My sources for the PowerMac3,1 system is this link: 
> http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html
> 
> and this device tree:
> 
> PowerMac G4 device tree
> 
> ff839ab8: /cpus
> ff839ce8:   /PowerPC,G4@0
> ff83a060: /l2-cache
> ff83ab58: /chosen
> ff83ace8: /memory@0
> ff83af00: /openprom
> ff83b008:   /client-services
> ff83c1a8: /rom@ff80
> ff83c330:   /boot-rom@fff0
> ff83c4a8:   /macos
> ff83c528: /options
> ff83c5a8: /aliases
> ff83cec8: /packages
> ff83cf30:   /deblocker
> ff83d798:   /disk-label
> ff83e198:   /obp-tftp
> ff8439f0:   /mac-parts
> ff844850:   /mac-files
> ff847540:   /hfs-plus-files
> ff84c1c8:   /fat-files
> ff84def8:   /iso-9660-files
> ff84eb00:   /bootinfo-loader
> ff8507a0:   /xcoff-loader
> ff8511b8:   /pe-loader
> ff851b90:   /elf-loader
> ff8531c0:   /usb-hid-class
> ff8554d8:   /usb-ms-class
> ff8576a8:   /sbp2-disk
> ff858ac0:   /ata-disk
> ff859cd8:   /atapi-disk
> ff85b348:   /bootpath-search
> ff861b68:   /terminal-emulator
> ff861c00: /psuedo-hid
> ff861c88:   /keyboard
> ff862308:   /mouse
> ff862820: /multiboot
> ff86e7f0: /diagnostics
> ff86e858: /tools-node
> ff8704b8: /rtas
> ff8706b8: /nvram@fff04000
> ff871180: /uni-n@f800
> ff8713c8:   /i2c@f8001000
> ff871b10: /cereal
> ff8721c0: /pci@f000
> ff898cd0:   /uni-north-agp@b
> ff898f40:   /ATY,Rage128Ps@10
> ff873268: /pci@f200
> ff8742d8:   /pci-bridge@d
> ff876368: /mac-io@7
> ff8773a0:   /interrupt-controller@4
> ff877548:   /gpio@50
> ff877630: /extint-gpio1
> ff8777c8: /programmer-switch
> ff877900:   /escc-legacy@12000
> ff877af8: /ch-a@12004
> ff877c78: /ch-b@12000
> ff877df8:   /escc@13000
> ff878000: /ch-a@13020
> ff8789a8: /ch-b@13000
> ff8792c0:   /davbus@14000
> ff879540: /sound
> ff879c40:   /timer@15000
> ff879da8:   /via-pmu@16000
> ff87ccf0: /rtc
> ff87d3e0: /power-mgt
> ff8bf378:   /usb-power-mgt
> ff87d648:   /i2c@18000
> ff87ded8: /cereal
> ff87e5a0:   /ata-4@1f000
> ff880318: /disk
> ff8809e8:   /ata-3@2
> ff882760: /disk
> ff882da8:   /ata-3@21000
> ff884b20: /disk
> ff8864c8: /ethernet@4
> ff888690: /usb@8
> ff88dd50: /usb@9
> ff8be3f0:   /hub@1
> ff8be580: /keyboard@1
> ff893410: /firewire@a
> ff8752e8: /pci@f400
> ff8bb128:   /ethernet@f

I've done quite a bit of work on Cormac's tree (primarily to fix CUDA
issues that broke OS X among other things) and posted it to the
qemu-devel list at
https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.

The patchset posted works well for me here, and I suspect will fix the
issues that you've been seeing. Note that you'll also need the separate
OpenBIOS binary mentioned in the link above if you want to try booting
OS 9 since one of the OpenBIOS patches hasn't been applied to trunk
since it regresses other images.


ATB,

Mark.




[Qemu-devel] [PULL for-2.5 03/15] MAINTAINERS: update s390 file patterns

2015-11-11 Thread Cornelia Huck
We were missing some files, and some files should get an additional
entry to add the people actually looking after the code.

Reported-by: Thomas Huth 
Acked-by: Christian Borntraeger 
Signed-off-by: Cornelia Huck 
---
 MAINTAINERS | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fc8abe8..9585a8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -237,9 +237,12 @@ M: Cornelia Huck 
 M: Alexander Graf 
 S: Maintained
 F: target-s390x/kvm.c
+F: target-s390x/ioinst.[ch]
+F: target-s390x/machine.c
 F: hw/intc/s390_flic.c
 F: hw/intc/s390_flic_kvm.c
 F: include/hw/s390x/s390_flic.h
+F: gdb-xml/s390*.xml
 
 X86
 M: Paolo Bonzini 
@@ -637,14 +640,11 @@ M: Christian Borntraeger 
 M: Alexander Graf 
 S: Supported
 F: hw/char/sclp*.[hc]
-F: hw/s390x/s390-virtio-ccw.c
-F: hw/s390x/css.[hc]
-F: hw/s390x/sclp*.[hc]
-F: hw/s390x/ipl*.[hc]
-F: hw/s390x/*pci*.[hc]
-F: hw/s390x/s390-skeys*.c
+F: hw/s390x/
+X: hw/s390x/s390-virtio-bus.[ch]
 F: include/hw/s390x/
 F: pc-bios/s390-ccw/
+F: hw/watchdog/wdt_diag288.c
 T: git git://github.com/cohuck/qemu virtio-ccw-upstr
 
 UniCore32 Machines
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 00/15] s390x patches for 2.5

2015-11-11 Thread Cornelia Huck
The following changes since commit 3c07587d49458341510360557c849e93e9afaf59:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-next-2015' into 
staging (2015-11-11 09:34:18 +)

are available in the git repository at:

  git://github.com/cohuck/qemu tags/s390x-2015

for you to fetch changes up to 3c4c694c7ce2d21c0cf17a27cc60c91b6725ce48:

  s390: deprecate the non-ccw machine in 2.5 (2015-11-11 17:21:39 +0100)


Hopefully last big batch of s390x patches, including:
- bugfixes for LE host and for pci translation
- MAINTAINERS update
- hugetlbfs enablement (kernel patches pending)
- boot from El Torito iso images on virtio-blk
  (boot from scsi pending)
- cleanup in the ipl device code

There's also a helper function for resetting busless devices in the
qdev core in there.



Christian Borntraeger (1):
  s390: deprecate the non-ccw machine in 2.5

Cornelia Huck (4):
  s390x/css: sense data endianness
  MAINTAINERS: update s390 file patterns
  MAINTAINERS: update virtio-ccw/s390 git tree
  pc-bios/s390-ccw: rebuild image

David Hildenbrand (3):
  qdev: provide qdev_reset_all_fn()
  s390x/ipl: clean up qom definitions and turn into TYPE_DEVICE
  s390x/ipl: switch error reporting to error_setg

Dominik Dingel (2):
  s390x: switch to memory_region_allocate_system_memory
  s390x/kvm: don't enable CMMA when hugetlbfs will be used

Maxim Samoylov (4):
  pc-bios/s390-ccw: Always adjust virtio sector count
  pc-bios/s390-ccw: ISO-9660 El Torito boot implementation
  pc-bios/s390-ccw: El Torito s390x boot entry check
  pc-bios/s390-ccw: El Torito 16-bit boot image size field workaround

Yi Min Zhao (1):
  s390x/pci : fix up s390 pci iommu translation function

 MAINTAINERS|  20 +++--
 hw/core/qdev.c |   5 ++
 hw/s390x/css.c |   6 ++
 hw/s390x/ipl.c |  68 ---
 hw/s390x/ipl.h |  25 ++
 hw/s390x/s390-pci-bus.c|   8 +-
 hw/s390x/s390-virtio-ccw.c |   3 +-
 hw/s390x/s390-virtio.c |  16 ++--
 include/hw/qdev-core.h |   1 +
 pc-bios/s390-ccw.img   | Bin 13856 -> 17760 bytes
 pc-bios/s390-ccw/bootmap.c | 206 +
 pc-bios/s390-ccw/bootmap.h | 206 +
 pc-bios/s390-ccw/virtio.c  |   7 ++
 pc-bios/s390-ccw/virtio.h  |   8 +-
 target-s390x/kvm.c |   4 +-
 15 files changed, 506 insertions(+), 77 deletions(-)

-- 
2.6.3




[Qemu-devel] [PULL for-2.5 10/15] pc-bios/s390-ccw: El Torito 16-bit boot image size field workaround

2015-11-11 Thread Cornelia Huck
From: Maxim Samoylov 

Because of El Torito spec flaw boot image size needs to be verified.

Boot catalog entry size field has 16-bit width, and specifies size
in 512-byte units.

Thus, boot image size cannot exceed 32M.

We actually search for the file to get the file size.

This is done by scanning the ISO directory tree for the ISO block number
and reading the file size from the directory entry.

Signed-off-by: Maxim Samoylov 
Reviewed-by: David Hildenbrand 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/bootmap.c | 90 ++
 pc-bios/s390-ccw/bootmap.h |  7 
 2 files changed, 97 insertions(+)

diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 82cca9c..415508b 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -462,6 +462,87 @@ static bool is_iso_bc_entry_compatible(IsoBcSection *s)
 return !_memcmp(magic_sec + 8, linux_s390_magic, 24);
 }
 
+/* Location of the current sector of the directory */
+static uint32_t sec_loc[ISO9660_MAX_DIR_DEPTH];
+/* Offset in the current sector of the directory */
+static uint32_t sec_offset[ISO9660_MAX_DIR_DEPTH];
+/* Remained directory space in bytes */
+static uint32_t dir_rem[ISO9660_MAX_DIR_DEPTH];
+
+static inline uint32_t iso_get_file_size(uint32_t load_rba)
+{
+IsoVolDesc *vd = (IsoVolDesc *)sec;
+IsoDirHdr *cur_record = >vd.primary.rootdir;
+uint8_t *temp = sec + ISO_SECTOR_SIZE;
+int level = 0;
+
+read_iso_sector(ISO_PRIMARY_VD_SECTOR, sec,
+"Failed to read ISO primary descriptor");
+sec_loc[0] = iso_733_to_u32(cur_record->ext_loc);
+dir_rem[0] = 0;
+sec_offset[0] = 0;
+
+while (level >= 0) {
+IPL_assert(sec_offset[level] <= ISO_SECTOR_SIZE,
+   "Directory tree structure violation");
+
+cur_record = (IsoDirHdr *)(temp + sec_offset[level]);
+
+if (sec_offset[level] == 0) {
+read_iso_sector(sec_loc[level], temp,
+"Failed to read ISO directory");
+if (dir_rem[level] == 0) {
+/* Skip self and parent records */
+dir_rem[level] = iso_733_to_u32(cur_record->data_len) -
+ cur_record->dr_len;
+sec_offset[level] += cur_record->dr_len;
+
+cur_record = (IsoDirHdr *)(temp + sec_offset[level]);
+dir_rem[level] -= cur_record->dr_len;
+sec_offset[level] += cur_record->dr_len;
+continue;
+}
+}
+
+if (!cur_record->dr_len || sec_offset[level] == ISO_SECTOR_SIZE) {
+/* Zero-padding and/or the end of current sector */
+dir_rem[level] -= ISO_SECTOR_SIZE - sec_offset[level];
+sec_offset[level] = 0;
+sec_loc[level]++;
+} else {
+/* The directory record is valid */
+if (load_rba == iso_733_to_u32(cur_record->ext_loc)) {
+return iso_733_to_u32(cur_record->data_len);
+}
+
+dir_rem[level] -= cur_record->dr_len;
+sec_offset[level] += cur_record->dr_len;
+
+if (cur_record->file_flags & 0x2) {
+/* Subdirectory */
+if (level == ISO9660_MAX_DIR_DEPTH - 1) {
+sclp_print("ISO-9660 directory depth limit exceeded\n");
+} else {
+level++;
+sec_loc[level] = iso_733_to_u32(cur_record->ext_loc);
+sec_offset[level] = 0;
+dir_rem[level] = 0;
+continue;
+}
+}
+}
+
+if (dir_rem[level] == 0) {
+/* Nothing remaining */
+level--;
+read_iso_sector(sec_loc[level], temp,
+"Failed to read ISO directory");
+}
+}
+
+return 0;
+}
+
 static void load_iso_bc_entry(IsoBcSection *load)
 {
 IsoBcSection s = *load;
@@ -470,6 +551,15 @@ static void load_iso_bc_entry(IsoBcSection *load)
  * is padded and ISO_SECTOR_SIZE bytes aligned
  */
 uint32_t blks_to_load = bswap16(s.sector_count) >> ET_SECTOR_SHIFT;
+uint32_t real_size = iso_get_file_size(bswap32(s.load_rba));
+
+if (real_size) {
+/* Round up blocks to load */
+blks_to_load = (real_size + ISO_SECTOR_SIZE - 1) / ISO_SECTOR_SIZE;
+sclp_print("ISO boot image size verified\n");
+} else {
+sclp_print("ISO boot image size could not be verified\n");
+}
 
 read_iso_boot_image(bswap32(s.load_rba),
 (void *)((uint64_t)bswap16(s.load_segment)),
diff --git a/pc-bios/s390-ccw/bootmap.h b/pc-bios/s390-ccw/bootmap.h
index cc77fd7..f98765b 100644
--- a/pc-bios/s390-ccw/bootmap.h
+++ b/pc-bios/s390-ccw/bootmap.h
@@ -381,6 +381,11 @@ static 

Re: [Qemu-devel] [PULL v2 00/40] Block layer patches

2015-11-11 Thread Eric Blake
On 11/11/2015 08:35 AM, Kevin Wolf wrote:

>> Also some warnings:
>>
>> /Users/pm215/src/qemu-for-merges/qemu-io-cmds.c:772:56: warning:
>> format specifies type 'size_t' (aka 'unsigned long') but the argument
>> has type 'unsigned long lo
>> ng' [-Wformat]
>> printf("length cannot exceed %zu, given %s\n", SIZE_MAX, 
>> argv[optind]);
>>  ~~~   ^~~~
>>  %llu
>> /usr/include/stdint.h:153:20: note: expanded from macro 'SIZE_MAX'
>> #define SIZE_MAX  UINT64_MAX
>>   ^~
>> /usr/include/stdint.h:87:27: note: expanded from macro 'UINT64_MAX'
>> #define UINT64_MAX18446744073709551615ULL
>>   ^~~
> 
> Isn't that actually a bug in the system headers? If I understand the
> spec correctly, SIZE_MAX should be size_t. ("this expression shall have
> the same type as would an expression that is an object of the
> corresponding type converted according to the integer promotions.")

You are correct; the system headers are buggy.

-- 
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 v11 21/28] qapi: Convert qtype_code into qapi enum type

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> What's more meta than using qapi to define qapi? :)
>
> Convert qtype_code into a full-fledged[*] builtin qapi enum type,
> so that a subsequent patch can then use it as the discriminator
> type of qapi alternate types.  Doing so is easiest when renaming
> it to qapi conventions, as QTypeCode.

Out of curiosity: why does the rename make the conversion easier?

If we rename anyway, what about renaming to QType?  Hmm, we burned that
on a struct we use only internally in qobject/.  Oh well.

>Fortunately, there are not
> many places in the tree that were actually spelling the type name
> out, and the judicious use of 'prefix' in the qapi defintion

definition

> avoids churn to the spelling of the enum constants.
>
> To avoid circular definitions, we have to flip the order of
> inclusion between "qobject.h" vs. "qapi-types.h".  Back in commit
> 28770e0, we had the latter include the former, so that we could
> use 'QObject *' for our implementation of 'any'.  But that usage
> also works with only a forward declaration, whereas the
> definition of QType requires QTypeCode to be a complete type.
>
> [*] The type has to be builtin, rather than declared in
> qapi/common.json, because we want to use it for alternates even
> when common.json is not included. But since it is the first
> builtin enum type, we have to add special cases to qapi-types
> and qapi-visit to only emit definitions once, even when two
> qapi files are being compiled into the same binary (the way we
> already handled builtin list types like 'intList').  We may
> need to revisit how multiple qapi files share common types,
> but that's a project for another day.
>
> Signed-off-by: Eric Blake 
>
> ---
> v11: new patch
> ---
>  block/qapi.c |  4 ++--
>  docs/qapi-code-gen.txt   |  1 +
>  include/hw/qdev-core.h   |  2 +-
>  include/qapi/qmp/qobject.h   | 19 +++
>  qobject/qdict.c  |  2 +-
>  scripts/qapi-types.py| 13 ++---
>  scripts/qapi-visit.py| 10 --
>  scripts/qapi.py  |  7 ++-
>  tests/qapi-schema/alternate-empty.out|  2 ++
>  tests/qapi-schema/comments.out   |  2 ++
>  tests/qapi-schema/empty.out  |  2 ++
>  tests/qapi-schema/event-case.out |  2 ++
>  tests/qapi-schema/flat-union-empty.out   |  2 ++
>  tests/qapi-schema/ident-with-escape.out  |  2 ++
>  tests/qapi-schema/include-relpath.out|  2 ++
>  tests/qapi-schema/include-repetition.out |  2 ++
>  tests/qapi-schema/include-simple.out |  2 ++
>  tests/qapi-schema/indented-expr.out  |  2 ++
>  tests/qapi-schema/qapi-schema-test.out   |  2 ++
>  tests/qapi-schema/union-clash-data.out   |  2 ++
>  tests/qapi-schema/union-empty.out|  2 ++
>  21 files changed, 58 insertions(+), 26 deletions(-)
>
> diff --git a/block/qapi.c b/block/qapi.c
> index ec0f513..4211f11 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @@ -539,7 +539,7 @@ static void dump_qlist(fprintf_function func_fprintf, 
> void *f, int indentation,
>  int i = 0;
>
>  for (entry = qlist_first(list); entry; entry = qlist_next(entry), i++) {
> -qtype_code type = qobject_type(entry->value);
> +QTypeCode type = qobject_type(entry->value);
>  bool composite = (type == QTYPE_QDICT || type == QTYPE_QLIST);
>  const char *format = composite ? "%*s[%i]:\n" : "%*s[%i]: ";
>
> @@ -557,7 +557,7 @@ static void dump_qdict(fprintf_function func_fprintf, 
> void *f, int indentation,
>  const QDictEntry *entry;
>
>  for (entry = qdict_first(dict); entry; entry = qdict_next(dict, entry)) {
> -qtype_code type = qobject_type(entry->value);
> +QTypeCode type = qobject_type(entry->value);
>  bool composite = (type == QTYPE_QDICT || type == QTYPE_QLIST);
>  const char *format = composite ? "%*s%s:\n" : "%*s%s: ";
>  char key[strlen(entry->key) + 1];
> diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
> index 54a6a7b..35301c5 100644
> --- a/docs/qapi-code-gen.txt
> +++ b/docs/qapi-code-gen.txt
> @@ -163,6 +163,7 @@ The following types are predefined, and map to C as 
> follows:
> accepts size suffixes
>bool  bool   JSON true or false
>any   QObject *  any JSON value
> +  QTypeCode QTypeCode  JSON string of enum QTypeCode values

QTypeCode is currently used only internally, so the JSON values don't
matter.  I don't expect that to change.  However, we either enforce
internal use somehow, or document the JSON values.  Documenting them is
easier.

In short, your patch is fine.

>
>
>  === Includes ===
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index 8057aed..8e7df8e 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -239,7 +239,7 

Re: [Qemu-devel] [PATCH v11 21/28] qapi: Convert qtype_code into qapi enum type

2015-11-11 Thread Eric Blake
On 11/11/2015 09:42 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> What's more meta than using qapi to define qapi? :)
>>
>> Convert qtype_code into a full-fledged[*] builtin qapi enum type,
>> so that a subsequent patch can then use it as the discriminator
>> type of qapi alternate types.  Doing so is easiest when renaming
>> it to qapi conventions, as QTypeCode.
> 
> Out of curiosity: why does the rename make the conversion easier?

It guarantees I found all affected instances.  (Although I guess the
rename could be split to a separate patch from making it builtin).

It makes sure that if we later tighten rules about naming, we won't have
to whitelist 'qtype_code' as an anomaly to our conventions.

> 
> If we rename anyway, what about renaming to QType?  Hmm, we burned that
> on a struct we use only internally in qobject/.  Oh well.

Internal structs are often easy to rename.  So if we want to avoid the
need for 'prefix', I could certainly try to achieve that (move internal
QType out of the way, then rename qtype_code to QType, then make QType
the builtin).  Looks like this one patch just became three :)

> 
>>Fortunately, there are not
>> many places in the tree that were actually spelling the type name
>> out, and the judicious use of 'prefix' in the qapi defintion
> 
> definition

I've got to quit coding late at night - my rate of typos increases :)

>> +++ b/docs/qapi-code-gen.txt
>> @@ -163,6 +163,7 @@ The following types are predefined, and map to C as 
>> follows:
>> accepts size suffixes
>>bool  bool   JSON true or false
>>any   QObject *  any JSON value
>> +  QTypeCode QTypeCode  JSON string of enum QTypeCode values
> 
> QTypeCode is currently used only internally, so the JSON values don't
> matter.  I don't expect that to change.  However, we either enforce
> internal use somehow, or document the JSON values.  Documenting them is
> easier.
> 
> In short, your patch is fine.
> 

>> -
>> -struct QObject;
>> +#include "qapi-types.h"
>>
>>  typedef struct QType {
>> -qtype_code code;
>> +QTypeCode code;
>>  void (*destroy)(struct QObject *);
>>  } QType;
>>
>typedef struct QObject {
>const QType *type;
>size_t refcnt;
>} QObject;
> 
> Note: typedef name QObject still defined here.

Oh, I see what you're saying. Since qapi-types.h now has a forward
declaration of the QObject typedef, this could be changed to just

struct QObject {
...
};

>> +++ b/scripts/qapi-types.py
>> @@ -233,8 +233,14 @@ class QAPISchemaGenTypeVisitor(QAPISchemaVisitor):
>>  self.defn += gen_type_cleanup(name)
>>
>>  def visit_enum_type(self, name, info, values, prefix):
>> -self._fwdecl += gen_enum(name, values, prefix)
>> -self._fwdefn += gen_enum_lookup(name, values, prefix)
>> +# Special case for our lone builtin enum type
>> +if name == 'QTypeCode':
> 
> Would "if not info" work?  Same in qapi-visit.py below.

Feels a bit hacky, since we just recently added is_implicit() to hide
(and then change) the 'if not info' check on objects.  Maybe an accessor
is_builtin() makes more sense?  But yes, same approach to both client files.


>> -#include "qapi/qmp/qobject.h"
>> +
>> +typedef struct QObject QObject;
> 
> Typedef name QObject now also defined here.  GCC accepts this silently
> without -Wpedantic, but other compilers might not.  Whether we care for
> such compilers or not, defining things in exactly one place is neater.
> 
> Possible fixes:
> 
> * Drop the typedef from qobject.h
> 
> * Don't add it to qapi-types.h, and use struct QObject there
> 

I favor dropping the second typedef.


>> +++ b/scripts/qapi.py
>> @@ -33,7 +33,7 @@ builtin_types = {
>>  'uint32':   'QTYPE_QINT',
>>  'uint64':   'QTYPE_QINT',
>>  'size': 'QTYPE_QINT',
>> -'any':  None,   # any qtype_code possible, actually
>> +'any':  None,   # any QTypeCode possible, actually
>>  }
>>
> 
> Should we list QTypeCode here?

Yeah, probably.  This array is only used by the ad hoc parser, and may
disappear later as we move more into check(), but we should be
consistent in the meantime.

> 
>>  # Whitelist of commands allowed to return a non-dictionary
>> @@ -1243,6 +1243,11 @@ class QAPISchema(object):
>>  self.the_empty_object_type = QAPISchemaObjectType(':empty', None, 
>> None,
>>[], None)
>>  self._def_entity(self.the_empty_object_type)
>> +self._def_entity(QAPISchemaEnumType('QTypeCode', None,
>> +['none', 'qnull', 'qint',
>> + 'qstring', 'qdict', 'qlist',
>> + 'qfloat', 'qbool'],
>> +'QTYPE'))
>>
>>  def _make_implicit_enum_type(self, name, info, values):
>>

Re: [Qemu-devel] [PATCH v11 18/28] qerror: more error_setg() usage

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> On 11/11/2015 07:21 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) have snuck in
>>> since c6bd8c706.  Nuke them.
>> 
>> Doesn't really belong to this series, but that's okay.
>
> If you're going to modify this for 2.5 inclusion through your qerror
> tree, you may want to change the description to:

I'll try to get this into 2.5 mostly for the documentation update.

> A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) were missed in
> c6bd8c706, or have snuck in since.  Nuke them.

Done.

>>> +++ b/hw/i386/pc.c
>>> @@ -1795,7 +1795,7 @@ static void pc_machine_set_max_ram_below_4g(Object 
>>> *obj, Visitor *v,
>>>  return;
>>>  }
>>>  if (value > (1ULL << 32)) {
>>> -error_set(, ERROR_CLASS_GENERIC_ERROR,
>>> +error_setg(,
>>>"Machine option 'max-ram-below-4g=%"PRIu64
>>>"' expects size less than or equal to 4G", value);
>> 
>> Indentation is now off.  Can tidy up in my tree.
>> 
>>>  error_propagate(errp, error);
>> [Rest snipped, it looks good]
>> 
>
> There's also the question if we want to address the ErrorClass name
> munging of 19/28 by adding your idea of an aliasing typedef in error.h;
> if so, should I prepare a smaller patch series of both of those changes
> for consideration for 2.5?

Can safely wait for 2.6, can't it?



[Qemu-devel] [PULL 1/1] error: More error_setg() usage

2015-11-11 Thread Markus Armbruster
From: Eric Blake 

A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) were missed in
c6bd8c706, or have snuck in since.  Nuke them.

Signed-off-by: Eric Blake 
Message-Id: <1447224690-9743-19-git-send-email-ebl...@redhat.com>
Acked-by: Andreas Färber 
[Commit message tweaked]
Signed-off-by: Markus Armbruster 

Signed-off-by: Markus Armbruster 
---
 block.c   |  3 +--
 docs/writing-qmp-commands.txt | 20 +---
 hw/i386/pc.c  |  2 +-
 hw/net/rocker/rocker.c|  6 ++
 hw/net/rocker/rocker_of_dpa.c | 12 
 qom/object.c  |  4 ++--
 6 files changed, 19 insertions(+), 28 deletions(-)

diff --git a/block.c b/block.c
index e9f40dc..53a978a 100644
--- a/block.c
+++ b/block.c
@@ -1795,8 +1795,7 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, 
BlockReopenQueue *queue,
 
 ret = bdrv_flush(reopen_state->bs);
 if (ret) {
-error_set(errp, ERROR_CLASS_GENERIC_ERROR, "Error (%s) flushing drive",
-  strerror(-ret));
+error_setg_errno(errp, -ret, "Error flushing drive");
 goto error;
 }
 
diff --git a/docs/writing-qmp-commands.txt b/docs/writing-qmp-commands.txt
index 8647cac..59aa77a 100644
--- a/docs/writing-qmp-commands.txt
+++ b/docs/writing-qmp-commands.txt
@@ -210,7 +210,7 @@ if you don't see these strings, then something went wrong.
 === Errors ===
 
 QMP commands should use the error interface exported by the error.h header
-file. Basically, errors are set by calling the error_set() function.
+file. Basically, most errors are set by calling the error_setg() function.
 
 Let's say we don't accept the string "message" to contain the word "love". If
 it does contain it, we want the "hello-world" command to return an error:
@@ -219,8 +219,7 @@ void qmp_hello_world(bool has_message, const char *message, 
Error **errp)
 {
 if (has_message) {
 if (strstr(message, "love")) {
-error_set(errp, ERROR_CLASS_GENERIC_ERROR,
-  "the word 'love' is not allowed");
+error_setg(errp, "the word 'love' is not allowed");
 return;
 }
 printf("%s\n", message);
@@ -229,10 +228,8 @@ void qmp_hello_world(bool has_message, const char 
*message, Error **errp)
 }
 }
 
-The first argument to the error_set() function is the Error pointer to pointer,
-which is passed to all QMP functions. The second argument is a ErrorClass
-value, which should be ERROR_CLASS_GENERIC_ERROR most of the time (more
-details about error classes are given below). The third argument is a human
+The first argument to the error_setg() function is the Error pointer
+to pointer, which is passed to all QMP functions. The next argument is a human
 description of the error, this is a free-form printf-like string.
 
 Let's test the example above. Build qemu, run it as defined in the "Testing"
@@ -249,8 +246,9 @@ The QMP server's response should be:
 }
 }
 
-As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR. There
-are two exceptions to this rule:
+As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR
+(done by default when using error_setg()). There are two exceptions to
+this rule:
 
  1. A non-generic ErrorClass value exists* for the failure you want to report
 (eg. DeviceNotFound)
@@ -259,8 +257,8 @@ are two exceptions to this rule:
 want to report, hence you have to add a new ErrorClass value so that they
 can check for it
 
-If the failure you want to report doesn't fall in one of the two cases above,
-just report ERROR_CLASS_GENERIC_ERROR.
+If the failure you want to report falls into one of the two cases above,
+use error_set() with a second argument of an ErrorClass value.
 
  * All existing ErrorClass values are defined in the qapi-schema.json file
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0cb8afd..dfb57a8 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1795,7 +1795,7 @@ static void pc_machine_set_max_ram_below_4g(Object *obj, 
Visitor *v,
 return;
 }
 if (value > (1ULL << 32)) {
-error_set(, ERROR_CLASS_GENERIC_ERROR,
+error_setg(,
   "Machine option 'max-ram-below-4g=%"PRIu64
   "' expects size less than or equal to 4G", value);
 error_propagate(errp, error);
diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index bb6fdc3..c57f1a6 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -101,8 +101,7 @@ RockerSwitch *qmp_query_rocker(const char *name, Error 
**errp)
 
 r = rocker_find(name);
 if (!r) {
-error_set(errp, ERROR_CLASS_GENERIC_ERROR,
-  "rocker %s not found", name);
+error_setg(errp, "rocker %s not found", name);
 return NULL;
 }
 
@@ -122,8 +121,7 @@ RockerPortList *qmp_query_rocker_ports(const char *name, 
Error **errp)
 
 

Re: [Qemu-devel] [PATCH v11 18/28] qerror: more error_setg() usage

2015-11-11 Thread Eric Blake
On 11/11/2015 10:31 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> On 11/11/2015 07:21 AM, Markus Armbruster wrote:
>>> Eric Blake  writes:
>>>
 A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) have snuck in
 since c6bd8c706.  Nuke them.
>>>
>>> Doesn't really belong to this series, but that's okay.
>>
>> If you're going to modify this for 2.5 inclusion through your qerror
>> tree, you may want to change the description to:
> 
> I'll try to get this into 2.5 mostly for the documentation update.
> 
>> A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) were missed in
>> c6bd8c706, or have snuck in since.  Nuke them.
> 
> Done.

Oh, and I missed your capitalization preferences in the title:

qerror: More error_setg() usage


>> There's also the question if we want to address the ErrorClass name
>> munging of 19/28 by adding your idea of an aliasing typedef in error.h;
>> if so, should I prepare a smaller patch series of both of those changes
>> for consideration for 2.5?
> 
> Can safely wait for 2.6, can't it?

Yes.  Just trying to make sure I'm focusing on 2.5 patches first.

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



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH for-2.5] qapi: Document introspection stability considerations

2015-11-11 Thread Eric Blake
We are not ready (and might never be ready) to declare
introspection stable between releases. Clients written to
control multiple versions of qemu, and desiring to know
whether a particular member is supported for a given
command, must be prepared to locate that member in spite
of qapi changes that may affect the member's location or
type within the overall object, even though such changes
did not break QMP wire back-compatibility.

Signed-off-by: Eric Blake 
---
 docs/qapi-code-gen.txt | 11 +++
 qapi/introspect.json   |  9 +
 2 files changed, 20 insertions(+)

diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index f9fa6f3..ceb9a78 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -514,6 +514,17 @@ exactly the server (QEMU) supports.
 For this purpose, QMP provides introspection via command
 query-qmp-schema.  QGA currently doesn't support introspection.

+While Client JSON Protocol wire compatibility should be maintained
+between qemu versions, we cannot make the same guarantees for
+introspection stability.  For example, one version of qemu may provide
+a non-variant optional member of a struct, and a later version rework
+the member to instead be non-optional and associated with a variant.
+Likewise, one version of qemu may list a member with open-ended type
+'str', and a later version could convert it to a finite set of strings
+via an enum type; or a member may be converted from a specific type to
+an alternate that represents a choice between the original type and
+something else.
+
 query-qmp-schema returns a JSON array of SchemaInfo objects.  These
 objects together describe the wire ABI, as defined in the QAPI schema.
 There is no specified order to the SchemaInfo objects returned; a
diff --git a/qapi/introspect.json b/qapi/introspect.json
index e7c4c3e..9e9369e 100644
--- a/qapi/introspect.json
+++ b/qapi/introspect.json
@@ -22,6 +22,15 @@
 # what's there), not interface specification.  The specification is in
 # the QAPI schema.
 #
+# Furthermore, while we strive to keep the QMP wire format
+# backwards-compatible across qemu versions, the introspection output
+# is not guaranteed to have the same stability.  For example, one
+# version of qemu may list an object member as an optional
+# non-variant, while another lists the same member only through the
+# object's variants; or the type of a member may change from a generic
+# string into a specific enum or from one specific type into an
+# alternate that includes the original type alongside something else.
+#
 # Returns: array of @SchemaInfo, where each element describes an
 # entity in the ABI: command, event, type, ...
 #
-- 
2.4.3




[Qemu-devel] [PULL for-2.5 08/15] pc-bios/s390-ccw: ISO-9660 El Torito boot implementation

2015-11-11 Thread Cornelia Huck
From: Maxim Samoylov 

This patch enables boot from media formatted according to
ISO-9660 and El Torito bootable CD specification.

We try to boot from device as ISO-9660 media when SCSI IPL failed.

The first boot catalog entry with bootable flag is used.

ISO-9660 media with default 2048-bytes sector size only is supported.

Signed-off-by: Maxim Samoylov 
Reviewed-by: David Hildenbrand 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/bootmap.c | 107 +
 pc-bios/s390-ccw/bootmap.h | 191 +
 pc-bios/s390-ccw/virtio.c  |   7 ++
 pc-bios/s390-ccw/virtio.h  |   1 +
 4 files changed, 306 insertions(+)

diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index b678d5e..7c8dce1 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -445,6 +445,107 @@ static void ipl_scsi(void)
 }
 
 /***
+ * IPL El Torito ISO9660 image or DVD
+ */
+
+static bool is_iso_bc_entry_compatible(IsoBcSection *s)
+{
+return true;
+}
+
+static void load_iso_bc_entry(IsoBcSection *load)
+{
+IsoBcSection s = *load;
+/*
+ * According to spec, extent for each file
+ * is padded and ISO_SECTOR_SIZE bytes aligned
+ */
+uint32_t blks_to_load = bswap16(s.sector_count) >> ET_SECTOR_SHIFT;
+
+read_iso_boot_image(bswap32(s.load_rba),
+(void *)((uint64_t)bswap16(s.load_segment)),
+blks_to_load);
+
+/* Trying to get PSW at zero address */
+if (*((uint64_t *)0) & IPL_PSW_MASK) {
+jump_to_IPL_code((*((uint64_t *)0)) & 0x7fff);
+}
+
+/* Try default linux start address */
+jump_to_IPL_code(KERN_IMAGE_START);
+}
+
+static uint32_t find_iso_bc(void)
+{
+IsoVolDesc *vd = (IsoVolDesc *)sec;
+uint32_t block_num = ISO_PRIMARY_VD_SECTOR;
+
+if (virtio_read_many(block_num++, sec, 1)) {
+/* If primary vd cannot be read, there is no boot catalog */
+return 0;
+}
+
+while (is_iso_vd_valid(vd) && vd->type != VOL_DESC_TERMINATOR) {
+if (vd->type == VOL_DESC_TYPE_BOOT) {
+IsoVdElTorito *et = >vd.boot;
+
+if (!_memcmp(>el_torito[0], el_torito_magic, 32)) {
+return bswap32(et->bc_offset);
+}
+}
+read_iso_sector(block_num++, sec,
+"Failed to read ISO volume descriptor");
+}
+
+return 0;
+}
+
+static IsoBcSection *find_iso_bc_entry(void)
+{
+IsoBcEntry *e = (IsoBcEntry *)sec;
+uint32_t offset = find_iso_bc();
+int i;
+
+if (!offset) {
+return NULL;
+}
+
+read_iso_sector(offset, sec, "Failed to read El Torito boot catalog");
+
+if (!is_iso_bc_valid(e)) {
+/* The validation entry is mandatory */
+virtio_panic("No valid boot catalog found!\n");
+return NULL;
+}
+
+/*
+ * Each entry has 32 bytes size, so one sector cannot contain > 64 entries.
+ * We consider only boot catalogs with no more than 64 entries.
+ */
+for (i = 1; i < ISO_BC_ENTRY_PER_SECTOR; i++) {
+if (e[i].id == ISO_BC_BOOTABLE_SECTION) {
+if (is_iso_bc_entry_compatible([i].body.sect)) {
+return [i].body.sect;
+}
+}
+}
+
+virtio_panic("No suitable boot entry found on ISO-9660 media!\n");
+
+return NULL;
+}
+
+static void ipl_iso_el_torito(void)
+{
+IsoBcSection *s = find_iso_bc_entry();
+
+if (s) {
+load_iso_bc_entry(s);
+/* no return */
+}
+}
+
+/***
  * IPL starts here
  */
 
@@ -463,6 +564,12 @@ void zipl_load(void)
 ipl_scsi(); /* no return */
 }
 
+/* Check if we can boot as ISO media */
+if (virtio_guessed_disk_nature()) {
+virtio_assume_iso9660();
+}
+ipl_iso_el_torito();
+
 /* We have failed to follow the SCSI scheme, so */
 if (virtio_guessed_disk_nature()) {
 sclp_print("Using guessed DASD geometry.\n");
diff --git a/pc-bios/s390-ccw/bootmap.h b/pc-bios/s390-ccw/bootmap.h
index ab132e3..4f6f767 100644
--- a/pc-bios/s390-ccw/bootmap.h
+++ b/pc-bios/s390-ccw/bootmap.h
@@ -341,4 +341,195 @@ static inline bool magic_match(const void *data, const 
void *magic)
 return *((uint32_t *)data) == *((uint32_t *)magic);
 }
 
+static inline int _memcmp(const void *s1, const void *s2, size_t n)
+{
+int i;
+const uint8_t *p1 = s1, *p2 = s2;
+
+for (i = 0; i < n; i++) {
+if (p1[i] != p2[i]) {
+return p1[i] > p2[i] ? 1 : -1;
+}
+}
+
+return 0;
+}
+
+/* from include/qemu/bswap.h */
+
+/* El Torito is always little-endian */
+static inline uint16_t bswap16(uint16_t x)
+{
+return ((x & 0x00ff) << 8) | ((x & 0xff00) >> 8);
+}
+
+static inline 

[Qemu-devel] [PULL for-2.5 09/15] pc-bios/s390-ccw: El Torito s390x boot entry check

2015-11-11 Thread Cornelia Huck
From: Maxim Samoylov 

Boot entry is considered compatible if boot image is Linux kernel
with matching S390 Linux magic string.

Empty boot images with sector_count == 0 are considered broken.

Signed-off-by: Maxim Samoylov 
Reviewed-by: David Hildenbrand 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/bootmap.c | 11 ++-
 pc-bios/s390-ccw/bootmap.h |  8 
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 7c8dce1..82cca9c 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -450,7 +450,16 @@ static void ipl_scsi(void)
 
 static bool is_iso_bc_entry_compatible(IsoBcSection *s)
 {
-return true;
+uint8_t *magic_sec = (uint8_t *)(sec + ISO_SECTOR_SIZE);
+
+if (s->unused || !s->sector_count) {
+return false;
+}
+read_iso_sector(bswap32(s->load_rba), magic_sec,
+"Failed to read image sector 0");
+
+/* Checking bytes 8 - 32 for S390 Linux magic */
+return !_memcmp(magic_sec + 8, linux_s390_magic, 24);
 }
 
 static void load_iso_bc_entry(IsoBcSection *load)
diff --git a/pc-bios/s390-ccw/bootmap.h b/pc-bios/s390-ccw/bootmap.h
index 4f6f767..cc77fd7 100644
--- a/pc-bios/s390-ccw/bootmap.h
+++ b/pc-bios/s390-ccw/bootmap.h
@@ -495,6 +495,14 @@ typedef struct IsoBcHdr {
 uint8_t id[28];
 } __attribute__((packed)) IsoBcHdr;
 
+/*
+ * Match two CCWs located after PSW and eight filler bytes.
+ * From libmagic and arch/s390/kernel/head.S.
+ */
+const uint8_t linux_s390_magic[] = "\x02\x00\x00\x18\x60\x00\x00\x50\x02\x00"
+   "\x00\x68\x60\x00\x00\x50\x40\x40\x40\x40"
+   "\x40\x40\x40\x40";
+
 typedef struct IsoBcEntry {
 uint8_t id;
 union {
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 13/15] s390x/ipl: clean up qom definitions and turn into TYPE_DEVICE

2015-11-11 Thread Cornelia Huck
From: David Hildenbrand 

Let's move the qom definitions of the ipl device into ipl.h, replace
"s390-ipl" by a proper type define, turn it into a TYPE_DEVICE
and remove the unneeded class definition.

Signed-off-by: David Hildenbrand 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/ipl.c | 52 ++
 hw/s390x/ipl.h | 25 
 hw/s390x/s390-virtio.c | 10 +-
 3 files changed, 36 insertions(+), 51 deletions(-)

diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 5f7f349..c75071d 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -15,7 +15,6 @@
 #include "cpu.h"
 #include "elf.h"
 #include "hw/loader.h"
-#include "hw/sysbus.h"
 #include "hw/s390x/virtio-ccw.h"
 #include "hw/s390x/css.h"
 #include "ipl.h"
@@ -29,44 +28,6 @@
 #define ZIPL_IMAGE_START0x009000UL
 #define IPL_PSW_MASK(PSW_MASK_32 | PSW_MASK_64)
 
-#define TYPE_S390_IPL "s390-ipl"
-#define S390_IPL(obj) \
-OBJECT_CHECK(S390IPLState, (obj), TYPE_S390_IPL)
-#if 0
-#define S390_IPL_CLASS(klass) \
-OBJECT_CLASS_CHECK(S390IPLState, (klass), TYPE_S390_IPL)
-#define S390_IPL_GET_CLASS(obj) \
-OBJECT_GET_CLASS(S390IPLState, (obj), TYPE_S390_IPL)
-#endif
-
-typedef struct S390IPLClass {
-/*< private >*/
-SysBusDeviceClass parent_class;
-/*< public >*/
-
-void (*parent_reset) (SysBusDevice *dev);
-} S390IPLClass;
-
-typedef struct S390IPLState {
-/*< private >*/
-SysBusDevice parent_obj;
-uint64_t start_addr;
-uint64_t bios_start_addr;
-bool enforce_bios;
-IplParameterBlock iplb;
-bool iplb_valid;
-bool reipl_requested;
-
-/*< public >*/
-char *kernel;
-char *initrd;
-char *cmdline;
-char *firmware;
-uint8_t cssid;
-uint8_t ssid;
-uint16_t devno;
-} S390IPLState;
-
 static const VMStateDescription vmstate_iplb = {
 .name = "ipl/iplb",
 .version_id = 0,
@@ -110,7 +71,7 @@ static uint64_t bios_translate_addr(void *opaque, uint64_t 
srcaddr)
 return srcaddr + dstaddr;
 }
 
-static int s390_ipl_init(SysBusDevice *dev)
+static void s390_ipl_realize(DeviceState *dev, Error **errp)
 {
 S390IPLState *ipl = S390_IPL(dev);
 uint64_t pentry = KERN_IMAGE_START;
@@ -165,7 +126,7 @@ static int s390_ipl_init(SysBusDevice *dev)
 }
 if (kernel_size < 0) {
 fprintf(stderr, "could not load kernel '%s'\n", ipl->kernel);
-return -1;
+exit(1);
 }
 /*
  * Is it a Linux kernel (starting at 0x1)? If yes, we fill in the
@@ -205,7 +166,7 @@ static int s390_ipl_init(SysBusDevice *dev)
 stq_p(rom_ptr(INITRD_PARM_SIZE), initrd_size);
 }
 }
-return 0;
+qemu_register_reset(qdev_reset_all_fn, dev);
 }
 
 static Property s390_ipl_properties[] = {
@@ -308,9 +269,8 @@ static void s390_ipl_reset(DeviceState *dev)
 static void s390_ipl_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
 
-k->init = s390_ipl_init;
+dc->realize = s390_ipl_realize;
 dc->props = s390_ipl_properties;
 dc->reset = s390_ipl_reset;
 dc->vmsd = _ipl;
@@ -319,8 +279,8 @@ static void s390_ipl_class_init(ObjectClass *klass, void 
*data)
 
 static const TypeInfo s390_ipl_info = {
 .class_init = s390_ipl_class_init,
-.parent = TYPE_SYS_BUS_DEVICE,
-.name  = "s390-ipl",
+.parent = TYPE_DEVICE,
+.name  = TYPE_S390_IPL,
 .instance_size  = sizeof(S390IPLState),
 };
 
diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
index 7f2b403..6b48ed7 100644
--- a/hw/s390x/ipl.h
+++ b/hw/s390x/ipl.h
@@ -12,6 +12,7 @@
 #ifndef HW_S390_IPL_H
 #define HW_S390_IPL_H
 
+#include "hw/qdev.h"
 #include "cpu.h"
 
 typedef struct IplParameterBlock {
@@ -25,4 +26,28 @@ void s390_ipl_prepare_cpu(S390CPU *cpu);
 IplParameterBlock *s390_ipl_get_iplb(void);
 void s390_reipl_request(void);
 
+#define TYPE_S390_IPL "s390-ipl"
+#define S390_IPL(obj) OBJECT_CHECK(S390IPLState, (obj), TYPE_S390_IPL)
+
+struct S390IPLState {
+/*< private >*/
+DeviceState parent_obj;
+uint64_t start_addr;
+uint64_t bios_start_addr;
+bool enforce_bios;
+IplParameterBlock iplb;
+bool iplb_valid;
+bool reipl_requested;
+
+/*< public >*/
+char *kernel;
+char *initrd;
+char *cmdline;
+char *firmware;
+uint8_t cssid;
+uint8_t ssid;
+uint16_t devno;
+};
+typedef struct S390IPLState S390IPLState;
+
 #endif
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index cbde977..cebebb1 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -31,7 +31,6 @@
 #include "hw/boards.h"
 #include "hw/loader.h"
 #include "hw/virtio/virtio.h"
-#include "hw/sysbus.h"
 #include "sysemu/kvm.h"
 #include "exec/address-spaces.h"
 
@@ -151,9 +150,9 @@ void s390_init_ipl_dev(const 

[Qemu-devel] [PULL v2 1/1] error: More error_setg() usage

2015-11-11 Thread Markus Armbruster
From: Eric Blake 

A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) were missed in
c6bd8c706, or have snuck in since.  Nuke them.

Signed-off-by: Eric Blake 
Message-Id: <1447224690-9743-19-git-send-email-ebl...@redhat.com>
Acked-by: Andreas Färber 
[Indentation tidied up, commit message tweaked]
Signed-off-by: Markus Armbruster 
---
 block.c   |  3 +--
 docs/writing-qmp-commands.txt | 20 +---
 hw/i386/pc.c  |  6 +++---
 hw/net/rocker/rocker.c|  6 ++
 hw/net/rocker/rocker_of_dpa.c | 12 
 qom/object.c  |  4 ++--
 6 files changed, 21 insertions(+), 30 deletions(-)

diff --git a/block.c b/block.c
index e9f40dc..53a978a 100644
--- a/block.c
+++ b/block.c
@@ -1795,8 +1795,7 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, 
BlockReopenQueue *queue,
 
 ret = bdrv_flush(reopen_state->bs);
 if (ret) {
-error_set(errp, ERROR_CLASS_GENERIC_ERROR, "Error (%s) flushing drive",
-  strerror(-ret));
+error_setg_errno(errp, -ret, "Error flushing drive");
 goto error;
 }
 
diff --git a/docs/writing-qmp-commands.txt b/docs/writing-qmp-commands.txt
index 8647cac..59aa77a 100644
--- a/docs/writing-qmp-commands.txt
+++ b/docs/writing-qmp-commands.txt
@@ -210,7 +210,7 @@ if you don't see these strings, then something went wrong.
 === Errors ===
 
 QMP commands should use the error interface exported by the error.h header
-file. Basically, errors are set by calling the error_set() function.
+file. Basically, most errors are set by calling the error_setg() function.
 
 Let's say we don't accept the string "message" to contain the word "love". If
 it does contain it, we want the "hello-world" command to return an error:
@@ -219,8 +219,7 @@ void qmp_hello_world(bool has_message, const char *message, 
Error **errp)
 {
 if (has_message) {
 if (strstr(message, "love")) {
-error_set(errp, ERROR_CLASS_GENERIC_ERROR,
-  "the word 'love' is not allowed");
+error_setg(errp, "the word 'love' is not allowed");
 return;
 }
 printf("%s\n", message);
@@ -229,10 +228,8 @@ void qmp_hello_world(bool has_message, const char 
*message, Error **errp)
 }
 }
 
-The first argument to the error_set() function is the Error pointer to pointer,
-which is passed to all QMP functions. The second argument is a ErrorClass
-value, which should be ERROR_CLASS_GENERIC_ERROR most of the time (more
-details about error classes are given below). The third argument is a human
+The first argument to the error_setg() function is the Error pointer
+to pointer, which is passed to all QMP functions. The next argument is a human
 description of the error, this is a free-form printf-like string.
 
 Let's test the example above. Build qemu, run it as defined in the "Testing"
@@ -249,8 +246,9 @@ The QMP server's response should be:
 }
 }
 
-As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR. There
-are two exceptions to this rule:
+As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR
+(done by default when using error_setg()). There are two exceptions to
+this rule:
 
  1. A non-generic ErrorClass value exists* for the failure you want to report
 (eg. DeviceNotFound)
@@ -259,8 +257,8 @@ are two exceptions to this rule:
 want to report, hence you have to add a new ErrorClass value so that they
 can check for it
 
-If the failure you want to report doesn't fall in one of the two cases above,
-just report ERROR_CLASS_GENERIC_ERROR.
+If the failure you want to report falls into one of the two cases above,
+use error_set() with a second argument of an ErrorClass value.
 
  * All existing ErrorClass values are defined in the qapi-schema.json file
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0cb8afd..5e20e07 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1795,9 +1795,9 @@ static void pc_machine_set_max_ram_below_4g(Object *obj, 
Visitor *v,
 return;
 }
 if (value > (1ULL << 32)) {
-error_set(, ERROR_CLASS_GENERIC_ERROR,
-  "Machine option 'max-ram-below-4g=%"PRIu64
-  "' expects size less than or equal to 4G", value);
+error_setg(,
+   "Machine option 'max-ram-below-4g=%"PRIu64
+   "' expects size less than or equal to 4G", value);
 error_propagate(errp, error);
 return;
 }
diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index bb6fdc3..c57f1a6 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -101,8 +101,7 @@ RockerSwitch *qmp_query_rocker(const char *name, Error 
**errp)
 
 r = rocker_find(name);
 if (!r) {
-error_set(errp, ERROR_CLASS_GENERIC_ERROR,
-  "rocker %s not found", name);
+error_setg(errp, "rocker %s not found", 

[Qemu-devel] [PULL 0/1] Block patches

2015-11-11 Thread Jeff Cody
The following changes since commit 3c07587d49458341510360557c849e93e9afaf59:

  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-next-2015' into 
staging (2015-11-11 09:34:18 +)

are available in the git repository at:


  g...@github.com:codyprime/qemu-kvm-jtc.git tags/block-pull-request

for you to fetch changes up to c833d1e8f5e95762336a823a35ade65a2d0fe587:

  gluster: allocate GlusterAIOCBs on the stack (2015-11-11 10:45:39 -0500)


Block patches


Paolo Bonzini (1):
  gluster: allocate GlusterAIOCBs on the stack

 block/gluster.c | 86 ++---
 1 file changed, 33 insertions(+), 53 deletions(-)

-- 
1.9.3




Re: [Qemu-devel] [PULL v3 00/41] Block layer patches

2015-11-11 Thread Peter Maydell
On 11 November 2015 at 16:08, Kevin Wolf <kw...@redhat.com> wrote:
> The following changes since commit 3c07587d49458341510360557c849e93e9afaf59:
>
>   Merge remote-tracking branch 'remotes/dgibson/tags/ppc-next-2015' into 
> staging (2015-11-11 09:34:18 +)
>
> are available in the git repository at:
>
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to 4d07c720f44beafd10907cecfd5b8a57622243c1:
>
>   Merge remote-tracking branch 'mreitz/tags/pull-block-for-kevin-2015-11-11' 
> into queue-block (2015-11-11 17:02:02 +0100)
>
> 
>
> Block layer patches
>
> 

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH v13 06/13] aer: impove pcie_aer_init to support vfio device

2015-11-11 Thread Michael S. Tsirkin
On Wed, Nov 11, 2015 at 06:34:24PM +0800, Cao jin wrote:
> From: Chen Fan 
> 
> pcie_aer_init was used to emulate an aer capability for pcie device,
> but for vfio device, the aer config space size is mutable and is not
> always equal to PCI_ERR_SIZEOF(0x48). it depends on where the TLP Prefix
> register required, so here we add a size argument.
> 
> Signed-off-by: Chen Fan 

Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/pci-bridge/ioh3420.c| 2 +-
>  hw/pci-bridge/xio3130_downstream.c | 2 +-
>  hw/pci-bridge/xio3130_upstream.c   | 2 +-
>  hw/pci/pcie_aer.c  | 4 ++--
>  include/hw/pci/pcie_aer.h  | 2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
> index cce2fdd..4d9cd3f 100644
> --- a/hw/pci-bridge/ioh3420.c
> +++ b/hw/pci-bridge/ioh3420.c
> @@ -129,7 +129,7 @@ static int ioh3420_initfn(PCIDevice *d)
>  goto err_pcie_cap;
>  }
>  pcie_cap_root_init(d);
> -rc = pcie_aer_init(d, IOH_EP_AER_OFFSET);
> +rc = pcie_aer_init(d, IOH_EP_AER_OFFSET, PCI_ERR_SIZEOF);
>  if (rc < 0) {
>  goto err;
>  }
> diff --git a/hw/pci-bridge/xio3130_downstream.c 
> b/hw/pci-bridge/xio3130_downstream.c
> index b3a6479..9737041 100644
> --- a/hw/pci-bridge/xio3130_downstream.c
> +++ b/hw/pci-bridge/xio3130_downstream.c
> @@ -92,7 +92,7 @@ static int xio3130_downstream_initfn(PCIDevice *d)
>  goto err_pcie_cap;
>  }
>  pcie_cap_arifwd_init(d);
> -rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
> +rc = pcie_aer_init(d, XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
>  if (rc < 0) {
>  goto err;
>  }
> diff --git a/hw/pci-bridge/xio3130_upstream.c 
> b/hw/pci-bridge/xio3130_upstream.c
> index eada582..4d7f894 100644
> --- a/hw/pci-bridge/xio3130_upstream.c
> +++ b/hw/pci-bridge/xio3130_upstream.c
> @@ -81,7 +81,7 @@ static int xio3130_upstream_initfn(PCIDevice *d)
>  }
>  pcie_cap_flr_init(d);
>  pcie_cap_deverr_init(d);
> -rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
> +rc = pcie_aer_init(d, XIO3130_AER_OFFSET, PCI_ERR_SIZEOF);
>  if (rc < 0) {
>  goto err;
>  }
> diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
> index 98d2c18..45f351b 100644
> --- a/hw/pci/pcie_aer.c
> +++ b/hw/pci/pcie_aer.c
> @@ -94,12 +94,12 @@ static void aer_log_clear_all_err(PCIEAERLog *aer_log)
>  aer_log->log_num = 0;
>  }
>  
> -int pcie_aer_init(PCIDevice *dev, uint16_t offset)
> +int pcie_aer_init(PCIDevice *dev, uint16_t offset, uint16_t size)
>  {
>  PCIExpressDevice *exp;
>  
>  pcie_add_capability(dev, PCI_EXT_CAP_ID_ERR, PCI_ERR_VER,
> -offset, PCI_ERR_SIZEOF);
> +offset, size);
>  exp = >exp;
>  exp->aer_cap = offset;
>  
> diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
> index 2fb8388..156acb0 100644
> --- a/include/hw/pci/pcie_aer.h
> +++ b/include/hw/pci/pcie_aer.h
> @@ -87,7 +87,7 @@ struct PCIEAERErr {
>  
>  extern const VMStateDescription vmstate_pcie_aer_log;
>  
> -int pcie_aer_init(PCIDevice *dev, uint16_t offset);
> +int pcie_aer_init(PCIDevice *dev, uint16_t offset, uint16_t size);
>  void pcie_aer_exit(PCIDevice *dev);
>  void pcie_aer_write_config(PCIDevice *dev,
> uint32_t addr, uint32_t val, int len);
> -- 
> 1.9.3



Re: [Qemu-devel] [PATCH v13 11/13] pcie_aer: expose pcie_aer_msg() interface

2015-11-11 Thread Michael S. Tsirkin
On Wed, Nov 11, 2015 at 06:34:29PM +0800, Cao jin wrote:
> From: Chen Fan 
> 
> For vfio device, we need to propagate the aer error to
> Guest OS. we use the pcie_aer_msg() to send aer error
> to guest.
> 
> Signed-off-by: Chen Fan 

Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/pci/pcie_aer.c | 2 +-
>  include/hw/pci/pcie_aer.h | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
> index 45f351b..fbbd7d2 100644
> --- a/hw/pci/pcie_aer.c
> +++ b/hw/pci/pcie_aer.c
> @@ -370,7 +370,7 @@ static void pcie_aer_msg_root_port(PCIDevice *dev, const 
> PCIEAERMsg *msg)
>   *
>   * Walk up the bus tree from the device, propagate the error message.
>   */
> -static void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg)
> +void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg)
>  {
>  uint8_t type;
>  
> diff --git a/include/hw/pci/pcie_aer.h b/include/hw/pci/pcie_aer.h
> index 156acb0..c2ee4e2 100644
> --- a/include/hw/pci/pcie_aer.h
> +++ b/include/hw/pci/pcie_aer.h
> @@ -102,5 +102,6 @@ void pcie_aer_root_write_config(PCIDevice *dev,
>  
>  /* error injection */
>  int pcie_aer_inject_error(PCIDevice *dev, const PCIEAERErr *err);
> +void pcie_aer_msg(PCIDevice *dev, const PCIEAERMsg *msg);
>  
>  #endif /* QEMU_PCIE_AER_H */
> -- 
> 1.9.3



Re: [Qemu-devel] [PATCH v11 13/28] qapi: Hoist tag collision check to Variants.check()

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> On 11/11/2015 06:56 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> Checking that a given QAPISchemaObjectTypeVariant.name is a
>>> member of the corresponding QAPISchemaEnumType of the owning
>>> QAPISchemaObjectTypeVariants.tag_member ensures that there are
>>> no collisions in the generated C union for those tag values
>>> (since the enum itself should have no collisions).
>>>
>>> However, this check was the only thing that Variant.check() was
>>> doing beyond the work of the superclass ObjectTypeMember.check(),
>> 
>> Since PATCH 05, actually.  Suggest to mention that.
>
> I debated about munging patch 5 or 6 to actually make this change there;
> but decided that separate is just fine.  But yes, mentioning the earlier
> commit title will help.
>
>>> @@ -1075,10 +1076,6 @@ class 
>>> QAPISchemaObjectTypeVariant(QAPISchemaObjectTypeMember):
>>>  def __init__(self, name, typ):
>>>  QAPISchemaObjectTypeMember.__init__(self, name, typ, False)
>>>
>>> -def check(self, schema, tag_type):
>>> -QAPISchemaObjectTypeMember.check(self, schema)
>>> -assert self.name in tag_type.values
>>> -
>>>  # This function exists to support ugly simple union special cases
>>>  # TODO get rid of them, and drop the function
>>>  def simple_union_type(self):
>> 
>> QAPISchemaObjectTypeVariant is now an almost trivial variation of
>> QAPISchemaObjectTypeMember.  Differences:
>> 
>> * __init__() has no parameter optional
>> 
>> * Method simple_union_type(), which exists only to support pointless
>>   differences in code generation for simple unions, all marked TODO.
>> 
>> There's hope we can get rid of the class after the TODOs are resolved.
>
> Nope. Because in 15/28 I add back in a non-trivial difference of "role =
> 'branch'" compared to the superclass "role = 'member'", which affects
> the quality of error messages using .describe().
>
> That, and I still have no idea how to get rid of the TODO (we know how
> to convert simple unions to flat unions, but the conversion is an
> either-or choice: either we keep the C layout the same but change {} in
> the JSON representation, or we keep QMP the same but affect the C layout
> - so fixing the TODO has to resolve that discrepancy, and may end up
> touching lots of code).

I'm not afraid of touching lots of QEMU code when I have a good reason.
Anyway, it's not something we should worry about right now.



[Qemu-devel] [PATCH 0/4] target-ppc/spapr: Add FWNMI support in QEMU for PowerKVM guests

2015-11-11 Thread Aravinda Prasad
This series of patches add support for FWNMI in PowerKVM guests.

Memory error such as bit flips that cannot be corrected
by hardware is passed on to the kernel for handling
by raising machine check exception (an NMI). Upon such
machine check exception, if the address in error belongs
to guest then KVM causes a guest exit with KVM_EXIT_NMI
exit reason [1].

This patch series adds functionality to pass on such
machine check exception to the guest kernel by suitably
handling KVM_EXIT_NMI exit and building the error log.
This patch series explores the alternate design
discussed in the QEMU mailing list [2], [3].

In earlier design [2] KVM invoked guest's NMI interrupt
vector 0x200 upon machine check exception, while QEMU
patched 0x200 vector to issue hcall to facilitate
building and copying of error log into RTAS space.

The new design simplifies couple of things. Thanks to
David Gibson for the suggestion:

- Eliminates patching of 0x200 interrupt vector from
  QEMU, hence, trampoline not required
- Avoids introducing a new private hcall to be called
  from guest's 0x200 vector to enable QEMU to build
  error log
- Simplifies re-trying by other processors when one
  of the processor is consuming/processing the error
  log.

[1] http://marc.info/?l=kvm-ppc=144726114408289
[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-11/msg00813.html
[3] https://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg00898.html

---

Aravinda Prasad (4):
  spapr: Extend rtas-blob
  spapr: Register and handle HCALL to receive updated RTAS region
  spapr: Handle "ibm,nmi-register" and "ibm,nmi-interlock" RTAS calls
  target-ppc: Handle NMI guest exit


 hw/ppc/spapr.c |4 ++
 hw/ppc/spapr_hcall.c   |8 +
 hw/ppc/spapr_rtas.c|   29 +
 include/hw/ppc/spapr.h |   11 +--
 target-ppc/kvm.c   |   69 +
 target-ppc/kvm_ppc.h   |   81 
 6 files changed, 200 insertions(+), 2 deletions(-)

-- 
Aravinda Prasad




[Qemu-devel] [PULL for-2.5 07/15] pc-bios/s390-ccw: Always adjust virtio sector count

2015-11-11 Thread Cornelia Huck
From: Maxim Samoylov 

Let's always adjust the sector number to be read using the current
virtio block size value.

This prepares for the implementation of IPL from ISO-9660 media.

Signed-off-by: Maxim Samoylov 
Reviewed-by: David Hildenbrand 
Reviewed-by: Cornelia Huck 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/virtio.h | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/pc-bios/s390-ccw/virtio.h b/pc-bios/s390-ccw/virtio.h
index c23466b..76c42f1 100644
--- a/pc-bios/s390-ccw/virtio.h
+++ b/pc-bios/s390-ccw/virtio.h
@@ -199,14 +199,9 @@ extern int virtio_read_many(ulong sector, void *load_addr, 
int sec_num);
 
 #define VIRTIO_SECTOR_SIZE 512
 
-static inline ulong virtio_eckd_sector_adjust(ulong sector)
-{
- return sector * (virtio_get_block_size() / VIRTIO_SECTOR_SIZE);
-}
-
 static inline ulong virtio_sector_adjust(ulong sector)
 {
-return virtio_disk_is_eckd() ? virtio_eckd_sector_adjust(sector) : sector;
+return sector * (virtio_get_block_size() / VIRTIO_SECTOR_SIZE);
 }
 
 #endif /* VIRTIO_H */
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 02/15] s390x/pci : fix up s390 pci iommu translation function

2015-11-11 Thread Cornelia Huck
From: Yi Min Zhao 

On s390x, each pci device has its own iommu, which is only properly
setup in qemu once the mpcifc instruction used to register the
translation table has been intercepted. Therefore, for a pci device that
is not configured or has not been initialized, proper translation is
neither required nor possible. Moreover, we may not have a host bridge
device ready yet.

This was exposed by a recent vfio change that triggers iommu translation
during the initialization of the vfio pci device. Let's do an early exit
in that case.

Reviewed-by: Cornelia Huck 
Reviewed-by: Jens Freimann 
Signed-off-by: Yi Min Zhao 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-pci-bus.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 560b66a..d5712ae 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -309,8 +309,7 @@ static IOMMUTLBEntry s390_translate_iommu(MemoryRegion 
*iommu, hwaddr addr,
 uint64_t pte;
 uint32_t flags;
 S390PCIBusDevice *pbdev = container_of(iommu, S390PCIBusDevice, mr);
-S390pciState *s = S390_PCI_HOST_BRIDGE(pci_device_root_bus(pbdev->pdev)
-   ->qbus.parent);
+S390pciState *s;
 IOMMUTLBEntry ret = {
 .target_as = _space_memory,
 .iova = 0,
@@ -319,8 +318,13 @@ static IOMMUTLBEntry s390_translate_iommu(MemoryRegion 
*iommu, hwaddr addr,
 .perm = IOMMU_NONE,
 };
 
+if (!pbdev->configured || !pbdev->pdev) {
+return ret;
+}
+
 DPRINTF("iommu trans addr 0x%" PRIx64 "\n", addr);
 
+s = S390_PCI_HOST_BRIDGE(pci_device_root_bus(pbdev->pdev)->qbus.parent);
 /* s390 does not have an APIC mapped to main storage so we use
  * a separate AddressSpace only for msix notifications
  */
-- 
2.6.3




[Qemu-devel] [PULL for-2.5 11/15] pc-bios/s390-ccw: rebuild image

2015-11-11 Thread Cornelia Huck
Contains:
  pc-bios/s390-ccw: Always adjust virtio sector count
  pc-bios/s390-ccw: ISO-9660 El Torito boot implementation
  pc-bios/s390-ccw: El Torito s390x boot entry check
  pc-bios/s390-ccw: El Torito 16-bit boot image size field workaround

Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw.img | Bin 13856 -> 17760 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/pc-bios/s390-ccw.img b/pc-bios/s390-ccw.img
index 
0c540a10cf2a662889f5fbd08a7580395a7577d0..e0d9452945668fa74402c2caf942fc6eec1a9701
 100644
GIT binary patch
literal 17760
zcmeHvdw5jU+3*a;UWKrZoayY9p;mTU)^)-ZIsRQbk4f`MvMndoqc5=3
z{y2ZQpJ(=3`(5vCy|=a2-hm$!mo2i{6pCGT8jrpSNbs0%Wb#lZW#Bmx
zzXX93V8%6~RZbXSt0gC%?f5wixNZLFTN-V^V=e2~z(tud4%8yLPy5d@B
zG_+(ytIQFA@`?!;IvXDTcXTGcX*QDi@!YKWl^6)N5iRAIgjVaQ3G{o1=*~0YBU@#X
zL1(qZbV~tCGWq>?8x?fRfNbjdwRSQ2#pb7+S6{dKy!x8CbMl(~c{630d5p!+{+-Lq
z$@TEe^6V>*^=H01^0)cco++~5#Kf~4xOAaI1R&}hh#JJq0z)|VTngdl$0e~86XhU67pw7Rlv8ti2nyUQ`%`NMEtD39p8&}me1gNR5
zVeP7_CSR4w$85YVvy*1DmK?7(9B$3qn>!rdNCVGAD<~%%)pParJ^e&!7xW$`n(-|6
z)#H)Fl&5d${T9(#hXyVqmC_<(XXIs+cmF3{oUcW9_nwK7=NOmTBe|$PTYF~!@)Scx
z|6cCb06vShazClH2YO{p5!Atyfs9?bohk#7lK2Tczy&~@SaQ^8vknX11|TZ4Zi
zrRVREV-LQ9-!c7d=B2(VIQyjkuJpT-~
zs7LHvsju&>{SO6x>G?yi?cr{Du^p>+FJ
z+*9?fw<&!I!2o3hpCBc8zkVzTuZBH?Dml8x(qu?FLXM>4?1`LD*(RfpL~`{3+8Wu0
z)nRK`?MtMNh)aK~asw!puTt{7Sf8B3{blqNkyoXC#%z<420n~7TJvDusf$A
zcpU!46;_dJORc+bWc+db
zywJ|vQm=;x#u@RGK2!Kl7XCL$f0FdEUO?7S0FEugZ*XEhY_FMsI-zT_TyqROiCxYpjD`?lKA1o}_2uJ;p!=9#S7|UyLmp}roNnYHMy9chu8Ua1
zl)=bUx(6#ARt41YpAGz!qdq?i*{O0p0Cu)$d@FOr{Jzk)1alQV(xo42-2i<$A-C0?
zKpkR%KSXYzajhFPEhLIbVw;U(eQ0F!iIq|2lg-
zDv_H~hgIwQMr@3dJ%dwf>Zo6e2I-=~IMHAq;#%T&)Myza8Iu@K`ds>o;Oz$9vfyG;
z*z(5!$&-kvto=U}*ZOo9)>OITrfJauB%GElf^H8{*Rv07EE8Zw##P1kv@

[Qemu-devel] [PULL for-2.5 12/15] qdev: provide qdev_reset_all_fn()

2015-11-11 Thread Cornelia Huck
From: David Hildenbrand 

For TYPE_DEVICE, the dc->reset() function is not called on system resets
yet. Until that is changed, we have to manually register a reset handler.
Let's provide qdev_reset_all_fn(), that can directly be used - just like
the reset handler that is already available for qbus.

Reviewed-by: Cornelia Huck 
Signed-off-by: David Hildenbrand 
Signed-off-by: Cornelia Huck 
---
 hw/core/qdev.c | 5 +
 include/hw/qdev-core.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4ab04aa..b3ad467 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -325,6 +325,11 @@ void qdev_reset_all(DeviceState *dev)
 qdev_walk_children(dev, NULL, NULL, qdev_reset_one, qbus_reset_one, NULL);
 }
 
+void qdev_reset_all_fn(void *opaque)
+{
+qdev_reset_all(DEVICE(opaque));
+}
+
 void qbus_reset_all(BusState *bus)
 {
 qbus_walk_children(bus, NULL, NULL, qdev_reset_one, qbus_reset_one, NULL);
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 8057aed..e6dbde4 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -337,6 +337,7 @@ int qdev_walk_children(DeviceState *dev,
void *opaque);
 
 void qdev_reset_all(DeviceState *dev);
+void qdev_reset_all_fn(void *opaque);
 
 /**
  * @qbus_reset_all:
-- 
2.6.3




Re: [Qemu-devel] [PATCH v11 19/28] qapi: Change munging of CamelCase enum values

2015-11-11 Thread Markus Armbruster
Eric Blake  writes:

> When munging enum values, the fact that we were passing the entire
> prefix + value through camel_to_upper() meant that enum values
> spelled with CamelCase could be turned into CAMEL_CASE.  However,
> this provides a potential collision (both OneTwo and One-Two would
> munge into ONE_TWO).  By changing the generation of enum constants
> to always be prefix + '_' + c_name(value).upper(), we can avoid
> any risk of collisions (if we can also ensure no case collisions,
> in the next patch) without having to think about what the
> heuristics in camel_to_upper() will actually do to the value.

This is the good part: the rules for clashes become much simpler.

Bonus: the implementation for detecting them will be simple, too.

> Thankfully, only two enums are affected: ErrorClass and InputButton.

By convention (see CODING_STYLE), we use CamelCase for type names, and
nothing else.

Only enums violating this naming convention can be affected.  The bad
part: they exist.

InputButton has two camels: WheelUp and WheelDown.  The C enumeration
constants change from INPUT_BUTTON_WHEEL_UP/WHEEL_DOWN to
INPUT_BUTTON_WHEELUP/WHEELDOWN.  Not exactly an improvement, but one,
there are just 21 occurences in 11 files, and two, I think we can still
fix the enumeration to "lower case with dash", as it's only used by
x-input-send-event.

ErrorClass's members are all camels.  The C enumeration constants change
as follows

ERROR_CLASS_GENERIC_ERROR   ERROR_CLASS_GENERICERROR
ERROR_CLASS_COMMAND_NOT_FOUND   ERROR_CLASS_COMMANDNOTFOUND
ERROR_CLASS_DEVICE_ENCRYPTEDERROR_CLASS_DEVICEENCRYPTED
ERROR_CLASS_DEVICE_NOT_ACTIVE   ERROR_CLASS_DEVICENOTACTIVE
ERROR_CLASS_DEVICE_NOT_FOUNDERROR_CLASS_DEVICENOTFOUND
ERROR_CLASS_KVM_MISSING_CAP ERROR_CLASS_KVMMISSINGCAP

Again, not an improvement, but perhaps tolerabe, because these constants
aren't used much anymore: 55 occurences in 20 files.

If we find it not tolerable, we can manually add aliases: rename the
QAPI type out of the way, say 'QAPIErrorClass', then stick

typedef enum ErrorClass {
ERROR_CLASS_GENERIC_ERROR = QAPI_ERROR_CLASS_GENERICERROR,
ERROR_CLASS_COMMAND_NOT_FOUND = QAPI_ERROR_CLASS_COMMANDNOTFOUND,
ERROR_CLASS_DEVICE_ENCRYPTED = QAPI_ERROR_CLASS_DEVICEENCRYPTED,
ERROR_CLASS_DEVICE_NOT_ACTIVE = QAPI_ERROR_CLASS_DEVICENOTACTIVE,
ERROR_CLASS_DEVICE_NOT_FOUND = QAPI_ERROR_CLASS_DEVICENOTFOUND,
ERROR_CLASS_KVM_MISSING_CAP = QAPI_ERROR_CLASS_KVMMISSINGCAP,
} ErrorClass;

into error.h with a suitable comment.

Opinions?



Re: [Qemu-devel] [PATCH] qga: fix append file open modes for win32

2015-11-11 Thread Paolo Bonzini


On 11/11/2015 15:02, Michael Roth wrote:
>> GENERIC_READ for files
>> = FILE_READ_DATA
>> + FILE_READ_ATTRIBUTES
>> + FILE_READ_EA
>> + SYNCHRONIZE
>> + STANDARD_RIGHTS_READ (which is READ_CONTROL)
>>
>> GENERIC_WRITE for files
>> = FILE_APPEND_DATA
>> + FILE_WRITE_DATA
>> + FILE_WRITE_ATTRIBUTES
>> + FILE_WRITE_EA
>> + SYNCHRONIZE
>> + STANDARD_RIGHTS_WRITE (which is READ_CONTROL too!)
>>
>> Of these of course qemu-ga only needs FILE_*_DATA and possibly SYNCHRONIZE.
>>
>> The above description doesn't say what happens if you specify
>> FILE_READ_DATA and FILE_APPEND_DATA together, but I guess you can expect
>> it to just work.
> 
> Thanks, this is very helpful. This seems to coincide with
> FILE_GENERIC_WRITE / FILE_GENERIC_READ if you want to access the
> bitmasks directly (though it looks like you can still add flags
> to GENERIC_WRITE / GENERIC_READ):
> 
>   
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa364399(v=vs.85).aspx

Yes, I had missed the FILE_GENERIC_* definitions.  I found them now in
mingw as well, and they are exactly what you would expect (an | of the
various flags).

> Looks like the crux of it is that FILE_WRITE_DATA causes us not to ignore
> the start offset (0) for writes, so we end up writing data at the
> beginning of the file instead of the end.
> 
> So I think the following
> should work:
> 
>   a: FILE_GENERIC_WRITE & ~FILE_WRITE_DATA
>   a+: FILE_GENERIC_READ | FILE_APPEND_DATA
> 
> FILE_APPEND_DATA by itself might work for a:, but for consistency I
> think I'd prefer sticking with the generic set and masking out
> FILE_WRITE_DATA.

For a+ I would use any of

(FILE_GENERIC_READ | FILE_GENERIC_WRITE) & ~FILE_WRITE_DATA
GENERIC_READ | (FILE_GENERIC_WRITE & ~FILE_WRITE_DATA)

Perhaps you can define this:

#define FILE_GENERIC_APPEND (FILE_GENERIC_WRITE & ~FILE_WRITE_DATA)

and then use

a: FILE_GENERIC_APPEND
a+: GENERIC_READ|FILE_GENERIC_APPEND

or

a: FILE_GENERIC_APPEND
a+: FILE_GENERIC_READ|FILE_GENERIC_APPEND

?

Paolo



Re: [Qemu-devel] [PATCH 3/3] migrate-start-postcopy: Improve text

2015-11-11 Thread Juan Quintela
"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Improve the text in both the qapi-schema and hmp help to point out
> you need to set the postcopy-ram capability prior to issuing
> migrate-start-postcopy.
>
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 



Re: [Qemu-devel] [PATCH for-2.5] block: make 'stats-intervals' a list of integers

2015-11-11 Thread Eric Blake
On 11/11/2015 06:17 AM, Alberto Garcia wrote:
> This is the natural JSON representation and prevents us from having to
> decode the list manually.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  blockdev.c | 64 
> ++
>  qapi/block-core.json   |  7 +++---
>  tests/qemu-iotests/136 |  2 +-
>  3 files changed, 48 insertions(+), 25 deletions(-)
> 

> +for (entry = qlist_first(interval_list); entry;
> + entry = qlist_next(entry)) {
> +unsigned length;
> +switch (qobject_type(entry->value)) {
>  
> -if (*stats_intervals == '\0') {
> -error_setg(, "stats-intervals can't have an empty 
> value");
> -}
> -
> -for (i = 0; !error && intervals[i] != NULL; i++) {
> +case QTYPE_QSTRING: {

> +case QTYPE_QINT: {

Why are we accepting both string and int here, but typing it as 'int' in
qapi?  I guess its due to how command line parsing passes in strings
rather than ints?

But that should be okay.

Reviewed-by: Eric Blake 

We may eventually want to add an alternate type that takes both int and
string from QMP (parsing the port number of server addresses is another
spot that could benefit from such an alternate), but that's a project
for 2.6.

-- 
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 v3 00/18] Record/replay core for 2.5-rc1

2015-11-11 Thread Eric Blake
On 11/11/2015 03:53 AM, Markus Armbruster wrote:

> 
> Can we have an entry in MAINTAINERS, please?
> 

A while ago, someone suggested patching checkpatch.pl to flag any new
files without a maintainer; I'm not the best perl expert to try and
write such a patch, though.

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



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH 12/13] iotests: add default node-name

2015-11-11 Thread Vladimir Sementsov-Ogievskiy
When testing migration, auto-generated by qemu node-names differs in
source and destination qemu and migration fails. After this patch,
auto-generated by iotest nodenames will be the same.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/iotests.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index aac698a..3f005b7 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -147,7 +147,8 @@ class VM(object):
 options = ['if=%s' % interface,
'format=%s' % imgfmt,
'cache=%s' % cachemode,
-   'id=drive%d' % self._num_drives]
+   'id=drive%d' % self._num_drives,
+   'node-name=drivenode%d' % self._num_drives]
 
 if path is not None:
 options.append('file=%s' % path)
-- 
2.1.4




[Qemu-devel] [PATCH 03/13] block: tiny refactoring: minimize hbitmap_(set/reset) usage

2015-11-11 Thread Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block.c b/block.c
index 70106b8..1171dbb 100644
--- a/block.c
+++ b/block.c
@@ -3449,7 +3449,7 @@ void bdrv_set_dirty(BlockDriverState *bs, int64_t 
cur_sector,
 if (!bdrv_dirty_bitmap_enabled(bitmap)) {
 continue;
 }
-hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors);
+bdrv_set_dirty_bitmap(bitmap, cur_sector, nr_sectors);
 }
 }
 
-- 
2.1.4




[Qemu-devel] [PATCH 10/13] iotests: add add_incoming_migration to VM class

2015-11-11 Thread Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/iotests.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 92b6d5e..aac698a 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -160,6 +160,12 @@ class VM(object):
 self._num_drives += 1
 return self
 
+def add_incoming_migration(self, desc):
+'''Add an incoming migration to the VM'''
+self._args.append('-incoming')
+self._args.append(desc)
+return self
+
 def pause_drive(self, drive, event=None):
 '''Pause drive r/w operations'''
 if not event:
-- 
2.1.4




[Qemu-devel] [PATCH 08/13] migration: add migration/block-dirty-bitmap.c

2015-11-11 Thread Vladimir Sementsov-Ogievskiy
Live migration of dirty bitmaps. Only named dirty bitmaps, associated with
root nodes and non-root named nodes are migrated.

If destination qemu is already containing a dirty bitmap with the same name
as a migrated bitmap (for the same node), than, if their granularities are
the same the migration will be done, otherwise the error will be generated.

If destination qemu doesn't contain such bitmap it will be created.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/migration/block.h  |   1 +
 migration/Makefile.objs|   2 +-
 migration/block-dirty-bitmap.c | 708 +
 vl.c   |   1 +
 4 files changed, 711 insertions(+), 1 deletion(-)
 create mode 100644 migration/block-dirty-bitmap.c

diff --git a/include/migration/block.h b/include/migration/block.h
index ffa8ac0..566bb9f 100644
--- a/include/migration/block.h
+++ b/include/migration/block.h
@@ -14,6 +14,7 @@
 #ifndef BLOCK_MIGRATION_H
 #define BLOCK_MIGRATION_H
 
+void dirty_bitmap_mig_init(void);
 void blk_mig_init(void);
 int blk_mig_active(void);
 uint64_t blk_mig_bytes_transferred(void);
diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 0cac6d7..1432619 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -6,5 +6,5 @@ common-obj-y += xbzrle.o postcopy-ram.o
 common-obj-$(CONFIG_RDMA) += rdma.o
 common-obj-$(CONFIG_POSIX) += exec.o unix.o fd.o
 
-common-obj-y += block.o
+common-obj-y += block.o block-dirty-bitmap.o
 
diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
new file mode 100644
index 000..4747919
--- /dev/null
+++ b/migration/block-dirty-bitmap.c
@@ -0,0 +1,708 @@
+/*
+ * QEMU dirty bitmap migration
+ *
+ * Live migration of dirty bitmaps. Only named dirty bitmaps, associated with
+ * root nodes and non-root named nodes are migrated. Live iteration is disabled
+ * for small data amount (see MIN_LIVE_SIZE).
+ *
+ * If destination qemu is already containing a dirty bitmap with the same name
+ * as a migrated bitmap (for the same node), than, if their granularities are
+ * the same the migration will be done, otherwise the error will be generated.
+ *
+ * If destination qemu doesn't contain such bitmap it will be created.
+ *
+ * format of migration:
+ *
+ * # Header (shared for different chunk types)
+ * 1, 2 or 4 bytes: flags (see qemu_{put,put}_flags)
+ * [ 1 byte: node name size ] \  flags & DEVICE_NAME
+ * [ n bytes: node name ] /
+ * [ 1 byte: bitmap name size ] \  flags & BITMAP_NAME
+ * [ n bytes: bitmap name ] /
+ *
+ * # Start of bitmap migration (flags & START)
+ * header
+ * be64: granularity
+ *
+ * # Complete of bitmap migration (flags & COMPLETE)
+ * header
+ * 1 byte: bitmap enabled flag
+ *
+ * # Data chunk of bitmap migration
+ * header
+ * be64: start sector
+ * be32: number of sectors
+ * [ be64: buffer size  ] \ ! (flags & ZEROES)
+ * [ n bytes: buffer] /
+ *
+ * The last chunk in stream should contain flags & EOS. The chunk may skip
+ * device and/or bitmap names, assuming them to be the same with the previous
+ * chunk.
+ *
+ *
+ * This file is derived from migration/block.c
+ *
+ * Author:
+ * Vladimir Sementsov-Ogievskiy 
+ *
+ * original copyright message:
+ * =
+ * Copyright IBM, Corp. 2009
+ *
+ * Authors:
+ *  Liran Schour   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ * =
+ */
+
+#include "block/block.h"
+#include "block/block_int.h"
+#include "sysemu/block-backend.h"
+#include "qemu/main-loop.h"
+#include "qemu/error-report.h"
+#include "migration/block.h"
+#include "migration/migration.h"
+#include "qemu/hbitmap.h"
+#include 
+
+#define CHUNK_SIZE (1 << 10)
+#define MIN_LIVE_SIZE  (1 << 20)
+
+/* Flags occupy from one to four bytes. In all but one the 7-th (EXTRA_FLAGS)
+ * bit should be set. */
+#define DIRTY_BITMAP_MIG_FLAG_EOS   0x01
+#define DIRTY_BITMAP_MIG_FLAG_ZEROES0x02
+#define DIRTY_BITMAP_MIG_FLAG_BITMAP_NAME   0x04
+#define DIRTY_BITMAP_MIG_FLAG_DEVICE_NAME   0x08
+#define DIRTY_BITMAP_MIG_FLAG_START 0x10
+#define DIRTY_BITMAP_MIG_FLAG_COMPLETE  0x20
+#define DIRTY_BITMAP_MIG_FLAG_BITS  0x40
+
+#define DIRTY_BITMAP_MIG_EXTRA_FLAGS0x80
+#define DIRTY_BITMAP_MIG_FLAGS_SIZE_16  0x8000
+#define DIRTY_BITMAP_MIG_FLAGS_SIZE_32  0x8080
+
+#define DEBUG_DIRTY_BITMAP_MIGRATION 0
+
+#define DPRINTF(fmt, args...) \
+do { \
+if (DEBUG_DIRTY_BITMAP_MIGRATION) { \
+printf("DMIG %s:%d", __func__, __LINE__); \
+printf(fmt, ##args); \
+} \
+ 

[Qemu-devel] [PATCH 01/13] hbitmap: serialization

2015-11-11 Thread Vladimir Sementsov-Ogievskiy
Functions to serialize / deserialize(restore) HBitmap. HBitmap should be
saved to linear sequence of bits independently of endianness and bitmap
array element (unsigned long) size. Therefore Little Endian is chosen.

These functions are appropriate for dirty bitmap migration, restoring
the bitmap in several steps is available. To save performance, every
step writes only the last level of the bitmap. All other levels are
restored by hbitmap_deserialize_finish() as a last step of restoring.
So, HBitmap is inconsistent while restoring.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/qemu/hbitmap.h |  73 +++
 util/hbitmap.c | 114 +
 2 files changed, 187 insertions(+)

diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
index bb94a00..0a37dbf 100644
--- a/include/qemu/hbitmap.h
+++ b/include/qemu/hbitmap.h
@@ -149,6 +149,79 @@ void hbitmap_reset_all(HBitmap *hb);
 bool hbitmap_get(const HBitmap *hb, uint64_t item);
 
 /**
+ * hbitmap_data_size:
+ * @hb: HBitmap to operate on.
+ * @count: Number of bits
+ *
+ * Grunularity of serialization chunks, used by other serializetion functions.
+ * For every chunk:
+ * 1. Chunk start should be aligned to this granularity.
+ * 2. Chunk size should be aligned too, except for last chunk (for which
+ *  start + count == hb->size)
+ */
+uint64_t hbitmap_serialization_granularity(const HBitmap *hb);
+
+/**
+ * hbitmap_data_size:
+ * @hb: HBitmap to operate on.
+ * @count: Number of bits
+ *
+ * Return amount of bytes hbitmap_(de)serialize_part needs
+ */
+uint64_t hbitmap_serialization_size(const HBitmap *hb,
+uint64_t start, uint64_t count);
+
+/**
+ * hbitmap_serialize_part
+ * @hb: HBitmap to operate on.
+ * @buf: Buffer to store serialized bitmap.
+ * @start: First bit to store.
+ * @count: Number of bits to store.
+ *
+ * Stores HBitmap data corresponding to given region. The format of saved data
+ * is linear sequence of bits, so it can be used by hbitmap_deserialize_part
+ * independently of endianness and size of HBitmap level array elements
+ */
+void hbitmap_serialize_part(const HBitmap *hb, uint8_t *buf,
+uint64_t start, uint64_t count);
+
+/**
+ * hbitmap_deserialize_part
+ * @hb: HBitmap to operate on.
+ * @buf: Buffer to restore bitmap data from.
+ * @start: First bit to restore.
+ * @count: Number of bits to restore.
+ *
+ * Restores HBitmap data corresponding to given region. The format is the same
+ * as for hbitmap_serialize_part.
+ *
+ * ! The bitmap becomes inconsistent after this operation.
+ * hbitmap_serialize_finish should be called before using the bitmap after
+ * data restoring.
+ */
+void hbitmap_deserialize_part(HBitmap *hb, uint8_t *buf,
+  uint64_t start, uint64_t count);
+
+/**
+ * hbitmap_deserialize_zeroes
+ * @hb: HBitmap to operate on.
+ * @start: First bit to restore.
+ * @count: Number of bits to restore.
+ *
+ * Same as hbitmap_serialize_part, but fills the bitmap with zeroes.
+ */
+void hbitmap_deserialize_zeroes(HBitmap *hb, uint64_t start, uint64_t count);
+
+/**
+ * hbitmap_deserialize_finish
+ * @hb: HBitmap to operate on.
+ *
+ * Repair HBitmap after calling hbitmap_deserialize_data. Actually, all HBitmap
+ * layers are restored here.
+ */
+void hbitmap_deserialize_finish(HBitmap *hb);
+
+/**
  * hbitmap_free:
  * @hb: HBitmap to operate on.
  *
diff --git a/util/hbitmap.c b/util/hbitmap.c
index 50b888f..22276a6 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -378,6 +378,120 @@ bool hbitmap_get(const HBitmap *hb, uint64_t item)
 return (hb->levels[HBITMAP_LEVELS - 1][pos >> BITS_PER_LEVEL] & bit) != 0;
 }
 
+uint64_t hbitmap_serialization_granularity(const HBitmap *hb)
+{
+return BITS_PER_LONG << hb->granularity;
+}
+
+/* serilization chunk start should be aligned to serialization granularity.
+ * Serilization chunk size scould be aligned to serialization granularity too,
+ * except for last chunk.
+ */
+static void serialization_chunk(const HBitmap *hb,
+uint64_t start, uint64_t count,
+unsigned long **first_el, size_t *el_count)
+{
+uint64_t last = start + count - 1;
+uint64_t gran = hbitmap_serialization_granularity(hb);
+
+assert(((start + count - 1) >> hb->granularity) < hb->size);
+assert((start & (gran - 1)) == 0);
+assert((last == hb->size - 1) || ((count & (gran - 1)) == 0));
+
+start = (start >> hb->granularity) >> BITS_PER_LEVEL;
+last = (last >> hb->granularity) >> BITS_PER_LEVEL;
+
+*first_el = >levels[HBITMAP_LEVELS - 1][start];
+*el_count = last - start + 1;
+}
+
+uint64_t hbitmap_serialization_size(const HBitmap *hb,
+uint64_t start, uint64_t count)
+{
+uint64_t el_count;
+unsigned long *cur;
+
+serialization_chunk(hb, start, count, , 

[Qemu-devel] [PULL v3 14/41] blockdev: read-only-mode for blockdev-change-medium

2015-11-11 Thread Kevin Wolf
From: Max Reitz 

Add an option to qmp_blockdev_change_medium() which allows changing the
read-only status of the block device whose medium is changed.

Some drives do not have a inherently fixed read-only status; for
instance, floppy disks can be set read-only or writable independently of
the drive. Some users may find it useful to be able to therefore change
the read-only status of a block device when changing the medium.

Signed-off-by: Max Reitz 
Signed-off-by: Kevin Wolf 
---
 blockdev.c   | 22 ++
 hmp.c|  2 +-
 qapi/block-core.json | 24 +++-
 qmp-commands.hx  | 24 +++-
 qmp.c|  3 ++-
 ui/cocoa.m   |  1 +
 6 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index b3a958c..34f6e5b 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2145,6 +2145,8 @@ void qmp_blockdev_insert_medium(const char *device, const 
char *node_name,
 
 void qmp_blockdev_change_medium(const char *device, const char *filename,
 bool has_format, const char *format,
+bool has_read_only,
+BlockdevChangeReadOnlyMode read_only,
 Error **errp)
 {
 BlockBackend *blk;
@@ -2166,6 +2168,26 @@ void qmp_blockdev_change_medium(const char *device, 
const char *filename,
 
 bdrv_flags = blk_get_open_flags_from_root_state(blk);
 
+if (!has_read_only) {
+read_only = BLOCKDEV_CHANGE_READ_ONLY_MODE_RETAIN;
+}
+
+switch (read_only) {
+case BLOCKDEV_CHANGE_READ_ONLY_MODE_RETAIN:
+break;
+
+case BLOCKDEV_CHANGE_READ_ONLY_MODE_READ_ONLY:
+bdrv_flags &= ~BDRV_O_RDWR;
+break;
+
+case BLOCKDEV_CHANGE_READ_ONLY_MODE_READ_WRITE:
+bdrv_flags |= BDRV_O_RDWR;
+break;
+
+default:
+abort();
+}
+
 if (has_format) {
 options = qdict_new();
 qdict_put(options, "driver", qstring_from_str(format));
diff --git a/hmp.c b/hmp.c
index e5ad944..16006aa 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1355,7 +1355,7 @@ void hmp_change(Monitor *mon, const QDict *qdict)
 }
 qmp_change("vnc", target, !!arg, arg, );
 } else {
-qmp_blockdev_change_medium(device, target, !!arg, arg, );
+qmp_blockdev_change_medium(device, target, !!arg, arg, false, 0, );
 if (err &&
 error_get_class(err) == ERROR_CLASS_DEVICE_ENCRYPTED) {
 error_free(err);
diff --git a/qapi/block-core.json b/qapi/block-core.json
index e9fa649..fa08ba9 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1959,6 +1959,24 @@
 
 
 ##
+# @BlockdevChangeReadOnlyMode:
+#
+# Specifies the new read-only mode of a block device subject to the
+# @blockdev-change-medium command.
+#
+# @retain:  Retains the current read-only mode
+#
+# @read-only:   Makes the device read-only
+#
+# @read-write:  Makes the device writable
+#
+# Since: 2.3
+##
+{ 'enum': 'BlockdevChangeReadOnlyMode',
+  'data': ['retain', 'read-only', 'read-write'] }
+
+
+##
 # @blockdev-change-medium:
 #
 # Changes the medium inserted into a block device by ejecting the current 
medium
@@ -1973,12 +1991,16 @@
 # @format:  #optional, format to open the new image with (defaults to
 #   the probed format)
 #
+# @read-only-mode:  #optional, change the read-only mode of the device; 
defaults
+#   to 'retain'
+#
 # Since: 2.5
 ##
 { 'command': 'blockdev-change-medium',
   'data': { 'device': 'str',
 'filename': 'str',
-'*format': 'str' } }
+'*format': 'str',
+'*read-only-mode': 'BlockdevChangeReadOnlyMode' } }
 
 
 ##
diff --git a/qmp-commands.hx b/qmp-commands.hx
index f6d9c25..39d6e25 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -4183,7 +4183,7 @@ EQMP
 
 {
 .name   = "blockdev-change-medium",
-.args_type  = "device:B,filename:F,format:s?",
+.args_type  = "device:B,filename:F,format:s?,read-only-mode:s?",
 .mhandler.cmd_new = qmp_marshal_blockdev_change_medium,
 },
 
@@ -4199,6 +4199,8 @@ Arguments:
 - "device": device name (json-string)
 - "filename": filename of the new image (json-string)
 - "format": format of the new image (json-string, optional)
+- "read-only-mode": new read-only mode (json-string, optional)
+  - Possible values: "retain" (default), "read-only", "read-write"
 
 Examples:
 
@@ -4210,6 +4212,26 @@ Examples:
 "format": "raw" } }
 <- { "return": {} }
 
+2. Load a read-only medium into a writable drive
+
+-> { "execute": "blockdev-change-medium",
+ "arguments": { "device": "isa-fd0",
+"filename": "/srv/images/ro.img",
+"format": "raw",
+"read-only-mode": "retain" } }
+
+<- { 

[Qemu-devel] [PULL v3 41/41] iotests: Check for quorum support in test 139

2015-11-11 Thread Kevin Wolf
From: Alberto Garcia 

The quorum driver is always built in, but it is disabled during
run-time if there's no SHA256 support available (see commit e94867e).

This patch skips the quorum test in iotest 139 in that case.

Signed-off-by: Alberto Garcia 
Message-id: 1447172891-20410-1-git-send-email-be...@igalia.com
Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/139 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/qemu-iotests/139 b/tests/qemu-iotests/139
index b5470f7..42f78c7 100644
--- a/tests/qemu-iotests/139
+++ b/tests/qemu-iotests/139
@@ -400,6 +400,8 @@ class TestBlockdevDel(iotests.QMPTestCase):
 self.checkBlockDriverState('node1', False)
 
 def testQuorum(self):
+if not 'quorum' in iotests.qemu_img_pipe('--help'):
+return
 self.addQuorum('quorum0', 'node0', 'node1')
 # We cannot remove the children of a Quorum device
 self.delBlockDriverState('node0', expect_error = True)
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v11 13/28] qapi: Hoist tag collision check to Variants.check()

2015-11-11 Thread Eric Blake
On 11/11/2015 06:56 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> Checking that a given QAPISchemaObjectTypeVariant.name is a
>> member of the corresponding QAPISchemaEnumType of the owning
>> QAPISchemaObjectTypeVariants.tag_member ensures that there are
>> no collisions in the generated C union for those tag values
>> (since the enum itself should have no collisions).
>>
>> However, this check was the only thing that Variant.check() was
>> doing beyond the work of the superclass ObjectTypeMember.check(),
> 
> Since PATCH 05, actually.  Suggest to mention that.

I debated about munging patch 5 or 6 to actually make this change there;
but decided that separate is just fine.  But yes, mentioning the earlier
commit title will help.

>> @@ -1075,10 +1076,6 @@ class 
>> QAPISchemaObjectTypeVariant(QAPISchemaObjectTypeMember):
>>  def __init__(self, name, typ):
>>  QAPISchemaObjectTypeMember.__init__(self, name, typ, False)
>>
>> -def check(self, schema, tag_type):
>> -QAPISchemaObjectTypeMember.check(self, schema)
>> -assert self.name in tag_type.values
>> -
>>  # This function exists to support ugly simple union special cases
>>  # TODO get rid of them, and drop the function
>>  def simple_union_type(self):
> 
> QAPISchemaObjectTypeVariant is now an almost trivial variation of
> QAPISchemaObjectTypeMember.  Differences:
> 
> * __init__() has no parameter optional
> 
> * Method simple_union_type(), which exists only to support pointless
>   differences in code generation for simple unions, all marked TODO.
> 
> There's hope we can get rid of the class after the TODOs are resolved.

Nope. Because in 15/28 I add back in a non-trivial difference of "role =
'branch'" compared to the superclass "role = 'member'", which affects
the quality of error messages using .describe().

That, and I still have no idea how to get rid of the TODO (we know how
to convert simple unions to flat unions, but the conversion is an
either-or choice: either we keep the C layout the same but change {} in
the JSON representation, or we keep QMP the same but affect the C layout
- so fixing the TODO has to resolve that discrepancy, and may end up
touching lots of code).

-- 
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 v11 18/28] qerror: more error_setg() usage

2015-11-11 Thread Eric Blake
On 11/11/2015 07:21 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) have snuck in
>> since c6bd8c706.  Nuke them.
> 
> Doesn't really belong to this series, but that's okay.

If you're going to modify this for 2.5 inclusion through your qerror
tree, you may want to change the description to:

A few uses of error_set(ERROR_CLASS_GENERIC_ERROR) were missed in
c6bd8c706, or have snuck in since.  Nuke them.

>> +++ b/hw/i386/pc.c
>> @@ -1795,7 +1795,7 @@ static void pc_machine_set_max_ram_below_4g(Object 
>> *obj, Visitor *v,
>>  return;
>>  }
>>  if (value > (1ULL << 32)) {
>> -error_set(, ERROR_CLASS_GENERIC_ERROR,
>> +error_setg(,
>>"Machine option 'max-ram-below-4g=%"PRIu64
>>"' expects size less than or equal to 4G", value);
> 
> Indentation is now off.  Can tidy up in my tree.
> 
>>  error_propagate(errp, error);
> [Rest snipped, it looks good]
> 

There's also the question if we want to address the ErrorClass name
munging of 19/28 by adding your idea of an aliasing typedef in error.h;
if so, should I prepare a smaller patch series of both of those changes
for consideration for 2.5?

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



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] CUDA has problems with Mac OS 10.4

2015-11-11 Thread Programmingkid
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 
10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use 
the mac99 target. Here is the error message: 

panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR

This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom 
~/tiger.iso  -prom-env boot-args=-v -usb -M mac99

I think there is still something wrong with CUDA. But we might not have to 
"fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is 
what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't 
have a CUDA chip. This chip is used for ADB communications. Using it only on 
the BeigeG3 target makes sense. 

My sources for the PowerMac3,1 system is this link: 
http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp.html

and this device tree:

PowerMac G4 device tree

ff839ab8: /cpus
ff839ce8:   /PowerPC,G4@0
ff83a060: /l2-cache
ff83ab58: /chosen
ff83ace8: /memory@0
ff83af00: /openprom
ff83b008:   /client-services
ff83c1a8: /rom@ff80
ff83c330:   /boot-rom@fff0
ff83c4a8:   /macos
ff83c528: /options
ff83c5a8: /aliases
ff83cec8: /packages
ff83cf30:   /deblocker
ff83d798:   /disk-label
ff83e198:   /obp-tftp
ff8439f0:   /mac-parts
ff844850:   /mac-files
ff847540:   /hfs-plus-files
ff84c1c8:   /fat-files
ff84def8:   /iso-9660-files
ff84eb00:   /bootinfo-loader
ff8507a0:   /xcoff-loader
ff8511b8:   /pe-loader
ff851b90:   /elf-loader
ff8531c0:   /usb-hid-class
ff8554d8:   /usb-ms-class
ff8576a8:   /sbp2-disk
ff858ac0:   /ata-disk
ff859cd8:   /atapi-disk
ff85b348:   /bootpath-search
ff861b68:   /terminal-emulator
ff861c00: /psuedo-hid
ff861c88:   /keyboard
ff862308:   /mouse
ff862820: /multiboot
ff86e7f0: /diagnostics
ff86e858: /tools-node
ff8704b8: /rtas
ff8706b8: /nvram@fff04000
ff871180: /uni-n@f800
ff8713c8:   /i2c@f8001000
ff871b10: /cereal
ff8721c0: /pci@f000
ff898cd0:   /uni-north-agp@b
ff898f40:   /ATY,Rage128Ps@10
ff873268: /pci@f200
ff8742d8:   /pci-bridge@d
ff876368: /mac-io@7
ff8773a0:   /interrupt-controller@4
ff877548:   /gpio@50
ff877630: /extint-gpio1
ff8777c8: /programmer-switch
ff877900:   /escc-legacy@12000
ff877af8: /ch-a@12004
ff877c78: /ch-b@12000
ff877df8:   /escc@13000
ff878000: /ch-a@13020
ff8789a8: /ch-b@13000
ff8792c0:   /davbus@14000
ff879540: /sound
ff879c40:   /timer@15000
ff879da8:   /via-pmu@16000
ff87ccf0: /rtc
ff87d3e0: /power-mgt
ff8bf378:   /usb-power-mgt
ff87d648:   /i2c@18000
ff87ded8: /cereal
ff87e5a0:   /ata-4@1f000
ff880318: /disk
ff8809e8:   /ata-3@2
ff882760: /disk
ff882da8:   /ata-3@21000
ff884b20: /disk
ff8864c8: /ethernet@4
ff888690: /usb@8
ff88dd50: /usb@9
ff8be3f0:   /hub@1
ff8be580: /keyboard@1
ff893410: /firewire@a
ff8752e8: /pci@f400
ff8bb128:   /ethernet@f


  1   2   3   >