Re: [PATCH for-7.0] hw/i386/pc: Add missing property descriptions

2022-01-05 Thread Thomas Huth

On 06/12/2021 14.42, Thomas Huth wrote:

When running "qemu-system-x86_64 -M pc,help" I noticed that some
properties were still missing their description. Add them now so
that users get at least a slightly better idea what they are all
about.

Signed-off-by: Thomas Huth 
---
  hw/i386/pc.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a2ef40ecbc..837f2bff4e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1734,15 +1734,23 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
  
  object_class_property_add_bool(oc, PC_MACHINE_SMBUS,

  pc_machine_get_smbus, pc_machine_set_smbus);
+object_class_property_set_description(oc, PC_MACHINE_SMBUS,
+"Enable/disable system management bus");
  
  object_class_property_add_bool(oc, PC_MACHINE_SATA,

  pc_machine_get_sata, pc_machine_set_sata);
+object_class_property_set_description(oc, PC_MACHINE_SATA,
+"Enable/disable Serial ATA bus");
  
  object_class_property_add_bool(oc, PC_MACHINE_PIT,

  pc_machine_get_pit, pc_machine_set_pit);
+object_class_property_set_description(oc, PC_MACHINE_PIT,
+"Enable/disable Intel 8254 programmable interval timer emulation");
  
  object_class_property_add_bool(oc, "hpet",

  pc_machine_get_hpet, pc_machine_set_hpet);
+object_class_property_set_description(oc, "hpet",
+"Enable/disable high precision event timer emulation");
  
  object_class_property_add_bool(oc, "default-bus-bypass-iommu",

  pc_machine_get_default_bus_bypass_iommu,


Friendly happy new year ping!

 Thomas




Re: [PATCH v3 kvm/queue 14/16] KVM: Handle page fault for private memory

2022-01-05 Thread Yan Zhao
On Wed, Jan 05, 2022 at 02:28:10PM +0800, Chao Peng wrote:
> On Tue, Jan 04, 2022 at 06:06:12PM +0800, Yan Zhao wrote:
> > On Tue, Jan 04, 2022 at 05:10:08PM +0800, Chao Peng wrote:
<...> 
> > Thanks. So QEMU will re-generate memslots and set KVM_MEM_PRIVATE
> > accordingly? Will it involve slot deletion and create?
> 
> KVM will not re-generate memslots when do the conversion, instead, it
> does unmap/map a range on the same memslot. For memslot with tag
> KVM_MEM_PRIVATE, it always have two mappings (private/shared) but at a
> time only one is effective. What conversion does is to turn off the
> existing mapping and turn on the other mapping for specified range in
> that slot.
>
got it. thanks!

<...>
> > > > > +static bool kvm_faultin_pfn_private(struct kvm_vcpu *vcpu,
> > > > > + struct kvm_page_fault *fault,
> > > > > + bool *is_private_pfn, int *r)
> > > > > +{
> > > > > + int order;
> > > > > + int mem_convert_type;
> > > > > + struct kvm_memory_slot *slot = fault->slot;
> > > > > + long pfn = kvm_memfd_get_pfn(slot, fault->gfn, &order);
> > > > For private memory slots, it's possible to have pfns backed by
> > > > backends other than memfd, e.g. devicefd.
> > > 
> > > Surely yes, although this patch only supports memfd, but it's designed
> > > to be extensible to support other memory backing stores than memfd. There
> > > is one assumption in this design however: one private memslot can be
> > > backed by only one type of such memory backing store, e.g. if the
> > > devicefd you mentioned can independently provide memory for a memslot
> > > then that's no issue.
> > > 
> > > >So is it possible to let those
> > > > private memslots keep private and use traditional hva-based way?
> > > 
> > > Typically this fd-based private memory uses the 'offset' as the
> > > userspace address to get a pfn from the backing store fd. But I believe
> > > the current code does not prevent you from using the hva as the
> > By hva-based way, I mean mmap is required for this fd.
> > 
> > > userspace address, as long as your memory backing store understand that
> > > address and can provide the pfn basing on it. But since you already have
> > > the hva, you probably already mmap-ed the fd to userspace, that seems
> > > not this private memory patch can protect you. Probably I didn't quite
> > Yes, for this fd, though mapped in private memslot, there's no need to
> > prevent QEMU/host from accessing it as it will not cause the severe machine
> > check.
> > 
> > > understand 'keep private' you mentioned here.
> > 'keep private' means allow this kind of private memslot which does not
> > require protection from this private memory patch :)
> 
> Then I think such memory can be the shared part of memory of the
> KVM_MEM_PRIVATE memslot. As said above, this is initially supported :)
>
Sorry, maybe I didn't express it clearly.

As in the kvm_faultin_pfn_private(), 
static bool kvm_faultin_pfn_private(struct kvm_vcpu *vcpu,
struct kvm_page_fault *fault,
bool *is_private_pfn, int *r)
{
int order;
int mem_convert_type;
struct kvm_memory_slot *slot = fault->slot;
long pfn = kvm_memfd_get_pfn(slot, fault->gfn, &order);
...
}
Currently, kvm_memfd_get_pfn() is called unconditionally.
However, if the backend of a private memslot is not memfd, and is device
fd for example, a different xxx_get_pfn() is required here.

Further, though mapped to a private gfn, it might be ok for QEMU to
access the device fd in hva-based way (or call it MMU access way, e.g.
read/write/mmap), it's desired that it could use the traditional to get
pfn without convert the range to a shared one.
pfn = __gfn_to_pfn_memslot(slot, fault->gfn, ...)
|->addr = __gfn_to_hva_many (slot, gfn,...)
|  pfn = hva_to_pfn (addr,...)


So, is it possible to recognize such kind of backends in KVM, and to get
the pfn in traditional way without converting them to shared?
e.g.
- specify KVM_MEM_PRIVATE_NONPROTECT to memory regions with such kind
of backends, or
- detect the fd type and check if get_pfn is provided. if no, go the
  traditional way.

Thanks
Yan

> > > > Reasons below:
> > > > 1. only memfd is supported in this patch set.
> > > > 2. qemu/host read/write to those private memslots backing up by 
> > > > devicefd may
> > > > not cause machine check.




RE: [RFC 02/10] vhost: add 3 commands for vhost-vdpa

2022-01-05 Thread longpeng2--- via


> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Wednesday, January 5, 2022 3:54 PM
> To: Michael S. Tsirkin 
> Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; Stefan Hajnoczi ; Stefano
> Garzarella ; Cornelia Huck ; pbonzini
> ; Gonglei (Arei) ; Yechuan
> ; Huangzhichao ; qemu-devel
> 
> Subject: Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa
> 
> On Wed, Jan 5, 2022 at 3:02 PM Michael S. Tsirkin  wrote:
> >
> > On Wed, Jan 05, 2022 at 12:35:53PM +0800, Jason Wang wrote:
> > > On Wed, Jan 5, 2022 at 8:59 AM Longpeng(Mike)  
> > > wrote:
> > > >
> > > > From: Longpeng 
> > > >
> > > > To support generic vdpa deivce, we need add the following ioctls:
> > > > - GET_VECTORS_NUM: the count of vectors that supported
> > >
> > > Does this mean MSI vectors? If yes, it looks like a layer violation:
> > > vhost is transport independent.
> >
> > Well *guest* needs to know how many vectors device supports.
> > I don't think there's a way around that. Do you?
> 
> We have VHOST_SET_VRING/CONFIG_CALL which is per vq. I think we can
> simply assume #vqs + 1?
> 
> > Otherwise guests will at best be suboptimal.
> >
> > >  And it reveals device implementation
> > > details which block (cross vendor) migration.
> > >
> > > Thanks
> >
> > Not necessarily, userspace can hide this from guest if it
> > wants to, just validate.
> 
> If we can hide it at vhost/uAPI level, it would be even better?
> 

Not only MSI vectors, but also queue-size, #vqs, etc.

Maybe the vhost level could expose the hardware's real capabilities
and let the userspace (QEMU) do the hiding? The userspace know how
to process them.

> Thanks
> 
> >
> >
> > > > - GET_CONFIG_SIZE: the size of the virtio config space
> > > > - GET_VQS_NUM: the count of virtqueues that exported
> > > >
> > > > Signed-off-by: Longpeng 
> > > > ---
> > > >  linux-headers/linux/vhost.h | 10 ++
> > > >  1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h
> > > > index c998860d7b..c5edd75d15 100644
> > > > --- a/linux-headers/linux/vhost.h
> > > > +++ b/linux-headers/linux/vhost.h
> > > > @@ -150,4 +150,14 @@
> > > >  /* Get the valid iova range */
> > > >  #define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
> > > >  struct 
> > > > vhost_vdpa_iova_range)
> > > > +
> > > > +/* Get the number of vectors */
> > > > +#define VHOST_VDPA_GET_VECTORS_NUM _IOR(VHOST_VIRTIO, 0x79, int)
> > > > +
> > > > +/* Get the virtio config size */
> > > > +#define VHOST_VDPA_GET_CONFIG_SIZE _IOR(VHOST_VIRTIO, 0x80, int)
> > > > +
> > > > +/* Get the number of virtqueues */
> > > > +#define VHOST_VDPA_GET_VQS_NUM _IOR(VHOST_VIRTIO, 0x81, int)
> > > > +
> > > >  #endif
> > > > --
> > > > 2.23.0
> > > >
> >



Re: [PATCH qemu] s390x/css: fix PMCW invalid mask

2022-01-05 Thread Thomas Huth

On 16/12/2021 14.16, Nico Boehr wrote:

Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But,
as per the principles of operation, bit 5 is ignored in MSCH and bits 0,
1, 6 and 7 need to be zero.

As both PMCW_FLAGS_MASK_INVALID and ioinst_schib_valid() are only used
by ioinst_handle_msch(), adjust the mask accordingly.

Fixes: db1c8f53bfb1 ("s390: Channel I/O basic definitions.")
Signed-off-by: Nico Boehr 
Reviewed-by: Pierre Morel 
Reviewed-by: Halil Pasic 
Reviewed-by: Janosch Frank 
---
  include/hw/s390x/ioinst.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/s390x/ioinst.h b/include/hw/s390x/ioinst.h
index 3771fff9d44d..ea8d0f244492 100644
--- a/include/hw/s390x/ioinst.h
+++ b/include/hw/s390x/ioinst.h
@@ -107,7 +107,7 @@ QEMU_BUILD_BUG_MSG(sizeof(PMCW) != 28, "size of PMCW is 
wrong");
  #define PMCW_FLAGS_MASK_MP 0x0004
  #define PMCW_FLAGS_MASK_TF 0x0002
  #define PMCW_FLAGS_MASK_DNV 0x0001
-#define PMCW_FLAGS_MASK_INVALID 0x0700
+#define PMCW_FLAGS_MASK_INVALID 0xc300
  
  #define PMCW_CHARS_MASK_ST 0x00e0

  #define PMCW_CHARS_MASK_MBFC 0x0004


Thanks, queued to my s390x-next branch now:

https://gitlab.com/thuth/qemu/-/commits/s390x-next/

 Thomas




[PATCH 2/2] i386: Hyper-V Enlightened MSR bitmap feature

2022-01-05 Thread Vitaly Kuznetsov
The newly introduced enlightenment allow L0 (KVM) and L1 (Hyper-V)
hypervisors to collaborate to avoid unnecessary updates to L2
MSR-Bitmap upon vmexits.

Signed-off-by: Vitaly Kuznetsov 
---
 docs/hyperv.txt| 10 ++
 target/i386/cpu.c  |  2 ++
 target/i386/cpu.h  |  1 +
 target/i386/kvm/hyperv-proto.h |  5 +
 target/i386/kvm/kvm.c  |  7 +++
 5 files changed, 25 insertions(+)

diff --git a/docs/hyperv.txt b/docs/hyperv.txt
index 0417c183a3b0..08429124a634 100644
--- a/docs/hyperv.txt
+++ b/docs/hyperv.txt
@@ -225,6 +225,16 @@ default (WS2016).
 Note: hv-version-id-* are not enlightenments and thus don't enable Hyper-V
 identification when specified without any other enlightenments.
 
+3.21. hv-emsr-bitmap
+=
+The enlightenment is nested specific, it targets Hyper-V on KVM guests. When
+enabled, it allows L0 (KVM) and L1 (Hyper-V) hypervisors to collaborate to
+avoid unnecessary updates to L2 MSR-Bitmap upon vmexits. While the protocol is
+supported for both VMX (Intel) and SVM (AMD), the VMX implementation requires
+Enlightened VMCS ('hv-evmcs') feature to also be enabled.
+
+Recommended: hv-evmcs (Intel)
+
 4. Supplementary features
 =
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index aa9e6368004c..f7405fdf4fa5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6839,6 +6839,8 @@ static Property x86_cpu_properties[] = {
   HYPERV_FEAT_STIMER_DIRECT, 0),
 DEFINE_PROP_BIT64("hv-avic", X86CPU, hyperv_features,
   HYPERV_FEAT_AVIC, 0),
+DEFINE_PROP_BIT64("hv-emsr-bitmap", X86CPU, hyperv_features,
+  HYPERV_FEAT_MSR_BITMAP, 0),
 DEFINE_PROP_ON_OFF_AUTO("hv-no-nonarch-coresharing", X86CPU,
 hyperv_no_nonarch_cs, ON_OFF_AUTO_OFF),
 DEFINE_PROP_BOOL("hv-passthrough", X86CPU, hyperv_passthrough, false),
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index a1165215d972..04e3b38abf25 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1060,6 +1060,7 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
 #define HYPERV_FEAT_IPI 13
 #define HYPERV_FEAT_STIMER_DIRECT   14
 #define HYPERV_FEAT_AVIC15
+#define HYPERV_FEAT_MSR_BITMAP  16
 
 #ifndef HYPERV_SPINLOCK_NEVER_NOTIFY
 #define HYPERV_SPINLOCK_NEVER_NOTIFY 0x
diff --git a/target/i386/kvm/hyperv-proto.h b/target/i386/kvm/hyperv-proto.h
index 89f81afda7c6..38e25468122d 100644
--- a/target/i386/kvm/hyperv-proto.h
+++ b/target/i386/kvm/hyperv-proto.h
@@ -72,6 +72,11 @@
 #define HV_ENLIGHTENED_VMCS_RECOMMENDED (1u << 14)
 #define HV_NO_NONARCH_CORESHARING   (1u << 18)
 
+/*
+ * HV_CPUID_NESTED_FEATURES.EAX bits
+ */
+#define HV_NESTED_MSR_BITMAP(1u << 19)
+
 /*
  * Basic virtualized MSRs
  */
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index c8f4956a4e0e..2baa9609e181 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -933,6 +933,13 @@ static struct {
  .bits = HV_DEPRECATING_AEOI_RECOMMENDED}
 }
 },
+[HYPERV_FEAT_MSR_BITMAP] = {
+.desc = "enlightened MSR-Bitmap (hv-emsr-bitmap)",
+.flags = {
+{.func = HV_CPUID_NESTED_FEATURES, .reg = R_EAX,
+ .bits = HV_NESTED_MSR_BITMAP}
+}
+},
 };
 
 static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max,
-- 
2.33.1




[PATCH 0/2] i386: Add support for Hyper-V Enlightened MSR-Bitmap feature

2022-01-05 Thread Vitaly Kuznetsov
The new nested specific enlightenment speeds up L2 vmexits by avoiding
unnecessary updates to L2 MSR-Bitmap. Support for both VMX and SVM is
coming to KVM:
https://lore.kernel.org/kvm/20211129094704.326635-1-vkuzn...@redhat.com/
https://lore.kernel.org/kvm/20211220152139.418372-1-vkuzn...@redhat.com/

Vitaly Kuznetsov (2):
  i386: Use hv_build_cpuid_leaf() for HV_CPUID_NESTED_FEATURES
  i386: Hyper-V Enlightened MSR bitmap feature

 docs/hyperv.txt| 10 ++
 target/i386/cpu.c  |  2 ++
 target/i386/cpu.h  |  2 +-
 target/i386/kvm/hyperv-proto.h |  5 +
 target/i386/kvm/kvm.c  | 30 ++
 5 files changed, 40 insertions(+), 9 deletions(-)

-- 
2.33.1




Re: [PATCH v2] FreeBSD: Upgrade to 12.3 release

2022-01-05 Thread Alex Bennée


Brad Smith  writes:

> FreeBSD: Upgrade to 12.3 release
>
> Note, since libtasn1 was fixed in 12.3 [*], this commit re-enables GnuTLS.
>
> [*] https://gitlab.com/gnutls/libtasn1/-/merge_requests/71
>
>
> Signed-off-by: Brad Smith 
> Tested-by: Thomas Huth 
> Reviewed-by: Warner Losh 

Queued to testing/next, thanks.

-- 
Alex Bennée



[PATCH 1/2] i386: Use hv_build_cpuid_leaf() for HV_CPUID_NESTED_FEATURES

2022-01-05 Thread Vitaly Kuznetsov
Previously, HV_CPUID_NESTED_FEATURES.EAX CPUID leaf was handled differently
as it was only used to encode the supported eVMCS version range. In fact,
there are also feature (e.g. Enlightened MSR-Bitmap) bits there. In
preparation to adding these features, move HV_CPUID_NESTED_FEATURES leaf
handling to hv_build_cpuid_leaf() and drop now-unneeded 'hyperv_nested'.

No functional change intended.

Signed-off-by: Vitaly Kuznetsov 
---
 target/i386/cpu.h |  1 -
 target/i386/kvm/kvm.c | 23 +++
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 04f2b790c9fa..a1165215d972 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1722,7 +1722,6 @@ struct X86CPU {
 uint32_t hyperv_vendor_id[3];
 uint32_t hyperv_interface_id[4];
 uint32_t hyperv_limits[3];
-uint32_t hyperv_nested[4];
 bool hyperv_enforce_cpuid;
 uint32_t hyperv_ver_id_build;
 uint16_t hyperv_ver_id_major;
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 13f8e30c2a54..c8f4956a4e0e 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -801,6 +801,8 @@ static bool tsc_is_stable_and_known(CPUX86State *env)
 || env->user_tsc_khz;
 }
 
+#define DEFAULT_EVMCS_VERSION ((1 << 8) | 1)
+
 static struct {
 const char *desc;
 struct {
@@ -1208,6 +1210,13 @@ static uint32_t hv_build_cpuid_leaf(CPUState *cs, 
uint32_t func, int reg)
 }
 }
 
+/* HV_CPUID_NESTED_FEATURES.EAX also encodes the supported eVMCS range */
+if (func == HV_CPUID_NESTED_FEATURES && reg == R_EAX) {
+if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS)) {
+r |= DEFAULT_EVMCS_VERSION;
+}
+}
+
 return r;
 }
 
@@ -1337,11 +1346,13 @@ static int hyperv_fill_cpuids(CPUState *cs,
 X86CPU *cpu = X86_CPU(cs);
 struct kvm_cpuid_entry2 *c;
 uint32_t cpuid_i = 0;
+uint32_t nested_eax =
+hv_build_cpuid_leaf(cs, HV_CPUID_NESTED_FEATURES, R_EAX);
 
 c = &cpuid_ent[cpuid_i++];
 c->function = HV_CPUID_VENDOR_AND_MAX_FUNCTIONS;
-c->eax = hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS) ?
-HV_CPUID_NESTED_FEATURES : HV_CPUID_IMPLEMENT_LIMITS;
+c->eax = nested_eax ? HV_CPUID_NESTED_FEATURES :
+HV_CPUID_IMPLEMENT_LIMITS;
 c->ebx = cpu->hyperv_vendor_id[0];
 c->ecx = cpu->hyperv_vendor_id[1];
 c->edx = cpu->hyperv_vendor_id[2];
@@ -1405,7 +1416,7 @@ static int hyperv_fill_cpuids(CPUState *cs,
 c->ecx = cpu->hyperv_limits[1];
 c->edx = cpu->hyperv_limits[2];
 
-if (hyperv_feat_enabled(cpu, HYPERV_FEAT_EVMCS)) {
+if (nested_eax) {
 uint32_t function;
 
 /* Create zeroed 0x4006..0x4009 leaves */
@@ -1417,7 +1428,7 @@ static int hyperv_fill_cpuids(CPUState *cs,
 
 c = &cpuid_ent[cpuid_i++];
 c->function = HV_CPUID_NESTED_FEATURES;
-c->eax = cpu->hyperv_nested[0];
+c->eax = nested_eax;
 }
 
 return cpuid_i;
@@ -1439,8 +1450,6 @@ static bool evmcs_version_supported(uint16_t 
evmcs_version,
 (max_version <= max_supported_version);
 }
 
-#define DEFAULT_EVMCS_VERSION ((1 << 8) | 1)
-
 static int hyperv_init_vcpu(X86CPU *cpu)
 {
 CPUState *cs = CPU(cpu);
@@ -1544,8 +1553,6 @@ static int hyperv_init_vcpu(X86CPU *cpu)
  supported_evmcs_version >> 8);
 return -ENOTSUP;
 }
-
-cpu->hyperv_nested[0] = evmcs_version;
 }
 
 if (cpu->hyperv_enforce_cpuid) {
-- 
2.33.1




Re: [PATCH v2] FreeBSD: Upgrade to 12.3 release

2022-01-05 Thread Daniel P . Berrangé
On Tue, Jan 04, 2022 at 09:28:16PM -0500, Brad Smith wrote:
> FreeBSD: Upgrade to 12.3 release
> 
> Note, since libtasn1 was fixed in 12.3 [*], this commit re-enables GnuTLS.
> 
> [*] https://gitlab.com/gnutls/libtasn1/-/merge_requests/71
> 
> 
> Signed-off-by: Brad Smith 
> Tested-by: Thomas Huth 
> Reviewed-by: Warner Losh 
> ---
>  .gitlab-ci.d/cirrus.yml | 5 +
>  tests/vm/freebsd| 8 +++-
>  2 files changed, 4 insertions(+), 9 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa

2022-01-05 Thread Jason Wang
On Wed, Jan 5, 2022 at 4:37 PM Longpeng (Mike, Cloud Infrastructure
Service Product Dept.)  wrote:
>
>
>
> > -Original Message-
> > From: Jason Wang [mailto:jasow...@redhat.com]
> > Sent: Wednesday, January 5, 2022 3:54 PM
> > To: Michael S. Tsirkin 
> > Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> > ; Stefan Hajnoczi ; Stefano
> > Garzarella ; Cornelia Huck ; 
> > pbonzini
> > ; Gonglei (Arei) ; Yechuan
> > ; Huangzhichao ; qemu-devel
> > 
> > Subject: Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa
> >
> > On Wed, Jan 5, 2022 at 3:02 PM Michael S. Tsirkin  wrote:
> > >
> > > On Wed, Jan 05, 2022 at 12:35:53PM +0800, Jason Wang wrote:
> > > > On Wed, Jan 5, 2022 at 8:59 AM Longpeng(Mike)  
> > > > wrote:
> > > > >
> > > > > From: Longpeng 
> > > > >
> > > > > To support generic vdpa deivce, we need add the following ioctls:
> > > > > - GET_VECTORS_NUM: the count of vectors that supported
> > > >
> > > > Does this mean MSI vectors? If yes, it looks like a layer violation:
> > > > vhost is transport independent.
> > >
> > > Well *guest* needs to know how many vectors device supports.
> > > I don't think there's a way around that. Do you?
> >
> > We have VHOST_SET_VRING/CONFIG_CALL which is per vq. I think we can
> > simply assume #vqs + 1?
> >
> > > Otherwise guests will at best be suboptimal.
> > >
> > > >  And it reveals device implementation
> > > > details which block (cross vendor) migration.
> > > >
> > > > Thanks
> > >
> > > Not necessarily, userspace can hide this from guest if it
> > > wants to, just validate.
> >
> > If we can hide it at vhost/uAPI level, it would be even better?
> >
>
> Not only MSI vectors, but also queue-size, #vqs, etc.

MSI is PCI specific, we have non PCI vDPA parent e.g VDUSE/simulator/mlx5

And it's something that is not guaranteed to be not changed. E.g some
drivers may choose to allocate MSI during set_status() which can fail
for various reasons.

>
> Maybe the vhost level could expose the hardware's real capabilities
> and let the userspace (QEMU) do the hiding? The userspace know how
> to process them.

#MSI vectors is much more easier to be mediated than queue-size and #vqs.

For interrupts, we've already had VHOST_SET_X_KICK, we can keep
allocating eventfd based on #MSI vectors to make it work with any
number of MSI vectors that the virtual device had.

For queue-size, it's Ok to have a new uAPI but it's not a must, Qemu
can simply fail if SET_VRING_NUM fail.

For #vqs, it's OK to have a new uAPI since the emulated virtio-pci
device requires knowledge the #vqs in the config space. (still not a
must, we can enumerate #vqs per device type)

For the config size, it's OK but not a must, technically we can simply
relay what guest write to vhost-vdpa. It's just because current Qemu
require to have it during virtio device initialization.

Thanks

>
> > Thanks
> >
> > >
> > >
> > > > > - GET_CONFIG_SIZE: the size of the virtio config space
> > > > > - GET_VQS_NUM: the count of virtqueues that exported
> > > > >
> > > > > Signed-off-by: Longpeng 
> > > > > ---
> > > > >  linux-headers/linux/vhost.h | 10 ++
> > > > >  1 file changed, 10 insertions(+)
> > > > >
> > > > > diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h
> > > > > index c998860d7b..c5edd75d15 100644
> > > > > --- a/linux-headers/linux/vhost.h
> > > > > +++ b/linux-headers/linux/vhost.h
> > > > > @@ -150,4 +150,14 @@
> > > > >  /* Get the valid iova range */
> > > > >  #define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
> > > > >  struct 
> > > > > vhost_vdpa_iova_range)
> > > > > +
> > > > > +/* Get the number of vectors */
> > > > > +#define VHOST_VDPA_GET_VECTORS_NUM _IOR(VHOST_VIRTIO, 0x79, int)
> > > > > +
> > > > > +/* Get the virtio config size */
> > > > > +#define VHOST_VDPA_GET_CONFIG_SIZE _IOR(VHOST_VIRTIO, 0x80, int)
> > > > > +
> > > > > +/* Get the number of virtqueues */
> > > > > +#define VHOST_VDPA_GET_VQS_NUM _IOR(VHOST_VIRTIO, 0x81, int)
> > > > > +
> > > > >  #endif
> > > > > --
> > > > > 2.23.0
> > > > >
> > >
>




Re: [PATCH] docs/can: convert to restructuredText

2022-01-05 Thread Thomas Huth

On 17/12/2021 22.21, oxr...@gmx.us wrote:

From: Lucas Ramage 


 Hi!

Thanks for your patch! This looks like a good idea, but I think there are 
some minor issues which should be fixed...


First: Please check your mailer setup. The mail has been sent via @gmx.us, 
but the Signed-off-by uses @infinite-omicron.com ... not a big issue, I 
guess, but it might be better to use the same address for both.


Second, it does not work here, at least not with Sphinx 1.7 which I have 
installed on my system:


 docs/can.rst:39:Enumerated list ends without a blank line;
 unexpected unindent.

Does this render correctly on your system?

Also there are paragraphs in this file which should be clearly marked as 
pre-formatted text (use "::" for those), e.g.:


diff --git a/docs/can.rst b/docs/can.rst
--- a/docs/can.rst
+++ b/docs/can.rst
@@ -122,7 +125,7 @@ is setup according to the previous SJA1000 section.
 -device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus \
 -nographic

-Setup of CTU CAN FD controller in a guest Linux system
+Setup of CTU CAN FD controller in a guest Linux system::

   insmod ctucanfd.ko || modprobe ctucanfd
   insmod ctucanfd_pci.ko || modprobe ctucanfd_pci


Bug: https://gitlab.com/qemu-project/qemu/-/issues/527


Please use "Buglink:" instead, it's more common in the QEMU project.


Signed-off-by: Lucas Ramage 
---
  docs/{can.txt => can.rst} | 14 ++


While you're at it, I think this file should be moved into one of the 
subfolders as well, likely docs/system/ I guess.



  docs/index.rst|  1 +
  2 files changed, 7 insertions(+), 8 deletions(-)
  rename docs/{can.txt => can.rst} (97%)

diff --git a/docs/can.txt b/docs/can.rst
similarity index 97%
rename from docs/can.txt
rename to docs/can.rst
index 0d310237df..995134d079 100644
--- a/docs/can.txt
+++ b/docs/can.rst

[...]

@@ -196,3 +193,4 @@ Links to other resources
   
http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/driver_doc/ctucanfd-driver.html
   (11) Integration with PCIe interfacing for Intel/Altera Cyclone IV based 
board
   https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd
+


This look like an unnecessary addition of an empty line.


diff --git a/docs/index.rst b/docs/index.rst
index 0b9ee9901d..beb868ca7f 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -18,3 +18,4 @@ Welcome to QEMU's documentation!
 interop/index
 specs/index
 devel/index
+   can
--
2.32.0




 Thomas




Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa

2022-01-05 Thread Michael S. Tsirkin
On Wed, Jan 05, 2022 at 03:54:13PM +0800, Jason Wang wrote:
> On Wed, Jan 5, 2022 at 3:02 PM Michael S. Tsirkin  wrote:
> >
> > On Wed, Jan 05, 2022 at 12:35:53PM +0800, Jason Wang wrote:
> > > On Wed, Jan 5, 2022 at 8:59 AM Longpeng(Mike)  
> > > wrote:
> > > >
> > > > From: Longpeng 
> > > >
> > > > To support generic vdpa deivce, we need add the following ioctls:
> > > > - GET_VECTORS_NUM: the count of vectors that supported
> > >
> > > Does this mean MSI vectors? If yes, it looks like a layer violation:
> > > vhost is transport independent.
> >
> > Well *guest* needs to know how many vectors device supports.
> > I don't think there's a way around that. Do you?
> 
> We have VHOST_SET_VRING/CONFIG_CALL which is per vq. I think we can
> simply assume #vqs + 1?

Some hardware may be more limited. E.g. there could be a bunch of vqs
which don't need a dedicated interrupt. Or device could support a single
interrupt shared between VQs.


> > Otherwise guests will at best be suboptimal.
> >
> > >  And it reveals device implementation
> > > details which block (cross vendor) migration.
> > >
> > > Thanks
> >
> > Not necessarily, userspace can hide this from guest if it
> > wants to, just validate.
> 
> If we can hide it at vhost/uAPI level, it would be even better?
> 
> Thanks
> 
> >
> >
> > > > - GET_CONFIG_SIZE: the size of the virtio config space
> > > > - GET_VQS_NUM: the count of virtqueues that exported
> > > >
> > > > Signed-off-by: Longpeng 
> > > > ---
> > > >  linux-headers/linux/vhost.h | 10 ++
> > > >  1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h
> > > > index c998860d7b..c5edd75d15 100644
> > > > --- a/linux-headers/linux/vhost.h
> > > > +++ b/linux-headers/linux/vhost.h
> > > > @@ -150,4 +150,14 @@
> > > >  /* Get the valid iova range */
> > > >  #define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
> > > >  struct 
> > > > vhost_vdpa_iova_range)
> > > > +
> > > > +/* Get the number of vectors */
> > > > +#define VHOST_VDPA_GET_VECTORS_NUM _IOR(VHOST_VIRTIO, 0x79, int)
> > > > +
> > > > +/* Get the virtio config size */
> > > > +#define VHOST_VDPA_GET_CONFIG_SIZE _IOR(VHOST_VIRTIO, 0x80, int)
> > > > +
> > > > +/* Get the number of virtqueues */
> > > > +#define VHOST_VDPA_GET_VQS_NUM _IOR(VHOST_VIRTIO, 0x81, int)
> > > > +
> > > >  #endif
> > > > --
> > > > 2.23.0
> > > >
> >




Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa

2022-01-05 Thread Jason Wang
On Wed, Jan 5, 2022 at 5:12 PM Michael S. Tsirkin  wrote:
>
> On Wed, Jan 05, 2022 at 03:54:13PM +0800, Jason Wang wrote:
> > On Wed, Jan 5, 2022 at 3:02 PM Michael S. Tsirkin  wrote:
> > >
> > > On Wed, Jan 05, 2022 at 12:35:53PM +0800, Jason Wang wrote:
> > > > On Wed, Jan 5, 2022 at 8:59 AM Longpeng(Mike)  
> > > > wrote:
> > > > >
> > > > > From: Longpeng 
> > > > >
> > > > > To support generic vdpa deivce, we need add the following ioctls:
> > > > > - GET_VECTORS_NUM: the count of vectors that supported
> > > >
> > > > Does this mean MSI vectors? If yes, it looks like a layer violation:
> > > > vhost is transport independent.
> > >
> > > Well *guest* needs to know how many vectors device supports.
> > > I don't think there's a way around that. Do you?
> >
> > We have VHOST_SET_VRING/CONFIG_CALL which is per vq. I think we can
> > simply assume #vqs + 1?
>
> Some hardware may be more limited. E.g. there could be a bunch of vqs
> which don't need a dedicated interrupt. Or device could support a single
> interrupt shared between VQs.

Right, but in the worst case, we may just waste some eventfds?

Or if we want to be optimized in the case you mentioned above, we need
to know the association among vectors and vqs which requires more
extensions.

1) API to know which vectors does a dedicated VQ belong
2) the kick eventfd is set based on the vectors but not vq

And such mappings are not static, e.g IFCVF requesting MSI-X vectors
during DRIVER_OK.

Thanks

>
>
> > > Otherwise guests will at best be suboptimal.
> > >
> > > >  And it reveals device implementation
> > > > details which block (cross vendor) migration.
> > > >
> > > > Thanks
> > >
> > > Not necessarily, userspace can hide this from guest if it
> > > wants to, just validate.
> >
> > If we can hide it at vhost/uAPI level, it would be even better?
> >
> > Thanks
> >
> > >
> > >
> > > > > - GET_CONFIG_SIZE: the size of the virtio config space
> > > > > - GET_VQS_NUM: the count of virtqueues that exported
> > > > >
> > > > > Signed-off-by: Longpeng 
> > > > > ---
> > > > >  linux-headers/linux/vhost.h | 10 ++
> > > > >  1 file changed, 10 insertions(+)
> > > > >
> > > > > diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h
> > > > > index c998860d7b..c5edd75d15 100644
> > > > > --- a/linux-headers/linux/vhost.h
> > > > > +++ b/linux-headers/linux/vhost.h
> > > > > @@ -150,4 +150,14 @@
> > > > >  /* Get the valid iova range */
> > > > >  #define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
> > > > >  struct 
> > > > > vhost_vdpa_iova_range)
> > > > > +
> > > > > +/* Get the number of vectors */
> > > > > +#define VHOST_VDPA_GET_VECTORS_NUM _IOR(VHOST_VIRTIO, 0x79, int)
> > > > > +
> > > > > +/* Get the virtio config size */
> > > > > +#define VHOST_VDPA_GET_CONFIG_SIZE _IOR(VHOST_VIRTIO, 0x80, int)
> > > > > +
> > > > > +/* Get the number of virtqueues */
> > > > > +#define VHOST_VDPA_GET_VQS_NUM _IOR(VHOST_VIRTIO, 0x81, int)
> > > > > +
> > > > >  #endif
> > > > > --
> > > > > 2.23.0
> > > > >
> > >
>




Re: [PATCH v3 3/5] hw/arm/virt: Honor highmem setting when computing the memory map

2022-01-05 Thread Eric Auger
Hi Marc,

On 12/27/21 10:16 PM, Marc Zyngier wrote:
> Even when the VM is configured with highmem=off, the highest_gpa
> field includes devices that are above the 4GiB limit.
> Similarily, nothing seem to check that the memory is within
> the limit set by the highmem=off option.
>
> This leads to failures in virt_kvm_type() on systems that have
> a crippled IPA range, as the reported IPA space is larger than
> what it should be.
>
> Instead, honor the user-specified limit to only use the devices
> at the lowest end of the spectrum, and fail if we have memory
> crossing the 4GiB limit.
>
> Reviewed-by: Andrew Jones 
> Signed-off-by: Marc Zyngier 
> ---
>  hw/arm/virt.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 8b600d82c1..84dd3b36fb 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1678,6 +1678,11 @@ static void virt_set_memmap(VirtMachineState *vms)
>  exit(EXIT_FAILURE);
>  }
>  
> +if (!vms->highmem &&
> +vms->memmap[VIRT_MEM].base + ms->maxram_size > 4 * GiB) {
> +error_report("highmem=off, but memory crosses the 4GiB limit\n");
> +exit(EXIT_FAILURE);

The memory is composed of initial memory and device memory.
device memory is put after the initial memory but has a 1GB alignment
On top of that you have 1G page alignment per device memory slot

so potentially the highest mem address is larger than
vms->memmap[VIRT_MEM].base + ms->maxram_size.
I would rather do the check on device_memory_base + device_memory_size
> +}
>  /*
>   * We compute the base of the high IO region depending on the
>   * amount of initial and device memory. The device memory start/size
> @@ -1707,7 +1712,9 @@ static void virt_set_memmap(VirtMachineState *vms)
>  vms->memmap[i].size = size;
>  base += size;
>  }
> -vms->highest_gpa = base - 1;
> +vms->highest_gpa = (vms->highmem ?
> +base :
> +vms->memmap[VIRT_MEM].base + ms->maxram_size) - 1;
As per the previous comment this looks wrong to me if !highmem.

If !highmem, if RAM requirements are low we still could get benefit from
REDIST2 and HIGH ECAM which could fit within the 4GB limit. But maybe we
simply don't care? If we don't, why don't we simply skip the
extended_memmap overlay as suggested in v2? I did not get your reply sorry.

Thanks

Eric
>  if (device_memory_size > 0) {
>  ms->device_memory = g_malloc0(sizeof(*ms->device_memory));
>  ms->device_memory->base = device_memory_base;




Re: [PATCH v5 00/18] tests/docker: start using libvirt-ci's "lcitool" for dockerfiles

2022-01-05 Thread Alex Bennée


Daniel P. Berrangé  writes:

> Currently the tests/docker/dockerfiles/*Dockerfile recipes are all hand
> written by contributors. There is a common design pattern, but the set
> of packages listed for installation leaves alot to be desired

Queued to testing/next, thanks.

-- 
Alex Bennée



Re: [PATCH v3 3/5] hw/arm/virt: Honor highmem setting when computing the memory map

2022-01-05 Thread Eric Auger
Hi Marc,

On 1/5/22 10:22 AM, Eric Auger wrote:
> Hi Marc,
> 
> On 12/27/21 10:16 PM, Marc Zyngier wrote:
>> Even when the VM is configured with highmem=off, the highest_gpa
>> field includes devices that are above the 4GiB limit.
>> Similarily, nothing seem to check that the memory is within
>> the limit set by the highmem=off option.
>>
>> This leads to failures in virt_kvm_type() on systems that have
>> a crippled IPA range, as the reported IPA space is larger than
>> what it should be.
>>
>> Instead, honor the user-specified limit to only use the devices
>> at the lowest end of the spectrum, and fail if we have memory
>> crossing the 4GiB limit.
>>
>> Reviewed-by: Andrew Jones 
>> Signed-off-by: Marc Zyngier 
>> ---
>>  hw/arm/virt.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 8b600d82c1..84dd3b36fb 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -1678,6 +1678,11 @@ static void virt_set_memmap(VirtMachineState *vms)
>>  exit(EXIT_FAILURE);
>>  }
>>  
>> +if (!vms->highmem &&
>> +vms->memmap[VIRT_MEM].base + ms->maxram_size > 4 * GiB) {
>> +error_report("highmem=off, but memory crosses the 4GiB limit\n");
>> +exit(EXIT_FAILURE);
> 
> The memory is composed of initial memory and device memory.
> device memory is put after the initial memory but has a 1GB alignment
> On top of that you have 1G page alignment per device memory slot
> 
> so potentially the highest mem address is larger than
> vms->memmap[VIRT_MEM].base + ms->maxram_size.
> I would rather do the check on device_memory_base + device_memory_size
>> +}
>>  /*
>>   * We compute the base of the high IO region depending on the
>>   * amount of initial and device memory. The device memory start/size
>> @@ -1707,7 +1712,9 @@ static void virt_set_memmap(VirtMachineState *vms)
>>  vms->memmap[i].size = size;
>>  base += size;
>>  }
>> -vms->highest_gpa = base - 1;
>> +vms->highest_gpa = (vms->highmem ?
>> +base :
>> +vms->memmap[VIRT_MEM].base + ms->maxram_size) - 1;
> As per the previous comment this looks wrong to me if !highmem.
> 
> If !highmem, if RAM requirements are low we still could get benefit from
> REDIST2 and HIGH ECAM which could fit within the 4GB limit. But maybe we
the above assertion is wrong, sorry, as we kept the legacy mem map in
that situation (HIGH regions always put above 256 GB). So anyway we can
skip the extended memmap if !highmem.

Eric
> simply don't care? If we don't, why don't we simply skip the
> extended_memmap overlay as suggested in v2? I did not get your reply sorry.
> 
> Thanks
> 
> Eric
>>  if (device_memory_size > 0) {
>>  ms->device_memory = g_malloc0(sizeof(*ms->device_memory));
>>  ms->device_memory->base = device_memory_base;
> 




Re: [PATCH v2 1/5] hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam

2022-01-05 Thread Eric Auger
Hi Marc,

On 1/4/22 11:15 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Tue, 04 Jan 2022 15:31:33 +,
> Eric Auger  wrote:
>> Hi Marc,
>>
>> On 12/27/21 4:53 PM, Marc Zyngier wrote:
>>> Hi Eric,
>>>
>>> Picking this up again after a stupidly long time...
>>>
>>> On Mon, 04 Oct 2021 13:00:21 +0100,
>>> Eric Auger  wrote:
 Hi Marc,

 On 10/3/21 6:46 PM, Marc Zyngier wrote:
> Currently, the highmem PCIe region is oddly keyed on the highmem
> attribute instead of highmem_ecam. Move the enablement of this PCIe
> region over to highmem_ecam.
>
> Signed-off-by: Marc Zyngier 
> ---
>  hw/arm/virt-acpi-build.c | 10 --
>  hw/arm/virt.c|  4 ++--
>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 037cc1fd82..d7bef0e627 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -157,10 +157,9 @@ static void acpi_dsdt_add_virtio(Aml *scope,
>  }
>  
>  static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry *memmap,
> -  uint32_t irq, bool use_highmem, bool 
> highmem_ecam,
> -  VirtMachineState *vms)
> +  uint32_t irq, VirtMachineState *vms)
>  {
> -int ecam_id = VIRT_ECAM_ID(highmem_ecam);
> +int ecam_id = VIRT_ECAM_ID(vms->highmem_ecam);
>  struct GPEXConfig cfg = {
>  .mmio32 = memmap[VIRT_PCIE_MMIO],
>  .pio= memmap[VIRT_PCIE_PIO],
> @@ -169,7 +168,7 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
> MemMapEntry *memmap,
>  .bus= vms->bus,
>  };
>  
> -if (use_highmem) {
> +if (vms->highmem_ecam) {
 highmem_ecam is more restrictive than use_highmem:
 vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);

 If I remember correctly there was a problem using highmem ECAM with 32b
 AAVMF FW.

 However 5125f9cd2532 ("hw/arm/virt: Add high MMIO PCI region, 512G in
 size") introduced high MMIO PCI region without this constraint.
>>> Then I really don't understand the point of this highmem_ecam. We only
>>> register the highmem version if highmem_ecam is set (see the use of
>>> VIRT_ECAM_ID() to pick the right ECAM window).
>> but aren't we talking about different regions? On one hand the [high]
>> MMIO region (512GB wide) and the [high] ECAM region (256MB large).
>> To me you can enable either independently. High MMIO region is used by
>> some devices likes ivshmem/video cards while high ECAM was introduced to
>> extend the number of supported buses: 601d626d148a (hw/arm/virt: Add a
>> new 256MB ECAM region).
>>
>> with the above change the high MMIO region won't be set with 32b
>> FW+kernel and LPAE whereas it is currently.
>>
>> high ECAM was not supported by 32b FW, hence the highmem_ecam.
>>
>> but maybe I miss your point?
> There are two issues.
>
> First, I have been conflating the ECAM and MMIO ranges, and you only
> made me realise that they were supposed to be independent.  I still
> think the keying on highmem is wrong, but the main issue is that the
> highmem* flags don't quite describe the shape of the platform.
>
> All these booleans indicate is whether the feature they describe (the
> high MMIO range, the high ECAM range, and in one of my patches the
> high RD range) are *allowed* to live above 4GB, but do not express
> whether then are actually usable (i.e. fit in the PA range).
>
> Maybe we need to be more thorough in the way we describe the extended
> region in the VirtMachineState structure:
>
> - highmem: overall control for anything that *can* live above 4GB
> - highmem_ecam: Has a PCIe ECAM region above 256GB
> - highmem_mmio: Has a PCIe MMIO region above 256GB
> - highmem_redist: Has 512 RDs above 256GB
>
> Crucially, the last 3 items must fit in the PA range or be disabled.
>
> We have highmem_ecam which is keyed on highmem, but not on the PA
> range.  highmem_mmio doesn't exist at all (we use highmem instead),
"highmem_ecam is keyed on highmem but not on the PA range". True but it
is properly taken into account in highest_gpa computation so eventually
we make sure it does not overflow the IPA limit. Same for the high mmio
region which is keyed on highmem.
> and I'm only introducing highmem_redist.
>
> For these 3 ranges, we should have something like
>
> vms->highmem_xxx &= (vms->highmem &&
>(vms->memmap[XXX].base + vms->vms->memmap[XXX].size) < 
> vms->highest_gpa);

couldn't you simply introduce highmem_redist which is truly missing. You
could set it in virt_set_memmap() in case you skip extended_map overlay
and use it in virt_gicv3_redist_region_count() as you did?
In addition to the device memory top address check against the 4GB limit
if !highmem, we should be fine then?

Eric
>
> and treat them as independent entities.  U

Re: [PATCH] gitlab-ci: Enable docs in the centos job

2022-01-05 Thread Alex Bennée


Thomas Huth  writes:

> We just ran into a problem that the docs don't build on RHEL8 / CentOS 8
> anymore. Seems like these distros are using one of the oldest Sphinx
> versions that we still have to support. Thus enable the docs build in
> the CI on CentOS so that such bugs don't slip in so easily again.
>
> Signed-off-by: Thomas Huth 

Queued to testing/next, thanks.

-- 
Alex Bennée



Re: [PATCH] docker: include bison in debian-tricore-cross

2022-01-05 Thread Alex Bennée


Paolo Bonzini  writes:

> Binutils sometimes fail to build if bison is not installed:
>
>   /bin/sh ./ylwrap `test -f arparse.y || echo ./`arparse.y y.tab.c arparse.c 
> y.tab.h arparse.h y.output arparse.output --  -d
>   ./ylwrap: 109: ./ylwrap: -d: not found
>
> (the correct invocation of ylwrap would have "bison -d" after the double
> dash).  Work around by installing it in the container.
>
> Cc: Alex Bennée 
> Signed-off-by: Paolo Bonzini 

Queued to testing/next, thanks.

-- 
Alex Bennée



Re: [PATCH] linux-user: Remove the deprecated ppc64abi32 target

2022-01-05 Thread Alex Bennée


Thomas Huth  writes:

> It's likely broken, and nobody cared for picking it up again
> during the deprecation phase, so let's remove this now.
>
> Since this is the last entry in deprecated_targets_list, remove
> the related code in the configure script, too.
>
> Signed-off-by: Thomas Huth 

Queued to testing/next, thanks.

-- 
Alex Bennée



Re: [RFC 03/10] vdpa: add the infrastructure of vdpa-dev

2022-01-05 Thread Stefan Hajnoczi
On Wed, Jan 05, 2022 at 08:58:53AM +0800, Longpeng(Mike) wrote:
> +static const VirtioPCIDeviceTypeInfo vhost_vdpa_device_pci_info = {
> +.base_name   = TYPE_VHOST_VDPA_DEVICE_PCI,
> +.generic_name= "vhost-vdpa-device-pci",
> +.transitional_name   = "vhost-vdpa-device-pci-transitional",
> +.non_transitional_name   = "vhost-vdpa-device-pci-non-transitional",

Does vDPA support Transitional VIRTIO devices?

I expected this device to support Modern devices only.

Stefan


signature.asc
Description: PGP signature


[PATCH 1/2] target/ppc: Add popcntb instruction to POWER5+ processors

2022-01-05 Thread Cédric Le Goater
popcntb instruction was added in ISA v2.02. Add support for POWER5+
processors since they implement ISA v2.03.

PPC970 CPUs implement v2.01 and do not support popcntb.

Signed-off-by: Cédric Le Goater 
---
 target/ppc/cpu_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index cc93bff3fac4..f15a52259c90 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -6957,6 +6957,7 @@ POWERPC_FAMILY(POWER5P)(ObjectClass *oc, void *data)
PPC_MEM_SYNC | PPC_MEM_EIEIO |
PPC_MEM_TLBIE | PPC_MEM_TLBSYNC |
PPC_64B |
+   PPC_POPCNTB |
PPC_SEGMENT_64B | PPC_SLBI;
 pcc->insns_flags2 = PPC2_FP_CVT_S64;
 pcc->msr_mask = (1ull << MSR_SF) |
-- 
2.31.1




[PATCH] MAINTAINERS: Add entry for QEMU Guest Agent Windows components

2022-01-05 Thread Kostiantyn Kostiuk
Signed-off-by: Kostiantyn Kostiuk 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f871d759fd..1f255ec874 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2729,6 +2729,14 @@ F: scripts/qemu-guest-agent/
 F: tests/unit/test-qga.c
 T: git https://github.com/mdroth/qemu.git qga

+QEMU Guest Agent Win32
+M: Konstantin Kostiuk 
+S: Maintained
+F: qga/*win32*
+F: qga/vss-win32/
+F: qga/installer/
+T: git https://github.com/kostyanf14/qemu.git qga-win32
+
 QOM
 M: Paolo Bonzini 
 R: Daniel P. Berrange 
--
2.25.1




[PATCH 0/2] spapr: Fix support of POWER5+ processors

2022-01-05 Thread Cédric Le Goater
Hello,

Grab the images under : 

  
https://github.com/legoater/qemu-ppc-boot/tree/main/buildroot/qemu_ppc64_pseries_p5p-2021.11-730-g4f325ce788-20220104

and run with :

  qemu-system-ppc64 -M pseries -cpu POWER5+ -m 1G -smp 2 -kernel ./vmlinux 
-append "root=/dev/sda" -drive file=./rootfs.ext2,if=scsi,index=0,format=raw  
-device spapr-vlan,netdev=net0 -netdev user,id=net0 -serial mon:stdio 
-nographic -nodefaults

CPU 970, 970MP are also well supported. 

Virtio devices and USB should be avoided because SLOF would use a
'stdbrx' instruction (cpu_to_le64 helper) which is invalid under
POWER5+ and 970 CPUs. SLOF needs to be compiled with -mcpu=power5 to
fix this issue.

Thanks,

C. 

Cédric Le Goater (2):
  target/ppc: Add popcntb instruction to POWER5+ processors
  spapr: Fix support of POWER5+ processors

 hw/ppc/spapr.c| 10 ++
 target/ppc/cpu_init.c |  1 +
 2 files changed, 7 insertions(+), 4 deletions(-)

-- 
2.31.1




[PATCH 2/2] spapr: Fix support of POWER5+ processors

2022-01-05 Thread Cédric Le Goater
POWER5+ (ISA v2.03) processors are supported by the pseries machine
but they do not have Altivec instructions. Do not advertise support
for it in the DT.

To be noted that this test is in contradiction with the assert in
cap_vsx_apply().

Signed-off-by: Cédric Le Goater 
---
 hw/ppc/spapr.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3b5fd749be89..69c9e1c59f5e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -723,10 +723,12 @@ static void spapr_dt_cpu(CPUState *cs, void *fdt, int 
offset,
  *
  * Only CPUs for which we create core types in spapr_cpu_core.c
  * are possible, and all of those have VMX */
-if (spapr_get_cap(spapr, SPAPR_CAP_VSX) != 0) {
-_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 2)));
-} else {
-_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 1)));
+if (env->insns_flags & PPC_ALTIVEC) {
+if (spapr_get_cap(spapr, SPAPR_CAP_VSX) != 0) {
+_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 2)));
+} else {
+_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 1)));
+}
 }
 
 /* Advertise DFP (Decimal Floating Point) if available
-- 
2.31.1




Re: [RFC 04/10] vdpa-dev: implement the instance_init/class_init interface

2022-01-05 Thread Stefan Hajnoczi
On Wed, Jan 05, 2022 at 08:58:54AM +0800, Longpeng(Mike) wrote:
> From: Longpeng 
> 
> Implements the .instance_init and the .class_init interface.
> 
> Signed-off-by: Longpeng 
> ---
>  hw/virtio/vdpa-dev-pci.c | 80 +++-
>  hw/virtio/vdpa-dev.c | 68 +-
>  include/hw/virtio/vdpa-dev.h |  2 +
>  3 files changed, 146 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/virtio/vdpa-dev-pci.c b/hw/virtio/vdpa-dev-pci.c
> index a5a7b528a9..0af54a26d4 100644
> --- a/hw/virtio/vdpa-dev-pci.c
> +++ b/hw/virtio/vdpa-dev-pci.c
> @@ -23,14 +23,90 @@ struct VhostVdpaDevicePCI {
>  VhostVdpaDevice vdev;
>  };
>  
> +static uint32_t
> +vdpa_dev_pci_get_info(const char *name, uint64_t cmd, Error **errp)

vdpa_dev_pci_get_u32() might be a clearer name.

> +{
> +int device_fd;
> +uint32_t val;
> +int ret;
> +
> +device_fd = qemu_open(name, O_RDWR, errp);
> +if (device_fd == -1) {
> +return (uint32_t)-1;
> +}
> +
> +ret = ioctl(device_fd, cmd, &val);
> +if (ret < 0) {
> +error_setg(errp, "vhost-vdpa-device-pci: cmd 0x%lx failed: %s",
> +   cmd, strerror(errno));
> +goto out;
> +}
> +
> +out:
> +close(device_fd);

Race conditions are possible if the device node is replaced between
calls. Why not open the file once and reuse the fd across ioctl calls?

Both VhostVdpaDevicePCI and VhostVdpaDevice need the fd but
VhostVdpaDevicePCI needs it first. I suggest passing ownership of the fd
to the VhostVdpaDevice. One way of doing this is using QOM properties so
that VhostVdpaDevice can use the given fd instead of reopening the file.
(If fd is -1 then VhostVdpaDevice can try to open the file. That is
necessary when VhostVdpaDevice is used directly with virtio-mmio because
there is no proxy object.)


signature.asc
Description: PGP signature


Re: [PATCH v2] FreeBSD: Upgrade to 12.3 release

2022-01-05 Thread Philippe Mathieu-Daudé
On 1/5/22 03:28, Brad Smith wrote:
> FreeBSD: Upgrade to 12.3 release
> 
> Note, since libtasn1 was fixed in 12.3 [*], this commit re-enables GnuTLS.
> 
> [*] https://gitlab.com/gnutls/libtasn1/-/merge_requests/71
> 
> 
> Signed-off-by: Brad Smith 
> Tested-by: Thomas Huth 
> Reviewed-by: Warner Losh 
> ---
>  .gitlab-ci.d/cirrus.yml | 5 +
>  tests/vm/freebsd| 8 +++-
>  2 files changed, 4 insertions(+), 9 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 



Re: [PATCH] common-user: Really fix i386 calls to safe_syscall_set_errno_tail

2022-01-05 Thread Philippe Mathieu-Daudé
On 1/5/22 06:23, Richard Henderson wrote:
> Brown bag time: offset 0 from esp is the return address,
> offset 4 is the first argument.
> 
> Fixes: d7478d4229f0 ("common-user: Fix tail calls to 
> safe_syscall_set_errno_tail")
> Signed-off-by: Richard Henderson 
> ---
> 
> Ho hum.  I'm disappointed that our CI didn't catch this,
> despite cross-i386-user.  And I'm disappointed that I
> didn't run a full manual build on an i386 vm to catch
> it myself.  I plan on committing this directly.

Sorry for missing this myself too while reviewing, x86 is my weakness.

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  common-user/host/i386/safe-syscall.inc.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common-user/host/i386/safe-syscall.inc.S 
> b/common-user/host/i386/safe-syscall.inc.S
> index 9c45e56e480..db2ed098394 100644
> --- a/common-user/host/i386/safe-syscall.inc.S
> +++ b/common-user/host/i386/safe-syscall.inc.S
> @@ -120,7 +120,7 @@ safe_syscall_end:
>  pop %ebp
>  .cfi_adjust_cfa_offset -4
>  .cfi_restore ebp
> -mov %eax, (%esp)
> +mov %eax, 4(%esp)
>  jmp safe_syscall_set_errno_tail
>  
>  .cfi_endproc



Re: [PATCH v4 1/2] linux-user: add sched_getattr support

2022-01-05 Thread Laurent Vivier

Le 05/01/2022 à 05:18, Tonis Tiigi a écrit :

These syscalls are not exposed by glibc. The struct type need to be
redefined as it can't be included directly before
https://lkml.org/lkml/2020/5/28/810 .

sched_attr type can grow in future kernel versions. When client sends
values that QEMU does not understand it will return E2BIG with same
semantics as old kernel would so client can retry with smaller inputs.

Signed-off-by: Tonis Tiigi 
---
  linux-user/syscall.c  | 123 ++
  linux-user/syscall_defs.h |  14 +
  2 files changed, 137 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 56a3e17183..1b8415c8a3 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -340,6 +340,25 @@ _syscall3(int, sys_sched_getaffinity, pid_t, pid, unsigned 
int, len,
  #define __NR_sys_sched_setaffinity __NR_sched_setaffinity
  _syscall3(int, sys_sched_setaffinity, pid_t, pid, unsigned int, len,
unsigned long *, user_mask_ptr);
+/* sched_attr is not defined in glibc */
+struct sched_attr {
+uint32_t size;
+uint32_t sched_policy;
+uint64_t sched_flags;
+int32_t sched_nice;
+uint32_t sched_priority;
+uint64_t sched_runtime;
+uint64_t sched_deadline;
+uint64_t sched_period;
+uint32_t sched_util_min;
+uint32_t sched_util_max;
+};
+#define __NR_sys_sched_getattr __NR_sched_getattr
+_syscall4(int, sys_sched_getattr, pid_t, pid, struct sched_attr *, attr,
+  unsigned int, size, unsigned int, flags);
+#define __NR_sys_sched_setattr __NR_sched_setattr
+_syscall3(int, sys_sched_setattr, pid_t, pid, struct sched_attr *, attr,
+  unsigned int, flags);
  #define __NR_sys_getcpu __NR_getcpu
  _syscall3(int, sys_getcpu, unsigned *, cpu, unsigned *, node, void *, tcache);
  _syscall4(int, reboot, int, magic1, int, magic2, unsigned int, cmd,
@@ -558,6 +577,24 @@ const char *target_strerror(int err)
  return strerror(target_to_host_errno(err));
  }
  
+static int check_zeroed_user(abi_long addr, size_t ksize, size_t usize)

+{
+int i;
+uint8_t b;
+if (usize <= ksize) {
+return 1;
+}
+for (i = ksize; i < usize; i++) {
+if (get_user_u8(b, addr + i)) {
+return -TARGET_EFAULT;
+}
+if (b != 0) {
+return 0;
+}
+}
+return 1;
+}
+
  #define safe_syscall0(type, name) \
  static type safe_##name(void) \
  { \
@@ -10594,6 +10631,92 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  }
  case TARGET_NR_sched_getscheduler:
  return get_errno(sched_getscheduler(arg1));
+case TARGET_NR_sched_getattr:
+{
+struct target_sched_attr *target_scha;
+struct sched_attr scha;
+if (arg2 == 0) {
+return -TARGET_EINVAL;
+}
+if (arg3 > sizeof(scha)) {
+arg3 = sizeof(scha);
+}
+ret = get_errno(sys_sched_getattr(arg1, &scha, arg3, arg4));
+if (!is_error(ret)) {
+target_scha = lock_user(VERIFY_WRITE, arg2, arg3, 0);
+if (!target_scha) {
+return -TARGET_EFAULT;
+}
+target_scha->size = tswap32(scha.size);
+target_scha->sched_policy = tswap32(scha.sched_policy);
+target_scha->sched_flags = tswap64(scha.sched_flags);
+target_scha->sched_nice = tswap32(scha.sched_nice);
+target_scha->sched_priority = tswap32(scha.sched_priority);
+target_scha->sched_runtime = tswap64(scha.sched_runtime);
+target_scha->sched_deadline = tswap64(scha.sched_deadline);
+target_scha->sched_period = tswap64(scha.sched_period);
+if (scha.size > offsetof(struct sched_attr, sched_util_min)) {
+target_scha->sched_util_min = tswap32(scha.sched_util_min);
+target_scha->sched_util_max = tswap32(scha.sched_util_max);
+}
+unlock_user(target_scha, arg2, arg3);
+}
+return ret;
+}
+case TARGET_NR_sched_setattr:
+{
+struct target_sched_attr *target_scha;
+struct sched_attr scha;
+uint32_t size;
+int zeroed;
+if (arg2 == 0) {
+return -TARGET_EINVAL;
+}
+if (get_user_u32(size, arg2)) {
+return -TARGET_EFAULT;
+}
+if (!size) {
+size = offsetof(struct target_sched_attr, sched_util_min);
+}
+if (size < offsetof(struct target_sched_attr, sched_util_min)) {
+if (put_user_u32(sizeof(struct target_sched_attr), arg2)) {
+return -TARGET_EFAULT;
+}
+return -TARGET_E2BIG;
+}
+
+zeroed = check_zeroed_user(arg2, sizeof(struct t

Re: [PATCH v4 2/2] linux-user: call set/getscheduler set/getparam directly

2022-01-05 Thread Laurent Vivier

Le 05/01/2022 à 05:18, Tonis Tiigi a écrit :

There seems to be difference in syscall and libc definition of these
methods and therefore musl does not implement them (1e21e78bf7). Call
syscall directly to ensure the behavior of the libc of user application,
not the libc that was used to build QEMU.

Signed-off-by: Tonis Tiigi 
---
  linux-user/syscall.c  | 34 --
  linux-user/syscall_defs.h |  4 
  2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 1b8415c8a3..30962155a6 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -359,6 +359,17 @@ _syscall4(int, sys_sched_getattr, pid_t, pid, struct 
sched_attr *, attr,
  #define __NR_sys_sched_setattr __NR_sched_setattr
  _syscall3(int, sys_sched_setattr, pid_t, pid, struct sched_attr *, attr,
unsigned int, flags);
+#define __NR_sys_sched_getscheduler __NR_sched_getscheduler
+_syscall1(int, sys_sched_getscheduler, pid_t, pid);
+#define __NR_sys_sched_setscheduler __NR_sched_setscheduler
+_syscall3(int, sys_sched_setscheduler, pid_t, pid, int, policy,
+  const struct sched_param *, param);
+#define __NR_sys_sched_getparam __NR_sched_getparam
+_syscall2(int, sys_sched_getparam, pid_t, pid,
+  struct sched_param *, param);
+#define __NR_sys_sched_setparam __NR_sched_setparam
+_syscall2(int, sys_sched_setparam, pid_t, pid,
+  const struct sched_param *, param);
  #define __NR_sys_getcpu __NR_getcpu
  _syscall3(int, sys_getcpu, unsigned *, cpu, unsigned *, node, void *, tcache);
  _syscall4(int, reboot, int, magic1, int, magic2, unsigned int, cmd,
@@ -10587,30 +10598,32 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  return ret;
  case TARGET_NR_sched_setparam:
  {
-struct sched_param *target_schp;
+struct target_sched_param *target_schp;
  struct sched_param schp;
  
  if (arg2 == 0) {

  return -TARGET_EINVAL;
  }
-if (!lock_user_struct(VERIFY_READ, target_schp, arg2, 1))
+if (!lock_user_struct(VERIFY_READ, target_schp, arg2, 1)) {
  return -TARGET_EFAULT;
+}
  schp.sched_priority = tswap32(target_schp->sched_priority);
  unlock_user_struct(target_schp, arg2, 0);
-return get_errno(sched_setparam(arg1, &schp));
+return get_errno(sys_sched_setparam(arg1, &schp));
  }
  case TARGET_NR_sched_getparam:
  {
-struct sched_param *target_schp;
+struct target_sched_param *target_schp;
  struct sched_param schp;
  
  if (arg2 == 0) {

  return -TARGET_EINVAL;
  }
-ret = get_errno(sched_getparam(arg1, &schp));
+ret = get_errno(sys_sched_getparam(arg1, &schp));
  if (!is_error(ret)) {
-if (!lock_user_struct(VERIFY_WRITE, target_schp, arg2, 0))
+if (!lock_user_struct(VERIFY_WRITE, target_schp, arg2, 0)) {
  return -TARGET_EFAULT;
+}
  target_schp->sched_priority = tswap32(schp.sched_priority);
  unlock_user_struct(target_schp, arg2, 1);
  }
@@ -10618,19 +10631,20 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  return ret;
  case TARGET_NR_sched_setscheduler:
  {
-struct sched_param *target_schp;
+struct target_sched_param *target_schp;
  struct sched_param schp;
  if (arg3 == 0) {
  return -TARGET_EINVAL;
  }
-if (!lock_user_struct(VERIFY_READ, target_schp, arg3, 1))
+if (!lock_user_struct(VERIFY_READ, target_schp, arg3, 1)) {
  return -TARGET_EFAULT;
+}
  schp.sched_priority = tswap32(target_schp->sched_priority);
  unlock_user_struct(target_schp, arg3, 0);
-return get_errno(sched_setscheduler(arg1, arg2, &schp));
+return get_errno(sys_sched_setscheduler(arg1, arg2, &schp));
  }
  case TARGET_NR_sched_getscheduler:
-return get_errno(sched_getscheduler(arg1));
+return get_errno(sys_sched_getscheduler(arg1));
  case TARGET_NR_sched_getattr:
  {
  struct target_sched_attr *target_scha;
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 310d6ce8ad..28b9fe9a47 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2928,4 +2928,8 @@ struct target_sched_attr {
  abi_uint sched_util_max;
  };
  
+struct target_sched_param {

+abi_int sched_priority;
+};
+
  #endif


Reviewed-by: Laurent Vivier 




Re: [PATCH v4 1/2] linux-user: add sched_getattr support

2022-01-05 Thread Laurent Vivier

Le 05/01/2022 à 05:18, Tonis Tiigi a écrit :

These syscalls are not exposed by glibc. The struct type need to be
redefined as it can't be included directly before
https://lkml.org/lkml/2020/5/28/810 .

sched_attr type can grow in future kernel versions. When client sends
values that QEMU does not understand it will return E2BIG with same
semantics as old kernel would so client can retry with smaller inputs.

Signed-off-by: Tonis Tiigi 
---
  linux-user/syscall.c  | 123 ++
  linux-user/syscall_defs.h |  14 +
  2 files changed, 137 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 56a3e17183..1b8415c8a3 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -340,6 +340,25 @@ _syscall3(int, sys_sched_getaffinity, pid_t, pid, unsigned 
int, len,
  #define __NR_sys_sched_setaffinity __NR_sched_setaffinity
  _syscall3(int, sys_sched_setaffinity, pid_t, pid, unsigned int, len,
unsigned long *, user_mask_ptr);
+/* sched_attr is not defined in glibc */
+struct sched_attr {
+uint32_t size;
+uint32_t sched_policy;
+uint64_t sched_flags;
+int32_t sched_nice;
+uint32_t sched_priority;
+uint64_t sched_runtime;
+uint64_t sched_deadline;
+uint64_t sched_period;
+uint32_t sched_util_min;
+uint32_t sched_util_max;
+};
+#define __NR_sys_sched_getattr __NR_sched_getattr
+_syscall4(int, sys_sched_getattr, pid_t, pid, struct sched_attr *, attr,
+  unsigned int, size, unsigned int, flags);
+#define __NR_sys_sched_setattr __NR_sched_setattr
+_syscall3(int, sys_sched_setattr, pid_t, pid, struct sched_attr *, attr,
+  unsigned int, flags);
  #define __NR_sys_getcpu __NR_getcpu
  _syscall3(int, sys_getcpu, unsigned *, cpu, unsigned *, node, void *, tcache);
  _syscall4(int, reboot, int, magic1, int, magic2, unsigned int, cmd,
@@ -558,6 +577,24 @@ const char *target_strerror(int err)
  return strerror(target_to_host_errno(err));
  }
  
+static int check_zeroed_user(abi_long addr, size_t ksize, size_t usize)

+{
+int i;
+uint8_t b;
+if (usize <= ksize) {
+return 1;
+}
+for (i = ksize; i < usize; i++) {
+if (get_user_u8(b, addr + i)) {
+return -TARGET_EFAULT;
+}
+if (b != 0) {
+return 0;
+}
+}
+return 1;
+}
+
  #define safe_syscall0(type, name) \
  static type safe_##name(void) \
  { \
@@ -10594,6 +10631,92 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  }
  case TARGET_NR_sched_getscheduler:
  return get_errno(sched_getscheduler(arg1));
+case TARGET_NR_sched_getattr:
+{
+struct target_sched_attr *target_scha;
+struct sched_attr scha;
+if (arg2 == 0) {
+return -TARGET_EINVAL;
+}
+if (arg3 > sizeof(scha)) {
+arg3 = sizeof(scha);
+}
+ret = get_errno(sys_sched_getattr(arg1, &scha, arg3, arg4));
+if (!is_error(ret)) {
+target_scha = lock_user(VERIFY_WRITE, arg2, arg3, 0);
+if (!target_scha) {
+return -TARGET_EFAULT;
+}
+target_scha->size = tswap32(scha.size);
+target_scha->sched_policy = tswap32(scha.sched_policy);
+target_scha->sched_flags = tswap64(scha.sched_flags);
+target_scha->sched_nice = tswap32(scha.sched_nice);
+target_scha->sched_priority = tswap32(scha.sched_priority);
+target_scha->sched_runtime = tswap64(scha.sched_runtime);
+target_scha->sched_deadline = tswap64(scha.sched_deadline);
+target_scha->sched_period = tswap64(scha.sched_period);
+if (scha.size > offsetof(struct sched_attr, sched_util_min)) {
+target_scha->sched_util_min = tswap32(scha.sched_util_min);
+target_scha->sched_util_max = tswap32(scha.sched_util_max);
+}
+unlock_user(target_scha, arg2, arg3);
+}
+return ret;
+}
+case TARGET_NR_sched_setattr:
+{
+struct target_sched_attr *target_scha;
+struct sched_attr scha;
+uint32_t size;
+int zeroed;
+if (arg2 == 0) {
+return -TARGET_EINVAL;
+}
+if (get_user_u32(size, arg2)) {
+return -TARGET_EFAULT;
+}
+if (!size) {
+size = offsetof(struct target_sched_attr, sched_util_min);
+}
+if (size < offsetof(struct target_sched_attr, sched_util_min)) {
+if (put_user_u32(sizeof(struct target_sched_attr), arg2)) {
+return -TARGET_EFAULT;
+}
+return -TARGET_E2BIG;
+}
+
+zeroed = check_zeroed_user(arg2, sizeof(struct t

Re: [PATCH v4 2/2] linux-user: call set/getscheduler set/getparam directly

2022-01-05 Thread Laurent Vivier

Le 05/01/2022 à 05:18, Tonis Tiigi a écrit :

There seems to be difference in syscall and libc definition of these
methods and therefore musl does not implement them (1e21e78bf7). Call
syscall directly to ensure the behavior of the libc of user application,
not the libc that was used to build QEMU.

Signed-off-by: Tonis Tiigi 
---
  linux-user/syscall.c  | 34 --
  linux-user/syscall_defs.h |  4 
  2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 1b8415c8a3..30962155a6 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -359,6 +359,17 @@ _syscall4(int, sys_sched_getattr, pid_t, pid, struct 
sched_attr *, attr,
  #define __NR_sys_sched_setattr __NR_sched_setattr
  _syscall3(int, sys_sched_setattr, pid_t, pid, struct sched_attr *, attr,
unsigned int, flags);
+#define __NR_sys_sched_getscheduler __NR_sched_getscheduler
+_syscall1(int, sys_sched_getscheduler, pid_t, pid);
+#define __NR_sys_sched_setscheduler __NR_sched_setscheduler
+_syscall3(int, sys_sched_setscheduler, pid_t, pid, int, policy,
+  const struct sched_param *, param);
+#define __NR_sys_sched_getparam __NR_sched_getparam
+_syscall2(int, sys_sched_getparam, pid_t, pid,
+  struct sched_param *, param);
+#define __NR_sys_sched_setparam __NR_sched_setparam
+_syscall2(int, sys_sched_setparam, pid_t, pid,
+  const struct sched_param *, param);
  #define __NR_sys_getcpu __NR_getcpu
  _syscall3(int, sys_getcpu, unsigned *, cpu, unsigned *, node, void *, tcache);
  _syscall4(int, reboot, int, magic1, int, magic2, unsigned int, cmd,
@@ -10587,30 +10598,32 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  return ret;
  case TARGET_NR_sched_setparam:
  {
-struct sched_param *target_schp;
+struct target_sched_param *target_schp;
  struct sched_param schp;
  
  if (arg2 == 0) {

  return -TARGET_EINVAL;
  }
-if (!lock_user_struct(VERIFY_READ, target_schp, arg2, 1))
+if (!lock_user_struct(VERIFY_READ, target_schp, arg2, 1)) {
  return -TARGET_EFAULT;
+}
  schp.sched_priority = tswap32(target_schp->sched_priority);
  unlock_user_struct(target_schp, arg2, 0);
-return get_errno(sched_setparam(arg1, &schp));
+return get_errno(sys_sched_setparam(arg1, &schp));
  }
  case TARGET_NR_sched_getparam:
  {
-struct sched_param *target_schp;
+struct target_sched_param *target_schp;
  struct sched_param schp;
  
  if (arg2 == 0) {

  return -TARGET_EINVAL;
  }
-ret = get_errno(sched_getparam(arg1, &schp));
+ret = get_errno(sys_sched_getparam(arg1, &schp));
  if (!is_error(ret)) {
-if (!lock_user_struct(VERIFY_WRITE, target_schp, arg2, 0))
+if (!lock_user_struct(VERIFY_WRITE, target_schp, arg2, 0)) {
  return -TARGET_EFAULT;
+}
  target_schp->sched_priority = tswap32(schp.sched_priority);
  unlock_user_struct(target_schp, arg2, 1);
  }
@@ -10618,19 +10631,20 @@ static abi_long do_syscall1(void *cpu_env, int num, 
abi_long arg1,
  return ret;
  case TARGET_NR_sched_setscheduler:
  {
-struct sched_param *target_schp;
+struct target_sched_param *target_schp;
  struct sched_param schp;
  if (arg3 == 0) {
  return -TARGET_EINVAL;
  }
-if (!lock_user_struct(VERIFY_READ, target_schp, arg3, 1))
+if (!lock_user_struct(VERIFY_READ, target_schp, arg3, 1)) {
  return -TARGET_EFAULT;
+}
  schp.sched_priority = tswap32(target_schp->sched_priority);
  unlock_user_struct(target_schp, arg3, 0);
-return get_errno(sched_setscheduler(arg1, arg2, &schp));
+return get_errno(sys_sched_setscheduler(arg1, arg2, &schp));
  }
  case TARGET_NR_sched_getscheduler:
-return get_errno(sched_getscheduler(arg1));
+return get_errno(sys_sched_getscheduler(arg1));
  case TARGET_NR_sched_getattr:
  {
  struct target_sched_attr *target_scha;
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 310d6ce8ad..28b9fe9a47 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2928,4 +2928,8 @@ struct target_sched_attr {
  abi_uint sched_util_max;
  };
  
+struct target_sched_param {

+abi_int sched_priority;
+};
+
  #endif


Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent




Re: [PATCH] gitlab-ci: Enable docs in the centos job

2022-01-05 Thread Thomas Huth

On 05/01/2022 10.44, Alex Bennée wrote:


Thomas Huth  writes:


We just ran into a problem that the docs don't build on RHEL8 / CentOS 8
anymore. Seems like these distros are using one of the oldest Sphinx
versions that we still have to support. Thus enable the docs build in
the CI on CentOS so that such bugs don't slip in so easily again.

Signed-off-by: Thomas Huth 


Queued to testing/next, thanks.


Note that you need Marc-André's fix first, too. But I'm also planning a pull 
request with a bunch of misc other patches soon, so I can also stick these 
two patches in there, too.


 Thomas




Re: [RFC 05/10] vdpa-dev: implement the realize interface

2022-01-05 Thread Stefan Hajnoczi
On Wed, Jan 05, 2022 at 08:58:55AM +0800, Longpeng(Mike) wrote:
> From: Longpeng 
> 
> Implements the .realize interface.
> 
> Signed-off-by: Longpeng 
> ---
>  hw/virtio/vdpa-dev.c | 114 +++
>  include/hw/virtio/vdpa-dev.h |   8 +++
>  2 files changed, 122 insertions(+)
> 
> diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
> index 790117fb3b..2d534d837a 100644
> --- a/hw/virtio/vdpa-dev.c
> +++ b/hw/virtio/vdpa-dev.c
> @@ -15,9 +15,122 @@
>  #include "sysemu/sysemu.h"
>  #include "sysemu/runstate.h"
>  
> +static void
> +vhost_vdpa_device_dummy_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> +{
> +/* Nothing to do */
> +}
> +
> +static int vdpa_dev_get_info_by_fd(int fd, uint64_t cmd, Error **errp)

This looks similar to the helper function in a previous patch but this
time the return value type is int instead of uint32_t. Please make the
types consistent.

> +{
> +int val;
> +
> +if (ioctl(fd, cmd, &val) < 0) {
> +error_setg(errp, "vhost-vdpa-device: cmd 0x%lx failed: %s",
> +   cmd, strerror(errno));
> +return -1;
> +}
> +
> +return val;
> +}
> +
> +static inline int vdpa_dev_get_queue_size(int fd, Error **errp)
> +{
> +return vdpa_dev_get_info_by_fd(fd, VHOST_VDPA_GET_VRING_NUM, errp);
> +}
> +
> +static inline int vdpa_dev_get_vqs_num(int fd, Error **errp)
> +{
> +return vdpa_dev_get_info_by_fd(fd, VHOST_VDPA_GET_VQS_NUM, errp);
> +}
> +
> +static inline int vdpa_dev_get_config_size(int fd, Error **errp)
> +{
> +return vdpa_dev_get_info_by_fd(fd, VHOST_VDPA_GET_CONFIG_SIZE, errp);
> +}
> +
>  static void vhost_vdpa_device_realize(DeviceState *dev, Error **errp)
>  {
> +VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> +VhostVdpaDevice *s = VHOST_VDPA_DEVICE(vdev);
> +uint32_t device_id;
> +int max_queue_size;
> +int fd;
> +int i, ret;
> +
> +fd = qemu_open(s->vdpa_dev, O_RDWR, errp);
> +if (fd == -1) {
> +return;
> +}
> +s->vdpa.device_fd = fd;

This is the field I suggest exposing as a QOM property so it can be set
from the proxy object (e.g. when the PCI proxy opens the vdpa device
before our .realize() function is called).

> +
> +max_queue_size = vdpa_dev_get_queue_size(fd, errp);
> +if (*errp) {
> +goto out;
> +}
> +
> +if (s->queue_size > max_queue_size) {
> +error_setg(errp, "vhost-vdpa-device: invalid queue_size: %d 
> (max:%d)",
> +   s->queue_size, max_queue_size);
> +goto out;
> +} else if (!s->queue_size) {
> +s->queue_size = max_queue_size;
> +}
> +
> +ret = vdpa_dev_get_vqs_num(fd, errp);
> +if (*errp) {
> +goto out;
> +}
> +
> +s->dev.nvqs = ret;

There is no input validation because we trust the kernel vDPA return
values. That seems okay for now but if there is a vhost-user version of
this in the future then input validation will be necessary to achieve
isolation between QEMU and the vhost-user processes. I suggest including
input validation code right away because it's harder to audit the code
and fix missing input validation later on.

> +s->dev.vqs = g_new0(struct vhost_virtqueue, s->dev.nvqs);
> +s->dev.vq_index = 0;
> +s->dev.vq_index_end = s->dev.nvqs;
> +s->dev.backend_features = 0;
> +s->started = false;
> +
> +ret = vhost_dev_init(&s->dev, &s->vdpa, VHOST_BACKEND_TYPE_VDPA, 0, 
> NULL);
> +if (ret < 0) {
> +error_setg(errp, "vhost-vdpa-device: vhost initialization failed: 
> %s",
> +   strerror(-ret));
> +goto out;
> +}
> +
> +ret = s->dev.vhost_ops->vhost_get_device_id(&s->dev, &device_id);

The vhost_*() API abstracts the ioctl calls but this source file and the
PCI proxy have ioctl calls. I wonder if it's possible to move the ioctls
calls into the vhost_*() API? That would be cleaner and also make it
easier to add vhost-user vDPA support in the future.


signature.asc
Description: PGP signature


Re: [RFC 00/10] add generic vDPA device support

2022-01-05 Thread Stefan Hajnoczi
On Wed, Jan 05, 2022 at 08:58:50AM +0800, Longpeng(Mike) wrote:
> From: Longpeng 
> 
> Hi guys,
> 
> This patchset tries to support the generic vDPA device, the previous
> disscussion can be found here [1].
> 
> With the generic vDPA device, QEMU won't need to touch the device
> types any more, such like vfio.
> 
> We can use the generic vDPA device as follow:
>   -device vhost-vdpa-device-pci,vdpa-dev=/dev/vhost-vdpa-X
> 
> I've done some simple tests on Huawei's offloading card (net, 0.95)
> and vdpa_sim_blk (1.0);
> 
> Note:
>   the kernel part does not send out yet, I'll send it as soon as possible.
> 
> [1] https://lore.kernel.org/all/20211208052010.1719-1-longpe...@huawei.com/
> 
> Longpeng (Mike) (10):
>   virtio: get class_id and pci device id by the virtio id
>   vhost: add 3 commands for vhost-vdpa
>   vdpa: add the infrastructure of vdpa-dev
>   vdpa-dev: implement the instance_init/class_init interface
>   vdpa-dev: implement the realize interface
>   vdpa-dev: implement the unrealize interface
>   vdpa-dev: implement the get_config/set_config interface
>   vdpa-dev: implement the get_features interface
>   vdpa-dev: implement the set_status interface
>   vdpa-dev: mark the device as unmigratable

Nice and small.

Stefan


signature.asc
Description: PGP signature


Re: [PATCH] linux-user/syscall.c: fix missed flag for shared memory in open_self_maps

2022-01-05 Thread Laurent Vivier

Le 27/12/2021 à 13:50, Andrey Kazmin a écrit :

The possible variants for region type in /proc/self/maps are either
private "p" or shared "s". In the current implementation,
we mark shared regions as "-". It could break memory mapping parsers
such as included into ASan/HWASan sanitizers.

Signed-off-by: Andrey Kazmin 
---
  linux-user/syscall.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 56a3e17183..2199a98725 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -7790,7 +7790,7 @@ static int open_self_maps(void *cpu_env, int fd)
  (flags & PAGE_READ) ? 'r' : '-',
  (flags & PAGE_WRITE_ORG) ? 'w' : '-',
  (flags & PAGE_EXEC) ? 'x' : '-',
-e->is_priv ? 'p' : '-',
+e->is_priv ? 'p' : 's',
  (uint64_t) e->offset, e->dev, e->inode);
  if (path) {
  dprintf(fd, "%*s%s\n", 73 - count, "", path);



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



Re: [PATCH] linux-user/signal: Map exit signals in SIGCHLD siginfo_t

2022-01-05 Thread Laurent Vivier

Le 23/10/2021 à 21:59, Matthias Schiffer a écrit :

When converting a siginfo_t from waitid(), the interpretation of si_status
depends on the value of si_code: For CLD_EXITED, it is an exit code and
should be copied verbatim. For other codes, it is a signal number
(possibly with additional high bits from ptrace) that should be mapped.

This code was previously changed in commit 1c3dfb506ea3
("linux-user/signal: Decode waitid si_code"), but the fix was
incomplete.

Tested with the following test program:

 #include 
 #include 
 #include 
 #include 

 int main() {
pid_t pid = fork();
if (pid == 0) {
exit(12);
} else {
siginfo_t siginfo = {};
waitid(P_PID, pid, &siginfo, WEXITED);
printf("Code: %d, status: %d\n", (int)siginfo.si_code, 
(int)siginfo.si_status);
}

pid = fork();
if (pid == 0) {
raise(SIGUSR2);
} else {
siginfo_t siginfo = {};
waitid(P_PID, pid, &siginfo, WEXITED);
printf("Code: %d, status: %d\n", (int)siginfo.si_code, 
(int)siginfo.si_status);
}
 }

Output with an x86_64 host and mips64el target before 1c3dfb506ea3
(incorrect: exit code 12 is translated like a signal):

 Code: 1, status: 17
 Code: 2, status: 17

After 1c3dfb506ea3 (incorrect: signal number is not translated):

 Code: 1, status: 12
 Code: 2, status: 12

With this patch:

 Code: 1, status: 12
 Code: 2, status: 17

Signed-off-by: Matthias Schiffer 
---
  linux-user/signal.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 14d8fdfde152..8e3af98ec0a7 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -403,7 +403,12 @@ static inline void 
host_to_target_siginfo_noswap(target_siginfo_t *tinfo,
  case TARGET_SIGCHLD:
  tinfo->_sifields._sigchld._pid = info->si_pid;
  tinfo->_sifields._sigchld._uid = info->si_uid;
-tinfo->_sifields._sigchld._status = info->si_status;
+if (si_code == CLD_EXITED)
+tinfo->_sifields._sigchld._status = info->si_status;
+else
+tinfo->_sifields._sigchld._status
+= host_to_target_signal(info->si_status & 0x7f)
+| (info->si_status & ~0x7f);
  tinfo->_sifields._sigchld._utime = info->si_utime;
  tinfo->_sifields._sigchld._stime = info->si_stime;
  si_type = QEMU_SI_CHLD;


Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent




Re: [PATCH 2/3] linux-user: netlink: Add IFLA_VFINFO_LIST

2022-01-05 Thread Laurent Vivier

Le 19/12/2021 à 16:45, Laurent Vivier a écrit :

   # QEMU_LOG=unimp ip a
   Unknown host QEMU_IFLA type: 22

Signed-off-by: Laurent Vivier 
---
  linux-user/fd-trans.c | 174 ++
  1 file changed, 174 insertions(+)

diff --git a/linux-user/fd-trans.c b/linux-user/fd-trans.c
index 14c19a90b2b0..36e4a4c2aae8 100644
--- a/linux-user/fd-trans.c
+++ b/linux-user/fd-trans.c
@@ -271,6 +271,37 @@ enum {
  QEMU___RTA_MAX
  };
  
+enum {

+QEMU_IFLA_VF_STATS_RX_PACKETS,
+QEMU_IFLA_VF_STATS_TX_PACKETS,
+QEMU_IFLA_VF_STATS_RX_BYTES,
+QEMU_IFLA_VF_STATS_TX_BYTES,
+QEMU_IFLA_VF_STATS_BROADCAST,
+QEMU_IFLA_VF_STATS_MULTICAST,
+QEMU_IFLA_VF_STATS_PAD,
+QEMU_IFLA_VF_STATS_RX_DROPPED,
+QEMU_IFLA_VF_STATS_TX_DROPPED,
+QEMU__IFLA_VF_STATS_MAX,
+};
+
+enum {
+QEMU_IFLA_VF_UNSPEC,
+QEMU_IFLA_VF_MAC,
+QEMU_IFLA_VF_VLAN,
+QEMU_IFLA_VF_TX_RATE,
+QEMU_IFLA_VF_SPOOFCHK,
+QEMU_IFLA_VF_LINK_STATE,
+QEMU_IFLA_VF_RATE,
+QEMU_IFLA_VF_RSS_QUERY_EN,
+QEMU_IFLA_VF_STATS,
+QEMU_IFLA_VF_TRUST,
+QEMU_IFLA_VF_IB_NODE_GUID,
+QEMU_IFLA_VF_IB_PORT_GUID,
+QEMU_IFLA_VF_VLAN_LIST,
+QEMU_IFLA_VF_BROADCAST,
+QEMU__IFLA_VF_MAX,
+};
+
  TargetFdTrans **target_fd_trans;
  QemuMutex target_fd_trans_lock;
  unsigned int target_fd_max;
@@ -808,6 +839,145 @@ static abi_long host_to_target_data_xdp_nlattr(struct 
nlattr *nlattr,
  return 0;
  }
  
+static abi_long host_to_target_data_vlan_list_nlattr(struct nlattr *nlattr,

+ void *context)
+{
+struct ifla_vf_vlan_info *vlan_info;
+
+switch (nlattr->nla_type) {
+/* struct ifla_vf_vlan_info */
+case IFLA_VF_VLAN_INFO:
+vlan_info = NLA_DATA(nlattr);
+vlan_info->vf = tswap32(vlan_info->vf);
+vlan_info->vlan = tswap32(vlan_info->vlan);
+vlan_info->qos = tswap32(vlan_info->qos);
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "Unknown host VLAN LIST type: %d\n",
+  nlattr->nla_type);
+break;
+}
+return 0;
+}
+
+static abi_long host_to_target_data_vf_stats_nlattr(struct nlattr *nlattr,
+void *context)
+{
+uint64_t *u64;
+
+switch (nlattr->nla_type) {
+/* uint64_t */
+case QEMU_IFLA_VF_STATS_RX_PACKETS:
+case QEMU_IFLA_VF_STATS_TX_PACKETS:
+case QEMU_IFLA_VF_STATS_RX_BYTES:
+case QEMU_IFLA_VF_STATS_TX_BYTES:
+case QEMU_IFLA_VF_STATS_BROADCAST:
+case QEMU_IFLA_VF_STATS_MULTICAST:
+case QEMU_IFLA_VF_STATS_PAD:
+case QEMU_IFLA_VF_STATS_RX_DROPPED:
+case QEMU_IFLA_VF_STATS_TX_DROPPED:
+u64 = NLA_DATA(nlattr);
+*u64 = tswap64(*u64);
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "Unknown host VF STATS type: %d\n",
+  nlattr->nla_type);
+break;
+}
+return 0;
+}
+
+static abi_long host_to_target_data_vfinfo_nlattr(struct nlattr *nlattr,
+  void *context)
+{
+struct ifla_vf_mac *mac;
+struct ifla_vf_vlan *vlan;
+struct ifla_vf_vlan_info *vlan_info;
+struct ifla_vf_spoofchk *spoofchk;
+struct ifla_vf_rate *rate;
+struct ifla_vf_link_state *link_state;
+struct ifla_vf_rss_query_en *rss_query_en;
+struct ifla_vf_trust *trust;
+struct ifla_vf_guid *guid;
+
+switch (nlattr->nla_type) {
+/* struct ifla_vf_mac */
+case QEMU_IFLA_VF_MAC:
+mac = NLA_DATA(nlattr);
+mac->vf = tswap32(mac->vf);
+break;
+/* struct ifla_vf_broadcast */
+case QEMU_IFLA_VF_BROADCAST:
+break;
+/* struct struct ifla_vf_vlan */
+case QEMU_IFLA_VF_VLAN:
+vlan = NLA_DATA(nlattr);
+vlan->vf = tswap32(vlan->vf);
+vlan->vlan = tswap32(vlan->vlan);
+vlan->qos = tswap32(vlan->qos);
+break;
+/* struct ifla_vf_vlan_info */
+case QEMU_IFLA_VF_TX_RATE:
+vlan_info = NLA_DATA(nlattr);
+vlan_info->vf = tswap32(vlan_info->vf);
+vlan_info->vlan = tswap32(vlan_info->vlan);
+vlan_info->qos = tswap32(vlan_info->qos);
+break;
+/* struct ifla_vf_spoofchk */
+case QEMU_IFLA_VF_SPOOFCHK:
+spoofchk = NLA_DATA(nlattr);
+spoofchk->vf = tswap32(spoofchk->vf);
+spoofchk->setting = tswap32(spoofchk->setting);
+break;
+/* struct ifla_vf_rate */
+case QEMU_IFLA_VF_RATE:
+rate = NLA_DATA(nlattr);
+rate->vf = tswap32(rate->vf);
+rate->min_tx_rate = tswap32(rate->min_tx_rate);
+rate->max_tx_rate = tswap32(rate->max_tx_rate);
+break;
+/* struct ifla_vf_link_state */
+case QEMU_IFLA_VF_LINK_STATE:
+link_state = NLA_DATA(nlattr);
+link_state->vf = tswap32(link_state->vf);
+link_state->link_state = tswap32(link_state->link_state);
+break;
+/* struct ifla_vf_rss_query_en */
+ca

Re: [PATCH v2 1/7] linux-user/nios2: Properly emulate EXCP_TRAP

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

The real kernel has to load the instruction and extract
the imm5 field; for qemu, modify the translator to do this.

The use of R_AT for this in cpu_loop was a bug.  Handle
the other trap numbers as per the kernel's trap_table.

Reviewed-by: Alex Bennée 
Signed-off-by: Richard Henderson 
---
  target/nios2/cpu.h  |  2 +-
  linux-user/nios2/cpu_loop.c | 40 -
  target/nios2/translate.c| 17 +++-
  3 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/target/nios2/cpu.h b/target/nios2/cpu.h
index 1a69ed7a49..d2ba0c5bbd 100644
--- a/target/nios2/cpu.h
+++ b/target/nios2/cpu.h
@@ -160,9 +160,9 @@ struct CPUNios2State {
  
  #if !defined(CONFIG_USER_ONLY)

  Nios2MMU mmu;
-
  uint32_t irq_pending;
  #endif
+int error_code;
  };
  
  /**

diff --git a/linux-user/nios2/cpu_loop.c b/linux-user/nios2/cpu_loop.c
index 34290fb3b5..5c3d01d22d 100644
--- a/linux-user/nios2/cpu_loop.c
+++ b/linux-user/nios2/cpu_loop.c
@@ -26,7 +26,6 @@
  void cpu_loop(CPUNios2State *env)
  {
  CPUState *cs = env_cpu(env);
-Nios2CPU *cpu = NIOS2_CPU(cs);
  target_siginfo_t info;
  int trapnr, ret;
  
@@ -39,9 +38,10 @@ void cpu_loop(CPUNios2State *env)

  case EXCP_INTERRUPT:
  /* just indicate that signals should be handled asap */
  break;
+
  case EXCP_TRAP:
-if (env->regs[R_AT] == 0) {
-abi_long ret;
+switch (env->error_code) {
+case 0:
  qemu_log_mask(CPU_LOG_INT, "\nSyscall\n");
  
  ret = do_syscall(env, env->regs[2],

@@ -55,26 +55,30 @@ void cpu_loop(CPUNios2State *env)
  
  env->regs[2] = abs(ret);

  /* Return value is 0..4096 */
-env->regs[7] = (ret > 0xf000ULL);
-env->regs[CR_ESTATUS] = env->regs[CR_STATUS];
-env->regs[CR_STATUS] &= ~0x3;
-env->regs[R_EA] = env->regs[R_PC] + 4;
+env->regs[7] = ret > 0xf000u;
  env->regs[R_PC] += 4;
  break;
-} else {
-qemu_log_mask(CPU_LOG_INT, "\nTrap\n");
  
-env->regs[CR_ESTATUS] = env->regs[CR_STATUS];

-env->regs[CR_STATUS] &= ~0x3;
-env->regs[R_EA] = env->regs[R_PC] + 4;
-env->regs[R_PC] = cpu->exception_addr;
-
-info.si_signo = TARGET_SIGTRAP;
-info.si_errno = 0;
-info.si_code = TARGET_TRAP_BRKPT;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info);
+case 1:
+qemu_log_mask(CPU_LOG_INT, "\nTrap 1\n");
+force_sig_fault(TARGET_SIGUSR1, 0, env->regs[R_PC]);
+break;
+case 2:
+qemu_log_mask(CPU_LOG_INT, "\nTrap 2\n");
+force_sig_fault(TARGET_SIGUSR2, 0, env->regs[R_PC]);
+break;
+case 31:
+qemu_log_mask(CPU_LOG_INT, "\nTrap 31\n");
+force_sig_fault(TARGET_SIGTRAP, TARGET_TRAP_BRKPT, 
env->regs[R_PC]);
+break;
+default:
+qemu_log_mask(CPU_LOG_INT, "\nTrap %d\n", env->error_code);
+force_sig_fault(TARGET_SIGILL, TARGET_ILL_ILLTRP,
+env->regs[R_PC]);
  break;
  }
+break;
+
  case EXCP_DEBUG:
  info.si_signo = TARGET_SIGTRAP;
  info.si_errno = 0;
diff --git a/target/nios2/translate.c b/target/nios2/translate.c
index 08d7ac5398..a759877519 100644
--- a/target/nios2/translate.c
+++ b/target/nios2/translate.c
@@ -636,6 +636,21 @@ static void divu(DisasContext *dc, uint32_t code, uint32_t 
flags)
  tcg_temp_free(t0);
  }
  
+static void trap(DisasContext *dc, uint32_t code, uint32_t flags)

+{
+#ifdef CONFIG_USER_ONLY
+/*
+ * The imm5 field is not stored anywhere on real hw; the kernel
+ * has to load the insn and extract the field.  But we can make
+ * things easier for cpu_loop if we pop this into env->error_code.
+ */
+R_TYPE(instr, code);
+tcg_gen_st_i32(tcg_constant_i32(instr.imm5), cpu_env,
+   offsetof(CPUNios2State, error_code));
+#endif
+t_gen_helper_raise_exception(dc, EXCP_TRAP);
+}
+
  static const Nios2Instruction r_type_instructions[] = {
  INSTRUCTION_ILLEGAL(),
  INSTRUCTION(eret),/* eret */
@@ -682,7 +697,7 @@ static const Nios2Instruction r_type_instructions[] = {
  INSTRUCTION_ILLEGAL(),
  INSTRUCTION_ILLEGAL(),
  INSTRUCTION_ILLEGAL(),
-INSTRUCTION_FLG(gen_excp, EXCP_TRAP), /* trap */
+INSTRUCTION(trap),/* trap */
  INSTRUCTION(wrctl),   /* wrctl */
  INSTRUCTION_ILLEGAL(),
  INSTRU

Re: [PATCH v2 2/7] linux-user/nios2: Fixes for signal frame setup

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

Do not confuse host and guest addresses.  Lock and unlock
the target_rt_sigframe structure in setup_rt_sigframe.

Since rt_setup_ucontext always returns 0, drop the return
value entirely.  This eliminates the only write to the err
variable in setup_rt_sigframe.

Always copy the siginfo structure.

Reviewed-by: Alex Bennée 
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
  linux-user/nios2/signal.c | 49 ---
  1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/linux-user/nios2/signal.c b/linux-user/nios2/signal.c
index a77e8a40f4..adbffe32e3 100644
--- a/linux-user/nios2/signal.c
+++ b/linux-user/nios2/signal.c
@@ -42,7 +42,7 @@ struct target_rt_sigframe {
  struct target_ucontext uc;
  };
  
-static int rt_setup_ucontext(struct target_ucontext *uc, CPUNios2State *env)

+static void rt_setup_ucontext(struct target_ucontext *uc, CPUNios2State *env)
  {
  unsigned long *gregs = uc->tuc_mcontext.gregs;
  
@@ -75,8 +75,6 @@ static int rt_setup_ucontext(struct target_ucontext *uc, CPUNios2State *env)

  __put_user(env->regs[R_GP], &gregs[25]);
  __put_user(env->regs[R_EA], &gregs[27]);
  __put_user(env->regs[R_SP], &gregs[28]);
-
-return 0;
  }
  
  static int rt_restore_ucontext(CPUNios2State *env, struct target_ucontext *uc,

@@ -135,8 +133,8 @@ static int rt_restore_ucontext(CPUNios2State *env, struct 
target_ucontext *uc,
  return 0;
  }
  
-static void *get_sigframe(struct target_sigaction *ka, CPUNios2State *env,

-  size_t frame_size)
+static abi_ptr get_sigframe(struct target_sigaction *ka, CPUNios2State *env,
+size_t frame_size)
  {
  unsigned long usp;
  
@@ -144,7 +142,7 @@ static void *get_sigframe(struct target_sigaction *ka, CPUNios2State *env,

  usp = target_sigsp(get_sp_from_cpustate(env), ka);
  
  /* Verify, is it 32 or 64 bit aligned */

-return (void *)((usp - frame_size) & -8UL);
+return (usp - frame_size) & -8;
  }
  
  void setup_rt_frame(int sig, struct target_sigaction *ka,

@@ -153,26 +151,25 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
  CPUNios2State *env)
  {
  struct target_rt_sigframe *frame;
-int i, err = 0;
+abi_ptr frame_addr;
+int i;
  
-frame = get_sigframe(ka, env, sizeof(*frame));

-
-if (ka->sa_flags & SA_SIGINFO) {
-tswap_siginfo(&frame->info, info);
+frame_addr = get_sigframe(ka, env, sizeof(*frame));
+if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
+force_sigsegv(sig);
+return;
  }
  
+tswap_siginfo(&frame->info, info);

+
  /* Create the ucontext.  */
  __put_user(0, &frame->uc.tuc_flags);
  __put_user(0, &frame->uc.tuc_link);
  target_save_altstack(&frame->uc.tuc_stack, env);
-err |= rt_setup_ucontext(&frame->uc, env);
+rt_setup_ucontext(&frame->uc, env);
  for (i = 0; i < TARGET_NSIG_WORDS; i++) {
  __put_user((abi_ulong)set->sig[i],
-(abi_ulong *)&frame->uc.tuc_sigmask.sig[i]);
-}
-
-if (err) {
-goto give_sigsegv;
+   (abi_ulong *)&frame->uc.tuc_sigmask.sig[i]);
  }
  
  /* Set up to return from userspace; jump to fixed address sigreturn

@@ -180,19 +177,13 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
  env->regs[R_RA] = (unsigned long) (0x1044);
  
  /* Set up registers for signal handler */

-env->regs[R_SP] = (unsigned long) frame;
-env->regs[4] = (unsigned long) sig;
-env->regs[5] = (unsigned long) &frame->info;
-env->regs[6] = (unsigned long) &frame->uc;
-env->regs[R_EA] = (unsigned long) ka->_sa_handler;
-return;
+env->regs[R_SP] = frame_addr;
+env->regs[4] = sig;
+env->regs[5] = frame_addr + offsetof(struct target_rt_sigframe, info);
+env->regs[6] = frame_addr + offsetof(struct target_rt_sigframe, uc);
+env->regs[R_EA] = ka->_sa_handler;
  
-give_sigsegv:

-if (sig == TARGET_SIGSEGV) {
-ka->_sa_handler = TARGET_SIG_DFL;
-}
-force_sigsegv(sig);
-return;
+unlock_user_struct(frame, frame_addr, 1);
  }
  
  long do_sigreturn(CPUNios2State *env)



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



Re: [PATCH v2 6/7] linux-user/nios2: Fix sigmask in setup_rt_frame

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

Do not cast the signal mask elements; trust __put_user.

Reviewed-by: Laurent Vivier 
Signed-off-by: Richard Henderson 
---
  linux-user/nios2/signal.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/linux-user/nios2/signal.c b/linux-user/nios2/signal.c
index 20b65aa06e..80e3d42fc9 100644
--- a/linux-user/nios2/signal.c
+++ b/linux-user/nios2/signal.c
@@ -168,8 +168,7 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
  target_save_altstack(&frame->uc.tuc_stack, env);
  rt_setup_ucontext(&frame->uc, env);
  for (i = 0; i < TARGET_NSIG_WORDS; i++) {
-__put_user((abi_ulong)set->sig[i],
-   (abi_ulong *)&frame->uc.tuc_sigmask.sig[i]);
+__put_user(set->sig[i], &frame->uc.tuc_sigmask.sig[i]);
  }
  
  /* Set up to return from userspace; jump to fixed address sigreturn



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



[PATCH] docs/system/ppc: Merge the PEF information into the pseries page

2022-01-05 Thread Thomas Huth
The Protected Execution Facility is only available with the pseries
machine, so let's merge the old ASCII text into the new RST file now.

Signed-off-by: Thomas Huth 
---
 docs/papr-pef.txt   | 30 --
 docs/system/ppc/pseries.rst | 33 +
 2 files changed, 33 insertions(+), 30 deletions(-)
 delete mode 100644 docs/papr-pef.txt

diff --git a/docs/papr-pef.txt b/docs/papr-pef.txt
deleted file mode 100644
index 72550e9bf8..00
--- a/docs/papr-pef.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-POWER (PAPR) Protected Execution Facility (PEF)
-===
-
-Protected Execution Facility (PEF), also known as Secure Guest support
-is a feature found on IBM POWER9 and POWER10 processors.
-
-If a suitable firmware including an Ultravisor is installed, it adds
-an extra memory protection mode to the CPU.  The ultravisor manages a
-pool of secure memory which cannot be accessed by the hypervisor.
-
-When this feature is enabled in QEMU, a guest can use ultracalls to
-enter "secure mode".  This transfers most of its memory to secure
-memory, where it cannot be eavesdropped by a compromised hypervisor.
-
-Launching
--
-
-To launch a guest which will be permitted to enter PEF secure mode:
-
-# ${QEMU} \
--object pef-guest,id=pef0 \
--machine confidential-guest-support=pef0 \
-...
-
-Live Migration
-
-
-Live migration is not yet implemented for PEF guests.  For
-consistency, we currently prevent migration if the PEF feature is
-enabled, whether or not the guest has actually entered secure mode.
diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst
index 72e315eff6..16394fa521 100644
--- a/docs/system/ppc/pseries.rst
+++ b/docs/system/ppc/pseries.rst
@@ -230,6 +230,39 @@ nested. Combinations not shown in the table are not 
available.
 
 .. [3] Introduced on Power10 machines.
 
+
+POWER (PAPR) Protected Execution Facility (PEF)
+---
+
+Protected Execution Facility (PEF), also known as Secure Guest support
+is a feature found on IBM POWER9 and POWER10 processors.
+
+If a suitable firmware including an Ultravisor is installed, it adds
+an extra memory protection mode to the CPU.  The ultravisor manages a
+pool of secure memory which cannot be accessed by the hypervisor.
+
+When this feature is enabled in QEMU, a guest can use ultracalls to
+enter "secure mode".  This transfers most of its memory to secure
+memory, where it cannot be eavesdropped by a compromised hypervisor.
+
+Launching
+^
+
+To launch a guest which will be permitted to enter PEF secure mode::
+
+  $ qemu-system-ppc64 \
+  -object pef-guest,id=pef0 \
+  -machine confidential-guest-support=pef0 \
+  ...
+
+Live Migration
+^^
+
+Live migration is not yet implemented for PEF guests.  For
+consistency, QEMU currently prevents migration if the PEF feature is
+enabled, whether or not the guest has actually entered secure mode.
+
+
 Maintainer contact information
 --
 
-- 
2.27.0




Re: [PATCH v2 3/7] linux-user/elfload: Rename ARM_COMMPAGE to HI_COMMPAGE

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

Arm will no longer be the only target requiring a commpage,
but it will continue to be the only target placing the page
at the high end of the address space.

Reviewed-by: Laurent Vivier 
Signed-off-by: Richard Henderson 
---
  linux-user/elfload.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 767f54c76d..d34cd4fe43 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -390,11 +390,11 @@ enum {
  
  /* The commpage only exists for 32 bit kernels */
  
-#define ARM_COMMPAGE (intptr_t)0x0f00u

+#define HI_COMMPAGE (intptr_t)0x0f00u
  
  static bool init_guest_commpage(void)

  {
-void *want = g2h_untagged(ARM_COMMPAGE & -qemu_host_page_size);
+void *want = g2h_untagged(HI_COMMPAGE & -qemu_host_page_size);
  void *addr = mmap(want, qemu_host_page_size, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0);
  
@@ -2160,8 +2160,8 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,

  return sp;
  }
  
-#ifndef ARM_COMMPAGE

-#define ARM_COMMPAGE 0
+#ifndef HI_COMMPAGE
+#define HI_COMMPAGE 0
  #define init_guest_commpage() true
  #endif
  
@@ -2361,7 +2361,7 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr,

  }
  
  loaddr &= -align;

-if (ARM_COMMPAGE) {
+if (HI_COMMPAGE) {
  /*
   * Extend the allocation to include the commpage.
   * For a 64-bit host, this is just 4GiB; for a 32-bit host we
@@ -2372,14 +2372,14 @@ static void pgb_static(const char *image_name, 
abi_ulong orig_loaddr,
  if (sizeof(uintptr_t) == 8 || loaddr >= 0x8000u) {
  hiaddr = (uintptr_t) 4 << 30;
  } else {
-offset = -(ARM_COMMPAGE & -align);
+offset = -(HI_COMMPAGE & -align);
  }
  }
  
  addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset);

  if (addr == -1) {
  /*
- * If ARM_COMMPAGE, there *might* be a non-consecutive allocation
+ * If HI_COMMPAGE, there *might* be a non-consecutive allocation
   * that can satisfy both.  But as the normal arm32 link base address
   * is ~32k, and we extend down to include the commpage, making the
   * overhead only ~96k, this is unlikely.
@@ -2400,7 +2400,7 @@ static void pgb_dynamic(const char *image_name, long 
align)
   * All we need is a commpage that satisfies align.
   * If we do not need a commpage, leave guest_base == 0.
   */
-if (ARM_COMMPAGE) {
+if (HI_COMMPAGE) {
  uintptr_t addr, commpage;
  
  /* 64-bit hosts should have used reserved_va. */

@@ -2410,7 +2410,7 @@ static void pgb_dynamic(const char *image_name, long 
align)
   * By putting the commpage at the first hole, that puts guest_base
   * just above that, and maximises the positive guest addresses.
   */
-commpage = ARM_COMMPAGE & -align;
+commpage = HI_COMMPAGE & -align;
  addr = pgb_find_hole(commpage, -commpage, align, 0);
  assert(addr != -1);
  guest_base = addr;


Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent




Re: [PATCH] linux-user/syscall.c: malloc to g_try_malloc

2022-01-05 Thread Laurent Vivier

Le 04/01/2022 à 15:38, Ahmed Abouzied a écrit :

Use g_try_malloc instead of malloc to alocate the target ifconfig.
Also replace the corresponding free with g_free.

Signed-off-by: Ahmed Abouzied 
---

Hello,

I noticed that there was a `malloc` call in this file. It seems that it
was added by the commit 22e4a267 (3 years ago) which was after the commit
0e173b24 (6 years ago) that replaced malloc calls with glib alternative calls.

There is no issue for this on Gitlab. Should I have created an issue
first?

Best regards,

  linux-user/syscall.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 56a3e17183..715f9430e1 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4867,7 +4867,7 @@ static abi_long do_ioctl_ifconf(const IOCTLEntry *ie, 
uint8_t *buf_temp,
   * We can't fit all the extents into the fixed size buffer.
   * Allocate one that is large enough and use it instead.
   */
-host_ifconf = malloc(outbufsz);
+host_ifconf = g_try_malloc(outbufsz);
  if (!host_ifconf) {
  return -TARGET_ENOMEM;
  }
@@ -4915,7 +4915,7 @@ static abi_long do_ioctl_ifconf(const IOCTLEntry *ie, 
uint8_t *buf_temp,
  }
  
  if (free_buf) {

-free(host_ifconf);
+g_free(host_ifconf);
  }
  
  return ret;


Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



Re: [PATCH v2 7/7] linux-user/nios2: Use set_sigmask in do_rt_sigreturn

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

Using do_sigprocmask directly was incorrect, as it will
leave the signal blocked by the outer layers of linux-user.

Reviewed-by: Laurent Vivier 
Signed-off-by: Richard Henderson 
---
  linux-user/nios2/signal.c | 2 +-
  linux-user/signal.c   | 2 --
  2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/linux-user/nios2/signal.c b/linux-user/nios2/signal.c
index 80e3d42fc9..517cd39270 100644
--- a/linux-user/nios2/signal.c
+++ b/linux-user/nios2/signal.c
@@ -205,7 +205,7 @@ long do_rt_sigreturn(CPUNios2State *env)
  }
  
  target_to_host_sigset(&set, &frame->uc.tuc_sigmask);

-do_sigprocmask(SIG_SETMASK, &set, NULL);
+set_sigmask(&set);
  
  if (rt_restore_ucontext(env, &frame->uc, &rval)) {

  goto badframe;
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 6d5e5b698c..8cb33a351c 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -258,7 +258,6 @@ int do_sigprocmask(int how, const sigset_t *set, sigset_t 
*oldset)
  return 0;
  }
  
-#if !defined(TARGET_NIOS2)

  /* Just set the guest's signal mask to the specified value; the
   * caller is assumed to have called block_signals() already.
   */
@@ -268,7 +267,6 @@ void set_sigmask(const sigset_t *set)
  
  ts->signal_mask = *set;

  }
-#endif
  
  /* sigaltstack management */
  



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



Re: [PATCH v2 4/7] linux-user/nios2: Map a real kuser page

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

The first word of page1 is data, so the whole thing
can't be implemented with emulation of addresses.
Use init_guest_commpage for the allocation.

Hijack trap number 16 to implement cmpxchg.

Signed-off-by: Richard Henderson 
---
  linux-user/elfload.c| 50 -
  linux-user/nios2/cpu_loop.c | 50 -
  target/nios2/translate.c|  9 ---
  3 files changed, 76 insertions(+), 33 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index d34cd4fe43..329b2375ef 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1099,6 +1099,47 @@ static void init_thread(struct target_pt_regs *regs, 
struct image_info *infop)
  regs->estatus = 0x3;
  }
  
+#define LO_COMMPAGE  TARGET_PAGE_SIZE

+
+static bool init_guest_commpage(void)
+{
+static const uint8_t kuser_page[4 + 2 * 64] = {
+/* __kuser_helper_version */
+[0x00] = 0x02, 0x00, 0x00, 0x00,
+
+/* __kuser_cmpxchg */
+[0x04] = 0x3a, 0x6c, 0x3b, 0x00,  /* trap 16 */
+ 0x3a, 0x28, 0x00, 0xf8,  /* ret */
+
+/* __kuser_sigtramp */
+[0x44] = 0xc4, 0x22, 0x80, 0x00,  /* movi r2, __NR_rt_sigreturn */
+ 0x3a, 0x68, 0x3b, 0x00,  /* trap 0 */
+};
+
+void *want = g2h_untagged(LO_COMMPAGE & -qemu_host_page_size);
+void *addr = mmap(want, qemu_host_page_size, PROT_READ | PROT_WRITE,
+  MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0);
+
+if (addr == MAP_FAILED) {
+perror("Allocating guest commpage");
+exit(EXIT_FAILURE);
+}
+if (addr != want) {
+return false;
+}
+
+memcpy(addr, kuser_page, sizeof(kuser_page));
+
+if (mprotect(addr, qemu_host_page_size, PROT_READ)) {
+perror("Protecting guest commpage");
+exit(EXIT_FAILURE);
+}
+
+page_set_flags(LO_COMMPAGE, LO_COMMPAGE + TARGET_PAGE_SIZE,
+   PAGE_READ | PAGE_EXEC | PAGE_VALID);
+return true;
+}
+
  #define ELF_EXEC_PAGESIZE4096
  
  #define USE_ELF_CORE_DUMP

@@ -2160,8 +2201,13 @@ static abi_ulong create_elf_tables(abi_ulong p, int 
argc, int envc,
  return sp;
  }
  
-#ifndef HI_COMMPAGE

+#if defined(HI_COMMPAGE)
+#define LO_COMMPAGE 0
+#elif defined(LO_COMMPAGE)
  #define HI_COMMPAGE 0
+#else
+#define HI_COMMPAGE 0
+#define LO_COMMPAGE 0
  #define init_guest_commpage() true
  #endif
  
@@ -2374,6 +2420,8 @@ static void pgb_static(const char *image_name, abi_ulong orig_loaddr,

  } else {
  offset = -(HI_COMMPAGE & -align);
  }
+} else if (LO_COMMPAGE) {
+loaddr = MIN(loaddr, LO_COMMPAGE & -align);
  }
  
  addr = pgb_find_hole(loaddr, hiaddr - loaddr, align, offset);

diff --git a/linux-user/nios2/cpu_loop.c b/linux-user/nios2/cpu_loop.c
index 5c3d01d22d..de0fc63e21 100644
--- a/linux-user/nios2/cpu_loop.c
+++ b/linux-user/nios2/cpu_loop.c
@@ -76,6 +76,32 @@ void cpu_loop(CPUNios2State *env)
  force_sig_fault(TARGET_SIGILL, TARGET_ILL_ILLTRP,
  env->regs[R_PC]);
  break;
+
+case 16: /* QEMU specific, for __kuser_cmpxchg */
+{
+abi_ptr g = env->regs[4];
+uint32_t *h, n, o;
+
+if (g & 0x3) {
+force_sig_fault(TARGET_SIGBUS, TARGET_BUS_ADRALN, g);
+break;
+}
+ret = page_get_flags(g);
+if (!(ret & PAGE_VALID)) {
+force_sig_fault(TARGET_SIGSEGV, TARGET_SEGV_MAPERR, g);
+break;
+}
+if (!(ret & PAGE_READ) || !(ret & PAGE_WRITE)) {
+force_sig_fault(TARGET_SIGSEGV, TARGET_SEGV_ACCERR, g);
+break;
+}
+h = g2h(cs, g);
+o = env->regs[5];
+n = env->regs[6];
+env->regs[2] = qatomic_cmpxchg(h, o, n) - o;
+env->regs[R_PC] += 4;
+}
+break;
  }
  break;
  
@@ -86,29 +112,7 @@ void cpu_loop(CPUNios2State *env)

  queue_signal(env, info.si_signo, QEMU_SI_FAULT, &info);
  break;
  case 0xaa:
-switch (env->regs[R_PC]) {
-/*case 0x1000:*/  /* TODO:__kuser_helper_version */
-case 0x1004:  /* __kuser_cmpxchg */
-start_exclusive();
-if (env->regs[4] & 0x3) {
-goto kuser_fail;
-}
-ret = get_user_u32(env->regs[2], env->regs[4]);
-if (ret) {
-end_exclusive();
-goto kuser_fail;
-}
-env->regs[2] -= env->regs[5];
-if (e

Re: [PATCH 3/3] linux-user: netlink: update IFLA_BRPORT entries

2022-01-05 Thread Laurent Vivier

Le 19/12/2021 à 16:45, Laurent Vivier a écrit :

add IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT and IFLA_BRPORT_MCAST_EHT_HOSTS_CNT

   # QEMU_LOG=unimp ip a
   Unknown QEMU_IFLA_BRPORT type 37
   Unknown QEMU_IFLA_BRPORT type 38

Signed-off-by: Laurent Vivier 
---
  linux-user/fd-trans.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/linux-user/fd-trans.c b/linux-user/fd-trans.c
index 36e4a4c2aae8..a17d05c07923 100644
--- a/linux-user/fd-trans.c
+++ b/linux-user/fd-trans.c
@@ -182,6 +182,8 @@ enum {
  QEMU_IFLA_BRPORT_BACKUP_PORT,
  QEMU_IFLA_BRPORT_MRP_RING_OPEN,
  QEMU_IFLA_BRPORT_MRP_IN_OPEN,
+QEMU_IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT,
+QEMU_IFLA_BRPORT_MCAST_EHT_HOSTS_CNT,
  QEMU___IFLA_BRPORT_MAX
  };
  
@@ -607,6 +609,8 @@ static abi_long host_to_target_slave_data_bridge_nlattr(struct nlattr *nlattr,

  /* uin32_t */
  case QEMU_IFLA_BRPORT_COST:
  case QEMU_IFLA_BRPORT_BACKUP_PORT:
+case QEMU_IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT:
+case QEMU_IFLA_BRPORT_MCAST_EHT_HOSTS_CNT:
  u32 = NLA_DATA(nlattr);
  *u32 = tswap32(*u32);
  break;



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



RE: [PATCH v4 07/14] vfio-user: run vfio-user context

2022-01-05 Thread Thanos Makatos


> -Original Message-
> From: Jag Raman 
> Sent: 17 December 2021 18:00
> To: Stefan Hajnoczi ; John Levon
> ; Thanos Makatos 
> Cc: qemu-devel ; Alex Williamson
> ; Marc-André Lureau
> ; Philippe Mathieu-Daudé
> ; pbonz...@redhat.com; alex.ben...@linaro.org;
> th...@redhat.com; cr...@redhat.com; waine...@redhat.com;
> bl...@redhat.com; Elena Ufimtseva ; John
> Levon ; John Johnson
> ; Thanos Makatos
> ; Swapnil Ingle 
> Subject: Re: [PATCH v4 07/14] vfio-user: run vfio-user context
> 
> 
> 
> > On Dec 16, 2021, at 6:17 AM, Stefan Hajnoczi  wrote:
> >
> > On Wed, Dec 15, 2021 at 10:35:31AM -0500, Jagannathan Raman wrote:
> >> @@ -114,6 +118,62 @@ static void vfu_object_set_device(Object *obj,
> const char *str, Error **errp)
> >> vfu_object_init_ctx(o, errp);
> >> }
> >>
> >> +static void vfu_object_ctx_run(void *opaque)
> >> +{
> >> +VfuObject *o = opaque;
> >> +int ret = -1;
> >> +
> >> +while (ret != 0) {
> >> +ret = vfu_run_ctx(o->vfu_ctx);
> >> +if (ret < 0) {
> >> +if (errno == EINTR) {
> >> +continue;
> >> +} else if (errno == ENOTCONN) {
> >> +qemu_set_fd_handler(o->vfu_poll_fd, NULL, NULL, NULL);
> >> +o->vfu_poll_fd = -1;
> >> +object_unparent(OBJECT(o));
> >> +break;
> >
> > If nothing else logs a message then I think that should be done here so
> > users know why their vfio-user server object disappeared.
> 
> Sure will do.
> 
> Do you prefer a trace, or a message to the console? Trace makes sense to me.
> Presently, the client could unplug the vfio-user device which would trigger 
> the
> deletion of this object. This process could happen quietly.
> 
> >
> >> +} else {
> >> +error_setg(&error_abort, "vfu: Failed to run device %s - 
> >> %s",
> >> +   o->device, strerror(errno));
> >
> > error_abort is equivalent to assuming !o->daemon. In the case where the
> > user doesn't want to automatically shut down the process we need to log
> > a message without aborting.
> 
> OK, makes sense.
> 
> >
> >> + break;
> >
> > Indentation is off.
> >
> >> +}
> >> +}
> >> +}
> >> +}
> >> +
> >> +static void vfu_object_attach_ctx(void *opaque)
> >> +{
> >> +VfuObject *o = opaque;
> >> +GPollFD pfds[1];
> >> +int ret;
> >> +
> >> +qemu_set_fd_handler(o->vfu_poll_fd, NULL, NULL, NULL);
> >> +
> >> +pfds[0].fd = o->vfu_poll_fd;
> >> +pfds[0].events = G_IO_IN | G_IO_HUP | G_IO_ERR;
> >> +
> >> +retry_attach:
> >> +ret = vfu_attach_ctx(o->vfu_ctx);
> >> +if (ret < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
> >> +qemu_poll_ns(pfds, 1, 500 * (int64_t)SCALE_MS);
> >> +goto retry_attach;
> >
> > This can block the thread indefinitely. Other events like monitor
> > commands are not handled in this loop. Please make this asynchronous
> > (set an fd handler and return from this function so we can try again
> > later).
> >
> > The vfu_attach_ctx() implementation synchronously negotiates the
> > vfio-user connection :(. That's a shame because even if accept(2) is
> > handled asynchronously, the negotiation can still block. It would be
> > cleanest to have a fully async libvfio-user's vfu_attach_ctx() API to
> > avoid blocking. Is that possible?
> 
> Thanos / John,
> 
> Any thoughts on this?

I'm discussing this with John and FYI there are other places where libvfio-user 
can block, e.g. sending a response or receiving a command. Is it just the 
negotiation you want it to be asynchronous or _all_ libvfio-user operations? 
Making libvfio-user fully asynchronous might require a substantial API rewrite.

> 
> >
> > If libvfio-user can't make vfu_attach_ctx() fully async then it may be
> > possible to spawn a thread just for the blocking vfu_attach_ctx() call
> > and report the result back to the event loop (e.g. using EventNotifier).
> > That adds a bunch of code to work around a blocking API though, so I
> > guess we can leave the blocking part if necessary.
> >
> > At the very minimum, please make EAGAIN/EWOULDBLOCK async as
> mentioned
> > above and add a comment explaining the situation with the
> > partially-async vfu_attach_ctx() API so it's clear that this can block
> > (that way it's clear that you're aware of the issue and this isn't by
> > accident).
> 
> Sure, we could make the attach async at QEMU depending on how the
> library prefers to do this.
> 
> >
> >> +} else if (ret < 0) {
> >> +error_setg(&error_abort,
> >> +   "vfu: Failed to attach device %s to context - %s",
> >> +   o->device, strerror(errno));
> >
> > error_abort assumes !o->daemon. Please handle the o->daemon == true
> > case by logging an error without aborting.
> >
> >> +return;
> >> +}
> >> +
> >> +o->vfu_poll_fd = vfu_get_poll_fd(o->vfu_ctx);
> >> +if (o->vfu_poll_fd < 0) {
> >> +erro

Re: [PATCH v2 5/7] linux-user/nios2: Fix EA vs PC confusion

2022-01-05 Thread Laurent Vivier

Le 21/12/2021 à 03:50, Richard Henderson a écrit :

The real kernel will talk about the user PC as EA,
because that's where the hardware will have copied it,
and where it expects to put it to then use ERET.
But qemu does not emulate all of the exception stuff
while emulating user-only.  Manipulate PC directly.

This fixes signal entry and return, and eliminates
some slight confusion from target_cpu_copy_regs.

Signed-off-by: Richard Henderson 
---
  linux-user/nios2/cpu_loop.c | 5 +
  linux-user/nios2/signal.c   | 6 +++---
  2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/linux-user/nios2/cpu_loop.c b/linux-user/nios2/cpu_loop.c
index de0fc63e21..1e93ef34e6 100644
--- a/linux-user/nios2/cpu_loop.c
+++ b/linux-user/nios2/cpu_loop.c
@@ -155,9 +155,6 @@ void target_cpu_copy_regs(CPUArchState *env, struct 
target_pt_regs *regs)
  env->regs[R_SP] = regs->sp;
  env->regs[R_GP] = regs->gp;
  env->regs[CR_ESTATUS] = regs->estatus;
-env->regs[R_EA] = regs->ea;
-/* TODO: unsigned long  orig_r7; */
-
-/* Emulate eret when starting thread. */
  env->regs[R_PC] = regs->ea;
+/* TODO: unsigned long  orig_r7; */
  }
diff --git a/linux-user/nios2/signal.c b/linux-user/nios2/signal.c
index adbffe32e3..20b65aa06e 100644
--- a/linux-user/nios2/signal.c
+++ b/linux-user/nios2/signal.c
@@ -73,7 +73,7 @@ static void rt_setup_ucontext(struct target_ucontext *uc, 
CPUNios2State *env)
  __put_user(env->regs[R_RA], &gregs[23]);
  __put_user(env->regs[R_FP], &gregs[24]);
  __put_user(env->regs[R_GP], &gregs[25]);
-__put_user(env->regs[R_EA], &gregs[27]);
+__put_user(env->regs[R_PC], &gregs[27]);
  __put_user(env->regs[R_SP], &gregs[28]);
  }
  
@@ -122,7 +122,7 @@ static int rt_restore_ucontext(CPUNios2State *env, struct target_ucontext *uc,

  __get_user(env->regs[R_GP], &gregs[25]);
  /* Not really necessary no user settable bits */
  __get_user(temp, &gregs[26]);
-__get_user(env->regs[R_EA], &gregs[27]);
+__get_user(env->regs[R_PC], &gregs[27]);
  
  __get_user(env->regs[R_RA], &gregs[23]);

  __get_user(env->regs[R_SP], &gregs[28]);
@@ -181,7 +181,7 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
  env->regs[4] = sig;
  env->regs[5] = frame_addr + offsetof(struct target_rt_sigframe, info);
  env->regs[6] = frame_addr + offsetof(struct target_rt_sigframe, uc);
-env->regs[R_EA] = ka->_sa_handler;
+env->regs[R_PC] = ka->_sa_handler;
  
  unlock_user_struct(frame, frame_addr, 1);

  }


Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent




Re: [PATCH 1/3] linux-user: netlink: update IFLA entries

2022-01-05 Thread Laurent Vivier

Le 19/12/2021 à 16:45, Laurent Vivier a écrit :

Add IFLA_PHYS_PORT_ID, IFLA_PARENT_DEV_NAME, IFLA_PARENT_DEV_BUS_NAME

   # QEMU_LOG=unimp ip a
   Unknown host QEMU_IFLA type: 56
   Unknown host QEMU_IFLA type: 57
   Unknown host QEMU_IFLA type: 34

Signed-off-by: Laurent Vivier 
---
  linux-user/fd-trans.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/linux-user/fd-trans.c b/linux-user/fd-trans.c
index 69410899590c..14c19a90b2b0 100644
--- a/linux-user/fd-trans.c
+++ b/linux-user/fd-trans.c
@@ -138,6 +138,9 @@ enum {
  QEMU_IFLA_PROP_LIST,
  QEMU_IFLA_ALT_IFNAME,
  QEMU_IFLA_PERM_ADDRESS,
+QEMU_IFLA_PROTO_DOWN_REASON,
+QEMU_IFLA_PARENT_DEV_NAME,
+QEMU_IFLA_PARENT_DEV_BUS_NAME,
  QEMU___IFLA_MAX
  };
  
@@ -818,9 +821,12 @@ static abi_long host_to_target_data_link_rtattr(struct rtattr *rtattr)

  case QEMU_IFLA_ADDRESS:
  case QEMU_IFLA_BROADCAST:
  case QEMU_IFLA_PERM_ADDRESS:
+case QEMU_IFLA_PHYS_PORT_ID:
  /* string */
  case QEMU_IFLA_IFNAME:
  case QEMU_IFLA_QDISC:
+case QEMU_IFLA_PARENT_DEV_NAME:
+case QEMU_IFLA_PARENT_DEV_BUS_NAME:
  break;
  /* uin8_t */
  case QEMU_IFLA_OPERSTATE:



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent



Re: [RFC 01/10] virtio: get class_id and pci device id by the virtio id

2022-01-05 Thread Cornelia Huck
On Wed, Jan 05 2022, "Longpeng(Mike)"  wrote:

> From: Longpeng 
>
> Add helpers to get the "Transitional PCI Device ID" and "class_id" of the
> deivce which is specificed by the "Virtio Device ID".
>
> These helpers will be used to build the generic vDPA device later.
>
> Signed-off-by: Longpeng 
> ---
>  hw/virtio/virtio-pci.c | 93 ++
>  hw/virtio/virtio-pci.h |  4 ++
>  2 files changed, 97 insertions(+)
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 750aa47ec1..843085c4ea 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -19,6 +19,7 @@
>  
>  #include "exec/memop.h"
>  #include "standard-headers/linux/virtio_pci.h"
> +#include "standard-headers/linux/virtio_ids.h"
>  #include "hw/boards.h"
>  #include "hw/virtio/virtio.h"
>  #include "migration/qemu-file-types.h"
> @@ -213,6 +214,95 @@ static int virtio_pci_load_queue(DeviceState *d, int n, 
> QEMUFile *f)
>  return 0;
>  }
>  
> +typedef struct VirtIOPCIIDInfo {
> +uint16_t vdev_id; /* virtio id */
> +uint16_t pdev_id; /* pci device id */
> +uint16_t class_id;
> +} VirtIOPCIIDInfo;
> +
> +static const VirtIOPCIIDInfo virtio_pci_id_info[] = {
> +{
> +.vdev_id = VIRTIO_ID_NET,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_NET,
> +.class_id = PCI_CLASS_NETWORK_ETHERNET,
> +},
> +{
> +.vdev_id = VIRTIO_ID_BLOCK,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_BLOCK,
> +.class_id = PCI_CLASS_STORAGE_SCSI,
> +},
> +{
> +.vdev_id = VIRTIO_ID_CONSOLE,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_CONSOLE,
> +.class_id = PCI_CLASS_COMMUNICATION_OTHER,
> +},
> +{
> +.vdev_id = VIRTIO_ID_SCSI,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_SCSI,
> +.class_id = PCI_CLASS_STORAGE_SCSI,
> +},
> +{
> +.vdev_id = VIRTIO_ID_9P,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_9P,
> +.class_id = PCI_BASE_CLASS_NETWORK,
> +},
> +{
> +.vdev_id = VIRTIO_ID_VSOCK,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_VSOCK,
> +.class_id = PCI_CLASS_COMMUNICATION_OTHER,
> +},
> +{
> +.vdev_id = VIRTIO_ID_IOMMU,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_IOMMU,
> +.class_id = PCI_CLASS_OTHERS,
> +},
> +{
> +.vdev_id = VIRTIO_ID_MEM,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_MEM,
> +.class_id = PCI_CLASS_OTHERS,
> +},
> +{
> +.vdev_id = VIRTIO_ID_PMEM,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_PMEM,
> +.class_id = PCI_CLASS_OTHERS,
> +},
> +{
> +.vdev_id = VIRTIO_ID_RNG,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_RNG,
> +.class_id = PCI_CLASS_OTHERS,
> +},
> +{
> +.vdev_id = VIRTIO_ID_BALLOON,
> +.pdev_id = PCI_DEVICE_ID_VIRTIO_BALLOON,
> +.class_id = PCI_CLASS_OTHERS,
> +},
> +};
> +
> +static VirtIOPCIIDInfo virtio_pci_get_id_info(uint16_t vdev_id)
> +{
> +VirtIOPCIIDInfo info = {};
> +int i;
> +
> +for (i = 0; i < ARRAY_SIZE(virtio_pci_id_info); i++) {
> +if (virtio_pci_id_info[i].vdev_id == vdev_id) {
> +info = virtio_pci_id_info[i];
> +break;
> +}
> +}
> +
> +return info;
> +}
> +
> +uint16_t virtio_pci_get_pci_devid(uint16_t device_id)
> +{
> +return virtio_pci_get_id_info(device_id).pdev_id;
> +}
> +
> +uint16_t virtio_pci_get_class_id(uint16_t device_id)
> +{
> +return virtio_pci_get_id_info(device_id).class_id;
> +}

What happens if these functions are called for a device_id that is not
in the array, e.g. if we forgot to add a new id to the array?

Can the array be generated in some way?




[PATCH] MAINTAINERS: Improve the PowerPC machines section

2022-01-05 Thread Thomas Huth
Add some documentation files to the corresponding machine sections
and mention the machine names in the section titles where it is
not so obvious (e.g. that "taihu" is a 405 machine).

Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f871d759fd..53cf0fdc00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1245,7 +1245,7 @@ F: hw/openrisc/openrisc_sim.c
 
 PowerPC Machines
 
-405
+405 (ref405ep and taihu)
 L: qemu-...@nongnu.org
 S: Orphan
 F: hw/ppc/ppc405_boards.c
@@ -1281,6 +1281,7 @@ New World (mac99)
 M: Mark Cave-Ayland 
 L: qemu-...@nongnu.org
 S: Odd Fixes
+F: docs/system/ppc/powermac.rst
 F: hw/ppc/mac_newworld.c
 F: hw/pci-host/uninorth.c
 F: hw/pci-bridge/dec.[hc]
@@ -1299,6 +1300,7 @@ Old World (g3beige)
 M: Mark Cave-Ayland 
 L: qemu-...@nongnu.org
 S: Odd Fixes
+F: docs/system/ppc/powermac.rst
 F: hw/ppc/mac_oldworld.c
 F: hw/pci-host/grackle.c
 F: hw/misc/macio/
@@ -1312,6 +1314,7 @@ PReP
 M: Hervé Poussineau 
 L: qemu-...@nongnu.org
 S: Maintained
+F: docs/system/ppc/prep.rst
 F: hw/ppc/prep.c
 F: hw/ppc/prep_systemio.c
 F: hw/ppc/rs6000_mc.c
@@ -1324,7 +1327,7 @@ F: include/hw/isa/pc87312.h
 F: include/hw/rtc/m48t59.h
 F: tests/avocado/ppc_prep_40p.py
 
-sPAPR
+sPAPR (pseries)
 M: Cédric Le Goater 
 M: Daniel Henrique Barboza 
 R: David Gibson 
@@ -1336,8 +1339,8 @@ F: include/hw/*/spapr*
 F: hw/*/xics*
 F: include/hw/*/xics*
 F: pc-bios/slof.bin
-F: docs/specs/ppc-spapr-hcalls.txt
-F: docs/specs/ppc-spapr-hotplug.txt
+F: docs/system/ppc/pseries.rst
+F: docs/specs/ppc-spapr-*
 F: tests/qtest/spapr*
 F: tests/qtest/libqos/*spapr*
 F: tests/qtest/rtas*
@@ -1348,6 +1351,7 @@ PowerNV (Non-Virtualized)
 M: Cédric Le Goater 
 L: qemu-...@nongnu.org
 S: Maintained
+F: docs/system/ppc/powernv.rst
 F: hw/ppc/pnv*
 F: hw/intc/pnv*
 F: hw/intc/xics_pnv.c
-- 
2.27.0




Re: [RFC 1/5] libvhost-user: Add vu_rem_mem_reg input validation

2022-01-05 Thread Stefan Hajnoczi
On Wed, Dec 15, 2021 at 10:29:48PM +, Raphael Norwitz wrote:
> Signed-off-by: Raphael Norwitz 
> ---
>  subprojects/libvhost-user/libvhost-user.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/subprojects/libvhost-user/libvhost-user.c 
> b/subprojects/libvhost-user/libvhost-user.c
> index 787f4d2d4f..573212a83b 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -801,6 +801,12 @@ vu_rem_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
>  VuDevRegion shadow_regions[VHOST_USER_MAX_RAM_SLOTS] = {};
>  VhostUserMemoryRegion m = vmsg->payload.memreg.region, *msg_region = &m;
>  
> +if (vmsg->fd_num != 1 ||
> +vmsg->size != sizeof(vmsg->payload.memreg)) {
> +vu_panic(dev, "VHOST_USER_REM_MEM_REG received multiple regions");
> +return true;

Most vu_panic() callers return false to indicate that a reply does not
need to be sent. When the return value is true vu_dispatch() sends a
response, which we don't want.

Note that vu_dispatch() returns true (success) when the message handler
function returns false. The success/failure behavior should probably be
separated from the reply_requested behavior :(.

Anyway, returning false is probably appropriate here.

Stefan


signature.asc
Description: PGP signature


Re: [RFC 2/5] libvhost-user: Add vu_add_mem_reg input validation

2022-01-05 Thread Stefan Hajnoczi
On Wed, Dec 15, 2021 at 10:29:51PM +, Raphael Norwitz wrote:
> Signed-off-by: Raphael Norwitz 
> ---
>  subprojects/libvhost-user/libvhost-user.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/subprojects/libvhost-user/libvhost-user.c 
> b/subprojects/libvhost-user/libvhost-user.c
> index 573212a83b..80ef335254 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -690,6 +690,12 @@ vu_add_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
>  VuDevRegion *dev_region = &dev->regions[dev->nregions];
>  void *mmap_addr;
>  
> +if (vmsg->fd_num != 1 ||
> +vmsg->size != sizeof(vmsg->payload.memreg)) {
> +vu_panic(dev, "VHOST_USER_REM_MEM_REG received multiple regions");
> +return true;

return false - we don't want a reply to be sent.

Stefan


signature.asc
Description: PGP signature


Re: [RFC 3/5] libvhost-user: Simplify VHOST_USER_REM_MEM_REG

2022-01-05 Thread Stefan Hajnoczi
On Wed, Dec 15, 2021 at 10:29:52PM +, Raphael Norwitz wrote:
> From: David Hildenbrand 
> 
> Let's avoid having to manually copy all elements. Copy only the ones
> necessary to close the hole and perform the operation in-place without
> a second array.
> 
> Signed-off-by: David Hildenbrand 
> Signed-off-by: Raphael Norwitz 
> ---
>  subprojects/libvhost-user/libvhost-user.c | 30 +++
>  1 file changed, 14 insertions(+), 16 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [RFC 4/5] libvhost-user: prevent over-running max RAM slots

2022-01-05 Thread Stefan Hajnoczi
On Wed, Dec 15, 2021 at 10:29:54PM +, Raphael Norwitz wrote:
> When VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS support was added to
> libvhost-user, no guardrails were added to protect against QEMU
> attempting to hot-add too many RAM slots to a VM with a libvhost-user
> based backed attached.
> 
> This change adds the missing error handling by introducing a check on
> the number of RAM slots the device has available before proceeding to
> process the VHOST_USER_ADD_MEM_REG message.
> 
> Suggested-by: Stefan Hajnoczi 
> Signed-off-by: Raphael Norwitz 
> ---
>  subprojects/libvhost-user/libvhost-user.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/subprojects/libvhost-user/libvhost-user.c 
> b/subprojects/libvhost-user/libvhost-user.c
> index 714cc7e08b..74a9980194 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -690,6 +690,11 @@ vu_add_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
>  VuDevRegion *dev_region = &dev->regions[dev->nregions];
>  void *mmap_addr;
>  
> +if (dev->nregions == VHOST_USER_MAX_RAM_SLOTS) {
> +vu_panic(dev, "No free ram slots available");
> +return true;

return false

Stefan


signature.asc
Description: PGP signature


[PATCH] ide: Explicitly poll for BHs on cancel

2022-01-05 Thread Hanna Reitz
When we still have an AIOCB registered for DMA operations, we try to
settle the respective operation by draining the BlockBackend associated
with the IDE device.

However, this assumes that every DMA operation is associated with some
I/O operation on the BlockBackend, and so settling the latter will
settle the former.  That is not the case; for example, the guest is free
to issue a zero-length TRIM operation that will not result in any I/O
operation forwarded to the BlockBackend.  In such a case, blk_drain()
will be a no-op if no other operations are in flight.

It is clear that if blk_drain() is a no-op, the value of
s->bus->dma->aiocb will not change between checking it in the `if`
condition and asserting that it is NULL after blk_drain().

To settle the DMA operation, we will thus need to explicitly invoke
aio_poll() ourselves, which will run any outstanding BHs (like
ide_trim_bh_cb()), until s->bus->dma->aiocb is NULL.  To stop this from
being an infinite loop, assert that we made progress with every
aio_poll() call (i.e., invoked some BH).

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2029980
Signed-off-by: Hanna Reitz 
---
Perhaps for a lack of being aware of all the kinds of tests we have, I
found it impossible to write a reproducer in any of our current test
frameworks: From how I understand the issue, to reproduce it, you need
to issue a TRIM request and immediately cancel it, before
ide_trim_bh_cb() (scheduled as a BH) can run.

I wanted to do this via qtest, but that does not work, because every
port I/O operation is done via a qtest command, and QEMU will happily
poll the main context between each qtest command, which means that you
cannot cancel an ongoing IDE request before a BH scheduled by it is run.

Therefore, I wrote an x86 boot sector that sets up a no-op TRIM request
(i.e. one where all TRIM ranges have length 0) and immediately cancels
it by setting SRST.  It is attached to the BZ linked above, and can be
tested as follows:

$ TEST_BIN=test.bin
$ (sleep 1; echo 'info registers'; echo quit) \
| ./qemu-system-x86_64 \
-drive if=ide,file=$TEST_BIN,format=raw \
-monitor stdio \
| grep EIP= \
| sed -e 's/ EFL.*//'

The result should be:
EIP=7c72

Not:
qemu-system-x86_64: ../hw/ide/core.c:734: ide_cancel_dma_sync: Assertion
`s->bus->dma->aiocb == NULL' failed.
---
 hw/ide/core.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index e28f8aad61..c7f7a1016c 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -731,7 +731,17 @@ void ide_cancel_dma_sync(IDEState *s)
 if (s->bus->dma->aiocb) {
 trace_ide_cancel_dma_sync_remaining();
 blk_drain(s->blk);
-assert(s->bus->dma->aiocb == NULL);
+
+/*
+ * Wait for potentially still-scheduled BHs, like ide_trim_bh_cb()
+ * (blk_drain() will only poll if there are in-flight requests on the
+ * BlockBackend, which there may not necessarily be, e.g. when the
+ * guest has issued a zero-length TRIM request)
+ */
+while (s->bus->dma->aiocb) {
+bool progress = aio_poll(qemu_get_aio_context(), true);
+assert(progress);
+}
 }
 }
 
-- 
2.33.1




Re: [RFC 06/10] vdpa-dev: implement the unrealize interface

2022-01-05 Thread Stefano Garzarella

On Wed, Jan 05, 2022 at 08:58:56AM +0800, Longpeng(Mike) wrote:

From: Longpeng 

Implements the .unrealize interface.

Signed-off-by: Longpeng 
---
hw/virtio/vdpa-dev.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
index 2d534d837a..4e4dd3d201 100644
--- a/hw/virtio/vdpa-dev.c
+++ b/hw/virtio/vdpa-dev.c
@@ -133,9 +133,29 @@ out:
close(fd);
}

+static void vhost_vdpa_vdev_unrealize(VhostVdpaDevice *s)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(s);
+int i;
+
+for (i = 0; i < s->num_queues; i++) {

  ^
`s->num_queues` seems uninitialized to me, maybe we could just remove 
the num_queues field from VhostVdpaDevice, and use `s->dev.nvqs` as in 
vhost_vdpa_device_realize().



+virtio_delete_queue(s->virtqs[i]);
+}
+g_free(s->virtqs);
+virtio_cleanup(vdev);
+
+g_free(s->config);
+}
+
static void vhost_vdpa_device_unrealize(DeviceState *dev)
{
-return;
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+VhostVdpaDevice *s = VHOST_VDPA_DEVICE(vdev);
+
+virtio_set_status(vdev, 0);
+vhost_dev_cleanup(&s->dev);


If we will use `s->dev.nvqs` in vhost_vdpa_vdev_unrealize(), we should 
call vhost_dev_cleanup() after it, just before close() as we already do 
in the error path of vhost_vdpa_device_realize().



+vhost_vdpa_vdev_unrealize(s);
+close(s->vdpa.device_fd);
}

static void
--
2.23.0






Re: [RFC 5/5] libvhost-user: handle removal of identical regions

2022-01-05 Thread Stefan Hajnoczi
On Wed, Dec 15, 2021 at 10:29:55PM +, Raphael Norwitz wrote:
> diff --git a/subprojects/libvhost-user/libvhost-user.c 
> b/subprojects/libvhost-user/libvhost-user.c
> index 74a9980194..2f465a4f0e 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -809,6 +809,7 @@ static bool
>  vu_rem_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
>  VhostUserMemoryRegion m = vmsg->payload.memreg.region, *msg_region = &m;
>  int i;
> +bool found = false;
>  
>  if (vmsg->fd_num != 1 ||
>  vmsg->size != sizeof(vmsg->payload.memreg)) {
> @@ -831,25 +832,25 @@ vu_rem_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
>  VuDevRegion *r = &dev->regions[i];
>  void *m = (void *) (uintptr_t) r->mmap_addr;
>  
> -if (m) {
> +if (m && !found) {
>  munmap(m, r->size + r->mmap_offset);
>  }

Why is only the first region unmapped? My interpretation of
vu_add_mem_reg() is that it mmaps duplicate regions to unique mmap_addr
addresses, so we need to munmap each of them.

>  
> -break;
> +/*
> + * Shift all affected entries by 1 to close the hole at index i 
> and
> + * zero out the last entry.
> + */
> +memmove(dev->regions + i, dev->regions + i + 1,
> +sizeof(VuDevRegion) * (dev->nregions - i - 1));
> +memset(dev->regions + dev->nregions - 1, 0, sizeof(VuDevRegion));
> +DPRINT("Successfully removed a region\n");
> +dev->nregions--;
> +
> +found = true;
>  }

i-- is missing. dev->regions[] has been shortened so we need to check
the same element again.


signature.asc
Description: PGP signature


Re: [RFC 04/10] vdpa-dev: implement the instance_init/class_init interface

2022-01-05 Thread Stefano Garzarella

On Wed, Jan 05, 2022 at 08:58:54AM +0800, Longpeng(Mike) wrote:

From: Longpeng 

Implements the .instance_init and the .class_init interface.

Signed-off-by: Longpeng 
---
hw/virtio/vdpa-dev-pci.c | 80 +++-
hw/virtio/vdpa-dev.c | 68 +-
include/hw/virtio/vdpa-dev.h |  2 +
3 files changed, 146 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/vdpa-dev-pci.c b/hw/virtio/vdpa-dev-pci.c
index a5a7b528a9..0af54a26d4 100644
--- a/hw/virtio/vdpa-dev-pci.c
+++ b/hw/virtio/vdpa-dev-pci.c
@@ -23,14 +23,90 @@ struct VhostVdpaDevicePCI {
VhostVdpaDevice vdev;
};

+static uint32_t
+vdpa_dev_pci_get_info(const char *name, uint64_t cmd, Error **errp)
+{
+int device_fd;
+uint32_t val;
+int ret;
+
+device_fd = qemu_open(name, O_RDWR, errp);
+if (device_fd == -1) {
+return (uint32_t)-1;
+}
+
+ret = ioctl(device_fd, cmd, &val);
+if (ret < 0) {
+error_setg(errp, "vhost-vdpa-device-pci: cmd 0x%lx failed: %s",
+   cmd, strerror(errno));
+goto out;
+}
+
+out:
+close(device_fd);
+return val;
+}
+
+static inline uint32_t
+vdpa_dev_pci_get_devid(VhostVdpaDevicePCI *dev, Error **errp)
+{
+return vdpa_dev_pci_get_info(dev->vdev.vdpa_dev,
+ VHOST_VDPA_GET_DEVICE_ID, errp);
+}
+
+static inline uint32_t
+vdpa_dev_pci_get_vectors_num(VhostVdpaDevicePCI *dev, Error **errp)
+{
+return vdpa_dev_pci_get_info(dev->vdev.vdpa_dev,
+ VHOST_VDPA_GET_VECTORS_NUM, errp);
+}
+
static void vhost_vdpa_device_pci_instance_init(Object *obj)
{
-return;
+VhostVdpaDevicePCI *dev = VHOST_VDPA_DEVICE_PCI(obj);
+
+virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev),
+TYPE_VHOST_VDPA_DEVICE);
+object_property_add_alias(obj, "bootindex", OBJECT(&dev->vdev),
+  "bootindex");
+}
+
+static Property vhost_vdpa_device_pci_properties[] = {
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void
+vhost_vdpa_device_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
+{
+VhostVdpaDevicePCI *dev = VHOST_VDPA_DEVICE_PCI(vpci_dev);
+DeviceState *vdev = DEVICE(&dev->vdev);
+uint32_t devid;
+uint32_t vectors;
+
+devid = vdpa_dev_pci_get_devid(dev, errp);
+if (*errp) {
+return;
+}
+
+vectors = vdpa_dev_pci_get_vectors_num(dev, errp);
+if (*errp) {
+return;
+}
+
+vpci_dev->class_code = virtio_pci_get_class_id(devid);
+vpci_dev->pdev_id = virtio_pci_get_pci_devid(devid);
+vpci_dev->nvectors = vectors;
+qdev_realize(vdev, BUS(&vpci_dev->bus), errp);
}

static void vhost_vdpa_device_pci_class_init(ObjectClass *klass, void *data)
{
-return;
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+device_class_set_props(dc, vhost_vdpa_device_pci_properties);
+k->realize = vhost_vdpa_device_pci_realize;
}

static const VirtioPCIDeviceTypeInfo vhost_vdpa_device_pci_info = {
diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c
index f4f92b90b0..790117fb3b 100644
--- a/hw/virtio/vdpa-dev.c
+++ b/hw/virtio/vdpa-dev.c
@@ -15,16 +15,80 @@
#include "sysemu/sysemu.h"
#include "sysemu/runstate.h"

-static void vhost_vdpa_device_class_init(ObjectClass *klass, void *data)
+static void vhost_vdpa_device_realize(DeviceState *dev, Error **errp)
{
return;
}

-static void vhost_vdpa_device_instance_init(Object *obj)
+static void vhost_vdpa_device_unrealize(DeviceState *dev)
+{
+return;
+}
+
+static void
+vhost_vdpa_device_get_config(VirtIODevice *vdev, uint8_t *config)
+{
+return;
+}
+
+static void
+vhost_vdpa_device_set_config(VirtIODevice *vdev, const uint8_t *config)
{
return;
}

+static uint64_t vhost_vdpa_device_get_features(VirtIODevice *vdev,
+   uint64_t features,
+   Error **errp)
+{
+return (uint64_t)-1;
+}
+
+static void vhost_vdpa_device_set_status(VirtIODevice *vdev, uint8_t status)
+{
+return;
+}
+
+static Property vhost_vdpa_device_properties[] = {
+DEFINE_PROP_STRING("vdpa-dev", VhostVdpaDevice, vdpa_dev),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static const VMStateDescription vmstate_vhost_vdpa_device = {
+.name = "vhost-vdpa-device",
+.minimum_version_id = 1,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_VIRTIO_DEVICE,
+VMSTATE_END_OF_LIST()
+},
+};
+
+static void vhost_vdpa_device_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioDeviceClass *vdc = VIRTIO_DEVICE_CLASS(klass);
+
+device_class_set_props(dc, vhost_vdpa_device_properties);
+dc->desc = "VDPA-based generic PCI device assignment";


IIUC, this should be the description of the generic vhost vDPA device, 
not the PC

[PATCH] docs: reSTify virtio-balloon-stats documentation and move to docs/interop

2022-01-05 Thread Thomas Huth
The virtio-balloon-stats documentation might be useful for people that
are implementing software that talks to QEMU via QMP, so this should
reside in the docs/interop/ directory. While we're at it, also convert
the file to restructured text and mention it in the MAINTAINERS file.

Signed-off-by: Thomas Huth 
---
 MAINTAINERS   |  1 +
 docs/interop/index.rst|  1 +
 .../virtio-balloon-stats.rst} | 58 ++-
 3 files changed, 32 insertions(+), 28 deletions(-)
 rename docs/{virtio-balloon-stats.txt => interop/virtio-balloon-stats.rst} 
(66%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 53cf0fdc00..3c587410f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1929,6 +1929,7 @@ virtio-balloon
 M: Michael S. Tsirkin 
 M: David Hildenbrand 
 S: Maintained
+F: docs/interop/virtio-balloon-stats.rst
 F: hw/virtio/virtio-balloon*.c
 F: include/hw/virtio/virtio-balloon.h
 F: softmmu/balloon.c
diff --git a/docs/interop/index.rst b/docs/interop/index.rst
index c59bac9834..b7632acb7b 100644
--- a/docs/interop/index.rst
+++ b/docs/interop/index.rst
@@ -22,3 +22,4 @@ are useful for making QEMU interoperate with other software.
vhost-user
vhost-user-gpu
vhost-vdpa
+   virtio-balloon-stats
diff --git a/docs/virtio-balloon-stats.txt 
b/docs/interop/virtio-balloon-stats.rst
similarity index 66%
rename from docs/virtio-balloon-stats.txt
rename to docs/interop/virtio-balloon-stats.rst
index 1732cc8c8a..b9a6a6edb2 100644
--- a/docs/virtio-balloon-stats.txt
+++ b/docs/interop/virtio-balloon-stats.rst
@@ -1,4 +1,4 @@
-virtio balloon memory statistics
+Virtio balloon memory statistics
 
 
 The virtio balloon driver supports guest memory statistics reporting. These
@@ -9,10 +9,12 @@ Before querying the available stats, clients first have to 
enable polling.
 This is done by writing a time interval value (in seconds) to the
 guest-stats-polling-interval property. This value can be:
 
-  > 0  enables polling in the specified interval. If polling is already
+  > 0
+   enables polling in the specified interval. If polling is already
enabled, the polling time interval is changed to the new value
 
-  0disables polling. Previous polled statistics are still valid and
+  0
+   disables polling. Previous polled statistics are still valid and
can be queried.
 
 Once polling is enabled, the virtio-balloon device in QEMU will start
@@ -22,7 +24,7 @@ interval.
 To retrieve those stats, clients have to query the guest-stats property,
 which will return a dictionary containing:
 
-  o A key named 'stats', containing all available stats. If the guest
+  * A key named 'stats', containing all available stats. If the guest
 doesn't support a particular stat, or if it couldn't be retrieved,
 its value will be -1. Currently, the following stats are supported:
 
@@ -37,7 +39,7 @@ which will return a dictionary containing:
   - stat-htlb-pgalloc
   - stat-htlb-pgfail
 
-  o A key named last-update, which contains the last stats update
+  * A key named last-update, which contains the last stats update
 timestamp in seconds. Since this timestamp is generated by the host,
 a buggy guest can't influence its value. The value is 0 if the guest
 has not updated the stats (yet).
@@ -61,32 +63,32 @@ It's also important to note the following:
respond to the request the timer will never be re-armed, which has
the same effect as disabling polling
 
-Here are a few examples. QEMU is started with '-device virtio-balloon',
-which generates '/machine/peripheral-anon/device[1]' as the QOM path for
+Here are a few examples. QEMU is started with ``-device virtio-balloon``,
+which generates ``/machine/peripheral-anon/device[1]`` as the QOM path for
 the balloon device.
 
-Enable polling with 2 seconds interval:
+Enable polling with 2 seconds interval::
 
-{ "execute": "qom-set",
- "arguments": { "path": "/machine/peripheral-anon/device[1]",
-"property": "guest-stats-polling-interval", "value": 2 
} }
+  { "execute": "qom-set",
+   "arguments": { "path": "/machine/peripheral-anon/device[1]",
+   "property": "guest-stats-polling-interval", "value": 2 } }
 
-{ "return": {} }
+  { "return": {} }
 
-Change polling to 10 seconds:
+Change polling to 10 seconds::
 
-{ "execute": "qom-set",
- "arguments": { "path": "/machine/peripheral-anon/device[1]",
-"property": "guest-stats-polling-interval", "value": 
10 } }
+  { "execute": "qom-set",
+   "arguments": { "path": "/machine/peripheral-anon/device[1]",
+   "property": "guest-stats-polling-interval", "value": 10 } }
 
-{ "return": {} }
+  { "return": {} }
 
-Get stats:
+Get stats::
 
-{ "execute": "qom-get",
-  "arguments": { "path": "/machine/peripheral-anon/device[1]",
-  "property": "guest-stats" } }
-{
+  { "execute": "qom-get"

Re: [PATCH] optionrom: Turn off -fcf-protection

2022-01-05 Thread Stefano Garzarella

CCing Paolo

On Mon, Jan 03, 2022 at 10:01:12AM +0100, Björn Töpel wrote:

Ubuntu GCC enables -fcf-protection globally, which is not supported
for x86 16-bit (realmode). This causes the build to fail.

This commit turns off that option.

Signed-off-by: Björn Töpel 
---
pc-bios/optionrom/Makefile | 1 +
1 file changed, 1 insertion(+)

diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
index 5d55d25acca2..c5f5fa02ef06 100644
--- a/pc-bios/optionrom/Makefile
+++ b/pc-bios/optionrom/Makefile
@@ -21,6 +21,7 @@ override CFLAGS += $(filter -W%, $(QEMU_CFLAGS))
override CFLAGS += $(CFLAGS_NOPIE) -ffreestanding -I$(TOPSRC_DIR)/include
override CFLAGS += $(call cc-option, -fno-stack-protector)
override CFLAGS += $(call cc-option, -m16)
+override CFLAGS += $(call cc-option, -fcf-protection=none)


LGTM!

Reviewed-by: Stefano Garzarella 




Re: [PATCH 5/6] docs/qdev-device-use: Add CanoKey to QDEV devices examples

2022-01-05 Thread Thomas Huth

On 23/12/2021 18.17, Hongren (Zenithal) Zheng wrote:

Signed-off-by: Hongren (Zenithal) Zheng 
---
  docs/qdev-device-use.txt | 1 +
  1 file changed, 1 insertion(+)

diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt
index 2408889334..278fb66c0a 100644
--- a/docs/qdev-device-use.txt
+++ b/docs/qdev-device-use.txt
@@ -342,6 +342,7 @@ The new way is -device DEVNAME,DEV-OPTS...  Details depend 
on DRIVER:
  * tablet  -device usb-tablet
  * wacom-tablet-device usb-wacom-tablet
  * u2f -device u2f-{emulated,passthru}
+* canokey -device canokey
  * braille See "Character Devices"


Please drop this patch. The list here is only about legacy USB device usage 
with the "-usbdevice" parameter, but since there never was and never will be 
a "-usbdevice canokey", there is no need to add an entry here.


 Thomas




Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa

2022-01-05 Thread Michael S. Tsirkin
On Wed, Jan 05, 2022 at 05:09:07PM +0800, Jason Wang wrote:
> On Wed, Jan 5, 2022 at 4:37 PM Longpeng (Mike, Cloud Infrastructure
> Service Product Dept.)  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Jason Wang [mailto:jasow...@redhat.com]
> > > Sent: Wednesday, January 5, 2022 3:54 PM
> > > To: Michael S. Tsirkin 
> > > Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> > > ; Stefan Hajnoczi ; Stefano
> > > Garzarella ; Cornelia Huck ; 
> > > pbonzini
> > > ; Gonglei (Arei) ; Yechuan
> > > ; Huangzhichao ; qemu-devel
> > > 
> > > Subject: Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa
> > >
> > > On Wed, Jan 5, 2022 at 3:02 PM Michael S. Tsirkin  wrote:
> > > >
> > > > On Wed, Jan 05, 2022 at 12:35:53PM +0800, Jason Wang wrote:
> > > > > On Wed, Jan 5, 2022 at 8:59 AM Longpeng(Mike)  
> > > > > wrote:
> > > > > >
> > > > > > From: Longpeng 
> > > > > >
> > > > > > To support generic vdpa deivce, we need add the following ioctls:
> > > > > > - GET_VECTORS_NUM: the count of vectors that supported
> > > > >
> > > > > Does this mean MSI vectors? If yes, it looks like a layer violation:
> > > > > vhost is transport independent.
> > > >
> > > > Well *guest* needs to know how many vectors device supports.
> > > > I don't think there's a way around that. Do you?
> > >
> > > We have VHOST_SET_VRING/CONFIG_CALL which is per vq. I think we can
> > > simply assume #vqs + 1?
> > >
> > > > Otherwise guests will at best be suboptimal.
> > > >
> > > > >  And it reveals device implementation
> > > > > details which block (cross vendor) migration.
> > > > >
> > > > > Thanks
> > > >
> > > > Not necessarily, userspace can hide this from guest if it
> > > > wants to, just validate.
> > >
> > > If we can hide it at vhost/uAPI level, it would be even better?
> > >
> >
> > Not only MSI vectors, but also queue-size, #vqs, etc.
> 
> MSI is PCI specific, we have non PCI vDPA parent e.g VDUSE/simulator/mlx5
> 
> And it's something that is not guaranteed to be not changed. E.g some
> drivers may choose to allocate MSI during set_status() which can fail
> for various reasons.
> 
> >
> > Maybe the vhost level could expose the hardware's real capabilities
> > and let the userspace (QEMU) do the hiding? The userspace know how
> > to process them.
> 
> #MSI vectors is much more easier to be mediated than queue-size and #vqs.
> 
> For interrupts, we've already had VHOST_SET_X_KICK, we can keep
> allocating eventfd based on #MSI vectors to make it work with any
> number of MSI vectors that the virtual device had.

Right but if hardware does not support so many then what?
Just fail? Having a query API would make things somewhat cleaner imho.

> For queue-size, it's Ok to have a new uAPI but it's not a must, Qemu
> can simply fail if SET_VRING_NUM fail.
>
> For #vqs, it's OK to have a new uAPI since the emulated virtio-pci
> device requires knowledge the #vqs in the config space. (still not a
> must, we can enumerate #vqs per device type)
> 
> For the config size, it's OK but not a must, technically we can simply
> relay what guest write to vhost-vdpa. It's just because current Qemu
> require to have it during virtio device initialization.
> 
> Thanks


I agree but these ok things make for a cleaner API I think.

> >
> > > Thanks
> > >
> > > >
> > > >
> > > > > > - GET_CONFIG_SIZE: the size of the virtio config space
> > > > > > - GET_VQS_NUM: the count of virtqueues that exported
> > > > > >
> > > > > > Signed-off-by: Longpeng 
> > > > > > ---
> > > > > >  linux-headers/linux/vhost.h | 10 ++
> > > > > >  1 file changed, 10 insertions(+)
> > > > > >
> > > > > > diff --git a/linux-headers/linux/vhost.h 
> > > > > > b/linux-headers/linux/vhost.h
> > > > > > index c998860d7b..c5edd75d15 100644
> > > > > > --- a/linux-headers/linux/vhost.h
> > > > > > +++ b/linux-headers/linux/vhost.h
> > > > > > @@ -150,4 +150,14 @@
> > > > > >  /* Get the valid iova range */
> > > > > >  #define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
> > > > > >  struct 
> > > > > > vhost_vdpa_iova_range)
> > > > > > +
> > > > > > +/* Get the number of vectors */
> > > > > > +#define VHOST_VDPA_GET_VECTORS_NUM _IOR(VHOST_VIRTIO, 0x79, 
> > > > > > int)
> > > > > > +
> > > > > > +/* Get the virtio config size */
> > > > > > +#define VHOST_VDPA_GET_CONFIG_SIZE _IOR(VHOST_VIRTIO, 0x80, 
> > > > > > int)
> > > > > > +
> > > > > > +/* Get the number of virtqueues */
> > > > > > +#define VHOST_VDPA_GET_VQS_NUM _IOR(VHOST_VIRTIO, 0x81, 
> > > > > > int)
> > > > > > +
> > > > > >  #endif
> > > > > > --
> > > > > > 2.23.0
> > > > > >
> > > >
> >




Re: [PATCH] docs/sphinx: fix compatibility with sphinx < 1.8

2022-01-05 Thread Alex Bennée


marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> SphinxDirective was added with sphinx 1.8 (2018-09-13).
>
> Reported-by: Thomas Huth 
> Signed-off-by: Marc-André Lureau 

Queued to testing/next (as I need it for Thomas's API updates), thanks.


-- 
Alex Bennée



[PULL 0/8] Misc patches (tests, docs, compat machines)

2022-01-05 Thread Thomas Huth
 Hi!

The following changes since commit fb084237a3b78b20fd9d888dffd673b6656ea3be:

  common-user: Really fix i386 calls to safe_syscall_set_errno_tail (2022-01-04 
21:14:23 -0800)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2022-01-05

for you to fetch changes up to 057dc9a635fe37118a98b32e8bd9d8ed47b1a102:

  docs/tools/qemu-trace-stap.rst: Do not hard-code the QEMU binary name 
(2022-01-05 11:10:13 +0100)


* Add compat machines for 7.0
* Some minor qtest and unit test improvements
* Remove -no-quit option
* Fixes for the docs


Cornelia Huck (1):
  hw: Add compat machines for 7.0

Marc-André Lureau (1):
  docs/sphinx: fix compatibility with sphinx < 1.8

Philippe Mathieu-Daudé (1):
  tests/unit/test-util-sockets: Use g_file_open_tmp() to create temp file

Thomas Huth (5):
  tests/qtest/test-x86-cpuid-compat: Check for machines before using them
  tests/qtest/hd-geo-test: Check for the lsi53c895a controller before using 
it
  qemu-options: Remove the deprecated -no-quit option
  gitlab-ci: Enable docs in the centos job
  docs/tools/qemu-trace-stap.rst: Do not hard-code the QEMU binary name

 .gitlab-ci.d/buildtest.yml  |  2 +-
 docs/about/deprecated.rst   |  6 ---
 docs/about/removed-features.rst |  7 +++
 docs/sphinx/fakedbusdoc.py  |  4 +-
 docs/tools/qemu-trace-stap.rst  | 24 +--
 hw/arm/virt.c   |  9 +++-
 hw/core/machine.c   |  3 ++
 hw/i386/pc.c|  3 ++
 hw/i386/pc_piix.c   | 14 +-
 hw/i386/pc_q35.c| 13 +-
 hw/ppc/spapr.c  | 15 ++-
 hw/s390x/s390-virtio-ccw.c  | 14 +-
 include/hw/boards.h |  3 ++
 include/hw/i386/pc.h|  3 ++
 qemu-options.hx |  8 
 softmmu/vl.c|  8 +---
 tests/qtest/hd-geo-test.c   |  8 ++--
 tests/qtest/test-x86-cpuid-compat.c | 85 +
 tests/unit/test-util-sockets.c  |  6 ++-
 19 files changed, 151 insertions(+), 84 deletions(-)




[PULL 1/8] hw: Add compat machines for 7.0

2022-01-05 Thread Thomas Huth
From: Cornelia Huck 

Add 7.0 machine types for arm/i440fx/q35/s390x/spapr.

Signed-off-by: Cornelia Huck 
Reviewed-by: Juan Quintela 
Reviewed-by: Andrew Jones 
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Christian Borntraeger 
Acked-by: Cédric Le Goater 
Message-Id: <20211217143948.289995-1-coh...@redhat.com>
Signed-off-by: Thomas Huth 
---
 hw/arm/virt.c  |  9 -
 hw/core/machine.c  |  3 +++
 hw/i386/pc.c   |  3 +++
 hw/i386/pc_piix.c  | 14 +-
 hw/i386/pc_q35.c   | 13 -
 hw/ppc/spapr.c | 15 +--
 hw/s390x/s390-virtio-ccw.c | 14 +-
 include/hw/boards.h|  3 +++
 include/hw/i386/pc.h   |  3 +++
 9 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 6bce595aba..4593fea1ce 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2856,10 +2856,17 @@ static void machvirt_machine_init(void)
 }
 type_init(machvirt_machine_init);
 
+static void virt_machine_7_0_options(MachineClass *mc)
+{
+}
+DEFINE_VIRT_MACHINE_AS_LATEST(7, 0)
+
 static void virt_machine_6_2_options(MachineClass *mc)
 {
+virt_machine_7_0_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_2, hw_compat_6_2_len);
 }
-DEFINE_VIRT_MACHINE_AS_LATEST(6, 2)
+DEFINE_VIRT_MACHINE(6, 2)
 
 static void virt_machine_6_1_options(MachineClass *mc)
 {
diff --git a/hw/core/machine.c b/hw/core/machine.c
index a4a2df405f..debcdc0e70 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -37,6 +37,9 @@
 #include "hw/virtio/virtio.h"
 #include "hw/virtio/virtio-pci.h"
 
+GlobalProperty hw_compat_6_2[] = {};
+const size_t hw_compat_6_2_len = G_N_ELEMENTS(hw_compat_6_2);
+
 GlobalProperty hw_compat_6_1[] = {
 { "vhost-user-vsock-device", "seqpacket", "off" },
 { "nvme-ns", "shared", "off" },
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a2ef40ecbc..fccde2ef39 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -94,6 +94,9 @@
 #include "trace.h"
 #include CONFIG_DEVICES
 
+GlobalProperty pc_compat_6_2[] = {};
+const size_t pc_compat_6_2_len = G_N_ELEMENTS(pc_compat_6_2);
+
 GlobalProperty pc_compat_6_1[] = {
 { TYPE_X86_CPU, "hv-version-id-build", "0x1bbc" },
 { TYPE_X86_CPU, "hv-version-id-major", "0x0006" },
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 223dd3e05d..1999190276 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -413,7 +413,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
 }
 
-static void pc_i440fx_6_2_machine_options(MachineClass *m)
+static void pc_i440fx_7_0_machine_options(MachineClass *m)
 {
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_i440fx_machine_options(m);
@@ -422,6 +422,18 @@ static void pc_i440fx_6_2_machine_options(MachineClass *m)
 pcmc->default_cpu_version = 1;
 }
 
+DEFINE_I440FX_MACHINE(v7_0, "pc-i440fx-7.0", NULL,
+  pc_i440fx_7_0_machine_options);
+
+static void pc_i440fx_6_2_machine_options(MachineClass *m)
+{
+pc_i440fx_7_0_machine_options(m);
+m->alias = NULL;
+m->is_default = false;
+compat_props_add(m->compat_props, hw_compat_6_2, hw_compat_6_2_len);
+compat_props_add(m->compat_props, pc_compat_6_2, pc_compat_6_2_len);
+}
+
 DEFINE_I440FX_MACHINE(v6_2, "pc-i440fx-6.2", NULL,
   pc_i440fx_6_2_machine_options);
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e1e100316d..2e981f436c 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -360,7 +360,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->max_cpus = 288;
 }
 
-static void pc_q35_6_2_machine_options(MachineClass *m)
+static void pc_q35_7_0_machine_options(MachineClass *m)
 {
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_q35_machine_options(m);
@@ -368,6 +368,17 @@ static void pc_q35_6_2_machine_options(MachineClass *m)
 pcmc->default_cpu_version = 1;
 }
 
+DEFINE_Q35_MACHINE(v7_0, "pc-q35-7.0", NULL,
+   pc_q35_7_0_machine_options);
+
+static void pc_q35_6_2_machine_options(MachineClass *m)
+{
+pc_q35_7_0_machine_options(m);
+m->alias = NULL;
+compat_props_add(m->compat_props, hw_compat_6_2, hw_compat_6_2_len);
+compat_props_add(m->compat_props, pc_compat_6_2, pc_compat_6_2_len);
+}
+
 DEFINE_Q35_MACHINE(v6_2, "pc-q35-6.2", NULL,
pc_q35_6_2_machine_options);
 
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3b5fd749be..8373429325 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4665,15 +4665,26 @@ static void 
spapr_machine_latest_class_options(MachineClass *mc)
 }\
 type_init(spapr_machine_register_##suffix)
 
+/*
+ * pseries-7.0
+ */
+static void spapr_machine_7_0_class_options(MachineClass *mc)
+{
+/* Defaults for the latest behaviour inherited from the base class */
+}
+
+DEFINE_SPAPR_MACHINE(7_0, "7.0", true);
+
 /*
  * pseries-6

[PULL 3/8] tests/qtest/hd-geo-test: Check for the lsi53c895a controller before using it

2022-01-05 Thread Thomas Huth
The lsi53c895a SCSI controller might have been disabled in the target
binary, so let's check for its availability first before using it.

Message-Id: <20211222153600.976588-1-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/qtest/hd-geo-test.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/qtest/hd-geo-test.c b/tests/qtest/hd-geo-test.c
index 113126ae06..771eaa741b 100644
--- a/tests/qtest/hd-geo-test.c
+++ b/tests/qtest/hd-geo-test.c
@@ -960,9 +960,11 @@ int main(int argc, char **argv)
 qtest_add_func("hd-geo/ide/device/user/chst", test_ide_device_user_chst);
 if (have_qemu_img()) {
 qtest_add_func("hd-geo/override/ide", test_override_ide);
-qtest_add_func("hd-geo/override/scsi", test_override_scsi);
-qtest_add_func("hd-geo/override/scsi_2_controllers",
-   test_override_scsi_2_controllers);
+if (qtest_has_device("lsi53c895a")) {
+qtest_add_func("hd-geo/override/scsi", test_override_scsi);
+qtest_add_func("hd-geo/override/scsi_2_controllers",
+   test_override_scsi_2_controllers);
+}
 qtest_add_func("hd-geo/override/virtio_blk", test_override_virtio_blk);
 qtest_add_func("hd-geo/override/zero_chs", test_override_zero_chs);
 qtest_add_func("hd-geo/override/scsi_hot_unplug",
-- 
2.27.0




[PULL 5/8] qemu-options: Remove the deprecated -no-quit option

2022-01-05 Thread Thomas Huth
This option was just a wrapper around the -display ...,window-close=off
parameter, and the name "no-quit" is rather confusing compared to
"window-close" (since there are still other means to quit the emulator),
so let's remove this now.

Message-Id: <20211215082417.180735-1-th...@redhat.com>
Acked-by: Michal Prívozník 
Reviewed-by: Markus Armbruster 
Signed-off-by: Thomas Huth 
---
 docs/about/deprecated.rst   | 6 --
 docs/about/removed-features.rst | 7 +++
 qemu-options.hx | 8 
 softmmu/vl.c| 8 +---
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 5693abb663..e21e07478f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -134,12 +134,6 @@ specified.
 Use ``-display sdl,window-close=...`` instead (i.e. with a minus instead of
 an underscore between "window" and "close").
 
-``-no-quit`` (since 6.1)
-
-
-The ``-no-quit`` is a synonym for ``-display ...,window-close=off`` which
-should be used instead.
-
 ``-alt-grab`` and ``-display sdl,alt_grab=on`` (since 6.2)
 ''
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index d42c3341de..4c4da20d0f 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -330,6 +330,13 @@ RISC-V firmware not booted by default (removed in 5.1)
 QEMU 5.1 changes the default behaviour from ``-bios none`` to ``-bios default``
 for the RISC-V ``virt`` machine and ``sifive_u`` machine.
 
+``-no-quit`` (removed in 7.0)
+'
+
+The ``-no-quit`` was a synonym for ``-display ...,window-close=off`` which
+should be used instead.
+
+
 QEMU Machine Protocol (QMP) commands
 
 
diff --git a/qemu-options.hx b/qemu-options.hx
index fd1f8135fb..ec90505d84 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2065,14 +2065,6 @@ SRST
 ``-display sdl,grab-mod=rctrl`` instead.
 ERST
 
-DEF("no-quit", 0, QEMU_OPTION_no_quit,
-"-no-quitdisable SDL/GTK window close capability (deprecated)\n", 
QEMU_ARCH_ALL)
-SRST
-``-no-quit``
-Disable window close capability (SDL and GTK only). This option is
-deprecated, please use ``-display ...,window-close=off`` instead.
-ERST
-
 DEF("sdl", 0, QEMU_OPTION_sdl,
 "-sdlshorthand for -display sdl\n", QEMU_ARCH_ALL)
 SRST
diff --git a/softmmu/vl.c b/softmmu/vl.c
index d9e4c619d3..a8cad43691 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1941,7 +1941,7 @@ static void qemu_create_early_backends(void)
  "for SDL, ignoring option");
 }
 if (dpy.has_window_close && !use_gtk && !use_sdl) {
-error_report("-no-quit is only valid for GTK and SDL, "
+error_report("window-close is only valid for GTK and SDL, "
  "ignoring option");
 }
 
@@ -3301,12 +3301,6 @@ void qemu_init(int argc, char **argv, char **envp)
 warn_report("-ctrl-grab is deprecated, please use "
 "-display sdl,grab-mod=rctrl instead.");
 break;
-case QEMU_OPTION_no_quit:
-dpy.has_window_close = true;
-dpy.window_close = false;
-warn_report("-no-quit is deprecated, please use "
-"-display ...,window-close=off instead.");
-break;
 case QEMU_OPTION_sdl:
 warn_report("-sdl is deprecated, use -display sdl instead.");
 #ifdef CONFIG_SDL
-- 
2.27.0




[PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax

2022-01-05 Thread Daniel P . Berrangé
The -device JSON syntax impl leaks a reference on the created
DeviceState instance. As a result when you hot-unplug the
device, the device_finalize method won't be called and thus
it will fail to emit the required DEVICE_DELETED event.

A 'json-cli' feature was previously added against the
'device_add' QMP command QAPI schema to indicated to mgmt
apps that -device supported JSON syntax. Given the hotplug
bug that feature flag is no unusable for its purpose, so
we add a new 'json-cli-hotplug' feature to indicate the
-device supports JSON without breaking hotplug.

Fixes: https://gitlab.com/qemu-project/qemu/-/issues/802
Signed-off-by: Daniel P. Berrangé 
---
 qapi/qdev.json |  5 -
 softmmu/vl.c   |  4 +++-
 tests/qtest/device-plug-test.c | 19 +++
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/qapi/qdev.json b/qapi/qdev.json
index 69656b14df..26cd10106b 100644
--- a/qapi/qdev.json
+++ b/qapi/qdev.json
@@ -44,6 +44,9 @@
 # @json-cli: If present, the "-device" command line option supports JSON
 #syntax with a structure identical to the arguments of this
 #command.
+# @json-cli-hotplug: If present, the "-device" command line option supports 
JSON
+#syntax without the reference counting leak that broke
+#hot-unplug
 #
 # Notes:
 #
@@ -74,7 +77,7 @@
 { 'command': 'device_add',
   'data': {'driver': 'str', '*bus': 'str', '*id': 'str'},
   'gen': false, # so we can get the additional arguments
-  'features': ['json-cli'] }
+  'features': ['json-cli', 'json-cli-hotplug'] }
 
 ##
 # @device_del:
diff --git a/softmmu/vl.c b/softmmu/vl.c
index d9e4c619d3..b1fc7da104 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2684,6 +2684,7 @@ static void qemu_create_cli_devices(void)
 qemu_opts_foreach(qemu_find_opts("device"),
   device_init_func, NULL, &error_fatal);
 QTAILQ_FOREACH(opt, &device_opts, next) {
+DeviceState *dev;
 loc_push_restore(&opt->loc);
 /*
  * TODO Eventually we should call qmp_device_add() here to make sure it
@@ -2692,7 +2693,8 @@ static void qemu_create_cli_devices(void)
  * from the start, so call qdev_device_add_from_qdict() directly for
  * now.
  */
-qdev_device_add_from_qdict(opt->opts, true, &error_fatal);
+dev = qdev_device_add_from_qdict(opt->opts, true, &error_fatal);
+object_unref(OBJECT(dev));
 loc_pop(&opt->loc);
 }
 rom_reset_order_override();
diff --git a/tests/qtest/device-plug-test.c b/tests/qtest/device-plug-test.c
index 559d47727a..ad79bd4c14 100644
--- a/tests/qtest/device-plug-test.c
+++ b/tests/qtest/device-plug-test.c
@@ -77,6 +77,23 @@ static void test_pci_unplug_request(void)
 qtest_quit(qtest);
 }
 
+static void test_pci_unplug_json_request(void)
+{
+QTestState *qtest = qtest_initf(
+"-device '{\"driver\": \"virtio-mouse-pci\", \"id\": \"dev0\"}'");
+
+/*
+ * Request device removal. As the guest is not running, the request won't
+ * be processed. However during system reset, the removal will be
+ * handled, removing the device.
+ */
+device_del(qtest, "dev0");
+system_reset(qtest);
+wait_device_deleted_event(qtest, "dev0");
+
+qtest_quit(qtest);
+}
+
 static void test_ccw_unplug(void)
 {
 QTestState *qtest = qtest_initf("-device virtio-balloon-ccw,id=dev0");
@@ -145,6 +162,8 @@ int main(int argc, char **argv)
  */
 qtest_add_func("/device-plug/pci-unplug-request",
test_pci_unplug_request);
+qtest_add_func("/device-plug/pci-unplug-json-request",
+   test_pci_unplug_json_request);
 
 if (!strcmp(arch, "s390x")) {
 qtest_add_func("/device-plug/ccw-unplug",
-- 
2.33.1




[PULL 2/8] tests/qtest/test-x86-cpuid-compat: Check for machines before using them

2022-01-05 Thread Thomas Huth
The user might have disabled the pc-i440fx machine type (or it's older
versions, like done in downstream RHEL) in the QEMU binary, so let's
better check whether the machine types are available before using them.

Message-Id: <20211222153923.1000420-1-th...@redhat.com>
Reviewed-by: Igor Mammedov 
Signed-off-by: Thomas Huth 
---
 tests/qtest/test-x86-cpuid-compat.c | 85 -
 1 file changed, 48 insertions(+), 37 deletions(-)

diff --git a/tests/qtest/test-x86-cpuid-compat.c 
b/tests/qtest/test-x86-cpuid-compat.c
index f28848e06e..39138db774 100644
--- a/tests/qtest/test-x86-cpuid-compat.c
+++ b/tests/qtest/test-x86-cpuid-compat.c
@@ -302,54 +302,65 @@ int main(int argc, char **argv)
 
 /* Check compatibility of old machine-types that didn't
  * auto-increase level/xlevel/xlevel2: */
-
-add_cpuid_test("x86/cpuid/auto-level/pc-2.7",
-   "-machine pc-i440fx-2.7 -cpu 
486,arat=on,avx512vbmi=on,xsaveopt=on",
-   "level", 1);
-add_cpuid_test("x86/cpuid/auto-xlevel/pc-2.7",
-   "-machine pc-i440fx-2.7 -cpu 
486,3dnow=on,sse4a=on,invtsc=on,npt=on,svm=on",
-   "xlevel", 0);
-add_cpuid_test("x86/cpuid/auto-xlevel2/pc-2.7",
-   "-machine pc-i440fx-2.7 -cpu 486,xstore=on",
-   "xlevel2", 0);
+if (qtest_has_machine("pc-i440fx-2.7")) {
+add_cpuid_test("x86/cpuid/auto-level/pc-2.7",
+   "-machine pc-i440fx-2.7 -cpu 
486,arat=on,avx512vbmi=on,xsaveopt=on",
+   "level", 1);
+add_cpuid_test("x86/cpuid/auto-xlevel/pc-2.7",
+   "-machine pc-i440fx-2.7 -cpu 
486,3dnow=on,sse4a=on,invtsc=on,npt=on,svm=on",
+   "xlevel", 0);
+add_cpuid_test("x86/cpuid/auto-xlevel2/pc-2.7",
+   "-machine pc-i440fx-2.7 -cpu 486,xstore=on",
+   "xlevel2", 0);
+}
 /*
  * QEMU 1.4.0 had auto-level enabled for CPUID[7], already,
  * and the compat code that sets default level shouldn't
  * disable the auto-level=7 code:
  */
-add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-1.4/off",
-   "-machine pc-i440fx-1.4 -cpu Nehalem",
-   "level", 2);
-add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-1.5/on",
-   "-machine pc-i440fx-1.4 -cpu Nehalem,smap=on",
-   "level", 7);
-add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.3/off",
-   "-machine pc-i440fx-2.3 -cpu Penryn",
-   "level", 4);
-add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.3/on",
-   "-machine pc-i440fx-2.3 -cpu Penryn,erms=on",
-   "level", 7);
-add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.9/off",
-   "-machine pc-i440fx-2.9 -cpu Conroe",
-   "level", 10);
-add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.9/on",
-   "-machine pc-i440fx-2.9 -cpu Conroe,erms=on",
-   "level", 10);
+if (qtest_has_machine("pc-i440fx-1.4")) {
+add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-1.4/off",
+   "-machine pc-i440fx-1.4 -cpu Nehalem",
+   "level", 2);
+add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-1.5/on",
+   "-machine pc-i440fx-1.4 -cpu Nehalem,smap=on",
+   "level", 7);
+}
+if (qtest_has_machine("pc-i440fx-2.3")) {
+add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.3/off",
+   "-machine pc-i440fx-2.3 -cpu Penryn",
+   "level", 4);
+add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.3/on",
+   "-machine pc-i440fx-2.3 -cpu Penryn,erms=on",
+   "level", 7);
+}
+if (qtest_has_machine("pc-i440fx-2.9")) {
+add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.9/off",
+   "-machine pc-i440fx-2.9 -cpu Conroe",
+   "level", 10);
+add_cpuid_test("x86/cpuid/auto-level7/pc-i440fx-2.9/on",
+   "-machine pc-i440fx-2.9 -cpu Conroe,erms=on",
+   "level", 10);
+}
 
 /*
  * xlevel doesn't have any feature that triggers auto-level
  * code on old machine-types.  Just check that the compat code
  * is working correctly:
  */
-add_cpuid_test("x86/cpuid/xlevel-compat/pc-i440fx-2.3",
-   "-machine pc-i440fx-2.3 -cpu SandyBridge",
-   "xlevel", 0x800a);
-add_cpuid_test("x86/cpuid/xlevel-compat/pc-i440fx-2.4/npt-off",
-   "-machine pc-i440fx-2.4 -cpu SandyBridge,",
-   "xlevel", 0x8008);
-add_cpuid_test("x86/cpuid/xlevel-compat/pc-i440fx-2.4/npt-on",
-   "-machine pc-i440fx-2.4 -cpu SandyBridge,svm=on,npt=on",
-   "xlevel", 0x8008);
+if (qtest_has_machine("pc-i

[PULL 4/8] tests/unit/test-util-sockets: Use g_file_open_tmp() to create temp file

2022-01-05 Thread Thomas Huth
From: Philippe Mathieu-Daudé 

Similarly to commit e63ed64c6d1 ("tests/qtest/virtio-net-failover:
Use g_file_open_tmp() to create temporary file"), avoid calling
g_test_rand_int() before g_test_init(): use g_file_open_tmp().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20211224234504.3413370-1-phi...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/unit/test-util-sockets.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index 72b9246529..896247e3ed 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -305,9 +305,11 @@ static void test_socket_unix_abstract(void)
 };
 int i;
 
+i = g_file_open_tmp("unix-XX", &addr.u.q_unix.path, NULL);
+g_assert_true(i >= 0);
+close(i);
+
 addr.type = SOCKET_ADDRESS_TYPE_UNIX;
-addr.u.q_unix.path = g_strdup_printf("unix-%d-%u",
- getpid(), g_random_int());
 addr.u.q_unix.has_abstract = true;
 addr.u.q_unix.abstract = true;
 addr.u.q_unix.has_tight = false;
-- 
2.27.0




[PATCH 0/1] Fix -device JSON support wrt hotplug

2022-01-05 Thread Daniel P . Berrangé
Libvirt switched to using -device JSON support, but we discovered in
testing that it is broken for hotplug, never sending DEVICE_DELETED
events. This is caused by a subtle refcount leak.

Daniel P. Berrangé (1):
  softmmu: fix device deletion events with -device JSON syntax

 qapi/qdev.json |  5 -
 softmmu/vl.c   |  4 +++-
 tests/qtest/device-plug-test.c | 19 +++
 3 files changed, 26 insertions(+), 2 deletions(-)

-- 
2.33.1





[PULL 7/8] gitlab-ci: Enable docs in the centos job

2022-01-05 Thread Thomas Huth
We just ran into a problem that the docs don't build on RHEL8 / CentOS 8
anymore. Seems like these distros are using one of the oldest Sphinx
versions that we still have to support. Thus enable the docs build in
the CI on CentOS so that such bugs don't slip in so easily again.

Message-Id: <20220104091240.160867-1-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Marc-André Lureau 
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/buildtest.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index 7e1cb0b3c2..12fb1130fe 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -164,7 +164,7 @@ build-system-centos:
   variables:
 IMAGE: centos8
 CONFIGURE_ARGS: --disable-nettle --enable-gcrypt --enable-fdt=system
---enable-modules --enable-trace-backends=dtrace
+  --enable-modules --enable-trace-backends=dtrace --enable-docs
 TARGETS: ppc64-softmmu or1k-softmmu s390x-softmmu
   x86_64-softmmu rx-softmmu sh4-softmmu nios2-softmmu
 MAKE_CHECK_ARGS: check-build
-- 
2.27.0




[PULL 6/8] docs/sphinx: fix compatibility with sphinx < 1.8

2022-01-05 Thread Thomas Huth
From: Marc-André Lureau 

SphinxDirective was added with sphinx 1.8 (2018-09-13).

Reported-by: Thomas Huth 
Signed-off-by: Marc-André Lureau 
Tested-by: Thomas Huth 
Message-Id: <20220104074649.1712440-1-marcandre.lur...@redhat.com>
Signed-off-by: Thomas Huth 
---
 docs/sphinx/fakedbusdoc.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/sphinx/fakedbusdoc.py b/docs/sphinx/fakedbusdoc.py
index a680b25754..d2c5079046 100644
--- a/docs/sphinx/fakedbusdoc.py
+++ b/docs/sphinx/fakedbusdoc.py
@@ -7,12 +7,12 @@
 # Author: Marc-André Lureau 
 """dbus-doc is a Sphinx extension that provides documentation from D-Bus 
XML."""
 
+from docutils.parsers.rst import Directive
 from sphinx.application import Sphinx
-from sphinx.util.docutils import SphinxDirective
 from typing import Any, Dict
 
 
-class FakeDBusDocDirective(SphinxDirective):
+class FakeDBusDocDirective(Directive):
 has_content = True
 required_arguments = 1
 
-- 
2.27.0




RE: [PATCH v2 1/5] RISC-V: larger and more consistent register set for 'info registers'

2022-01-05 Thread Schwarz, Konrad
> -Original Message-
> From: Richard Henderson 
> Sent: Tuesday, January 4, 2022 21:57
> Subject: Re: [PATCH v2 1/5] RISC-V: larger and more consistent register set 
> for 'info registers'
> 
> On 1/4/22 7:51 AM, Konrad Schwarz wrote:
> >   static const int dump_csrs[] = {
> > +
> > +#  if 0
> > +CSR_USTATUS,
> > +CSR_UIE,
> > +CSR_UTVEC,
> 
> Adding huge sections of #if 0 code is not acceptable.

I'm not sure on how to solve the dilemma of

* transgressing on QEMUs coding guidelines on the one side
  (large sections of commented out code)

* having `info registers' output a huge swath of CSRs,
  swamping the user and making the command impractical

I feel that providing some control at compile
time via `# if' conditional compilation is preferrable to just dumping
everything.  I could of course only list the CSRs that
are interesting to me, currently, but I thought it
would be better to list (almost) all of them and give at least
programmers an easy way to enable the blocks of CSRs
that are of interest to them.

Obviously, the best solution would be to extend the command to
add a filter argument, similar to GDB's `info registers'
(i.e. info registers XXX), but I don't know how to do that in QEMU and
it would work differently from other target architectures.

What would you suggest?


[PULL 8/8] docs/tools/qemu-trace-stap.rst: Do not hard-code the QEMU binary name

2022-01-05 Thread Thomas Huth
In downstream, we want to use a different name for the QEMU binary,
and some people might also use the docs for non-x86 binaries, that's
why we already created the |qemu_system| placeholder in the past.
Use it now in the stap trace doc, too.

Message-Id: <20220104103319.179870-1-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 docs/tools/qemu-trace-stap.rst | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/docs/tools/qemu-trace-stap.rst b/docs/tools/qemu-trace-stap.rst
index d53073b52b..2169ce5d17 100644
--- a/docs/tools/qemu-trace-stap.rst
+++ b/docs/tools/qemu-trace-stap.rst
@@ -46,19 +46,19 @@ The following commands are valid:
   any of the listed names. If no *PATTERN* is given, the all possible
   probes will be listed.
 
-  For example, to list all probes available in the ``qemu-system-x86_64``
+  For example, to list all probes available in the |qemu_system|
   binary:
 
-  ::
+  .. parsed-literal::
 
-$ qemu-trace-stap list qemu-system-x86_64
+$ qemu-trace-stap list |qemu_system|
 
   To filter the list to only cover probes related to QEMU's cryptographic
   subsystem, in a binary outside ``$PATH``
 
-  ::
+  .. parsed-literal::
 
-$ qemu-trace-stap list /opt/qemu/4.0.0/bin/qemu-system-x86_64 'qcrypto*'
+$ qemu-trace-stap list /opt/qemu/|version|/bin/|qemu_system| 'qcrypto*'
 
 .. option:: run OPTIONS BINARY PATTERN...
 
@@ -90,26 +90,26 @@ The following commands are valid:
 Restrict the tracing session so that it only triggers for the process
 identified by *PID*.
 
-  For example, to monitor all processes executing ``qemu-system-x86_64``
+  For example, to monitor all processes executing |qemu_system|
   as found on ``$PATH``, displaying all I/O related probes:
 
-  ::
+  .. parsed-literal::
 
-$ qemu-trace-stap run qemu-system-x86_64 'qio*'
+$ qemu-trace-stap run |qemu_system| 'qio*'
 
   To monitor only the QEMU process with PID 1732
 
-  ::
+  .. parsed-literal::
 
-$ qemu-trace-stap run --pid=1732 qemu-system-x86_64 'qio*'
+$ qemu-trace-stap run --pid=1732 |qemu_system| 'qio*'
 
   To monitor QEMU processes running an alternative binary outside of
   ``$PATH``, displaying verbose information about setup of the
   tracing environment:
 
-  ::
+  .. parsed-literal::
 
-$ qemu-trace-stap -v run /opt/qemu/4.0.0/qemu-system-x86_64 'qio*'
+$ qemu-trace-stap -v run /opt/qemu/|version|/bin/|qemu_system| 'qio*'
 
 See also
 
-- 
2.27.0




Re: [PATCH] MAINTAINERS: Improve the PowerPC machines section

2022-01-05 Thread Daniel Henrique Barboza




On 1/5/22 07:48, Thomas Huth wrote:

Add some documentation files to the corresponding machine sections
and mention the machine names in the section titles where it is
not so obvious (e.g. that "taihu" is a 405 machine).

Signed-off-by: Thomas Huth 
---


Reviewed-by: Daniel Henrique Barboza 


  MAINTAINERS | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f871d759fd..53cf0fdc00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1245,7 +1245,7 @@ F: hw/openrisc/openrisc_sim.c
  
  PowerPC Machines

  
-405
+405 (ref405ep and taihu)
  L: qemu-...@nongnu.org
  S: Orphan
  F: hw/ppc/ppc405_boards.c
@@ -1281,6 +1281,7 @@ New World (mac99)
  M: Mark Cave-Ayland 
  L: qemu-...@nongnu.org
  S: Odd Fixes
+F: docs/system/ppc/powermac.rst
  F: hw/ppc/mac_newworld.c
  F: hw/pci-host/uninorth.c
  F: hw/pci-bridge/dec.[hc]
@@ -1299,6 +1300,7 @@ Old World (g3beige)
  M: Mark Cave-Ayland 
  L: qemu-...@nongnu.org
  S: Odd Fixes
+F: docs/system/ppc/powermac.rst
  F: hw/ppc/mac_oldworld.c
  F: hw/pci-host/grackle.c
  F: hw/misc/macio/
@@ -1312,6 +1314,7 @@ PReP
  M: Hervé Poussineau 
  L: qemu-...@nongnu.org
  S: Maintained
+F: docs/system/ppc/prep.rst
  F: hw/ppc/prep.c
  F: hw/ppc/prep_systemio.c
  F: hw/ppc/rs6000_mc.c
@@ -1324,7 +1327,7 @@ F: include/hw/isa/pc87312.h
  F: include/hw/rtc/m48t59.h
  F: tests/avocado/ppc_prep_40p.py
  
-sPAPR

+sPAPR (pseries)
  M: Cédric Le Goater 
  M: Daniel Henrique Barboza 
  R: David Gibson 
@@ -1336,8 +1339,8 @@ F: include/hw/*/spapr*
  F: hw/*/xics*
  F: include/hw/*/xics*
  F: pc-bios/slof.bin
-F: docs/specs/ppc-spapr-hcalls.txt
-F: docs/specs/ppc-spapr-hotplug.txt
+F: docs/system/ppc/pseries.rst
+F: docs/specs/ppc-spapr-*
  F: tests/qtest/spapr*
  F: tests/qtest/libqos/*spapr*
  F: tests/qtest/rtas*
@@ -1348,6 +1351,7 @@ PowerNV (Non-Virtualized)
  M: Cédric Le Goater 
  L: qemu-...@nongnu.org
  S: Maintained
+F: docs/system/ppc/powernv.rst
  F: hw/ppc/pnv*
  F: hw/intc/pnv*
  F: hw/intc/xics_pnv.c




Re: [PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax

2022-01-05 Thread Thomas Huth

On 05/01/2022 13.38, Daniel P. Berrangé wrote:

The -device JSON syntax impl leaks a reference on the created
DeviceState instance. As a result when you hot-unplug the
device, the device_finalize method won't be called and thus
it will fail to emit the required DEVICE_DELETED event.

A 'json-cli' feature was previously added against the
'device_add' QMP command QAPI schema to indicated to mgmt
apps that -device supported JSON syntax. Given the hotplug
bug that feature flag is no unusable for its purpose, so
we add a new 'json-cli-hotplug' feature to indicate the
-device supports JSON without breaking hotplug.

Fixes: https://gitlab.com/qemu-project/qemu/-/issues/802


We're mostly using "Fixes:" to refer to previous commit IDs, and "Resolves:" 
for referring to bugs in the gitlab issue tracker, so in case you respin, 
I'd suggest to replace it (but both keywords should work to close issues, so 
it's just a cosmetical thing).



Signed-off-by: Daniel P. Berrangé 
---
  qapi/qdev.json |  5 -
  softmmu/vl.c   |  4 +++-
  tests/qtest/device-plug-test.c | 19 +++
  3 files changed, 26 insertions(+), 2 deletions(-)


Reviewed-by: Thomas Huth 




Re: [PATCH] docs/system/ppc: Merge the PEF information into the pseries page

2022-01-05 Thread Daniel Henrique Barboza




On 1/5/22 07:32, Thomas Huth wrote:

The Protected Execution Facility is only available with the pseries
machine, so let's merge the old ASCII text into the new RST file now.

Signed-off-by: Thomas Huth 
---


Well observed. Thanks for fixing it.


Reviewed-by: Daniel Henrique Barboza 



  docs/papr-pef.txt   | 30 --
  docs/system/ppc/pseries.rst | 33 +
  2 files changed, 33 insertions(+), 30 deletions(-)
  delete mode 100644 docs/papr-pef.txt

diff --git a/docs/papr-pef.txt b/docs/papr-pef.txt
deleted file mode 100644
index 72550e9bf8..00
--- a/docs/papr-pef.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-POWER (PAPR) Protected Execution Facility (PEF)
-===
-
-Protected Execution Facility (PEF), also known as Secure Guest support
-is a feature found on IBM POWER9 and POWER10 processors.
-
-If a suitable firmware including an Ultravisor is installed, it adds
-an extra memory protection mode to the CPU.  The ultravisor manages a
-pool of secure memory which cannot be accessed by the hypervisor.
-
-When this feature is enabled in QEMU, a guest can use ultracalls to
-enter "secure mode".  This transfers most of its memory to secure
-memory, where it cannot be eavesdropped by a compromised hypervisor.
-
-Launching
--
-
-To launch a guest which will be permitted to enter PEF secure mode:
-
-# ${QEMU} \
--object pef-guest,id=pef0 \
--machine confidential-guest-support=pef0 \
-...
-
-Live Migration
-
-
-Live migration is not yet implemented for PEF guests.  For
-consistency, we currently prevent migration if the PEF feature is
-enabled, whether or not the guest has actually entered secure mode.
diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst
index 72e315eff6..16394fa521 100644
--- a/docs/system/ppc/pseries.rst
+++ b/docs/system/ppc/pseries.rst
@@ -230,6 +230,39 @@ nested. Combinations not shown in the table are not 
available.
  
  .. [3] Introduced on Power10 machines.
  
+

+POWER (PAPR) Protected Execution Facility (PEF)
+---
+
+Protected Execution Facility (PEF), also known as Secure Guest support
+is a feature found on IBM POWER9 and POWER10 processors.
+
+If a suitable firmware including an Ultravisor is installed, it adds
+an extra memory protection mode to the CPU.  The ultravisor manages a
+pool of secure memory which cannot be accessed by the hypervisor.
+
+When this feature is enabled in QEMU, a guest can use ultracalls to
+enter "secure mode".  This transfers most of its memory to secure
+memory, where it cannot be eavesdropped by a compromised hypervisor.
+
+Launching
+^
+
+To launch a guest which will be permitted to enter PEF secure mode::
+
+  $ qemu-system-ppc64 \
+  -object pef-guest,id=pef0 \
+  -machine confidential-guest-support=pef0 \
+  ...
+
+Live Migration
+^^
+
+Live migration is not yet implemented for PEF guests.  For
+consistency, QEMU currently prevents migration if the PEF feature is
+enabled, whether or not the guest has actually entered secure mode.
+
+
  Maintainer contact information
  --
  




RE: [PATCH v2 3/5] RISC-V: 'info gmem' to show hypervisor guest -> physical address translations

2022-01-05 Thread Schwarz, Konrad
> -Original Message-
> From: Alistair Francis 
> Sent: Tuesday, January 4, 2022 23:03
> On Wed, Jan 5, 2022 at 1:55 AM Konrad Schwarz
>  wrote:
> >
> > This is analog to the existing 'info mem' command and is implemented
> > using the same machinery.

> >  hmp-commands-info.hx |  16 +
> >  include/monitor/hmp-target.h |   2 +
> >  target/riscv/monitor.c   | 135 +--
> >  3 files changed, 117 insertions(+), 36 deletions(-)
> >
> > diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> > index 407a1da800..fa519f0129 100644
> > --- a/hmp-commands-info.hx
> > +++ b/hmp-commands-info.hx
> > @@ -237,6 +237,22 @@ SRST
> >  Show the active virtual memory mappings.
> >  ERST
> >
> > +#if defined TARGET_RISCV
> > +{
> > +.name   = "gmem",
> > +.args_type  = "",
> > +.params = "",
> > +.help   = "show the hypervisor guest's physical address"
> > +   " translation",
> > +.cmd= hmp_info_gmem,
> > +},
> > +#endif
> 
> I don't think we want RISC-V specific commands. Could we not just
> extend `info mem` instead?

Considering that the similar commands `info tlb' and `info mem'
are target dependent (i.e. specific to I386, SH4, SPARC,
PCC, XTENSA and M68K, respectively to I386 and RISC-V),
I honestly do not see a problem here.

Obviously, other architectures are free to add their own implementation
of the `info gmem' functionality, so the list of architectures
supporting this command might grow in future.  The command itself
is not specific to RISC-V.

PS: I will be taking your other points to heart on the re-roll,
I just wanted to get this out of the way before attempting it.

Regards,
Konrad


RE: [PATCH v2 4/5] RISC-V: Typed CSRs in gdbserver

2022-01-05 Thread Schwarz, Konrad
Hi,

> -Original Message-
> From: Alistair Francis 
> Sent: Tuesday, January 4, 2022 23:12
> To: Schwarz, Konrad (T CED SES-DE) 
> Subject: Re: [PATCH v2 4/5] RISC-V: Typed CSRs in gdbserver
> 
> On Wed, Jan 5, 2022 at 1:56 AM Konrad Schwarz
>  wrote:
> > diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> > index 9f41954894..557b4afe0e 100644
> > --- a/target/riscv/csr.c
> > +++ b/target/riscv/csr.c
> > @@ -3,6 +3,7 @@
> >   *
> >   * Copyright (c) 2016-2017 Sagar Karandikar, sag...@eecs.berkeley.edu
> >   * Copyright (c) 2017-2018 SiFive, Inc.
> > + * Copyright (c) 2021 Siemens AG, konrad.schw...@siemens.com
> 
> Please don't add these to existing files. In this case you have just
> added a newline to this file

Sorry, I don't know how that slipped through.
I originally didn't have any copyright messages, to which my company objected,
and I guess I overcompensated.
 
> diff --git a/target/riscv/csr32-op-gdbserver.h 
> b/target/riscv/csr32-op-gdbserver.h
> > new file mode 100644
> > index 00..e8ec527f23
> > --- /dev/null
> > +++ b/target/riscv/csr32-op-gdbserver.h
> > @@ -0,0 +1,109 @@
> > +/* Copyright (c) 2021 Siemens AG, konrad.schw...@siemens.com */
> 
> All of these files should have the usual file boiler plate

OK, I'll try to figure out something.

> > +#if !defined(CONFIG_USER_ONLY)
> > +#  ifdef TARGET_RISCV64
> > +#include "csr64-op-gdbserver.h"
> > +#  elif defined TARGET_RISCV64
> > +#include "csr32-op-gdbserver.h"
> 
> This doesn't look right. `if defined TARGET_RISCV64` -> `include
> "csr32-op-gdbserver.h"`?

You are quite right. 

> Also this should be dynamic instead of based on the build time CPU, as
> the user could use a 32-bit CPU on a 64-bit target build.

I'm not sure.  The machine itself is still a 64-bit machine; its CSRs are 64 
bits long.
`csr.c', which implements the CSRs contains an instance of # ifdef 
TARGET_RISCV64,
so that part of the implementation is not dynamic either.

Also, someone who is developing 32-bit system software can easily
sidestep the issue by using the 32-bit target.

Regards
Konrad


Re: [PATCH 1/2] target/ppc: Add popcntb instruction to POWER5+ processors

2022-01-05 Thread Fabiano Rosas
Cédric Le Goater  writes:

> popcntb instruction was added in ISA v2.02. Add support for POWER5+
> processors since they implement ISA v2.03.
>
> PPC970 CPUs implement v2.01 and do not support popcntb.
>
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Fabiano Rosas 



Re: [PATCH 2/2] spapr: Fix support of POWER5+ processors

2022-01-05 Thread Fabiano Rosas
Cédric Le Goater  writes:

> POWER5+ (ISA v2.03) processors are supported by the pseries machine
> but they do not have Altivec instructions. Do not advertise support
> for it in the DT.
>
> To be noted that this test is in contradiction with the assert in
> cap_vsx_apply().
>
> Signed-off-by: Cédric Le Goater 

Tested-by: Fabiano Rosas 



[PATCH v1 05/34] ci: explicitly skip I/O tests on alpine

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

The block I/O tests don't work on Alpine because their alternative libc
impl emits different strings for errnos, which breaks the expected
output matching. e.g.

=== IO: pattern 102
 wrote 512/512 bytes at offset 512
 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-qemu-img: Error while reading offset 0 of 
blkdebug:TEST_DIR/blkdebug.conf:TEST_DIR/t.IMGFMT: Input/output error
+qemu-img: Error while reading offset 0 of 
blkdebug:TEST_DIR/blkdebug.conf:TEST_DIR/t.IMGFMT: I/O error
 4
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 Formatting 'TEST_DIR/t.IMGFMT.2', fmt=IMGFMT size=0

Currently the I/O tests are skipped as a side effect of the Alpine image
containing a minimal busybox 'sed' binary, rather than GNU sed. This is
a fragile assumption that will be invalidated when the dockerfile is
changed to be autogenerated from a standardized package list that
includes GNU sed.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-6-berra...@redhat.com>
---
 .gitlab-ci.d/buildtest.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index 7e1cb0b3c2..e77aec873e 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -24,7 +24,7 @@ check-system-alpine:
   artifacts: true
   variables:
 IMAGE: alpine
-MAKE_CHECK_ARGS: check
+MAKE_CHECK_ARGS: check-unit check-qtest
 
 avocado-system-alpine:
   extends: .avocado_test_job_template
-- 
2.30.2




[PATCH v1 02/34] spice: Update QXLInterface for spice >= 0.15.0

2022-01-05 Thread Alex Bennée
From: John Snow 

spice updated the spelling (and arguments) of "attache_worker" in
0.15.0. Update QEMU to match, preventing -Wdeprecated-declarations
compilations from reporting build errors.

See also:
https://gitlab.freedesktop.org/spice/spice/-/commit/974692bda1e77af92b71ed43b022439448492cb9

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Signed-off-by: John Snow 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-3-berra...@redhat.com>
---
 include/ui/qemu-spice.h |  6 ++
 hw/display/qxl.c| 14 +-
 ui/spice-display.c  | 11 +++
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/include/ui/qemu-spice.h b/include/ui/qemu-spice.h
index 71ecd6cfd1..21fe195e18 100644
--- a/include/ui/qemu-spice.h
+++ b/include/ui/qemu-spice.h
@@ -40,6 +40,12 @@ int qemu_spice_migrate_info(const char *hostname, int port, 
int tls_port,
 #define SPICE_NEEDS_SET_MM_TIME 0
 #endif
 
+#if defined(SPICE_SERVER_VERSION) && (SPICE_SERVER_VERSION >= 0x000f00)
+#define SPICE_HAS_ATTACHED_WORKER 1
+#else
+#define SPICE_HAS_ATTACHED_WORKER 0
+#endif
+
 #else  /* CONFIG_SPICE */
 
 #include "qemu/error-report.h"
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index e2d6e317da..1f9ad31943 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -517,13 +517,20 @@ static int qxl_track_command(PCIQXLDevice *qxl, struct 
QXLCommandExt *ext)
 
 /* spice display interface callbacks */
 
-static void interface_attach_worker(QXLInstance *sin, QXLWorker *qxl_worker)
+static void interface_attached_worker(QXLInstance *sin)
 {
 PCIQXLDevice *qxl = container_of(sin, PCIQXLDevice, ssd.qxl);
 
 trace_qxl_interface_attach_worker(qxl->id);
 }
 
+#if !(SPICE_HAS_ATTACHED_WORKER)
+static void interface_attach_worker(QXLInstance *sin, QXLWorker *qxl_worker)
+{
+interface_attached_worker(sin);
+}
+#endif
+
 static void interface_set_compression_level(QXLInstance *sin, int level)
 {
 PCIQXLDevice *qxl = container_of(sin, PCIQXLDevice, ssd.qxl);
@@ -1131,7 +1138,12 @@ static const QXLInterface qxl_interface = {
 .base.major_version  = SPICE_INTERFACE_QXL_MAJOR,
 .base.minor_version  = SPICE_INTERFACE_QXL_MINOR,
 
+#if SPICE_HAS_ATTACHED_WORKER
+.attached_worker = interface_attached_worker,
+#else
 .attache_worker  = interface_attach_worker,
+#endif
+
 .set_compression_level   = interface_set_compression_level,
 #if SPICE_NEEDS_SET_MM_TIME
 .set_mm_time = interface_set_mm_time,
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 1043f47f94..a3078adf91 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -500,10 +500,17 @@ void qemu_spice_display_refresh(SimpleSpiceDisplay *ssd)
 
 /* spice display interface callbacks */
 
+#if SPICE_HAS_ATTACHED_WORKER
+static void interface_attached_worker(QXLInstance *sin)
+{
+/* nothing to do */
+}
+#else
 static void interface_attach_worker(QXLInstance *sin, QXLWorker *qxl_worker)
 {
 /* nothing to do */
 }
+#endif
 
 static void interface_set_compression_level(QXLInstance *sin, int level)
 {
@@ -702,7 +709,11 @@ static const QXLInterface dpy_interface = {
 .base.major_version  = SPICE_INTERFACE_QXL_MAJOR,
 .base.minor_version  = SPICE_INTERFACE_QXL_MINOR,
 
+#if SPICE_HAS_ATTACHED_WORKER
+.attached_worker = interface_attached_worker,
+#else
 .attache_worker  = interface_attach_worker,
+#endif
 .set_compression_level   = interface_set_compression_level,
 #if SPICE_NEEDS_SET_MM_TIME
 .set_mm_time = interface_set_mm_time,
-- 
2.30.2




[PATCH v1 01/34] ui: avoid compiler warnings from unused clipboard info variable

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

With latest clang 13.0.0 we get

../ui/clipboard.c:47:34: error: variable 'old' set but not used 
[-Werror,-Wunused-but-set-variable]
g_autoptr(QemuClipboardInfo) old = NULL;
 ^

The compiler can't tell that we only declared this variable in
order to get the side effect of free'ing it when out of scope.

This pattern is a little dubious for a use of g_autoptr, so
rewrite the code to avoid it.

Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
[AJB: fix merge conflict]
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-2-berra...@redhat.com>
---
 ui/clipboard.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/ui/clipboard.c b/ui/clipboard.c
index 82572ea116..5f15cf853d 100644
--- a/ui/clipboard.c
+++ b/ui/clipboard.c
@@ -62,13 +62,11 @@ void qemu_clipboard_update(QemuClipboardInfo *info)
 .type = QEMU_CLIPBOARD_UPDATE_INFO,
 .info = info,
 };
-g_autoptr(QemuClipboardInfo) old = NULL;
-
 assert(info->selection < QEMU_CLIPBOARD_SELECTION__COUNT);
 
 notifier_list_notify(&clipboard_notifiers, ¬ify);
 
-old = cbinfo[info->selection];
+qemu_clipboard_info_unref(cbinfo[info->selection]);
 cbinfo[info->selection] = qemu_clipboard_info_ref(info);
 }
 
-- 
2.30.2




[PATCH v1 00/34] testing/next and other misc fixes

2022-01-05 Thread Alex Bennée
Hi,

Happy New Year QEMU developers. To get our new year off to a quick
start here are a bunch of testing and testing adjacent updates. There
are some miscellaneous updates touching linux-user, ARM virt, and
various other minor code tweaks and cleanups. If maintainers want to
take via their own trees then please grab them otherwise I'm happy to
include them in my next pull request.

Everything is pretty well reviewed except:

 - tests/avocado: add :avocado: tags for some tests
 - linux-user/elfload: add extra logging for hole finding
 - hw/arm: add control knob to disable kaslr_seed via DTB (2 acks, 1 sobs)

Alex Bennée (7):
  hw/arm: add control knob to disable kaslr_seed via DTB
  monitor: move x-query-profile into accel/tcg to fix build
  docs/devel: update C standard to C11
  docs/devel: more documentation on the use of suffixes
  linux-user/elfload: add extra logging for hole finding
  linux-user: don't adjust base of found hole
  tests/avocado: add :avocado: tags for some tests

Brad Smith (1):
  FreeBSD: Upgrade to 12.3 release

Daniel P. Berrangé (17):
  ui: avoid compiler warnings from unused clipboard info variable
  meson: require liburing >= 0.3
  ui: avoid warnings about directdb on Alpine / musl libc
  ci: explicitly skip I/O tests on alpine
  tests/docker: switch fedora image to release 35
  tests: integrate lcitool for generating build env manifests
  tests/docker: auto-generate centos8.docker with lcitool
  tests/docker: auto-generate fedora.docker with lcitool
  tests/docker: auto-generate ubuntu1804.docker with lcitool
  tests/docker: auto-generate ubuntu2004.docker with lcitool
  tests/docker: auto-generate opensuse-leap.docker with lcitool
  tests/docker: remove ubuntu.docker container
  .gitlab-ci.d/cirrus: auto-generate variables with lcitool
  tests/docker: updates to alpine package list
  tests/docker: fix sorting of alpine image package lists
  tests/docker: fully expand the alpine package list
  tests/docker: auto-generate alpine.docker with lcitool

John Snow (1):
  spice: Update QXLInterface for spice >= 0.15.0

Marc-André Lureau (1):
  docs/sphinx: fix compatibility with sphinx < 1.8

Paolo Bonzini (2):
  tests/tcg: use CONFIG_LINUX_USER, not CONFIG_LINUX
  docker: include bison in debian-tricore-cross

Richard Henderson (2):
  tests/tcg/multiarch: Read fp flags before printf
  test/tcg/ppc64le: Add float reference files

Stefan Hajnoczi (1):
  tests/docker: add libfuse3 development headers

Thomas Huth (2):
  gitlab-ci: Enable docs in the centos job
  linux-user: Remove the deprecated ppc64abi32 target

 docs/about/deprecated.rst |   7 -
 docs/about/removed-features.rst   |   8 +
 docs/devel/style.rst  |  14 +-
 docs/devel/testing.rst| 104 ++-
 docs/sphinx/fakedbusdoc.py|   4 +-
 docs/system/arm/virt.rst  |   7 +
 docs/user/main.rst|   1 -
 configure |  29 +-
 Makefile  |   2 +
 configs/targets/ppc64abi32-linux-user.mak |   8 -
 meson.build   |   3 +-
 qapi/machine.json |   1 +
 include/glib-compat.h |   6 +-
 include/hw/arm/virt.h |   1 +
 include/ui/qemu-spice.h   |   6 +
 include/ui/sdl2.h |  11 +
 linux-user/ppc/target_syscall.h   |   4 +-
 linux-user/syscall_defs.h |   6 +-
 accel/tcg/cpu-exec.c  |  31 +
 hw/arm/virt.c |  32 +-
 hw/display/qxl.c  |  14 +-
 linux-user/elfload.c  |  27 +-
 linux-user/ppc/signal.c   |  11 +-
 monitor/qmp-cmds.c|  31 -
 tests/tcg/multiarch/float_convs.c |   2 +-
 tests/tcg/multiarch/float_madds.c |   2 +-
 ui/clipboard.c|   4 +-
 ui/spice-display.c|  11 +
 .gitlab-ci.d/buildtest.yml|  31 +-
 .gitlab-ci.d/cirrus.yml   |   5 +-
 .gitlab-ci.d/cirrus/freebsd-12.vars   |  11 +-
 .gitlab-ci.d/cirrus/freebsd-13.vars   |  11 +-
 .gitlab-ci.d/cirrus/macos-11.vars |  11 +-
 .gitlab-ci.d/containers.yml   |   5 -
 .gitmodules   |   3 +
 hmp-commands-info.hx  |   2 +
 tests/avocado/empty_cpu_model.py  |   3 +
 tests/avocado/info_usernet.py |   3 +
 tests/avocado/migration.py|   1 +
 tests/avocado/version.py  |   1 +
 tests/avocado/vnc.py  |   1 +
 tests/docker/dockerfiles/alpine.docker| 176 ++--
 tests/docker/dockerfiles/centos8.docker   | 244 +++---
 .../dockerfiles/debian-p

[PATCH v1 06/34] tests/docker: switch fedora image to release 35

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

The Fedora 33 release is shortly end of life. Switch to the newest
Fedora 35 to maximise lifespan until we need to update again.

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-7-berra...@redhat.com>
---
 tests/docker/dockerfiles/fedora.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index c6fd7e1113..855aefaac5 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,4 +1,4 @@
-FROM registry.fedoraproject.org/fedora:33
+FROM registry.fedoraproject.org/fedora:35
 
 # Please keep this list sorted alphabetically
 ENV PACKAGES \
-- 
2.30.2




[PATCH v1 11/34] tests/docker: auto-generate ubuntu2004.docker with lcitool

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

This commit is best examined using the "-b" option to diff.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-12-berra...@redhat.com>
---
 tests/docker/dockerfiles/ubuntu2004.docker | 257 -
 tests/lcitool/refresh  |   9 +-
 2 files changed, 151 insertions(+), 115 deletions(-)

diff --git a/tests/docker/dockerfiles/ubuntu2004.docker 
b/tests/docker/dockerfiles/ubuntu2004.docker
index 15a026be09..40402b91fe 100644
--- a/tests/docker/dockerfiles/ubuntu2004.docker
+++ b/tests/docker/dockerfiles/ubuntu2004.docker
@@ -1,119 +1,148 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool dockerfile ubuntu-2004 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
 FROM docker.io/library/ubuntu:20.04
-ENV PACKAGES \
-bc \
-bsdmainutils \
-bzip2 \
-ca-certificates \
-ccache \
-clang \
-dbus \
-debianutils \
-diffutils \
-exuberant-ctags \
-findutils \
-g++ \
-gcc \
-gcovr \
-genisoimage \
-gettext \
-git \
-hostname \
-libaio-dev \
-libasan5 \
-libasound2-dev \
-libattr1-dev \
-libbrlapi-dev \
-libbz2-dev \
-libc6-dev \
-libcacard-dev \
-libcap-ng-dev \
-libcapstone-dev \
-libcurl4-gnutls-dev \
-libdaxctl-dev \
-libdrm-dev \
-libepoxy-dev \
-libfdt-dev \
-libffi-dev \
-libgbm-dev \
-libgcrypt20-dev \
-libglib2.0-dev \
-libglusterfs-dev \
-libgnutls28-dev \
-libgtk-3-dev \
-libibverbs-dev \
-libiscsi-dev \
-libjemalloc-dev \
-libjpeg-turbo8-dev \
-liblttng-ust-dev \
-liblzo2-dev \
-libncursesw5-dev \
-libnfs-dev \
-libnuma-dev \
-libpam0g-dev \
-libpixman-1-dev \
-libpmem-dev \
-libpng-dev \
-libpulse-dev \
-librbd-dev \
-librdmacm-dev \
-libsasl2-dev \
-libsdl2-dev \
-libsdl2-image-dev \
-libseccomp-dev \
-libselinux-dev \
-libslirp-dev \
-libsnappy-dev \
-libspice-protocol-dev \
-libspice-server-dev \
-libssh-dev \
-libsystemd-dev \
-libtasn1-6-dev \
-libtest-harness-perl \
-libubsan1 \
-libudev-dev \
-libusb-1.0-0-dev \
-libusbredirhost-dev \
-libvdeplug-dev \
-libvirglrenderer-dev \
-libvte-2.91-dev \
-libxen-dev \
-libxml2-dev \
-libzstd-dev \
-llvm \
-locales \
-make \
-multipath-tools \
-ncat \
-nettle-dev \
-ninja-build \
-openssh-client \
-perl-base \
-pkgconf \
-python3 \
-python3-numpy \
-python3-opencv \
-python3-pillow \
-python3-pip \
-python3-setuptools \
-python3-sphinx \
-python3-sphinx-rtd-theme \
-python3-venv \
-python3-wheel \
-python3-yaml \
-rpm2cpio \
-sed \
-sparse \
-systemtap-sdt-dev \
-tar \
-tesseract-ocr \
-tesseract-ocr-eng \
-texinfo \
-xfslibs-dev \
-zlib1g-dev
-RUN apt-get update && \
-DEBIAN_FRONTEND=noninteractive apt-get -y install $PACKAGES
-RUN dpkg -l $PACKAGES | sort > /packages.txt
 
+RUN export DEBIAN_FRONTEND=noninteractive && \
+apt-get update && \
+apt-get install -y eatmydata && \
+eatmydata apt-get dist-upgrade -y && \
+eatmydata apt-get install --no-install-recommends -y \
+bash \
+bc \
+bsdmainutils \
+bzip2 \
+ca-certificates \
+ccache \
+clang \
+dbus \
+debianutils \
+diffutils \
+exuberant-ctags \
+findutils \
+g++ \
+gcc \
+gcovr \
+genisoimage \
+gettext \
+git \
+hostname \
+libaio-dev \
+libasan5 \
+libasound2-dev \
+libattr1-dev \
+libbrlapi-dev \
+libbz2-dev \
+libc6-dev \
+libcacard-dev \
+libcap-ng-dev \
+libcapstone-dev \
+libcurl4-gnutls-dev \
+libdaxctl-dev \
+libdrm-dev \
+libepoxy-dev \
+libfdt-dev \
+libffi-dev \
+libgbm-dev \
+libgcrypt20-dev \
+libglib2.0-dev \
+libglusterfs-dev \
+libgnutls28-dev \
+libgtk-3-dev \
+libibverbs-dev \
+libiscsi-dev \
+libjemalloc-dev \
+libjpeg-turbo8-dev \
+liblttng-ust-dev \
+liblzo2-dev \
+libncursesw5-dev \
+libnfs-dev \
+libnuma-dev \
+libpam0g-dev \
+libpcre2-dev \
+libpixman-1-dev \
+libpmem-dev \
+libpng-dev \
+libpulse-dev \
+librbd-dev \
+librdmacm-dev \
+libsasl2-dev \
+libsdl2-dev \
+libsdl2-

[PATCH v1 03/34] meson: require liburing >= 0.3

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

openSUSE Leap 15.2 ships with liburing == 0.2 against which QEMU fails
to build.

../util/fdmon-io_uring.c: In function ‘fdmon_io_uring_need_wait’:
../util/fdmon-io_uring.c:305:9: error: implicit declaration of function 
‘io_uring_sq_ready’; did you mean ‘io_uring_cq_ready’? 
[-Werror=implicit-function-declaration]
 if (io_uring_sq_ready(&ctx->fdmon_io_uring)) {
 ^
 io_uring_cq_ready

This method was introduced in liburing 0.3, so set that as a minimum
requirement.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-4-berra...@redhat.com>
---
 meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 53065e96ec..0e52f54b10 100644
--- a/meson.build
+++ b/meson.build
@@ -440,7 +440,8 @@ if not get_option('linux_aio').auto() or have_block
 endif
 linux_io_uring = not_found
 if not get_option('linux_io_uring').auto() or have_block
-  linux_io_uring = dependency('liburing', required: 
get_option('linux_io_uring'),
+  linux_io_uring = dependency('liburing', version: '>=0.3',
+  required: get_option('linux_io_uring'),
   method: 'pkg-config', kwargs: static_kwargs)
 endif
 libxml2 = not_found
-- 
2.30.2




[PATCH v1 27/34] tests/avocado: add :avocado: tags for some tests

2022-01-05 Thread Alex Bennée
This stops a bunch of tests failing because of a lack of
"./qemu-system-x86-64" in a build directory where you have configured
only one non-default target. I suspect what we really need is:

:avocado: tags=arch:host

to be properly multi-arch safe.

Signed-off-by: Alex Bennée 
---
 tests/avocado/empty_cpu_model.py | 3 +++
 tests/avocado/info_usernet.py| 3 +++
 tests/avocado/migration.py   | 1 +
 tests/avocado/version.py | 1 +
 tests/avocado/vnc.py | 1 +
 5 files changed, 9 insertions(+)

diff --git a/tests/avocado/empty_cpu_model.py b/tests/avocado/empty_cpu_model.py
index 22f504418d..ffe27780a3 100644
--- a/tests/avocado/empty_cpu_model.py
+++ b/tests/avocado/empty_cpu_model.py
@@ -11,6 +11,9 @@
 
 class EmptyCPUModel(QemuSystemTest):
 def test(self):
+"""
+:avocado: tags=arch:x86_64
+"""
 self.vm.add_args('-S', '-display', 'none', '-machine', 'none', '-cpu', 
'')
 self.vm.set_qmp_monitor(enabled=False)
 self.vm.launch()
diff --git a/tests/avocado/info_usernet.py b/tests/avocado/info_usernet.py
index dc01f74150..bafbc0e23e 100644
--- a/tests/avocado/info_usernet.py
+++ b/tests/avocado/info_usernet.py
@@ -16,6 +16,9 @@
 class InfoUsernet(QemuSystemTest):
 
 def test_hostfwd(self):
+"""
+:avocado: tags=arch:x86_64
+"""
 self.vm.add_args('-netdev', 'user,id=vnet,hostfwd=:127.0.0.1:0-:22')
 self.vm.launch()
 res = self.vm.command('human-monitor-command',
diff --git a/tests/avocado/migration.py b/tests/avocado/migration.py
index 584d6ef53f..4e5516f425 100644
--- a/tests/avocado/migration.py
+++ b/tests/avocado/migration.py
@@ -22,6 +22,7 @@
 class Migration(QemuSystemTest):
 """
 :avocado: tags=migration
+:avocado: tags=arch:x86_64
 """
 
 timeout = 10
diff --git a/tests/avocado/version.py b/tests/avocado/version.py
index ded7f039c1..be794b9354 100644
--- a/tests/avocado/version.py
+++ b/tests/avocado/version.py
@@ -15,6 +15,7 @@
 class Version(QemuSystemTest):
 """
 :avocado: tags=quick
+:avocado: tags=arch:x86_64
 """
 def test_qmp_human_info_version(self):
 self.vm.add_args('-nodefaults')
diff --git a/tests/avocado/vnc.py b/tests/avocado/vnc.py
index 096432988f..1f80647414 100644
--- a/tests/avocado/vnc.py
+++ b/tests/avocado/vnc.py
@@ -14,6 +14,7 @@
 class Vnc(QemuSystemTest):
 """
 :avocado: tags=vnc,quick
+:avocado: tags=arch:x86_64
 """
 def test_no_vnc(self):
 self.vm.add_args('-nodefaults', '-S')
-- 
2.30.2




[PATCH v1 07/34] tests: integrate lcitool for generating build env manifests

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

This introduces

  https://gitlab.com/libvirt/libvirt-ci

as a git submodule at tests/lcitool/libvirt-ci

The 'lcitool' program within this submodule will be used to
automatically generate build environment manifests from a definition
of requirements in tests/lcitool/projects/qemu.yml

It will ultimately be capable of generating

 - Dockerfiles
 - Package lists for installation in VMs
 - Variables for configuring Cirrus CI environments

When a new build pre-requisite is needed for QEMU, if this package
is not currently known to libvirt-ci, it must first be added to the
'mappings.yml' file in the above git repo.

Then the submodule can be updated and the build pre-requisite added
to the tests/lcitool/projects/qemu.yml file. Now all the build env
manifests can be re-generated using  'make lcitool-refresh'

This ensures that when a new build pre-requisite is introduced, it
is added to all the different OS containers, VMs and Cirrus CI
environments consistently.

It also facilitates the addition of containers targetting new distros
or updating existing containers to new versions of the same distro,
where packages might have been renamed.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-8-berra...@redhat.com>
---
 docs/devel/testing.rst  | 104 -
 Makefile|   2 +
 .gitmodules |   3 +
 tests/lcitool/Makefile.include  |  17 +
 tests/lcitool/libvirt-ci|   1 +
 tests/lcitool/projects/qemu.yml | 115 
 tests/lcitool/refresh   |  67 +++
 7 files changed, 306 insertions(+), 3 deletions(-)
 create mode 100644 tests/lcitool/Makefile.include
 create mode 16 tests/lcitool/libvirt-ci
 create mode 100644 tests/lcitool/projects/qemu.yml
 create mode 100755 tests/lcitool/refresh

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 755343c7dd..d744b5909c 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -382,14 +382,112 @@ Along with many other images, the ``centos8`` image is 
defined in a Dockerfile
 in ``tests/docker/dockerfiles/``, called ``centos8.docker``. ``make 
docker-help``
 command will list all the available images.
 
-To add a new image, simply create a new ``.docker`` file under the
-``tests/docker/dockerfiles/`` directory.
-
 A ``.pre`` script can be added beside the ``.docker`` file, which will be
 executed before building the image under the build context directory. This is
 mainly used to do necessary host side setup. One such setup is ``binfmt_misc``,
 for example, to make qemu-user powered cross build containers work.
 
+Most of the existing Dockerfiles were written by hand, simply by creating a
+a new ``.docker`` file under the ``tests/docker/dockerfiles/`` directory.
+This has led to an inconsistent set of packages being present across the
+different containers.
+
+Thus going forward, QEMU is aiming to automatically generate the Dockerfiles
+using the ``lcitool`` program provided by the ``libvirt-ci`` project:
+
+  https://gitlab.com/libvirt/libvirt-ci
+
+In that project, there is a ``mappings.yml`` file defining the distro native
+package names for a wide variety of third party projects. This is processed
+in combination with a project defined list of build pre-requisites to determine
+the list of native packages to install on each distribution. This can be used
+to generate dockerfiles, VM package lists and Cirrus CI variables needed to
+setup build environments across OS distributions with a consistent set of
+packages present.
+
+When preparing a patch series that adds a new build pre-requisite to QEMU,
+updates to various lcitool data files may be required.
+
+
+Adding new build pre-requisites
+^^^
+
+In the simple case where the pre-requisite is already known to ``libvirt-ci``
+the following steps are needed
+
+ * Edit ``tests/lcitool/projects/qemu.yml`` and add the pre-requisite
+
+ * Run ``make lcitool-refresh`` to re-generate all relevant build environment
+   manifests
+
+In some cases ``libvirt-ci`` will not know about the build pre-requisite and
+thus some extra preparation steps will be required first
+
+ * Fork the ``libvirt-ci`` project on gitlab
+
+ * Edit the ``mappings.yml`` change to add an entry for the new build
+   prerequisite, listing its native package name on as many OS distros
+   as practical.
+
+ * Commit the ``mappings.yml`` change and submit a merge request to
+   the ``libvirt-ci`` project, noting in the description that this
+   is a new build pre-requisite desired for use with QEMU
+
+ * CI pipeline will run to validate that the changes to ``mappings.yml``
+   are correct, by attempting to install the newly listed package on
+   all OS distributions supported by ``libvirt-ci``.
+
+ * Once the merge request is accepted, go back to QEMU and update
+   th

[PATCH v1 28/34] tests/tcg/multiarch: Read fp flags before printf

2022-01-05 Thread Alex Bennée
From: Richard Henderson 

We need to read the floating-point flags before printf may do
other floating-point operations which may affect the flags.

Hexagon reference files regenerated by Taylor Simpson.

Signed-off-by: Taylor Simpson 
Signed-off-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 
Reviewed-by: Taylor Simpson 
Message-Id: <1639510781-3790-1-git-send-email-tsimp...@quicinc.com>
Message-Id: <20211224035541.2159966-2-richard.hender...@linaro.org>
---
 tests/tcg/multiarch/float_convs.c |   2 +-
 tests/tcg/multiarch/float_madds.c |   2 +-
 tests/tcg/hexagon/float_convs.ref | 152 +++---
 tests/tcg/hexagon/float_madds.ref |  48 +-
 4 files changed, 102 insertions(+), 102 deletions(-)

diff --git a/tests/tcg/multiarch/float_convs.c 
b/tests/tcg/multiarch/float_convs.c
index e9be75c2d5..2e4fa55324 100644
--- a/tests/tcg/multiarch/float_convs.c
+++ b/tests/tcg/multiarch/float_convs.c
@@ -51,8 +51,8 @@ static void convert_single_to_double(float input)
 
 output = input;
 
-out_fmt = fmt_f64(output);
 flag_fmt = fmt_flags();
+out_fmt = fmt_f64(output);
 printf("  to double: %s (%s)\n", out_fmt, flag_fmt);
 free(out_fmt);
 free(flag_fmt);
diff --git a/tests/tcg/multiarch/float_madds.c 
b/tests/tcg/multiarch/float_madds.c
index e422608ccd..4888f8641f 100644
--- a/tests/tcg/multiarch/float_madds.c
+++ b/tests/tcg/multiarch/float_madds.c
@@ -54,8 +54,8 @@ static void print_result(float r, int j, int k)
 {
 char *r_fmt, *flag_fmt;
 
-r_fmt = fmt_f32(r);
 flag_fmt = fmt_flags();
+r_fmt = fmt_f32(r);
 
 printf("res: %s flags=%s (%d/%d)\n", r_fmt, flag_fmt, j, k);
 
diff --git a/tests/tcg/hexagon/float_convs.ref 
b/tests/tcg/hexagon/float_convs.ref
index 9ec9ffc08d..a5505c337b 100644
--- a/tests/tcg/hexagon/float_convs.ref
+++ b/tests/tcg/hexagon/float_convs.ref
@@ -18,31 +18,31 @@ from single: f32(-inf:0xff80)
   to uint32: 0 (INVALID)
   to uint64: 0 (INVALID)
 from single: f32(-0x1.fe00p+127:0xff7f)
-  to double: f64(-0x1.fe00p+127:0x00c7efe000) (INEXACT 
)
+  to double: f64(-0x1.fe00p+127:0x00c7efe000) (OK)
to int32: -2147483648 (INVALID)
to int64: -9223372036854775808 (INVALID)
   to uint32: 0 (INVALID)
   to uint64: 0 (INVALID)
 from single: f32(-0x1.1874b200p+103:0xf30c3a59)
-  to double: f64(-0x1.1874b200p+103:0x00c661874b2000) (INEXACT 
)
+  to double: f64(-0x1.1874b200p+103:0x00c661874b2000) (OK)
to int32: -2147483648 (INVALID)
to int64: -9223372036854775808 (INVALID)
   to uint32: 0 (INVALID)
   to uint64: 0 (INVALID)
 from single: f32(-0x1.c0bab600p+99:0xf1605d5b)
-  to double: f64(-0x1.c0bab600p+99:0x00c62c0bab6000) (INEXACT )
+  to double: f64(-0x1.c0bab600p+99:0x00c62c0bab6000) (OK)
to int32: -2147483648 (INVALID)
to int64: -9223372036854775808 (INVALID)
   to uint32: 0 (INVALID)
   to uint64: 0 (INVALID)
 from single: f32(-0x1.31f75000p-40:0xab98fba8)
-  to double: f64(-0x1.31f75000p-40:0x00bd731f75) (INEXACT )
+  to double: f64(-0x1.31f75000p-40:0x00bd731f75) (OK)
to int32: 0 (INEXACT )
to int64: 0 (INEXACT )
   to uint32: 0 (INVALID)
   to uint64: 0 (INVALID)
 from single: f32(-0x1.50544400p-66:0x9ea82a22)
-  to double: f64(-0x1.50544400p-66:0x00bbd505444000) (INEXACT )
+  to double: f64(-0x1.50544400p-66:0x00bbd505444000) (OK)
to int32: 0 (INEXACT )
to int64: 0 (INEXACT )
   to uint32: 0 (INVALID)
@@ -72,19 +72,19 @@ from single: f32(0x1.p-25:0x3300)
   to uint32: 0 (INEXACT )
   to uint64: 0 (INEXACT )
 from single: f32(0x1.e600p-25:0x3373)
-  to double: f64(0x1.e600p-25:0x003e6e6000) (INEXACT )
+  to double: f64(0x1.e600p-25:0x003e6e6000) (OK)
to int32: 0 (INEXACT )
to int64: 0 (INEXACT )
   to uint32: 0 (INEXACT )
   to uint64: 0 (INEXACT )
 from single: f32(0x1.ff801a00p-15:0x387fc00d)
-  to double: f64(0x1.ff801a00p-15:0x003f0ff801a000) (INEXACT )
+  to double: f64(0x1.ff801a00p-15:0x003f0ff801a000) (OK)
to int32: 0 (INEXACT )
to int64: 0 (INEXACT )
   to uint32: 0 (INEXACT )
   to uint64: 0 (INEXACT )
 from single: f32(0x1.0c00p-14:0x3886)
-  to double: f64(0x1.0c00p-14:0x003f10c000) (INEXACT )
+  to double: f64(0x1.0c00p-14:0x003f10c000) (OK)
to int32: 0 (INEXACT )
to int64: 0 (INEXACT )
   to uint32: 0 (INEXACT )
@@ -96,7 +96,7 @@ from single: f32(0x1.p+0:0x3f80)
   to uint32: 1 (OK)
   to uint64: 1 (OK)
 from single: f32(0x1.0040p+0:0x3f802000)
-  to double: f64(0x1.0040p+0:0x003ff00400) (INE

[PATCH v1 09/34] tests/docker: auto-generate fedora.docker with lcitool

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

This commit is best examined using the "-b" option to diff.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-10-berra...@redhat.com>
---
 tests/docker/dockerfiles/fedora.docker | 260 ++---
 tests/lcitool/refresh  |   1 +
 2 files changed, 146 insertions(+), 115 deletions(-)

diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index 855aefaac5..6784878b56 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,118 +1,148 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool dockerfile fedora-35 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
 FROM registry.fedoraproject.org/fedora:35
 
-# Please keep this list sorted alphabetically
-ENV PACKAGES \
-SDL2-devel \
-SDL2_image-devel \
-alsa-lib-devel \
-bc \
-brlapi-devel \
-bzip2 \
-bzip2-devel \
-ca-certificates \
-capstone-devel \
-ccache \
-clang \
-ctags \
-cyrus-sasl-devel \
-daxctl-devel \
-dbus-daemon \
-device-mapper-multipath-devel \
-diffutils \
-findutils \
-gcc \
-gcc-c++ \
-gcovr \
-genisoimage \
-gettext \
-git \
-glib2-devel \
-glibc-langpack-en \
-glibc-static \
-glusterfs-api-devel \
-gnutls-devel \
-gtk3-devel \
-hostname \
-jemalloc-devel \
-libaio-devel \
-libasan \
-libattr-devel \
-libbpf-devel \
-libcacard-devel \
-libcap-ng-devel \
-libcurl-devel \
-libdrm-devel \
-libepoxy-devel \
-libfdt-devel \
-libffi-devel \
-libgcrypt-devel \
-libiscsi-devel \
-libjpeg-devel \
-libnfs-devel \
-libpmem-devel \
-libpng-devel \
-librbd-devel \
-libseccomp-devel \
-libselinux-devel \
-libslirp-devel \
-libssh-devel \
-libtasn1-devel \
-libubsan \
-libudev-devel \
-liburing-devel \
-libusbx-devel \
-libxml2-devel \
-libzstd-devel \
-llvm \
-lttng-ust-devel \
-lzo-devel \
-make \
-mesa-libgbm-devel \
-meson \
-ncurses-devel \
-nettle-devel \
-ninja-build \
-nmap-ncat \
-numactl-devel \
-openssh-clients \
-pam-devel \
-perl-Test-Harness \
-perl-base \
-pixman-devel \
-pkgconfig \
-pulseaudio-libs-devel \
-python3 \
-python3-PyYAML \
-python3-numpy \
-python3-opencv \
-python3-pillow \
-python3-pip \
-python3-sphinx \
-python3-sphinx_rtd_theme \
-python3-virtualenv \
-rdma-core-devel \
-rpm \
-sed \
-snappy-devel \
-sparse \
-spice-protocol \
-spice-server-devel \
-systemd-devel \
-systemtap-sdt-devel \
-tar \
-tesseract \
-tesseract-langpack-eng \
-texinfo \
-usbredir-devel \
-util-linux \
-virglrenderer-devel \
-vte291-devel \
-which \
-xen-devel \
-xfsprogs-devel \
-zlib-devel
-ENV QEMU_CONFIGURE_OPTS --python=/usr/bin/python3
+RUN dnf install -y nosync && \
+echo -e '#!/bin/sh\n\
+if test -d /usr/lib64\n\
+then\n\
+export LD_PRELOAD=/usr/lib64/nosync/nosync.so\n\
+else\n\
+export LD_PRELOAD=/usr/lib/nosync/nosync.so\n\
+fi\n\
+exec "$@"' > /usr/bin/nosync && \
+chmod +x /usr/bin/nosync && \
+nosync dnf update -y && \
+nosync dnf install -y \
+SDL2-devel \
+SDL2_image-devel \
+alsa-lib-devel \
+bash \
+bc \
+brlapi-devel \
+bzip2 \
+bzip2-devel \
+ca-certificates \
+capstone-devel \
+ccache \
+clang \
+ctags \
+cyrus-sasl-devel \
+daxctl-devel \
+dbus-daemon \
+device-mapper-multipath-devel \
+diffutils \
+findutils \
+gcc \
+gcc-c++ \
+gcovr \
+genisoimage \
+gettext \
+git \
+glib2-devel \
+glib2-static \
+glibc-langpack-en \
+glibc-static \
+glusterfs-api-devel \
+gnutls-devel \
+gtk3-devel \
+hostname \
+jemalloc-devel \
+libaio-devel \
+libasan \
+libattr-devel \
+libbpf-devel \
+libcacard-devel \
+libcap-ng-devel \
+libcurl-devel \
+libdrm-devel \
+libepoxy-devel \
+libfdt-devel \
+libffi-devel \
+libgcrypt-devel \
+libiscsi-devel \
+libjpeg-devel \
+libnfs-devel \
+libpmem-devel \
+libpng-devel \
+librbd-devel \
+libseccomp-devel \
+libselinux-devel \
+libslirp-devel \
+libssh-devel \
+libtasn1-devel \
+libubsan \
+libudev-devel \
+liburing-devel \
+libusbx-devel \
+libxml2-devel \
+libzstd-devel \
+llvm \
+lttng-ust-devel \
+lzo-devel \
+ 

Re: [PATCH] ide: Explicitly poll for BHs on cancel

2022-01-05 Thread Hanna Reitz

On 05.01.22 12:13, Hanna Reitz wrote:

[...]


Perhaps for a lack of being aware of all the kinds of tests we have, I
found it impossible to write a reproducer in any of our current test
frameworks: From how I understand the issue, to reproduce it, you need
to issue a TRIM request and immediately cancel it, before
ide_trim_bh_cb() (scheduled as a BH) can run.

I wanted to do this via qtest, but that does not work, because every
port I/O operation is done via a qtest command, and QEMU will happily
poll the main context between each qtest command, which means that you
cannot cancel an ongoing IDE request before a BH scheduled by it is run.

Therefore, I wrote an x86 boot sector that sets up a no-op TRIM request
(i.e. one where all TRIM ranges have length 0) and immediately cancels
it by setting SRST.


I just realized we could, if we really wanted to, add this to the 
iotests’ sample_images directory, and then run it from an iotest...


Hanna




[PATCH v1 33/34] docker: include bison in debian-tricore-cross

2022-01-05 Thread Alex Bennée
From: Paolo Bonzini 

Binutils sometimes fail to build if bison is not installed:

  /bin/sh ./ylwrap `test -f arparse.y || echo ./`arparse.y y.tab.c arparse.c 
y.tab.h arparse.h y.output arparse.output --  -d
  ./ylwrap: 109: ./ylwrap: -d: not found

(the correct invocation of ylwrap would have "bison -d" after the double
dash).  Work around by installing it in the container.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Philippe Mathieu-Daudé 
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/596
Reviewed-by: Richard Henderson 
Message-Id: <2021122624.352804-1-pbonz...@redhat.com>
Signed-off-by: Alex Bennée 
---
 tests/docker/dockerfiles/debian-tricore-cross.docker | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/docker/dockerfiles/debian-tricore-cross.docker 
b/tests/docker/dockerfiles/debian-tricore-cross.docker
index d8df2c6117..3f6b55562c 100644
--- a/tests/docker/dockerfiles/debian-tricore-cross.docker
+++ b/tests/docker/dockerfiles/debian-tricore-cross.docker
@@ -16,6 +16,7 @@ MAINTAINER Philippe Mathieu-Daudé 
 RUN apt update && \
 DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
 DEBIAN_FRONTEND=noninteractive eatmydata apt install -yy \
+   bison \
bzip2 \
ca-certificates \
ccache \
-- 
2.30.2




[PATCH v1 12/34] tests/docker: auto-generate opensuse-leap.docker with lcitool

2022-01-05 Thread Alex Bennée
From: Daniel P. Berrangé 

This commit is best examined using the "-b" option to diff.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20211215141949.3512719-13-berra...@redhat.com>
---
 tests/docker/dockerfiles/opensuse-leap.docker | 245 ++
 tests/lcitool/refresh |   1 +
 2 files changed, 135 insertions(+), 111 deletions(-)

diff --git a/tests/docker/dockerfiles/opensuse-leap.docker 
b/tests/docker/dockerfiles/opensuse-leap.docker
index 3bbdb67f4f..5510bdf19c 100644
--- a/tests/docker/dockerfiles/opensuse-leap.docker
+++ b/tests/docker/dockerfiles/opensuse-leap.docker
@@ -1,114 +1,137 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool dockerfile opensuse-leap-152 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
 FROM registry.opensuse.org/opensuse/leap:15.2
 
-# Please keep this list sorted alphabetically
-ENV PACKAGES \
-Mesa-devel \
-alsa-lib-devel \
-bc \
-brlapi-devel \
-bzip2 \
-ca-certificates \
-ccache \
-clang \
-ctags \
-cyrus-sasl-devel \
-dbus-1 \
-diffutils \
-findutils \
-gcc \
-gcc-c++ \
-gcovr \
-gettext-runtime \
-git \
-glib2-devel \
-glibc-locale \
-glibc-static \
-glusterfs-devel \
-gtk3-devel \
-hostname \
-jemalloc-devel \
-libSDL2-devel \
-libSDL2_image-devel \
-libaio-devel \
-libasan6 \
-libattr-devel \
-libbpf-devel \
-libbz2-devel \
-libcacard-devel \
-libcap-ng-devel \
-libcurl-devel \
-libdrm-devel \
-libepoxy-devel \
-libfdt-devel \
-libffi-devel \
-libgcrypt-devel \
-libgnutls-devel \
-libiscsi-devel \
-libjpeg8-devel \
-libndctl-devel \
-libnettle-devel \
-libnfs-devel \
-libnuma-devel \
-libpixman-1-0-devel \
-libpmem-devel \
-libpng16-devel \
-libpulse-devel \
-librbd-devel \
-libseccomp-devel \
-libselinux-devel \
-libspice-server-devel \
-libssh-devel \
-libtasn1-devel \
-libubsan1 \
-libudev-devel \
-libusb-1_0-devel \
-libxml2-devel \
-libzstd-devel \
-llvm \
-lttng-ust-devel \
-lzo-devel \
-make \
-mkisofs \
-ncat \
-ncurses-devel \
-ninja \
-openssh \
-pam-devel \
-perl-Test-Harness \
-perl-base \
-pkgconfig \
-python3-Pillow \
-python3-PyYAML \
-python3-Sphinx \
-python3-base \
-python3-numpy \
-python3-opencv \
-python3-pip \
-python3-setuptools \
-python3-sphinx_rtd_theme \
-python3-virtualenv \
-python3-wheel \
-rdma-core-devel \
-rpm \
-sed \
-snappy-devel \
-sparse \
-spice-protocol-devel \
-systemd-devel \
-systemtap-sdt-devel \
-tar \
-tesseract-ocr \
-tesseract-ocr-traineddata-english \
-texinfo \
-usbredir-devel \
-util-linux \
-virglrenderer-devel \
-vte-devel \
-which \
-xen-devel \
-xfsprogs-devel \
-zlib-devel
-ENV QEMU_CONFIGURE_OPTS --python=/usr/bin/python3.6
+RUN zypper update -y && \
+zypper install -y \
+   Mesa-devel \
+   alsa-lib-devel \
+   bash \
+   bc \
+   brlapi-devel \
+   bzip2 \
+   ca-certificates \
+   ccache \
+   clang \
+   ctags \
+   cyrus-sasl-devel \
+   dbus-1 \
+   diffutils \
+   findutils \
+   gcc \
+   gcc-c++ \
+   gcovr \
+   gettext-runtime \
+   git \
+   glib2-devel \
+   glibc-locale \
+   glibc-static \
+   glusterfs-devel \
+   gtk3-devel \
+   hostname \
+   jemalloc-devel \
+   libSDL2-devel \
+   libSDL2_image-devel \
+   libaio-devel \
+   libasan6 \
+   libattr-devel \
+   libbpf-devel \
+   libbz2-devel \
+   libcacard-devel \
+   libcap-ng-devel \
+   libcurl-devel \
+   libdrm-devel \
+   libepoxy-devel \
+   libfdt-devel \
+   libffi-devel \
+   libgcrypt-devel \
+   libgnutls-devel \
+   libiscsi-devel \
+   libjpeg8-devel \
+   libndctl-devel \
+   libnettle-devel \
+   libnfs-devel \
+   libnuma-devel \
+   libpixman-1-0-devel \
+   libpmem-devel \
+   libpng16-devel \
+   libpulse-devel \
+   librbd-devel \
+   libseccomp-devel \
+   libselinux-devel \
+   libspice-server-devel \
+   libssh-devel \
+   libtasn1-devel \
+   libubsan1 \
+   libudev-devel \
+   liburing-devel \
+   libusb-1_0-devel \
+   libxml2-devel \
+   libzstd-devel \
+   llvm \
+   lttng-ust-devel \
+   lzo-devel \
+   make \
+   mkisofs \
+   ncat \
+   

[PATCH v1 32/34] gitlab-ci: Enable docs in the centos job

2022-01-05 Thread Alex Bennée
From: Thomas Huth 

We just ran into a problem that the docs don't build on RHEL8 / CentOS 8
anymore. Seems like these distros are using one of the oldest Sphinx
versions that we still have to support. Thus enable the docs build in
the CI on CentOS so that such bugs don't slip in so easily again.

Signed-off-by: Thomas Huth 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20220104091240.160867-1-th...@redhat.com>
Signed-off-by: Alex Bennée 
---
 .gitlab-ci.d/buildtest.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index e77aec873e..8f2a3c8f5b 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -164,7 +164,7 @@ build-system-centos:
   variables:
 IMAGE: centos8
 CONFIGURE_ARGS: --disable-nettle --enable-gcrypt --enable-fdt=system
---enable-modules --enable-trace-backends=dtrace
+  --enable-modules --enable-trace-backends=dtrace --enable-docs
 TARGETS: ppc64-softmmu or1k-softmmu s390x-softmmu
   x86_64-softmmu rx-softmmu sh4-softmmu nios2-softmmu
 MAKE_CHECK_ARGS: check-build
-- 
2.30.2




[PATCH v1 34/34] linux-user: Remove the deprecated ppc64abi32 target

2022-01-05 Thread Alex Bennée
From: Thomas Huth 

It's likely broken, and nobody cared for picking it up again
during the deprecation phase, so let's remove this now.

Since this is the last entry in deprecated_targets_list, remove
the related code in the configure script, too.

Signed-off-by: Thomas Huth 
Reviewed-by: Richard Henderson 
Acked-by: Cédric Le Goater 
Acked-by: Alex Bennée 
Message-Id: <20211215084958.185214-1-th...@redhat.com>
Signed-off-by: Alex Bennée 
---
 docs/about/deprecated.rst |  7 -
 docs/about/removed-features.rst   |  8 +
 docs/user/main.rst|  1 -
 configure | 29 +--
 configs/targets/ppc64abi32-linux-user.mak |  8 -
 linux-user/ppc/target_syscall.h   |  4 +--
 linux-user/syscall_defs.h |  6 ++--
 linux-user/elfload.c  |  4 +--
 linux-user/ppc/signal.c   | 11 ++-
 .gitlab-ci.d/buildtest.yml| 27 -
 .../dockerfiles/debian-ppc64el-cross.docker   |  2 +-
 tests/tcg/configure.sh|  2 +-
 12 files changed, 21 insertions(+), 88 deletions(-)
 delete mode 100644 configs/targets/ppc64abi32-linux-user.mak

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 5693abb663..7f12f53713 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -396,13 +396,6 @@ The above, converted to the current supported format::
 linux-user mode CPUs
 
 
-``ppc64abi32`` CPUs (since 5.2)
-'''
-
-The ``ppc64abi32`` architecture has a number of issues which regularly
-trip up our CI testing and is suspected to be quite broken. For that
-reason the maintainers strongly suspect no one actually uses it.
-
 MIPS ``I7200`` CPU (since 5.2)
 ''
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index d42c3341de..f92b8bd738 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -594,6 +594,14 @@ the upstream Linux kernel in 2018, and it has also been 
dropped from glibc, so
 there is no new Linux development taking place with this architecture. For
 running the old binaries, you can use older versions of QEMU.
 
+``ppc64abi32`` CPUs (removed in 7.0)
+
+
+The ``ppc64abi32`` architecture has a number of issues which regularly
+tripped up the CI testing and was suspected to be quite broken. For that
+reason the maintainers strongly suspected no one actually used it.
+
+
 System emulator devices
 ---
 
diff --git a/docs/user/main.rst b/docs/user/main.rst
index e08d4be63b..6f2ffa080f 100644
--- a/docs/user/main.rst
+++ b/docs/user/main.rst
@@ -166,7 +166,6 @@ Other binaries
 
 -  user mode (PowerPC)
 
-   * ``qemu-ppc64abi32`` TODO.
* ``qemu-ppc64`` TODO.
* ``qemu-ppc`` TODO.
 
diff --git a/configure b/configure
index 030728d11e..0c57a063c6 100755
--- a/configure
+++ b/configure
@@ -1273,8 +1273,6 @@ if [ "$ARCH" = "unknown" ]; then
 fi
 
 default_target_list=""
-deprecated_targets_list=ppc64abi32-linux-user
-deprecated_features=""
 mak_wilds=""
 
 if [ "$softmmu" = "yes" ]; then
@@ -1287,16 +1285,6 @@ if [ "$bsd_user" = "yes" ]; then
 mak_wilds="${mak_wilds} $source_path/configs/targets/*-bsd-user.mak"
 fi
 
-# If the user doesn't explicitly specify a deprecated target we will
-# skip it.
-if test -z "$target_list"; then
-if test -z "$target_list_exclude"; then
-target_list_exclude="$deprecated_targets_list"
-else
-target_list_exclude="$target_list_exclude,$deprecated_targets_list"
-fi
-fi
-
 for config in $mak_wilds; do
 target="$(basename "$config" .mak)"
 if echo "$target_list_exclude" | grep -vq "$target"; then
@@ -1315,11 +1303,9 @@ Standard options:
   --prefix=PREFIX  install in PREFIX [$prefix]
   --interp-prefix=PREFIX   where to find shared libraries, etc.
use %M for cpu name [$interp_prefix]
-  --target-list=LIST   set target list (default: build all non-deprecated)
+  --target-list=LIST   set target list (default: build all)
 $(echo Available targets: $default_target_list | \
   fold -s -w 53 | sed -e 's/^/   /')
-$(echo Deprecated targets: $deprecated_targets_list | \
-  fold -s -w 53 | sed -e 's/^/   /')
   --target-list-exclude=LIST exclude a set of targets from the default 
target-list
 
 Advanced options (experts only):
@@ -1804,13 +1790,6 @@ else
 done
 fi
 
-for target in $target_list; do
-# if a deprecated target is enabled we note it here
-if echo "$deprecated_targets_list" | grep -q "$target"; then
-add_to deprecated_features $target
-fi
-done
-
 # see if system emulation was really requested
 case " $target_list " in
   *"-softmmu "*) softmmu=yes
@@ -3950,12 +3929,6 @@ else
   fi
 fi
 

  1   2   3   >