Re: [PATCH v12 13/14] vfio-user: handle device interrupts

2022-06-14 Thread Stefan Hajnoczi
On Mon, Jun 13, 2022 at 04:26:33PM -0400, Jagannathan Raman wrote:
> Forward remote device's interrupts to the guest
> 
> Signed-off-by: Elena Ufimtseva 
> Signed-off-by: John G Johnson 
> Signed-off-by: Jagannathan Raman 
> ---
>  include/hw/pci/msi.h  |   1 +
>  include/hw/pci/msix.h |   1 +
>  include/hw/pci/pci.h  |  13 +++
>  include/hw/remote/vfio-user-obj.h |   6 ++
>  hw/pci/msi.c  |  49 +++--
>  hw/pci/msix.c |  35 ++-
>  hw/pci/pci.c  |  13 +++
>  hw/remote/machine.c   |  14 ++-
>  hw/remote/vfio-user-obj.c | 167 ++
>  stubs/vfio-user-obj.c |   6 ++
>  MAINTAINERS   |   1 +
>  hw/remote/trace-events|   1 +
>  stubs/meson.build |   1 +
>  13 files changed, 297 insertions(+), 11 deletions(-)
>  create mode 100644 include/hw/remote/vfio-user-obj.h
>  create mode 100644 stubs/vfio-user-obj.c

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [PATCH v12 00/14] vfio-user server in QEMU

2022-06-14 Thread Stefan Hajnoczi
On Mon, Jun 13, 2022 at 04:26:20PM -0400, Jagannathan Raman wrote:
> This is v12 of the server side changes to enable vfio-user in QEMU.
> 
> Thanks so much for reviewing this series and sharing your feedback.
> 
> We made the following changes in this series:
> [PATCH v12 13/14] vfio-user: handle device interrupts
>  - Renamed msi_set_irq_state() and msix_set_irq_state() as
>msi_set_mask() and msix_set_mask() respectively
>  - Added missing return statement for error case in msi_set_mask()

Thanks, applied to my block tree:
https://gitlab.com/stefanha/qemu/commits/block

Stefan


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] hw: m25p80: add WP# pin and SRWD bit for write protection

2022-06-14 Thread Cédric Le Goater

Hello Dan

On 6/14/22 07:45, Dan Zhang wrote:

Just find out how to use mutt to reply all in the thread.
repeat the previous comments. Add STATE_HIZ to handle decode_new_command
aborting gracefully.

On Thu, Jun 09, 2022 at 08:06:00PM +, Peter Delevoryas wrote:




On Jun 9, 2022, at 12:22 PM, Francisco Iglesias  
wrote:

Hi Iris,

Looks good some, a couple of comments below.

On [2022 Jun 08] Wed 20:13:19, Iris Chen wrote:

From: Iris Chen 

Signed-off-by: Iris Chen 
---
Addressed all comments from V1. The biggest change: removed 
object_class_property_add.

hw/block/m25p80.c | 37 +++
tests/qtest/aspeed_smc-test.c |  2 ++
2 files changed, 39 insertions(+)

diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 81ba3da4df..1a20bd55d4 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -27,12 +27,14 @@
#include "hw/qdev-properties.h"
#include "hw/qdev-properties-system.h"
#include "hw/ssi/ssi.h"
+#include "hw/irq.h"
#include "migration/vmstate.h"
#include "qemu/bitops.h"
#include "qemu/log.h"
#include "qemu/module.h"
#include "qemu/error-report.h"
#include "qapi/error.h"
+#include "qapi/visitor.h"
#include "trace.h"
#include "qom/object.h"

@@ -472,11 +474,13 @@ struct Flash {
 uint8_t spansion_cr2v;
 uint8_t spansion_cr3v;
 uint8_t spansion_cr4v;
+bool wp_level;
 bool write_enable;
 bool four_bytes_address_mode;
 bool reset_enable;
 bool quad_enable;
 bool aai_enable;
+bool status_register_write_disabled;
 uint8_t ear;

 int64_t dirty_page;
@@ -723,6 +727,21 @@ static void complete_collecting_data(Flash *s)
 flash_erase(s, s->cur_addr, s->cmd_in_progress);
 break;
 case WRSR:
+/*
+ * If WP# is low and status_register_write_disabled is high,
+ * status register writes are disabled.
+ * This is also called "hardware protected mode" (HPM). All other
+ * combinations of the two states are called "software protected mode"
+ * (SPM), and status register writes are permitted.
+ */
+if ((s->wp_level == 0 && s->status_register_write_disabled)
+|| !s->write_enable) {


'write_enable' needs to be true in 'decode_new_cmd' when issueing the WRSR
command, otherwise the state machinery will not advance to this function
(meaning that above check for !s->write_enable will never hit as far as I can
tell). A suggestion is to move the check for wp_level and
status_reg_wr_disabled into 'decode_new_cmd' to for keeping it consistent.


Oh good catch! Yes actually, in our fork, we also removed the write_enable
guard in decode_new_cmd. We either need both checks in decode_new_cmd,
or both checks in complete_collecting_data.

I think we had some difficulty deciding whether to block command decoding,
or to decode and ignore the command if restrictions are enabled.

The reason being that, in the qtest, the WRSR command code gets ignored, and
then the subsequent write data gets interpreted as some random command code.
We had elected to decode and ignore the command, but I think the
datasheet actually describes that the command won’t be decoded successfully,
so you’re probably right, we should put this logic in decode_new_cmd.

Most likely, the qtest will also need to be modified to reset the transfer
state machine after a blocked write command. I can’t remember if
exiting and re-entering user mode is sufficient for that, but something
like that is probably possible.

Thanks for catching this!
Peter



I am proposing add a CMDState: STATE_HIZ to handle command decode fail
situation. When decode_new_command need abort the decoding and ignore
following
on input bytes of this transaction, set the state to STATE_HIZ.
And m25p80_transfer8() will ignore all the following on byte when in
this state.

This is to simulating the real device operation behavior
i.e. Macronix MX66L1G45G data sheet section 8 DEVICE OPERATION described
```
2. When an incorrect command is written to this device, it enters
standby mode and stays in standby mode until the next CS# falling edge.
In standby mode, This device's SO pin should be High-Z.
```


Could you please send a patch ?

Thanks,

C.


BRs
Dan Zhang



+qemu_log_mask(LOG_GUEST_ERROR,
+  "M25P80: Status register write is disabled!\n");
+break;
+}
+s->status_register_write_disabled = extract32(s->data[0], 7, 1);
+
 switch (get_man(s)) {
 case MAN_SPANSION:
 s->quad_enable = !!(s->data[1] & 0x02);
@@ -1195,6 +1214,8 @@ static void decode_new_cmd(Flash *s, uint32_t value)

 case RDSR:
 s->data[0] = (!!s->write_enable) << 1;
+s->data[0] |= (!!s->status_register_write_disabled) << 7;
+
 if (get_man(s) == MAN_MACRONIX || get_man(s) == MAN_ISSI) {
 s->data[0] |= (!!s->quad_enable) << 6;
 }
@@ -1484,6 +1505,14 @@ static uint32_t m25p80_transfer8(SSIPeripheral *ss, 
uint32_t tx)

Re: [PATCH 1/2] hw/nvme: Implement shadow doorbell buffer support

2022-06-14 Thread Jinhao Fan



> On Jun 14, 2022, at 5:15 AM, Keith Busch  wrote:
> 
> 
> @@ -6538,9 +6544,25 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, 
> int val)
> 
> trace_pci_nvme_mmio_doorbell_sq(sq->sqid, new_tail);
> 
> -if (!sq->db_addr) {
> sq->tail = new_tail;
> +if (sq->db_addr) {
> +/*
> + * The spec states "the host shall also update the controller's
> + * corresponding doorbell property to match the value of that 
> entry
> + * in the Shadow Doorbell buffer."
> + *
> + * Since this context is currently a VM trap, we can safely 
> enforce
> + * the requirement from the device side in case the host is
> + * misbehaving.
> + *
> + * Note, we shouldn't have to do this, but various drivers
> + * including ones that run on Linux, are not updating Admin 
> Queues,
> + * so we can't trust reading it for an appropriate sq tail.
> + */
> +pci_dma_write(&n->parent_obj, sq->db_addr, &sq->tail,
> +sizeof(sq->tail));
> }
> +
> timer_mod(sq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 500);
> }
> }
> --

Thanks Keith,

This is an interesting hack. I wonder how should I incorporate your changes in 
my patch. I guess I can modify the code in PATCH 1/2 and add a “Proposed-by” 
tag. Is this the correct way?

Regards,
Jinhao Fan




Re: [PATCH v6 0/8] KVM: mm: fd-based approach for supporting KVM guest private memory

2022-06-14 Thread Chao Peng
On Thu, Jun 09, 2022 at 08:29:06PM +, Sean Christopherson wrote:
> On Wed, Jun 08, 2022, Vishal Annapurve wrote:
> > ...
> > > With this patch series, it's actually even not possible for userspace VMM
> > > to allocate private page by a direct write, it's basically unmapped from
> > > there. If it really wants to, it should so something special, by 
> > > intention,
> > > that's basically the conversion, which we should allow.
> > >
> > 
> > A VM can pass GPA backed by private pages to userspace VMM and when
> > Userspace VMM accesses the backing hva there will be pages allocated
> > to back the shared fd causing 2 sets of pages backing the same guest
> > memory range.
> > 
> > > Thanks for bringing this up. But in my mind I still think userspace VMM
> > > can do and it's its responsibility to guarantee that, if that is hard
> > > required.
> 
> That was my initial reaction too, but there are unfortunate side effects to 
> punting
> this to userspace. 
> 
> > By design, userspace VMM is the decision-maker for page
> > > conversion and has all the necessary information to know which page is
> > > shared/private. It also has the necessary knobs to allocate/free the
> > > physical pages for guest memory. Definitely, we should make userspace
> > > VMM more robust.
> > 
> > Making Userspace VMM more robust to avoid double allocation can get
> > complex, it will have to keep track of all in-use (by Userspace VMM)
> > shared fd memory to disallow conversion from shared to private and
> > will have to ensure that all guest supplied addresses belong to shared
> > GPA ranges.
> 
> IMO, the complexity argument isn't sufficient justfication for introducing new
> kernel functionality.  If multiple processes are accessing guest memory then 
> there
> already needs to be some amount of coordination, i.e. it can't be _that_ 
> complex.
> 
> My concern with forcing userspace to fully handle unmapping shared memory is 
> that
> it may lead to additional performance overhead and/or noisy neighbor issues, 
> even
> if all guests are well-behaved.
> 
> Unnmapping arbitrary ranges will fragment the virtual address space and 
> consume
> more memory for all the result VMAs.  The extra memory consumption isn't that 
> big
> of a deal, and it will be self-healing to some extent as VMAs will get merged 
> when
> the holes are filled back in (if the guest converts back to shared), but it's 
> still
> less than desirable.
> 
> More concerning is having to take mmap_lock for write for every conversion, 
> which
> is very problematic for configurations where a single userspace process maps 
> memory
> belong to multiple VMs.  Unmapping and remapping on every conversion will 
> create a
> bottleneck, especially if a VM has sub-optimal behavior and is converting 
> pages at
> a high rate.
> 
> One argument is that userspace can simply rely on cgroups to detect 
> misbehaving
> guests, but (a) those types of OOMs will be a nightmare to debug and (b) an 
> OOM
> kill from the host is typically considered a _host_ issue and will be treated 
> as
> a missed SLO.
> 
> An idea for handling this in the kernel without too much complexity would be 
> to
> add F_SEAL_FAULT_ALLOCATIONS (terrible name) that would prevent page faults 
> from
> allocating pages, i.e. holes can only be filled by an explicit fallocate().  
> Minor
> faults, e.g. due to NUMA balancing stupidity, and major faults due to swap 
> would
> still work, but writes to previously unreserved/unallocated memory would get a
> SIGSEGV on something it has mapped.  That would allow the userspace VMM to 
> prevent
> unintentional allocations without having to coordinate unmapping/remapping 
> across
> multiple processes.

Since this is mainly for shared memory and the motivation is catching
misbehaved access, can we use mprotect(PROT_NONE) for this? We can mark
those range backed by private fd as PROT_NONE during the conversion so
subsequence misbehaved accesses will be blocked instead of causing double
allocation silently.

Chao



Re: [PATCH v2 1/1] nbd: trace long NBD operations

2022-06-14 Thread Vladimir Sementsov-Ogievskiy

On 5/30/22 13:39, Denis V. Lunev wrote:

At the moment there are 2 sources of lengthy operations if configured:
* open connection, which could retry inside and
* reconnect of already opened connection
These operations could be quite lengthy and cumbersome to catch thus
it would be quite natural to add trace points for them.

This patch is based on the original downstream work made by Vladimir.

Signed-off-by: Denis V. Lunev
CC: Eric Blake
CC: Vladimir Sementsov-Ogievskiy
CC: Kevin Wolf
CC: Hanna Reitz
CC: Paolo Bonzini


Thanks, applied to my block branch at 
https://gitlab.com/vsementsov/qemu/-/commits/block

--
Best regards,
Vladimir



Re: [PATCH 1/1] block: use 'unsigned' for in_flight field on driver state

2022-06-14 Thread Vladimir Sementsov-Ogievskiy

On 5/30/22 13:39, Denis V. Lunev wrote:

This patch makes in_flight field 'unsigned' for BDRVNBDState and
MirrorBlockJob. This matches the definition of this field on BDS
and is generically correct - we should never get negative value here.

Signed-off-by: Denis V. Lunev
CC: John Snow
CC: Vladimir Sementsov-Ogievskiy
CC: Kevin Wolf
CC: Hanna Reitz
CC: Eric Blake



Thanks, applied to my block branch at 
https://gitlab.com/vsementsov/qemu/-/commits/block

--
Best regards,
Vladimir



Re: [RFC PATCH v8 00/21] Net Control VQ support with asid in vDPA SVQ

2022-06-14 Thread Eugenio Perez Martin
On Tue, Jun 14, 2022 at 10:02 AM Jason Wang  wrote:
>
> On Tue, Jun 14, 2022 at 12:32 AM Eugenio Perez Martin
>  wrote:
> >
> > On Wed, Jun 8, 2022 at 9:28 PM Eugenio Perez Martin  
> > wrote:
> > >
> > > On Wed, Jun 8, 2022 at 7:51 AM Jason Wang  wrote:
> > > >
> > > >
> > > > 在 2022/5/20 03:12, Eugenio Pérez 写道:
> > > > > Control virtqueue is used by networking device for accepting various
> > > > > commands from the driver. It's a must to support multiqueue and other
> > > > > configurations.
> > > > >
> > > > > Shadow VirtQueue (SVQ) already makes possible migration of virtqueue
> > > > > states, effectively intercepting them so qemu can track what regions 
> > > > > of memory
> > > > > are dirty because device action and needs migration. However, this 
> > > > > does not
> > > > > solve networking device state seen by the driver because CVQ 
> > > > > messages, like
> > > > > changes on MAC addresses from the driver.
> > > > >
> > > > > To solve that, this series uses SVQ infraestructure proposed to 
> > > > > intercept
> > > > > networking control messages used by the device. This way, qemu is 
> > > > > able to
> > > > > update VirtIONet device model and to migrate it.
> > > > >
> > > > > However, to intercept all queues would slow device data forwarding. 
> > > > > To solve
> > > > > that, only the CVQ must be intercepted all the time. This is achieved 
> > > > > using
> > > > > the ASID infraestructure, that allows different translations for 
> > > > > different
> > > > > virtqueues. The most updated kernel part of ASID is proposed at [1].
> > > > >
> > > > > You can run qemu in two modes after applying this series: only 
> > > > > intercepting
> > > > > cvq with x-cvq-svq=on or intercept all the virtqueues adding cmdline 
> > > > > x-svq=on:
> > > > >
> > > > > -netdev 
> > > > > type=vhost-vdpa,vhostdev=/dev/vhost-vdpa-0,id=vhost-vdpa0,x-cvq-svq=on,x-svq=on
> > > > >
> > > > > First three patches enable the update of the virtio-net device model 
> > > > > for each
> > > > > CVQ message acknoledged by the device.
> > > > >
> > > > > Patches from 5 to 9 enables individual SVQ to copy the buffers to 
> > > > > QEMU's VA.
> > > > > This allows simplyfing the memory mapping, instead of map all the 
> > > > > guest's
> > > > > memory like in the data virtqueues.
> > > > >
> > > > > Patch 10 allows to inject control messages to the device. This allows 
> > > > > to set
> > > > > state to the device both at QEMU startup and at live migration 
> > > > > destination. In
> > > > > the future, this may also be used to emulate _F_ANNOUNCE.
> > > > >
> > > > > Patch 11 updates kernel headers, but it assign random numbers to 
> > > > > needed ioctls
> > > > > because they are still not accepted in the kernel.
> > > > >
> > > > > Patches 12-16 enables the set of the features of the net device model 
> > > > > to the
> > > > > vdpa device at device start.
> > > > >
> > > > > Last ones enables the sepparated ASID and SVQ.
> > > > >
> > > > > Comments are welcomed.
> > > >
> > > >
> > > > As discussed, I think we need to split this huge series into smaller 
> > > > ones:
> > > >
> > > > 1) shadow CVQ only, this makes rx-filter-event work
> > > > 2) ASID support for CVQ
> > > >
> > > > And for 1) we need consider whether or not it could be simplified.
> > > >
> > > > Or do it in reverse order, since if we do 1) first, we may have security
> > > > issues.
> > > >
> > >
> > > I'm ok with both, but I also think 2) before 1) might make more sense.
> > > There is no way to only shadow CVQ otherwise ATM.
> > >
> >
> > On second thought, that order is kind of harder.
> >
> > If we only map CVQ buffers, we need to either:
> > a. Copy them to controlled buffers
> > b. Track properly when to unmap them
>
> Just to make sure we're at the same page:
>
> I meant we can start with e.g having a dedicated ASID for CVQ but
> still using CVQ passthrough.
>

That would imply duplicating all the memory listener updates to both
ASIDs. That part of the code needs to be reverted. I'm ok with that,
but I'm not sure if it's worth it to do it that way.

> Then do other stuff on top.
>
> >
> > Alternative a. have the same problems exposed in this RFC: It's hard
> > (and unneeded in the final version) to know the size to copy.
> > Alternative b. also requires things not needed in the final version,
> > like to count the number of times each page is mapped and unmapped.
> >
> > So I'll go to the first alternative, that is also the proposed order
> > of the RFC. What security issues do you expect beyond the comments in
> > this series?
>
> If we shadow CVQ without ASID. The guest may guess the IOVA of CVQ and
> try to peek/modify it?
>

It works the same way as data vqs, we're just updating the device
model in the middle. It should imply the exact same risk as updating
an emulated NIC control plane (including vhost-kernel / vhost-user).

Roughly speaking, it's just to propose patches 01 to 03, with your
comments. That already meets use cases li

Re: [RFC PATCH v8 00/21] Net Control VQ support with asid in vDPA SVQ

2022-06-14 Thread Jason Wang
On Tue, Jun 14, 2022 at 12:32 AM Eugenio Perez Martin
 wrote:
>
> On Wed, Jun 8, 2022 at 9:28 PM Eugenio Perez Martin  
> wrote:
> >
> > On Wed, Jun 8, 2022 at 7:51 AM Jason Wang  wrote:
> > >
> > >
> > > 在 2022/5/20 03:12, Eugenio Pérez 写道:
> > > > Control virtqueue is used by networking device for accepting various
> > > > commands from the driver. It's a must to support multiqueue and other
> > > > configurations.
> > > >
> > > > Shadow VirtQueue (SVQ) already makes possible migration of virtqueue
> > > > states, effectively intercepting them so qemu can track what regions of 
> > > > memory
> > > > are dirty because device action and needs migration. However, this does 
> > > > not
> > > > solve networking device state seen by the driver because CVQ messages, 
> > > > like
> > > > changes on MAC addresses from the driver.
> > > >
> > > > To solve that, this series uses SVQ infraestructure proposed to 
> > > > intercept
> > > > networking control messages used by the device. This way, qemu is able 
> > > > to
> > > > update VirtIONet device model and to migrate it.
> > > >
> > > > However, to intercept all queues would slow device data forwarding. To 
> > > > solve
> > > > that, only the CVQ must be intercepted all the time. This is achieved 
> > > > using
> > > > the ASID infraestructure, that allows different translations for 
> > > > different
> > > > virtqueues. The most updated kernel part of ASID is proposed at [1].
> > > >
> > > > You can run qemu in two modes after applying this series: only 
> > > > intercepting
> > > > cvq with x-cvq-svq=on or intercept all the virtqueues adding cmdline 
> > > > x-svq=on:
> > > >
> > > > -netdev 
> > > > type=vhost-vdpa,vhostdev=/dev/vhost-vdpa-0,id=vhost-vdpa0,x-cvq-svq=on,x-svq=on
> > > >
> > > > First three patches enable the update of the virtio-net device model 
> > > > for each
> > > > CVQ message acknoledged by the device.
> > > >
> > > > Patches from 5 to 9 enables individual SVQ to copy the buffers to 
> > > > QEMU's VA.
> > > > This allows simplyfing the memory mapping, instead of map all the 
> > > > guest's
> > > > memory like in the data virtqueues.
> > > >
> > > > Patch 10 allows to inject control messages to the device. This allows 
> > > > to set
> > > > state to the device both at QEMU startup and at live migration 
> > > > destination. In
> > > > the future, this may also be used to emulate _F_ANNOUNCE.
> > > >
> > > > Patch 11 updates kernel headers, but it assign random numbers to needed 
> > > > ioctls
> > > > because they are still not accepted in the kernel.
> > > >
> > > > Patches 12-16 enables the set of the features of the net device model 
> > > > to the
> > > > vdpa device at device start.
> > > >
> > > > Last ones enables the sepparated ASID and SVQ.
> > > >
> > > > Comments are welcomed.
> > >
> > >
> > > As discussed, I think we need to split this huge series into smaller ones:
> > >
> > > 1) shadow CVQ only, this makes rx-filter-event work
> > > 2) ASID support for CVQ
> > >
> > > And for 1) we need consider whether or not it could be simplified.
> > >
> > > Or do it in reverse order, since if we do 1) first, we may have security
> > > issues.
> > >
> >
> > I'm ok with both, but I also think 2) before 1) might make more sense.
> > There is no way to only shadow CVQ otherwise ATM.
> >
>
> On second thought, that order is kind of harder.
>
> If we only map CVQ buffers, we need to either:
> a. Copy them to controlled buffers
> b. Track properly when to unmap them

Just to make sure we're at the same page:

I meant we can start with e.g having a dedicated ASID for CVQ but
still using CVQ passthrough.

Then do other stuff on top.

>
> Alternative a. have the same problems exposed in this RFC: It's hard
> (and unneeded in the final version) to know the size to copy.
> Alternative b. also requires things not needed in the final version,
> like to count the number of times each page is mapped and unmapped.
>
> So I'll go to the first alternative, that is also the proposed order
> of the RFC. What security issues do you expect beyond the comments in
> this series?

If we shadow CVQ without ASID. The guest may guess the IOVA of CVQ and
try to peek/modify it?

Thanks

>
> Thanks!
>
> > Can we do as with previous base SVQ patches? they were merged although
> > there is still no way to enable SVQ.
> >
> > Thanks!
> >
> > > Thoughts?
> > >
> > > Thanks
> > >
> > >
> > > >
> > > > TODO:
> > > > * Fallback on regular CVQ if QEMU cannot isolate in its own ASID by any
> > > >reason, blocking migration. This is tricky, since it can cause that 
> > > > the VM
> > > >cannot be migrated anymore, so some way of block it must be used.
> > > > * Review failure paths, some are with TODO notes, other don't.
> > > >
> > > > Changes from rfc v7:
> > > > * Don't map all guest space in ASID 1 but copy all the buffers. No need 
> > > > for
> > > >more memory listeners.
> > > > * Move net backend start callback to SVQ.
> > > > * Wait for device CVQ 

Re: [RFC PATCH v8 00/21] Net Control VQ support with asid in vDPA SVQ

2022-06-14 Thread Jason Wang
On Tue, Jun 14, 2022 at 4:14 PM Eugenio Perez Martin
 wrote:
>
> On Tue, Jun 14, 2022 at 10:02 AM Jason Wang  wrote:
> >
> > On Tue, Jun 14, 2022 at 12:32 AM Eugenio Perez Martin
> >  wrote:
> > >
> > > On Wed, Jun 8, 2022 at 9:28 PM Eugenio Perez Martin  
> > > wrote:
> > > >
> > > > On Wed, Jun 8, 2022 at 7:51 AM Jason Wang  wrote:
> > > > >
> > > > >
> > > > > 在 2022/5/20 03:12, Eugenio Pérez 写道:
> > > > > > Control virtqueue is used by networking device for accepting various
> > > > > > commands from the driver. It's a must to support multiqueue and 
> > > > > > other
> > > > > > configurations.
> > > > > >
> > > > > > Shadow VirtQueue (SVQ) already makes possible migration of virtqueue
> > > > > > states, effectively intercepting them so qemu can track what 
> > > > > > regions of memory
> > > > > > are dirty because device action and needs migration. However, this 
> > > > > > does not
> > > > > > solve networking device state seen by the driver because CVQ 
> > > > > > messages, like
> > > > > > changes on MAC addresses from the driver.
> > > > > >
> > > > > > To solve that, this series uses SVQ infraestructure proposed to 
> > > > > > intercept
> > > > > > networking control messages used by the device. This way, qemu is 
> > > > > > able to
> > > > > > update VirtIONet device model and to migrate it.
> > > > > >
> > > > > > However, to intercept all queues would slow device data forwarding. 
> > > > > > To solve
> > > > > > that, only the CVQ must be intercepted all the time. This is 
> > > > > > achieved using
> > > > > > the ASID infraestructure, that allows different translations for 
> > > > > > different
> > > > > > virtqueues. The most updated kernel part of ASID is proposed at [1].
> > > > > >
> > > > > > You can run qemu in two modes after applying this series: only 
> > > > > > intercepting
> > > > > > cvq with x-cvq-svq=on or intercept all the virtqueues adding 
> > > > > > cmdline x-svq=on:
> > > > > >
> > > > > > -netdev 
> > > > > > type=vhost-vdpa,vhostdev=/dev/vhost-vdpa-0,id=vhost-vdpa0,x-cvq-svq=on,x-svq=on
> > > > > >
> > > > > > First three patches enable the update of the virtio-net device 
> > > > > > model for each
> > > > > > CVQ message acknoledged by the device.
> > > > > >
> > > > > > Patches from 5 to 9 enables individual SVQ to copy the buffers to 
> > > > > > QEMU's VA.
> > > > > > This allows simplyfing the memory mapping, instead of map all the 
> > > > > > guest's
> > > > > > memory like in the data virtqueues.
> > > > > >
> > > > > > Patch 10 allows to inject control messages to the device. This 
> > > > > > allows to set
> > > > > > state to the device both at QEMU startup and at live migration 
> > > > > > destination. In
> > > > > > the future, this may also be used to emulate _F_ANNOUNCE.
> > > > > >
> > > > > > Patch 11 updates kernel headers, but it assign random numbers to 
> > > > > > needed ioctls
> > > > > > because they are still not accepted in the kernel.
> > > > > >
> > > > > > Patches 12-16 enables the set of the features of the net device 
> > > > > > model to the
> > > > > > vdpa device at device start.
> > > > > >
> > > > > > Last ones enables the sepparated ASID and SVQ.
> > > > > >
> > > > > > Comments are welcomed.
> > > > >
> > > > >
> > > > > As discussed, I think we need to split this huge series into smaller 
> > > > > ones:
> > > > >
> > > > > 1) shadow CVQ only, this makes rx-filter-event work
> > > > > 2) ASID support for CVQ
> > > > >
> > > > > And for 1) we need consider whether or not it could be simplified.
> > > > >
> > > > > Or do it in reverse order, since if we do 1) first, we may have 
> > > > > security
> > > > > issues.
> > > > >
> > > >
> > > > I'm ok with both, but I also think 2) before 1) might make more sense.
> > > > There is no way to only shadow CVQ otherwise ATM.
> > > >
> > >
> > > On second thought, that order is kind of harder.
> > >
> > > If we only map CVQ buffers, we need to either:
> > > a. Copy them to controlled buffers
> > > b. Track properly when to unmap them
> >
> > Just to make sure we're at the same page:
> >
> > I meant we can start with e.g having a dedicated ASID for CVQ but
> > still using CVQ passthrough.
> >
>
> That would imply duplicating all the memory listener updates to both
> ASIDs. That part of the code needs to be reverted. I'm ok with that,
> but I'm not sure if it's worth it to do it that way.

I don't get why it is related to memory listeners. The only change is

1) read the groups
2) set cvq to be an independent asid
3) update CVQ's IOTLB with its own ASID

?

>
> > Then do other stuff on top.
> >
> > >
> > > Alternative a. have the same problems exposed in this RFC: It's hard
> > > (and unneeded in the final version) to know the size to copy.
> > > Alternative b. also requires things not needed in the final version,
> > > like to count the number of times each page is mapped and unmapped.
> > >
> > > So I'll go to the first alternative, that is also the proposed order
> > > of the RFC

[PATCH] target/ppc: cpu_init: Clean up stop state on cpu reset

2022-06-14 Thread Frederic Barrat
The 'resume_as_sreset' attribute of a cpu can be set when a thread is
entering a stop state on ppc books. It causes the thread to be
re-routed to vector 0x100 when woken up by an exception. So it must be
cleaned on reset or a thread might be re-routed unexpectedly after a
reset, when it was not in a stop state and/or when the appropriate
exception handler isn't set up yet.

Signed-off-by: Frederic Barrat 
---

I didn't find an appropriate commit to add a "Fixes:". It originates
when adding support for power management states but the code looked
quite different in 2016 and it's not clear whether we were supporting
reset then.

target/ppc/cpu_init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 0f891afa04..c16cb8dbe7 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -7186,6 +7186,9 @@ static void ppc_cpu_reset(DeviceState *dev)
 }
 pmu_update_summaries(env);
 }
+
+/* clean any pending stop state */
+env->resume_as_sreset = 0;
 #endif
 hreg_compute_hflags(env);
 env->reserve_addr = (target_ulong)-1ULL;
-- 
2.35.3




Re: [PATCH v1 3/7] gitlab-ci: Fix the build-cfi-aarch64 and build-cfi-ppc64-s390x jobs

2022-06-14 Thread Daniel P . Berrangé
On Tue, Jun 14, 2022 at 06:30:47AM +0200, Thomas Huth wrote:
> On 13/06/2022 23.46, Richard Henderson wrote:
> > On 6/13/22 10:12, Alex Bennée wrote:
> > > From: Thomas Huth 
> > > 
> > > The job definitions recently got a second "variables:" section by
> > > accident and thus are failing now if one tries to run them. Merge
> > > the two sections into one again to fix the issue.
> > > 
> > > And while we're at it, bump the timeout here (70 minutes are currently
> > > not enough for the aarch64 job). The jobs are marked as manual anyway,
> > > so if the user starts them, they want to see their result for sure and
> > > then it's annoying if the job timeouts too early.
> > > 
> > > Fixes: e312d1fdbb ("gitlab: convert build/container jobs to
> > > .base_job_template")
> > > Signed-off-by: Thomas Huth 
> > > Acked-by: Richard Henderson 
> > > Message-Id: <20220603124809.70794-1-th...@redhat.com>
> > > Signed-off-by: Alex Bennée 
> > > ---
> > >   .gitlab-ci.d/buildtest.yml | 22 ++
> > >   1 file changed, 10 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
> > > index 544385f5be..cb7cad44b5 100644
> > > --- a/.gitlab-ci.d/buildtest.yml
> > > +++ b/.gitlab-ci.d/buildtest.yml
> > > @@ -357,16 +357,15 @@ build-cfi-aarch64:
> > >     --enable-safe-stack --enable-slirp=git
> > >   TARGETS: aarch64-softmmu
> > >   MAKE_CHECK_ARGS: check-build
> > > -  timeout: 70m
> > > -  artifacts:
> > > -    expire_in: 2 days
> > > -    paths:
> > > -  - build
> > > -  variables:
> > >   # FIXME: This job is often failing, likely due to
> > > out-of-memory problems in
> > >   # the constrained containers of the shared runners. Thus this
> > > is marked as
> > >   # skipped until the situation has been solved.
> > >   QEMU_JOB_SKIPPED: 1
> > > +  timeout: 90m
> > > +  artifacts:
> > > +    expire_in: 2 days
> > > +    paths:
> > > +  - build
> > 
> > FWIW, 90 minutes was close, but insufficient:
> > 
> > https://gitlab.com/qemu-project/qemu/-/jobs/2584472225
> 
> Hmm, it was working at least once for me while I was working on the patch.
> But as I already wrote here:
> 
>  https://lists.gnu.org/archive/html/qemu-devel/2022-06/msg00463.html
> 
> I think nobody really used this build-cfi-aarch64 in month ... so we should
> maybe have a try with the 90 min timeout first (maybe the CI servers were
> just a little bit overloaded when you tried), but if the test continues to
> hit the 90 minutes timeout, I'd say we rather delete it instead of bumping
> the timeout even further. 90 minutes are really very close to the pain level
> already - at least for me.

The CFI jobs seem to massively slow down and timeout waaay
more often than any other job. I've seen the CFI jobs run
successfully in 45 minutes, and yet they frequently take so long
that they can't even complete in double that. CFI is certainly
slower at compile but not in a non-deterministic manner that
would randomly double compilation time. I would be willing to
blame CI overload if all our other jobs were showing similar
magnitude of slow down, but AFAIK, they are not showing this.
I worry that there are genuine problems with the CFI builds
that result in non-deterministic runtime problems in functional
testing. IOW not merely running slowly, but genuine hang


With 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: [PATCH v2 1/2] QIOChannelSocket: Reduce ifdefs to improve readability

2022-06-14 Thread Daniel P . Berrangé
On Mon, Jun 13, 2022 at 06:21:18PM -0300, Leonardo Bras Soares Passos wrote:
> On Fri, Jun 10, 2022 at 5:25 AM Daniel P. Berrangé  
> wrote:
> >
> 
> [...]
> 
> > Ok, so if it is checked earlier then we merely need an assert.
> >
> >  if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY) {
> >  #ifdef QEMU_MSG_ZEROCOPY
> >  sflags = MSG_ZEROCOPY;
> >  zero_copy_enabled = true;
> >  #else
> >  g_assert_unreachable();
> >  #endif
> > > }
> 
> Ok, I will add that in the next version.
> 
> >
> >
> >
> > > > > @@ -592,15 +594,13 @@ static ssize_t 
> > > > > qio_channel_socket_writev(QIOChannel *ioc,
> > > > >  return QIO_CHANNEL_ERR_BLOCK;
> > > > >  case EINTR:
> > > > >  goto retry;
> > > > > -#ifdef QEMU_MSG_ZEROCOPY
> > > > >  case ENOBUFS:
> > > > > -if (sflags & MSG_ZEROCOPY) {
> > > > > +if (zero_copy_enabled) {
> > > >
> > > > if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY)
> > > >
> > > > avoids the #ifdef without needing to add yet another
> > > > variable expressing what's already expressed in both
> > > > 'flags' and 'sflags'.
> > >
> > > Yes, it does, but at the cost of not compiling-out the zero-copy part
> > > when it's not supported,
> > > since the QIO_CHANNEL_WRITE_FLAG_ZERO_COPY comes as a parameter. This 
> > > ends up
> > > meaning there will be at least one extra test for every time this
> > > function is called (the one in the next patch).
> >
> > The cost of a simple bit test is between negligible-and-non-existant
> > with branch prediction. I doubt it would be possible to even measure
> > it.
> 
> Yeah, you are probably right on that.
> So the main learning point here is that it's not worth creating a new
> boolean for compiling-out
> code that should not impact performance ?

As ever "it depends" so there's no hard rule, and sometimes it can
verge on bikeshed colouring :-)

I didn't like the variable in this case, because it introduces a 3rd
variable to the method for representing whether zero copy is need,
which is excessive. I'm not a fan of redundancy as it can often then
lead to inconsistency. So it would need a compelling reason why it is
better, which is difficult for such a simple method. If the code was
more complex, a variable might have benefit of clarity, but in this
case IMHO it was just overkill.

With 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: [PATCH v3 2/2] QIOChannelSocket: Fix zero-copy send so socket flush works

2022-06-14 Thread Daniel P . Berrangé
On Tue, Jun 14, 2022 at 02:17:26AM -0300, Leonardo Bras wrote:
> Somewhere between v6 and v7 the of the zero-copy-send patchset a crucial
> part of the flushing mechanism got missing: incrementing zero_copy_queued.
> 
> Without that, the flushing interface becomes a no-op, and there is no
> guarantee the buffer is really sent.
> 
> This can go as bad as causing a corruption in RAM during migration.
> 
> Fixes: 2bc58ffc2926 ("QIOChannelSocket: Implement io_writev zero copy flag & 
> io_flush for CONFIG_LINUX")
> Reported-by: 徐闯 
> Signed-off-by: Leonardo Bras 
> ---
>  io/channel-socket.c | 5 +
>  1 file changed, 5 insertions(+)

Reviewed-by: Daniel P. Berrangé 


With 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: [PATCH v3 1/2] QIOChannelSocket: Introduce assert and reduce ifdefs to improve readability

2022-06-14 Thread Daniel P . Berrangé
On Tue, Jun 14, 2022 at 02:17:25AM -0300, Leonardo Bras wrote:
> During implementation of MSG_ZEROCOPY feature, a lot of #ifdefs were
> introduced, particularly at qio_channel_socket_writev().
> 
> Rewrite some of those changes so it's easier to read.
> 
> Also, introduce an assert to help detect incorrect zero-copy usage is when
> it's disabled on build.
> 
> Signed-off-by: Leonardo Bras 
> ---
>  io/channel-socket.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/io/channel-socket.c b/io/channel-socket.c
> index dc9c165de1..cdce7b0b45 100644
> --- a/io/channel-socket.c
> +++ b/io/channel-socket.c
> @@ -578,11 +578,13 @@ static ssize_t qio_channel_socket_writev(QIOChannel 
> *ioc,
>  memcpy(CMSG_DATA(cmsg), fds, fdsize);
>  }
>  
> -#ifdef QEMU_MSG_ZEROCOPY
>  if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY) {
> +#ifdef QEMU_MSG_ZEROCOPY
>  sflags = MSG_ZEROCOPY;
> -}
> +#else

I would just add a comment:

 /* We expect QIOChannel class entry point to have
blocked this code path already */

> +g_assert_unreachable();
>  #endif
> +}
>  
>   retry:
>  ret = sendmsg(sioc->fd, &msg, sflags);
> @@ -592,15 +594,13 @@ static ssize_t qio_channel_socket_writev(QIOChannel 
> *ioc,
>  return QIO_CHANNEL_ERR_BLOCK;
>  case EINTR:
>  goto retry;
> -#ifdef QEMU_MSG_ZEROCOPY
>  case ENOBUFS:
> -if (sflags & MSG_ZEROCOPY) {
> +if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY) {
>  error_setg_errno(errp, errno,
>   "Process can't lock enough memory for using 
> MSG_ZEROCOPY");
>  return -1;
>  }
>  break;
> -#endif
>  }
>  
>  error_setg_errno(errp, errno,

Reviewed-by: Daniel P. Berrangé 


With 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: [PATCH RFC 1/2] arm/kvm: enable MTE if available

2022-06-14 Thread Cornelia Huck
On Fri, Jun 10 2022, Eric Auger  wrote:

> Hi Connie,
> On 5/12/22 15:11, Cornelia Huck wrote:
>> We need to disable migration, as we do not yet have a way to migrate
>> the tags as well.
>
> This patch does much more than adding a migration blocker ;-) you may
> describe the new cpu option and how it works.

I admit this is a bit terse ;) The idea is to control mte at the cpu
level directly (and not indirectly via tag memory at the machine
level). I.e. the user gets whatever is available given the constraints
(host support etc.) if they don't specify anything, and they can
explicitly turn it off/on.

>> 
>> Signed-off-by: Cornelia Huck 
>> ---
>>  target/arm/cpu.c | 18 --
>>  target/arm/cpu.h |  4 +++
>>  target/arm/cpu64.c   | 78 
>>  target/arm/kvm64.c   |  5 +++
>>  target/arm/kvm_arm.h | 12 +++
>>  target/arm/monitor.c |  1 +
>>  6 files changed, 106 insertions(+), 12 deletions(-)
>> 
>> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
>> index 029f644768b1..f0505815b1e7 100644
>> --- a/target/arm/cpu.c
>> +++ b/target/arm/cpu.c
>> @@ -1435,6 +1435,11 @@ void arm_cpu_finalize_features(ARMCPU *cpu, Error 
>> **errp)
>>  error_propagate(errp, local_err);
>>  return;
>>  }
>> +arm_cpu_mte_finalize(cpu, &local_err);
>> +if (local_err != NULL) {
>> +error_propagate(errp, local_err);
>> +return;
>> +}
>>  }
>>  
>>  if (kvm_enabled()) {
>> @@ -1504,7 +1509,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
>> **errp)
>>  }
>>  if (cpu->tag_memory) {
>>  error_setg(errp,
>> -   "Cannot enable KVM when guest CPUs has MTE enabled");
>> +   "Cannot enable KVM when guest CPUs has tag memory 
>> enabled");
> before this series, tag_memory was used to detect MTE was enabled at
> machine level. And this was not compatible with KVM.
>
> Hasn't it changed now with this series? Sorry I don't know much about
> that tag_memory along with the KVM use case? Can you describe it as well
> in the cover letter.

IIU the current code correctly, the purpose of tag_memory is twofold:
- control whether mte should be available in the first place
- provide a place where a memory region used by the tcg implemtation can
  be linked

The latter part (extra memory region) is not compatible with
kvm. "Presence of extra memory for the implementation" as the knob to
configure mte for tcg makes sense, but it didn't seem right to me to use
it for kvm while controlling something which is basically a cpu property.

>>  return;
>>  }
>>  }

(...)

>> +void aarch64_add_mte_properties(Object *obj)
>> +{
>> +ARMCPU *cpu = ARM_CPU(obj);
>> +
>> +/*
>> + * For tcg, the machine type may provide tag memory for MTE emulation.
> s/machine type/machine?

Either, I guess, as only the virt machine type provides tag memory in
the first place.

>> + * We do not know whether that is the case at this point in time, so
>> + * default MTE to on and check later.
>> + * This preserves pre-existing behaviour, but is really a bit awkward.
>> + */
>> +qdev_property_add_static(DEVICE(obj), &arm_cpu_mte_property);
>> +if (kvm_enabled()) {
>> +/*
>> + * Default MTE to off, as long as migration support is not
>> + * yet implemented.
>> + * TODO: implement migration support for kvm
>> + */
>> +cpu->prop_mte = false;
>> +}
>> +}
>> +
>> +void arm_cpu_mte_finalize(ARMCPU *cpu, Error **errp)
>> +{
>> +if (!cpu->prop_mte) {
>> +/* Disable MTE feature bits. */
>> +cpu->isar.id_aa64pfr1 =
>> +FIELD_DP64(cpu->isar.id_aa64pfr1, ID_AA64PFR1, MTE, 0);
>> +return;
>> +}
>> +#ifndef CONFIG_USER_ONLY
>> +if (!kvm_enabled()) {
>> +if (cpu_isar_feature(aa64_mte, cpu) && !cpu->tag_memory) {
>> +/*
>> + * Disable the MTE feature bits, unless we have tag-memory
>> + * provided by the machine.
>> + * This silent downgrade is not really nice if the user had
>> + * explicitly requested MTE to be enabled by the cpu, but it
>> + * preserves pre-existing behaviour. In an ideal world, we
>
>
> Can't we "simply" prevent the end-user from using the prop_mte option
> with a TCG CPU? and have something like
>
> For TCG, MTE depends on the CPU feature availability + machine tag memory
> For KVM, MTE depends on the user opt-in + CPU feature avail (if
> relevant) + host VM capability (?)

I don't like kvm and tcg cpus behaving too differently... but then, tcg
is already different as it needs tag_memory.

Thinking about it, maybe we could repurpose tag_memory in the kvm case
(e.g. for a temporary buffer for migration purposes) and require it in
all cases (making kvm fail if the user specified tag memory, but the
host doesn't support it). A cpu

Re: [PATCH v2] docs: add PCIe root bus for VGA compat guideline

2022-06-14 Thread Gerd Hoffmann
On Mon, Jun 13, 2022 at 03:47:04PM +0200, Laszlo Ersek wrote:
> On 06/12/22 19:32, Kevin Locke wrote:
> > PCI Express devices which use legacy VGA compatibility should be placed
> > on the Root Complex.  This simplifies ioport access to VGA registers,
> > which requires use of a special exception bit to work across PCI(e)
> > bridges.  It is also necessary for ioport access to VESA BIOS Extension
> > (VBE) registers, which is not forwarded over PCI(e) bridges, even with
> > the special exception bit for VGA register access.[1]
> > 
> > Update the PCI Express Guidelines to add these to the list of devices
> > which can be placed directly on the Root Complex.
> > 
> > Note that the only PCI Express display devices currently supported
> > (bochs-display and virtio-gpu-pci) do not offer VGA compatibility.
> > Legacy PCI devices (e.g. vga, qxl-vga, virtio-vga) are already
> > documented as allowed on the Root Complex by the first item in the list.
> > However, this item documents an additional consideration for placing
> > devices which was not previously mentioned, and may be relevant for PCIe
> > devices offering VGA compatibility in the future.

Well, the *key* problem is emulated VGA devices with VBE registers in
io address space, because those are not forwarded over bridges.

For normal VGA registers this isn't much of a problem (in theory, not
fully sure whenever that holds in practice, Alex?).  The linux kernel
knows how to use the bridge control register to manage access to VGA
registers.

So, if the document already covers vga & qxl & virtio-vga (didn't check
that beforehand) I'm not sure we actually need an update ...

take care,
  Gerd




Re: [PATCH 1/5] tests/qemu-iotests: hotfix for 307, 223 output

2022-06-14 Thread Daniel P . Berrangé
On Mon, Jun 13, 2022 at 09:50:40PM -0400, John Snow wrote:
> Fixes: 58a6fdcc

CC'ing Eric given the above commit hash

> Signed-off-by: John Snow 
> ---
>  tests/qemu-iotests/223.out | 4 ++--
>  tests/qemu-iotests/307.out | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Tested-by: Daniel P. Berrangé 
Reviewed-by: Daniel P. Berrangé 

> 
> diff --git a/tests/qemu-iotests/223.out b/tests/qemu-iotests/223.out
> index 06479415312..26fb347c5da 100644
> --- a/tests/qemu-iotests/223.out
> +++ b/tests/qemu-iotests/223.out
> @@ -93,7 +93,7 @@ exports available: 3
>   export: 'n2'
>description: some text
>size:  4194304
> -  flags: 0xced ( flush fua trim zeroes df cache fast-zero )
> +  flags: 0xded ( flush fua trim zeroes df multi cache fast-zero )
>min block: 1
>opt block: 4096
>max block: 33554432
> @@ -212,7 +212,7 @@ exports available: 3
>   export: 'n2'
>description: some text
>size:  4194304
> -  flags: 0xced ( flush fua trim zeroes df cache fast-zero )
> +  flags: 0xded ( flush fua trim zeroes df multi cache fast-zero )
>min block: 1
>opt block: 4096
>max block: 33554432
> diff --git a/tests/qemu-iotests/307.out b/tests/qemu-iotests/307.out
> index ec8d2be0e0a..390f05d1b78 100644
> --- a/tests/qemu-iotests/307.out
> +++ b/tests/qemu-iotests/307.out
> @@ -83,7 +83,7 @@ exports available: 2
>   export: 'export1'
>description: This is the writable second export
>size:  67108864
> -  flags: 0xced ( flush fua trim zeroes df cache fast-zero )
> +  flags: 0xded ( flush fua trim zeroes df multi cache fast-zero )
>min block: XXX
>opt block: XXX
>max block: XXX
> @@ -109,7 +109,7 @@ exports available: 1
>   export: 'export1'
>description: This is the writable second export
>size:  67108864
> -  flags: 0xced ( flush fua trim zeroes df cache fast-zero )
> +  flags: 0xded ( flush fua trim zeroes df multi cache fast-zero )
>min block: XXX
>opt block: XXX
>max block: XXX
> -- 
> 2.34.3
> 

With 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: [PATCH] hw/mem/nvdimm: fix error message for 'unarmed' flag

2022-06-14 Thread Igor Mammedov
On Mon, 13 Jun 2022 16:09:53 +0100
Stefan Hajnoczi  wrote:

> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> > On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi  
> > wrote:  
> > >
> > > On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:  
> > > > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > > > cannot accept a persistent write. This means that when a memdev is
> > > > read-only, the 'unarmed' flag must be turned on. The logic is correct,
> > > > just changing the error message.
> > > >
> > > > [1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM State Flags" Bit 3
> > > >
> > > > Signed-off-by: Julia Suvorova 
> > > > ---
> > > >  hw/mem/nvdimm.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)  
> > >
> > > Reviewed-by: Stefan Hajnoczi   
> > 
> > It seems like Xiao is not active, whose tree should this patch go to?  

Perhaps David can add himself as maintainer (i.e. put it
under memory mantanership umbrella) and merge it 

> 
> Michael or Igor can merge it:
> 
>   $ scripts/get_maintainer.pl -f hw/mem/nvdimm.c
>   Xiao Guangrong  (maintainer:NVDIMM)
>   "Michael S. Tsirkin"  (supporter:ACPI/SMBIOS)
>   Igor Mammedov  (supporter:ACPI/SMBIOS)
>   Ani Sinha  (reviewer:ACPI/SMBIOS)
>   qemu-devel@nongnu.org (open list:All patches CC here)
> 
> Stefan




Re: [PATCH 2/5] tests/qemu-iotests: skip 108 when FUSE is not loaded

2022-06-14 Thread Daniel P . Berrangé
On Tue, Jun 14, 2022 at 06:46:35AM +0200, Thomas Huth wrote:
> On 14/06/2022 03.50, John Snow wrote:
> > In certain container environments we may not have FUSE at all, so skip
> > the test in this circumstance too.
> > 
> > Signed-off-by: John Snow 
> > ---
> >   tests/qemu-iotests/108 | 6 ++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
> > index 9e923d6a59f..e401c5e9933 100755
> > --- a/tests/qemu-iotests/108
> > +++ b/tests/qemu-iotests/108
> > @@ -60,6 +60,12 @@ if sudo -n losetup &>/dev/null; then
> >   else
> >   loopdev=false
> > +# Check for fuse support in the host environment:
> > +lsmod | grep fuse &>/dev/null;
> 
> That doesn't work if fuse has been linked statically into the kernel. Would
> it make sense to test for /sys/fs/fuse instead?
> 
> (OTOH, we likely hardly won't run this on statically linked kernels anyway,
> so it might not matter too much)

But more importantly 'lsmod' may not be installed in our container
images. So checking /sys/fs/fuse avoids introducing a dep on the
'kmod' package.

> 
> > +if [[ $? -ne 0 ]]; then
> 
> I'd prefer single "[" instead of "[[" ... but since we're requiring bash
> anyway, it likely doesn't matter.

Or

if  test $? != 0 ; then

> 
> > +_notrun 'No Passwordless sudo nor FUSE kernel module'
> > +fi
> > +
> >   # QSD --export fuse will either yield "Parameter 'id' is missing"
> >   # or "Invalid parameter 'fuse'", depending on whether there is
> >   # FUSE support or not.
> 
>  Thomas
> 

With 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 :|




[PATCH v16 0/9] Add LoongArch linux-user emulation support

2022-06-14 Thread Song Gao
Hi All,

This series add support linux-user emulation.
As the LoongArch kernel had merged into 5.19-rc1,
you can see the latest kernel at https://kernel.org

Need review patches:

  0002-linux-user-Add-LoongArch-signal-support.patch
  0007-target-loongarch-Adjust-functions-and-structure-to-s.patch
  0009-target-loongarch-Update-README.patch

V16:
  - Update signal.c;
  - Update helper_rdtime_d();
  - Update scripts/gensyscalls.sh, fixed a warning. 

v15:
  - Rebase;
  - Update README;
  - Adjust some functions and structure to support user-mode;
  - Update syscall;
  - Update target_sigcontext;


Old series:
   - https://patchew.org/QEMU/20220609024209.2406188-1-gaos...@loongson.cn/

Test:
   - user-mode:
   make check  && make check-tcg  &&  run LoongArch bash 
   - system-mode
   make check  && make check-tcg

Thanks.
Song Gao

Song Gao (9):
  linux-user: Add LoongArch generic header files
  linux-user: Add LoongArch signal support
  linux-user: Add LoongArch elf support
  linux-user: Add LoongArch syscall support
  linux-user: Add LoongArch cpu_loop support
  scripts: add loongarch64 binfmt config
  target/loongarch: Adjust functions and structure to support user-mode
  default-configs: Add loongarch linux-user support
  target/loongarch: Update README

 configs/targets/loongarch64-linux-user.mak|   3 +
 linux-user/elfload.c  |  54 +++
 linux-user/loongarch64/cpu_loop.c |  96 ++
 linux-user/loongarch64/signal.c   | 283 
 linux-user/loongarch64/sockbits.h |  11 +
 linux-user/loongarch64/syscall_nr.h   | 312 ++
 linux-user/loongarch64/target_cpu.h   |  34 ++
 linux-user/loongarch64/target_elf.h   |  12 +
 linux-user/loongarch64/target_errno_defs.h|  12 +
 linux-user/loongarch64/target_fcntl.h |  11 +
 linux-user/loongarch64/target_prctl.h |   1 +
 linux-user/loongarch64/target_resource.h  |  11 +
 linux-user/loongarch64/target_signal.h|  13 +
 linux-user/loongarch64/target_structs.h   |  11 +
 linux-user/loongarch64/target_syscall.h   |  48 +++
 linux-user/loongarch64/termbits.h |  11 +
 linux-user/syscall_defs.h |  10 +-
 scripts/gensyscalls.sh|   2 +
 scripts/qemu-binfmt-conf.sh   |   6 +-
 target/loongarch/README   |  39 ++-
 target/loongarch/cpu.c|  35 +-
 target/loongarch/cpu.h|   8 +-
 target/loongarch/gdbstub.c|   2 +-
 target/loongarch/helper.h |   2 +
 .../insn_trans/trans_privileged.c.inc |  36 ++
 target/loongarch/internals.h  |   2 +
 target/loongarch/op_helper.c  |  11 +-
 27 files changed, 1061 insertions(+), 15 deletions(-)
 create mode 100644 configs/targets/loongarch64-linux-user.mak
 create mode 100644 linux-user/loongarch64/cpu_loop.c
 create mode 100644 linux-user/loongarch64/signal.c
 create mode 100644 linux-user/loongarch64/sockbits.h
 create mode 100644 linux-user/loongarch64/syscall_nr.h
 create mode 100644 linux-user/loongarch64/target_cpu.h
 create mode 100644 linux-user/loongarch64/target_elf.h
 create mode 100644 linux-user/loongarch64/target_errno_defs.h
 create mode 100644 linux-user/loongarch64/target_fcntl.h
 create mode 100644 linux-user/loongarch64/target_prctl.h
 create mode 100644 linux-user/loongarch64/target_resource.h
 create mode 100644 linux-user/loongarch64/target_signal.h
 create mode 100644 linux-user/loongarch64/target_structs.h
 create mode 100644 linux-user/loongarch64/target_syscall.h
 create mode 100644 linux-user/loongarch64/termbits.h

-- 
2.31.1




[PATCH v16 8/9] default-configs: Add loongarch linux-user support

2022-06-14 Thread Song Gao
This patch adds loongarch64 linux-user default configs file.

Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
Reviewed-by: Richard Henderson 
Reviewed-by: WANG Xuerui 
---
 configs/targets/loongarch64-linux-user.mak | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 configs/targets/loongarch64-linux-user.mak

diff --git a/configs/targets/loongarch64-linux-user.mak 
b/configs/targets/loongarch64-linux-user.mak
new file mode 100644
index 00..7d1b964020
--- /dev/null
+++ b/configs/targets/loongarch64-linux-user.mak
@@ -0,0 +1,3 @@
+# Default configuration for loongarch64-linux-user
+TARGET_ARCH=loongarch64
+TARGET_BASE_ARCH=loongarch
-- 
2.31.1




[PATCH v16 5/9] linux-user: Add LoongArch cpu_loop support

2022-06-14 Thread Song Gao
Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
Reviewed-by: Richard Henderson 
---
 linux-user/loongarch64/cpu_loop.c   | 96 +
 linux-user/loongarch64/target_cpu.h | 34 ++
 2 files changed, 130 insertions(+)
 create mode 100644 linux-user/loongarch64/cpu_loop.c
 create mode 100644 linux-user/loongarch64/target_cpu.h

diff --git a/linux-user/loongarch64/cpu_loop.c 
b/linux-user/loongarch64/cpu_loop.c
new file mode 100644
index 00..894fdd111a
--- /dev/null
+++ b/linux-user/loongarch64/cpu_loop.c
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * QEMU LoongArch user cpu_loop.
+ *
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#include "qemu/osdep.h"
+#include "qemu.h"
+#include "user-internals.h"
+#include "cpu_loop-common.h"
+#include "signal-common.h"
+
+void cpu_loop(CPULoongArchState *env)
+{
+CPUState *cs = env_cpu(env);
+int trapnr, si_code;
+abi_long ret;
+
+for (;;) {
+cpu_exec_start(cs);
+trapnr = cpu_exec(cs);
+cpu_exec_end(cs);
+process_queued_cpu_work(cs);
+
+switch (trapnr) {
+case EXCP_INTERRUPT:
+/* just indicate that signals should be handled asap */
+break;
+case EXCCODE_SYS:
+env->pc += 4;
+ret = do_syscall(env, env->gpr[11],
+ env->gpr[4], env->gpr[5],
+ env->gpr[6], env->gpr[7],
+ env->gpr[8], env->gpr[9],
+ -1, -1);
+if (ret == -QEMU_ERESTARTSYS) {
+env->pc -= 4;
+break;
+}
+if (ret == -QEMU_ESIGRETURN) {
+/*
+ * Returning from a successful sigreturn syscall.
+ * Avoid clobbering register state.
+ */
+break;
+}
+env->gpr[4] = ret;
+break;
+case EXCCODE_INE:
+force_sig_fault(TARGET_SIGILL, 0, env->pc);
+break;
+case EXCCODE_FPE:
+si_code = TARGET_FPE_FLTUNK;
+if (GET_FP_CAUSE(env->fcsr0) & FP_INVALID) {
+si_code = TARGET_FPE_FLTINV;
+} else if (GET_FP_CAUSE(env->fcsr0) & FP_DIV0) {
+si_code = TARGET_FPE_FLTDIV;
+} else if (GET_FP_CAUSE(env->fcsr0) & FP_OVERFLOW) {
+si_code = TARGET_FPE_FLTOVF;
+} else if (GET_FP_CAUSE(env->fcsr0) & FP_UNDERFLOW) {
+si_code = TARGET_FPE_FLTUND;
+} else if (GET_FP_CAUSE(env->fcsr0) & FP_INEXACT) {
+si_code = TARGET_FPE_FLTRES;
+}
+force_sig_fault(TARGET_SIGFPE, si_code, env->pc);
+break;
+case EXCP_DEBUG:
+case EXCCODE_BRK:
+force_sig_fault(TARGET_SIGTRAP, TARGET_TRAP_BRKPT, env->pc);
+break;
+case EXCCODE_BCE:
+force_sig_fault(TARGET_SIGSYS, TARGET_SI_KERNEL, env->pc);
+break;
+case EXCP_ATOMIC:
+cpu_exec_step_atomic(cs);
+break;
+default:
+EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n",
+  trapnr);
+exit(EXIT_FAILURE);
+}
+process_pending_signals(env);
+}
+}
+
+void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs)
+{
+int i;
+
+for (i = 0; i < 32; i++) {
+env->gpr[i] = regs->regs[i];
+}
+env->pc = regs->csr.era;
+
+}
diff --git a/linux-user/loongarch64/target_cpu.h 
b/linux-user/loongarch64/target_cpu.h
new file mode 100644
index 00..a29af66156
--- /dev/null
+++ b/linux-user/loongarch64/target_cpu.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * LoongArch specific CPU ABI and functions for linux-user
+ *
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_CPU_H
+#define LOONGARCH_TARGET_CPU_H
+
+static inline void cpu_clone_regs_child(CPULoongArchState *env,
+target_ulong newsp, unsigned flags)
+{
+if (newsp) {
+env->gpr[3] = newsp;
+}
+env->gpr[4] = 0;
+}
+
+static inline void cpu_clone_regs_parent(CPULoongArchState *env,
+ unsigned flags)
+{
+}
+
+static inline void cpu_set_tls(CPULoongArchState *env, target_ulong newtls)
+{
+env->gpr[2] = newtls;
+}
+
+static inline abi_ulong get_sp_from_cpustate(CPULoongArchState *state)
+{
+return state->gpr[3];
+}
+#endif
-- 
2.31.1




[PATCH v16 6/9] scripts: add loongarch64 binfmt config

2022-06-14 Thread Song Gao
Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
Reviewed-by: Richard Henderson 
---
 scripts/qemu-binfmt-conf.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index 9cb723f443..1f4e2cd19d 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -4,7 +4,7 @@
 qemu_target_list="i386 i486 alpha arm armeb sparc sparc32plus sparc64 \
 ppc ppc64 ppc64le m68k mips mipsel mipsn32 mipsn32el mips64 mips64el \
 sh4 sh4eb s390x aarch64 aarch64_be hppa riscv32 riscv64 xtensa xtensaeb \
-microblaze microblazeel or1k x86_64 hexagon"
+microblaze microblazeel or1k x86_64 hexagon loongarch64"
 
 
i386_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00'
 
i386_mask='\xff\xff\xff\xff\xff\xfe\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
@@ -140,6 +140,10 @@ 
hexagon_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x
 
hexagon_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
 hexagon_family=hexagon
 
+loongarch64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02\x01'
+loongarch64_mask='\xff\xff\xff\xff\xff\xff\xff\xfc\x00\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+loongarch64_family=loongarch
+
 qemu_get_family() {
 cpu=${HOST_ARCH:-$(uname -m)}
 case "$cpu" in
-- 
2.31.1




[PATCH v16 3/9] linux-user: Add LoongArch elf support

2022-06-14 Thread Song Gao
Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
---
 linux-user/elfload.c| 54 +
 linux-user/loongarch64/target_elf.h | 12 +++
 2 files changed, 66 insertions(+)
 create mode 100644 linux-user/loongarch64/target_elf.h

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index f7eae357f4..01692110c4 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -918,6 +918,60 @@ static void elf_core_copy_regs(target_elf_gregset_t *regs, 
const CPUPPCState *en
 
 #endif
 
+#ifdef TARGET_LOONGARCH64
+
+#define ELF_START_MMAP 0x8000
+
+#define ELF_CLASS   ELFCLASS64
+#define ELF_ARCHEM_LOONGARCH
+
+#define elf_check_arch(x) ((x) == EM_LOONGARCH)
+static inline void init_thread(struct target_pt_regs *regs,
+   struct image_info *infop)
+{
+/*Set crmd PG,DA = 1,0 */
+regs->csr.crmd = 2 << 3;
+regs->csr.era = infop->entry;
+regs->regs[3] = infop->start_stack;
+}
+
+/* See linux kernel: arch/loongarch/include/asm/elf.h.  */
+#define ELF_NREG 45
+typedef target_elf_greg_t target_elf_gregset_t[ELF_NREG];
+
+enum {
+TARGET_EF_R0 = 0,
+TARGET_EF_CSR_ERA = TARGET_EF_R0 + 33,
+TARGET_EF_CSR_BADV = TARGET_EF_R0 + 34,
+};
+
+static void elf_core_copy_regs(target_elf_gregset_t *regs,
+   const CPULoongArchState *env)
+{
+int i;
+
+(*regs)[TARGET_EF_R0] = 0;
+
+for (i = 1; i < ARRAY_SIZE(env->gpr); i++) {
+(*regs)[TARGET_EF_R0 + i] = tswapreg(env->gpr[i]);
+}
+
+(*regs)[TARGET_EF_CSR_ERA] = tswapreg(env->pc);
+(*regs)[TARGET_EF_CSR_BADV] = tswapreg(env->badaddr);
+}
+
+#define USE_ELF_CORE_DUMP
+#define ELF_EXEC_PAGESIZE4096
+
+#define ELF_HWCAP get_elf_hwcap()
+
+static uint32_t get_elf_hwcap(void)
+{
+return 0;
+}
+
+#endif /* TARGET_LOONGARCH64 */
+
 #ifdef TARGET_MIPS
 
 #define ELF_START_MMAP 0x8000
diff --git a/linux-user/loongarch64/target_elf.h 
b/linux-user/loongarch64/target_elf.h
new file mode 100644
index 00..95c3f05a46
--- /dev/null
+++ b/linux-user/loongarch64/target_elf.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_ELF_H
+#define LOONGARCH_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "la464";
+}
+#endif
-- 
2.31.1




[PATCH v16 1/9] linux-user: Add LoongArch generic header files

2022-06-14 Thread Song Gao
This includes:
- sockbits.h
- target_errno_defs.h
- target_fcntl.h
- termbits.h
- target_resource.h
- target_structs.h

Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: WANG Xuerui 
---
 linux-user/loongarch64/sockbits.h  | 11 +++
 linux-user/loongarch64/target_errno_defs.h | 12 
 linux-user/loongarch64/target_fcntl.h  | 11 +++
 linux-user/loongarch64/target_prctl.h  |  1 +
 linux-user/loongarch64/target_resource.h   | 11 +++
 linux-user/loongarch64/target_structs.h| 11 +++
 linux-user/loongarch64/termbits.h  | 11 +++
 7 files changed, 68 insertions(+)
 create mode 100644 linux-user/loongarch64/sockbits.h
 create mode 100644 linux-user/loongarch64/target_errno_defs.h
 create mode 100644 linux-user/loongarch64/target_fcntl.h
 create mode 100644 linux-user/loongarch64/target_prctl.h
 create mode 100644 linux-user/loongarch64/target_resource.h
 create mode 100644 linux-user/loongarch64/target_structs.h
 create mode 100644 linux-user/loongarch64/termbits.h

diff --git a/linux-user/loongarch64/sockbits.h 
b/linux-user/loongarch64/sockbits.h
new file mode 100644
index 00..1cffcae120
--- /dev/null
+++ b/linux-user/loongarch64/sockbits.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_SOCKBITS_H
+#define LOONGARCH_TARGET_SOCKBITS_H
+
+#include "../generic/sockbits.h"
+
+#endif
diff --git a/linux-user/loongarch64/target_errno_defs.h 
b/linux-user/loongarch64/target_errno_defs.h
new file mode 100644
index 00..c198b8aca9
--- /dev/null
+++ b/linux-user/loongarch64/target_errno_defs.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_ERRNO_DEFS_H
+#define LOONGARCH_TARGET_ERRNO_DEFS_H
+
+/* Target uses generic errno */
+#include "../generic/target_errno_defs.h"
+
+#endif
diff --git a/linux-user/loongarch64/target_fcntl.h 
b/linux-user/loongarch64/target_fcntl.h
new file mode 100644
index 00..99bf586854
--- /dev/null
+++ b/linux-user/loongarch64/target_fcntl.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_FCNTL_H
+#define LOONGARCH_TARGET_FCNTL_H
+
+#include "../generic/fcntl.h"
+
+#endif
diff --git a/linux-user/loongarch64/target_prctl.h 
b/linux-user/loongarch64/target_prctl.h
new file mode 100644
index 00..eb53b31ad5
--- /dev/null
+++ b/linux-user/loongarch64/target_prctl.h
@@ -0,0 +1 @@
+/* No special prctl support required. */
diff --git a/linux-user/loongarch64/target_resource.h 
b/linux-user/loongarch64/target_resource.h
new file mode 100644
index 00..0f86bf24ee
--- /dev/null
+++ b/linux-user/loongarch64/target_resource.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_RESOURCE_H
+#define LOONGARCH_TARGET_RESOURCE_H
+
+#include "../generic/target_resource.h"
+
+#endif
diff --git a/linux-user/loongarch64/target_structs.h 
b/linux-user/loongarch64/target_structs.h
new file mode 100644
index 00..6041441e15
--- /dev/null
+++ b/linux-user/loongarch64/target_structs.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_STRUCTS_H
+#define LOONGARCH_TARGET_STRUCTS_H
+
+#include "../generic/target_structs.h"
+
+#endif
diff --git a/linux-user/loongarch64/termbits.h 
b/linux-user/loongarch64/termbits.h
new file mode 100644
index 00..d425db8748
--- /dev/null
+++ b/linux-user/loongarch64/termbits.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#ifndef LOONGARCH_TARGET_TERMBITS_H
+#define LOONGARCH_TARGET_TERMBITS_H
+
+#include "../generic/termbits.h"
+
+#endif
-- 
2.31.1




Re: [PATCH 05/11] ppc/pnv: make pnv_ics_get() use the chip8->phbs[] array

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

The function is working today by getting all the child objects of the
chip, interacting with each of them to check whether the child is a PHB,
and then doing what needs to be done.

We have all the chip PHBs in the phbs[] array so interacting with all
child objects is unneeded.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/ppc/pnv.c | 30 ++
  1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 40e0cbd84d..05a8d5034f 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1944,41 +1944,39 @@ typedef struct ForeachPhb3Args {
  ICSState *ics;
  } ForeachPhb3Args;
  
-static int pnv_ics_get_child(Object *child, void *opaque)

+static void pnv_ics_get_phb_ics(PnvPHB3 *phb3, ForeachPhb3Args *args)
  {
-ForeachPhb3Args *args = opaque;
-PnvPHB3 *phb3 = (PnvPHB3 *) object_dynamic_cast(child, TYPE_PNV_PHB3);
+if (ics_valid_irq(&phb3->lsis, args->irq)) {
+args->ics = &phb3->lsis;
+}
  
-if (phb3) {

-if (ics_valid_irq(&phb3->lsis, args->irq)) {
-args->ics = &phb3->lsis;
-}
-if (ics_valid_irq(ICS(&phb3->msis), args->irq)) {
-args->ics = ICS(&phb3->msis);
-}
+if (ics_valid_irq(ICS(&phb3->msis), args->irq)) {
+args->ics = ICS(&phb3->msis);
  }
-return args->ics ? 1 : 0;
  }



It seems that we could gain in readability by dropping the 
ForeachPhb3Args structure completely.
The 'irq' member can just be an input argument to the function instead 
of the full structure.
The 'ics' member is no longer needed, it can be the returned value of 
the function (instead of void)


  Fred


  
  static ICSState *pnv_ics_get(XICSFabric *xi, int irq)

  {
  PnvMachineState *pnv = PNV_MACHINE(xi);
  ForeachPhb3Args args = { irq, NULL };
-int i;
+int i, j;
  
  for (i = 0; i < pnv->num_chips; i++) {

-PnvChip *chip = pnv->chips[i];
  Pnv8Chip *chip8 = PNV8_CHIP(pnv->chips[i]);
  
  if (ics_valid_irq(&chip8->psi.ics, irq)) {

  return &chip8->psi.ics;
  }
  
-object_child_foreach(OBJECT(chip), pnv_ics_get_child, &args);

-if (args.ics) {
-return args.ics;
+for (j = 0; j < chip8->num_phbs; j++) {
+pnv_ics_get_phb_ics(&chip8->phbs[j], &args);
+
+if (args.ics) {
+return args.ics;
+}
  }
  }
+
  return NULL;
  }
  




[PATCH v16 7/9] target/loongarch: Adjust functions and structure to support user-mode

2022-06-14 Thread Song Gao
Some functions and member of the structure are different with softmmu-mode
So we need adjust them to support user-mode.

Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
---
 linux-user/elfload.c  |  2 +-
 target/loongarch/cpu.c| 35 +++---
 target/loongarch/cpu.h|  8 -
 target/loongarch/gdbstub.c|  2 +-
 target/loongarch/helper.h |  2 ++
 .../insn_trans/trans_privileged.c.inc | 36 +++
 target/loongarch/internals.h  |  2 ++
 target/loongarch/op_helper.c  | 11 --
 8 files changed, 88 insertions(+), 10 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 01692110c4..721469a8ed 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -957,7 +957,7 @@ static void elf_core_copy_regs(target_elf_gregset_t *regs,
 }
 
 (*regs)[TARGET_EF_CSR_ERA] = tswapreg(env->pc);
-(*regs)[TARGET_EF_CSR_BADV] = tswapreg(env->badaddr);
+(*regs)[TARGET_EF_CSR_BADV] = tswapreg(env->badvaddr);
 }
 
 #define USE_ELF_CORE_DUMP
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 4c8f96bc3a..dc669af6df 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -18,7 +18,6 @@
 #include "fpu/softfloat-helpers.h"
 #include "cpu-csr.h"
 #include "sysemu/reset.h"
-#include "hw/loader.h"
 
 const char * const regnames[32] = {
 "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
@@ -51,6 +50,7 @@ static const char * const excp_names[] = {
 [EXCCODE_IPE] = "Instruction privilege error",
 [EXCCODE_FPE] = "Floating Point Exception",
 [EXCCODE_DBP] = "Debug breakpoint",
+[EXCCODE_BCE] = "Bound Check Exception",
 };
 
 const char *loongarch_exception_name(int32_t exception)
@@ -82,6 +82,7 @@ static void loongarch_cpu_set_pc(CPUState *cs, vaddr value)
 env->pc = value;
 }
 
+#ifndef CONFIG_USER_ONLY
 #include "hw/loongarch/virt.h"
 
 void loongarch_cpu_set_irq(void *opaque, int irq, int level)
@@ -172,17 +173,20 @@ static void loongarch_cpu_do_interrupt(CPUState *cs)
 update_badinstr = 0;
 break;
 case EXCCODE_ADEM:
+case EXCCODE_BCE:
 case EXCCODE_SYS:
 case EXCCODE_BRK:
+case EXCCODE_INE:
+case EXCCODE_IPE:
+case EXCCODE_FPE:
+env->badvaddr = env->pc;
+QEMU_FALLTHROUGH;
 case EXCCODE_PIL:
 case EXCCODE_PIS:
 case EXCCODE_PME:
 case EXCCODE_PNR:
 case EXCCODE_PNX:
 case EXCCODE_PPI:
-case EXCCODE_INE:
-case EXCCODE_IPE:
-case EXCCODE_FPE:
 cause = cs->exception_index;
 break;
 default:
@@ -292,6 +296,7 @@ static bool loongarch_cpu_exec_interrupt(CPUState *cs, int 
interrupt_request)
 }
 return false;
 }
+#endif
 
 #ifdef CONFIG_TCG
 static void loongarch_cpu_synchronize_from_tb(CPUState *cs,
@@ -306,6 +311,9 @@ static void loongarch_cpu_synchronize_from_tb(CPUState *cs,
 
 static bool loongarch_cpu_has_work(CPUState *cs)
 {
+#ifdef CONFIG_USER_ONLY
+return true;
+#else
 LoongArchCPU *cpu = LOONGARCH_CPU(cs);
 CPULoongArchState *env = &cpu->env;
 bool has_work = false;
@@ -316,6 +324,7 @@ static bool loongarch_cpu_has_work(CPUState *cs)
 }
 
 return has_work;
+#endif
 }
 
 static void loongarch_la464_initfn(Object *obj)
@@ -464,7 +473,9 @@ static void loongarch_cpu_reset(DeviceState *dev)
 env->CSR_DMW[n] = FIELD_DP64(env->CSR_DMW[n], CSR_DMW, PLV3, 0);
 }
 
+#ifndef CONFIG_USER_ONLY
 env->pc = 0x1c00;
+#endif
 
 restore_fp_status(env);
 cs->exception_index = -1;
@@ -495,6 +506,7 @@ static void loongarch_cpu_realizefn(DeviceState *dev, Error 
**errp)
 lacc->parent_realize(dev, errp);
 }
 
+#ifndef CONFIG_USER_ONLY
 static void loongarch_qemu_write(void *opaque, hwaddr addr,
  uint64_t val, unsigned size)
 {
@@ -529,13 +541,16 @@ static const MemoryRegionOps loongarch_qemu_ops = {
 .max_access_size = 8,
 },
 };
+#endif
 
 static void loongarch_cpu_init(Object *obj)
 {
 LoongArchCPU *cpu = LOONGARCH_CPU(obj);
-CPULoongArchState *env = &cpu->env;
 
 cpu_set_cpustate_pointers(cpu);
+
+#ifndef CONFIG_USER_ONLY
+CPULoongArchState *env = &cpu->env;
 qdev_init_gpio_in(DEVICE(cpu), loongarch_cpu_set_irq, N_IRQS);
 timer_init_ns(&cpu->timer, QEMU_CLOCK_VIRTUAL,
   &loongarch_constant_timer_cb, cpu);
@@ -545,6 +560,7 @@ static void loongarch_cpu_init(Object *obj)
 memory_region_init_io(&env->iocsr_mem, OBJECT(cpu), &loongarch_qemu_ops,
   NULL, "iocsr_misc", 0x428);
 memory_region_add_subregion(&env->system_iocsr, 0, &env->iocsr_mem);
+#endif
 }
 
 static ObjectClass *loongarch_cpu_class_by_name(const char *cpu_model)
@@ -579,6 +595,7 @@ void loongarch_cpu_dump_state(CPUState *cs, FILE *f, int 
flags)
 }
 }
 
+#ifndef CONFIG_USER_ONLY
 qemu_fprintf(f, "CRMD=%016" PRIx64 "\n",

[PATCH v16 2/9] linux-user: Add LoongArch signal support

2022-06-14 Thread Song Gao
Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
---
 linux-user/loongarch64/signal.c| 283 +
 linux-user/loongarch64/target_signal.h |  13 ++
 2 files changed, 296 insertions(+)
 create mode 100644 linux-user/loongarch64/signal.c
 create mode 100644 linux-user/loongarch64/target_signal.h

diff --git a/linux-user/loongarch64/signal.c b/linux-user/loongarch64/signal.c
new file mode 100644
index 00..ff7c5d611b
--- /dev/null
+++ b/linux-user/loongarch64/signal.c
@@ -0,0 +1,283 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * LoongArch emulation of Linux signals
+ *
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#include "qemu/osdep.h"
+#include "qemu.h"
+#include "user-internals.h"
+#include "signal-common.h"
+#include "linux-user/trace.h"
+
+#include "target/loongarch/internals.h"
+
+/* FP context was used */
+#define SC_USED_FP  (1 << 0)
+
+struct target_sigcontext {
+uint64_t sc_pc;
+uint64_t sc_regs[32];
+uint32_t sc_flags;
+uint64_t sc_extcontext[0] __attribute__((aligned(16)));
+};
+
+struct target_fpu_context {
+uint64_t regs[32];
+uint64_t fcc;
+uint32_t fcsr;
+};
+
+struct target_sctx_info {
+uint32_t magic;
+uint32_t size;
+uint64_t padding;  /* padding to 16 bytes */
+};
+
+struct target_ucontext {
+target_ulong tuc_flags;
+struct target_ucontext *tuc_link;
+target_stack_t tuc_stack;
+target_sigset_t tuc_sigmask;
+uint8_t __unused[1024 / 8 - sizeof(target_sigset_t)];
+struct target_sigcontext tuc_mcontext;
+};
+
+struct target_rt_sigframe {
+struct target_siginfo rs_info;
+struct target_ucontext rs_uc;
+};
+
+struct target_ctx_layout {
+struct target_sctx_info *addr;
+unsigned int size;
+};
+
+struct target_extctx_layout {
+unsigned long size;
+unsigned int flags;
+struct target_ctx_layout fpu;
+struct target_ctx_layout end;
+};
+
+static uint64_t read_all_fcc(CPULoongArchState *env)
+{
+uint64_t ret = 0;
+
+for (int i = 0; i < 8; ++i) {
+ret |= (uint64_t)env->cf[i] << (i * 8);
+}
+
+return ret;
+}
+
+static void write_all_fcc(CPULoongArchState *env, uint64_t val)
+{
+for (int i = 0; i < 8; ++i) {
+env->cf[i] = (val >> (i * 8)) & 1;
+}
+}
+
+static void *get_ctx(struct target_sctx_info *info)
+{
+return (void *)((char *)info + sizeof(struct target_sctx_info));
+}
+
+static void copy_fpu_to_sigcontext(CPULoongArchState *env,
+   struct target_extctx_layout *extctx)
+{
+int i;
+struct target_sctx_info *info = extctx->fpu.addr;
+struct target_fpu_context *fpu_ctx = (struct target_fpu_context *)
+ get_ctx(info);
+
+for (i = 1; i < 32; ++i) {
+__put_user(env->fpr[i], &fpu_ctx->regs[i]);
+}
+
+fpu_ctx->fcc = read_all_fcc(env);
+__put_user(env->fcsr0, &fpu_ctx->fcsr);
+__put_user(extctx->fpu.size, &info->size);
+}
+
+static unsigned long extframe_alloc(struct target_extctx_layout *extctx,
+struct target_ctx_layout *layout,
+size_t size, unsigned long base)
+{
+unsigned long new_base = base - size;
+
+new_base -= sizeof(struct target_sctx_info);
+layout->addr = (void *)new_base;
+layout->size = (unsigned int)(base - new_base);
+extctx->size += layout->size;
+
+return new_base;
+}
+
+static unsigned long setup_extcontext(struct target_extctx_layout *extctx,
+  unsigned long sp)
+{
+unsigned long new_sp = sp;
+
+memset(extctx, 0, sizeof(struct target_extctx_layout));
+new_sp -= sizeof(struct target_sctx_info);
+
+extctx->end.addr = (void *) new_sp;
+extctx->end.size = (unsigned int)sizeof(struct target_sctx_info);
+extctx->size += extctx->end.size;
+extctx->flags = SC_USED_FP;
+
+new_sp = extframe_alloc(extctx, &extctx->fpu,
+sizeof(struct target_fpu_context), new_sp);
+
+return new_sp;
+}
+
+static void setup_sigcontext(CPULoongArchState *env,
+ struct target_sigcontext *sc,
+ struct target_extctx_layout *extctx)
+{
+int i;
+
+__put_user(extctx->flags, &sc->sc_flags);
+__put_user(env->pc, &sc->sc_pc);
+
+for (i = 1; i < 32; ++i) {
+__put_user(env->gpr[i], &sc->sc_regs[i]);
+}
+
+copy_fpu_to_sigcontext(env, extctx);
+}
+
+static void copy_fpu_from_sigcontext(CPULoongArchState *env,
+ struct target_extctx_layout *extctx)
+{
+int i;
+struct target_sctx_info *info = extctx->fpu.addr;
+struct target_fpu_context *fpu_ctx = (struct target_fpu_context *)
+ get_ctx(info);
+
+for (i = 1; i < 32; ++i) {
+__get_user(env->fpr[i], &fpu_ctx->regs[i]);
+}
+write_all_fcc(env, fpu_ctx->fcc);
+__get_

[PATCH v16 4/9] linux-user: Add LoongArch syscall support

2022-06-14 Thread Song Gao
Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
---
 linux-user/loongarch64/syscall_nr.h | 312 
 linux-user/loongarch64/target_syscall.h |  48 
 linux-user/syscall_defs.h   |  10 +-
 scripts/gensyscalls.sh  |   2 +
 4 files changed, 369 insertions(+), 3 deletions(-)
 create mode 100644 linux-user/loongarch64/syscall_nr.h
 create mode 100644 linux-user/loongarch64/target_syscall.h

diff --git a/linux-user/loongarch64/syscall_nr.h 
b/linux-user/loongarch64/syscall_nr.h
new file mode 100644
index 00..be00915adf
--- /dev/null
+++ b/linux-user/loongarch64/syscall_nr.h
@@ -0,0 +1,312 @@
+/*
+ * This file contains the system call numbers.
+ * Do not modify.
+ * This file is generated by scripts/gensyscalls.sh
+ */
+#ifndef LINUX_USER_LOONGARCH_SYSCALL_NR_H
+#define LINUX_USER_LOONGARCH_SYSCALL_NR_H
+
+#define TARGET_NR_io_setup 0
+#define TARGET_NR_io_destroy 1
+#define TARGET_NR_io_submit 2
+#define TARGET_NR_io_cancel 3
+#define TARGET_NR_io_getevents 4
+#define TARGET_NR_setxattr 5
+#define TARGET_NR_lsetxattr 6
+#define TARGET_NR_fsetxattr 7
+#define TARGET_NR_getxattr 8
+#define TARGET_NR_lgetxattr 9
+#define TARGET_NR_fgetxattr 10
+#define TARGET_NR_listxattr 11
+#define TARGET_NR_llistxattr 12
+#define TARGET_NR_flistxattr 13
+#define TARGET_NR_removexattr 14
+#define TARGET_NR_lremovexattr 15
+#define TARGET_NR_fremovexattr 16
+#define TARGET_NR_getcwd 17
+#define TARGET_NR_lookup_dcookie 18
+#define TARGET_NR_eventfd2 19
+#define TARGET_NR_epoll_create1 20
+#define TARGET_NR_epoll_ctl 21
+#define TARGET_NR_epoll_pwait 22
+#define TARGET_NR_dup 23
+#define TARGET_NR_dup3 24
+#define TARGET_NR_fcntl 25
+#define TARGET_NR_inotify_init1 26
+#define TARGET_NR_inotify_add_watch 27
+#define TARGET_NR_inotify_rm_watch 28
+#define TARGET_NR_ioctl 29
+#define TARGET_NR_ioprio_set 30
+#define TARGET_NR_ioprio_get 31
+#define TARGET_NR_flock 32
+#define TARGET_NR_mknodat 33
+#define TARGET_NR_mkdirat 34
+#define TARGET_NR_unlinkat 35
+#define TARGET_NR_symlinkat 36
+#define TARGET_NR_linkat 37
+#define TARGET_NR_umount2 39
+#define TARGET_NR_mount 40
+#define TARGET_NR_pivot_root 41
+#define TARGET_NR_nfsservctl 42
+#define TARGET_NR_statfs 43
+#define TARGET_NR_fstatfs 44
+#define TARGET_NR_truncate 45
+#define TARGET_NR_ftruncate 46
+#define TARGET_NR_fallocate 47
+#define TARGET_NR_faccessat 48
+#define TARGET_NR_chdir 49
+#define TARGET_NR_fchdir 50
+#define TARGET_NR_chroot 51
+#define TARGET_NR_fchmod 52
+#define TARGET_NR_fchmodat 53
+#define TARGET_NR_fchownat 54
+#define TARGET_NR_fchown 55
+#define TARGET_NR_openat 56
+#define TARGET_NR_close 57
+#define TARGET_NR_vhangup 58
+#define TARGET_NR_pipe2 59
+#define TARGET_NR_quotactl 60
+#define TARGET_NR_getdents64 61
+#define TARGET_NR_lseek 62
+#define TARGET_NR_read 63
+#define TARGET_NR_write 64
+#define TARGET_NR_readv 65
+#define TARGET_NR_writev 66
+#define TARGET_NR_pread64 67
+#define TARGET_NR_pwrite64 68
+#define TARGET_NR_preadv 69
+#define TARGET_NR_pwritev 70
+#define TARGET_NR_sendfile 71
+#define TARGET_NR_pselect6 72
+#define TARGET_NR_ppoll 73
+#define TARGET_NR_signalfd4 74
+#define TARGET_NR_vmsplice 75
+#define TARGET_NR_splice 76
+#define TARGET_NR_tee 77
+#define TARGET_NR_readlinkat 78
+#define TARGET_NR_sync 81
+#define TARGET_NR_fsync 82
+#define TARGET_NR_fdatasync 83
+#define TARGET_NR_sync_file_range 84
+#define TARGET_NR_timerfd_create 85
+#define TARGET_NR_timerfd_settime 86
+#define TARGET_NR_timerfd_gettime 87
+#define TARGET_NR_utimensat 88
+#define TARGET_NR_acct 89
+#define TARGET_NR_capget 90
+#define TARGET_NR_capset 91
+#define TARGET_NR_personality 92
+#define TARGET_NR_exit 93
+#define TARGET_NR_exit_group 94
+#define TARGET_NR_waitid 95
+#define TARGET_NR_set_tid_address 96
+#define TARGET_NR_unshare 97
+#define TARGET_NR_futex 98
+#define TARGET_NR_set_robust_list 99
+#define TARGET_NR_get_robust_list 100
+#define TARGET_NR_nanosleep 101
+#define TARGET_NR_getitimer 102
+#define TARGET_NR_setitimer 103
+#define TARGET_NR_kexec_load 104
+#define TARGET_NR_init_module 105
+#define TARGET_NR_delete_module 106
+#define TARGET_NR_timer_create 107
+#define TARGET_NR_timer_gettime 108
+#define TARGET_NR_timer_getoverrun 109
+#define TARGET_NR_timer_settime 110
+#define TARGET_NR_timer_delete 111
+#define TARGET_NR_clock_settime 112
+#define TARGET_NR_clock_gettime 113
+#define TARGET_NR_clock_getres 114
+#define TARGET_NR_clock_nanosleep 115
+#define TARGET_NR_syslog 116
+#define TARGET_NR_ptrace 117
+#define TARGET_NR_sched_setparam 118
+#define TARGET_NR_sched_setscheduler 119
+#define TARGET_NR_sched_getscheduler 120
+#define TARGET_NR_sched_getparam 121
+#define TARGET_NR_sched_setaffinity 122
+#define TARGET_NR_sched_getaffinity 123
+#define TARGET_NR_sched_yield 124
+#define TARGET_NR_sched_get_priority_max 125
+#define TARGET_NR_sched_get_priority_min 126
+#define TARGET_NR_s

Re: [PATCH 01/11] ppc/pnv: move root port attach to pnv_phb4_realize()

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

Creating a root port is something related to the PHB, not the PEC. It
also makes the logic more in line with what pnv-phb3 does.

Signed-off-by: Daniel Henrique Barboza 
---


LGTM,
Reviewed-by: Frederic Barrat 

  Fred



  hw/pci-host/pnv_phb4.c | 4 
  hw/pci-host/pnv_phb4_pec.c | 3 ---
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 6594016121..23ad8de7ee 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1547,6 +1547,7 @@ static void pnv_phb4_instance_init(Object *obj)
  static void pnv_phb4_realize(DeviceState *dev, Error **errp)
  {
  PnvPHB4 *phb = PNV_PHB4(dev);
+PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(phb->pec);
  PCIHostState *pci = PCI_HOST_BRIDGE(dev);
  XiveSource *xsrc = &phb->xsrc;
  int nr_irqs;
@@ -1583,6 +1584,9 @@ static void pnv_phb4_realize(DeviceState *dev, Error 
**errp)
  pci_setup_iommu(pci->bus, pnv_phb4_dma_iommu, phb);
  pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
  
+/* Add a single Root port if running with defaults */

+pnv_phb_attach_root_port(pci, pecc->rp_model);
+
  /* Setup XIVE Source */
  if (phb->big_phb) {
  nr_irqs = PNV_PHB4_MAX_INTs;
diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
index 8b7e823fa5..c9aaf1c28e 100644
--- a/hw/pci-host/pnv_phb4_pec.c
+++ b/hw/pci-host/pnv_phb4_pec.c
@@ -130,9 +130,6 @@ static void pnv_pec_default_phb_realize(PnvPhb4PecState 
*pec,
  if (!sysbus_realize(SYS_BUS_DEVICE(phb), errp)) {
  return;
  }
-
-/* Add a single Root port if running with defaults */
-pnv_phb_attach_root_port(PCI_HOST_BRIDGE(phb), pecc->rp_model);
  }
  
  static void pnv_pec_realize(DeviceState *dev, Error **errp)




Re: [PATCH 4/5] tests/vm: switch CentOS 8 to CentOS 8 Stream

2022-06-14 Thread Daniel P . Berrangé
On Mon, Jun 13, 2022 at 09:50:43PM -0400, John Snow wrote:
> The old CentOS image didn't work anymore because it was already EOL at
> the beginning of 2022.
> 
> Signed-off-by: John Snow 
> ---
>  tests/vm/centos | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/vm/centos b/tests/vm/centos
> index be4f6ff2f14..f5bbdecf62d 100755
> --- a/tests/vm/centos
> +++ b/tests/vm/centos
> @@ -1,8 +1,8 @@
>  #!/usr/bin/env python3
>  #
> -# CentOS image
> +# CentOS 8 Stream image
>  #
> -# Copyright 2018 Red Hat Inc.
> +# Copyright 2018, 2022 Red Hat Inc.
>  #
>  # Authors:
>  #  Fam Zheng 
> @@ -18,7 +18,7 @@ import basevm
>  import time
>  
>  class CentosVM(basevm.BaseVM):
> -name = "centos"
> +name = "centos8s"


What's the effect of this ?  It feels a little odd to set name to 'centos8s'
here but have this file still called just 'centos' - I assume the 'name'
variable was intended to always match the filename

>  arch = "x86_64"
>  BUILD_SCRIPT = """
>  set -e;
> @@ -32,7 +32,7 @@ class CentosVM(basevm.BaseVM):
>  """
>  
>  def build_image(self, img):
> -cimg = 
> self._download_with_cache("https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.3.2011-20201204.2.x86_64.qcow2";)
> +cimg = 
> self._download_with_cache("https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20220125.1.x86_64.qcow2";)
>  img_tmp = img + ".tmp"
>  subprocess.check_call(['cp', '-f', cimg, img_tmp])
>  self.exec_qemu_img("resize", img_tmp, "50G")


With 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 :|




[PATCH v16 9/9] target/loongarch: Update README

2022-06-14 Thread Song Gao
Add linux-user emulation introduction

Signed-off-by: Song Gao 
Signed-off-by: Xiaojuan Yang 
---
 target/loongarch/README | 39 +--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/target/loongarch/README b/target/loongarch/README
index 4dcd0f1682..9f5edd10c8 100644
--- a/target/loongarch/README
+++ b/target/loongarch/README
@@ -24,9 +24,9 @@
 
 Download cross-tools.
 
-  wget 
https://github.com/loongson/build-tools/releases/latest/download/loongarch64-clfs-20211202-cross-tools.tar.xz
+  wget 
https://github.com/loongson/build-tools/releases/download/2022.05.29/loongarch64-clfs-5.0-cross-tools-gcc-full.tar.xz
 
-  tar -vxf loongarch64-clfs-20211202-cross-tools.tar.xz -C /opt
+  tar -vxf loongarch64-clfs-5.0-cross-tools-gcc-full.tar.xz -C /opt
 
 Config cross-tools env.
 
@@ -60,5 +60,40 @@
 
 ./build/qemu-system-loongarch64 -machine virt -m 4G -cpu Loongson-3A5000 
-smp 1 -kernel build/tests/tcg/loongarch64-softmmu/hello -monitor none -display 
none -chardev file,path=hello.out,id=output -serial chardev:output
 
+- Linux-user emulation
+
+  We already support Linux user emulation. We can use LoongArch cross-tools to 
build LoongArch executables on X86 machines,
+  and We can also use qemu-loongarch64 to run LoongArch executables.
+
+  1. Config cross-tools env.
+
+ see System emulation.
+
+  2. Test tests/tcg/multiarch.
+
+ ./configure  --static  --prefix=/usr  --disable-werror 
--target-list="loongarch64-linux-user" --enable-debug
+
+ cd build
+
+ make && make check-tcg
+
+  3. Run LoongArch system basic command with loongarch-clfs-system.
+
+ - Config clfs env.
+
+   wget 
https://github.com/loongson/build-tools/releases/download/2022.05.29/loongarch64-clfs-system-5.0.tar.bz2
+
+   tar -vxf loongarch64-clfs-system-5.0.tar.bz2 -C /opt/clfs
+
+   cp /opt/clfs/lib64/ld-linux-loongarch-lp64d.so.1  /lib64
+
+   export LD_LIBRARY_PATH="/opt/clfs/lib64"
+
+ - Run LoongArch system basic command.
+
+   ./qemu-loongarch64  /opt/clfs/usr/bin/bash
+   ./qemu-loongarch64  /opt/clfs/usr/bin/ls
+   ./qemu-loongarch64  /opt/clfs/usr/bin/pwd
+
 - Note.
   We can get the latest LoongArch documents or LoongArch tools at 
https://github.com/loongson/
-- 
2.31.1




Re: [PATCH 06/11] ppc/pnv: make pnv_ics_resend() use chip8->phbs[]

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

pnv_ics_resend() is scrolling through all the child objects of the chip
to search for the PHBs. It's faster and simpler to just use the phbs[]
array.

pnv_ics_resend_child() was folded into pnv_ics_resend() since it's too
simple to justify its own function.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/ppc/pnv.c | 22 +++---
  1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 05a8d5034f..d70deffa1d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1993,28 +1993,20 @@ PnvChip *pnv_get_chip(PnvMachineState *pnv, uint32_t 
chip_id)
  return NULL;
  }
  
-static int pnv_ics_resend_child(Object *child, void *opaque)

-{
-PnvPHB3 *phb3 = (PnvPHB3 *) object_dynamic_cast(child, TYPE_PNV_PHB3);
-
-if (phb3) {
-ics_resend(&phb3->lsis);
-ics_resend(ICS(&phb3->msis));
-}
-return 0;
-}
-
  static void pnv_ics_resend(XICSFabric *xi)
  {
  PnvMachineState *pnv = PNV_MACHINE(xi);
-int i;
+int i, j;
  
  for (i = 0; i < pnv->num_chips; i++) {

-PnvChip *chip = pnv->chips[i];
  Pnv8Chip *chip8 = PNV8_CHIP(pnv->chips[i]);
  
-ics_resend(&chip8->psi.ics);



That line shouldn't be dropped, right?

  Fred



-object_child_foreach(OBJECT(chip), pnv_ics_resend_child, NULL);
+for (j = 0; j < chip8->num_phbs; j++) {
+PnvPHB3 *phb3 = &chip8->phbs[j];
+
+ics_resend(&phb3->lsis);
+ics_resend(ICS(&phb3->msis));
+}
  }
  }
  




Re: [PATCH 03/11] ppc/pnv: use dev->parent_bus->parent to get the PHB

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

It is not advisable to execute an object_dynamic_cast() to poke into
bus->qbus.parent and follow it up with a C cast into the PnvPHB type we
think we got.

A better way is to access the PnvPHB object via a QOM macro accessing
the existing parent links of the DeviceState. For a given
pnv-phb3/4-root-port 'dev', dev->parent_bus will give us the PHB bus,
and dev->parent_bus->parent is the PHB. Use the adequate QOM macro to
assert the type, and keep the NULL check in case we didn't get the
object we were expecting.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/pci-host/pnv_phb3.c | 10 +++---
  hw/pci-host/pnv_phb4.c | 10 +++---
  2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 4ba660f8b9..7901d8172c 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1139,12 +1139,16 @@ static void pnv_phb3_root_port_realize(DeviceState 
*dev, Error **errp)
  {
  PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
  PCIDevice *pci = PCI_DEVICE(dev);
-PCIBus *bus = pci_get_bus(pci);
  PnvPHB3 *phb = NULL;
  Error *local_err = NULL;
  
-phb = (PnvPHB3 *) object_dynamic_cast(OBJECT(bus->qbus.parent),

-  TYPE_PNV_PHB3);
+/*
+ * dev->parent_bus gives access to the pnv-phb-root bus.
+ * The PnvPHB3 is the owner (parent) of the bus.
+ */
+if (dev && dev->parent_bus) {
+phb = PNV_PHB3(dev->parent_bus->parent);
+}
  
  if (!phb) {

  error_setg(errp,
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index ffd9d8a947..bae9398d86 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1782,12 +1782,16 @@ static void pnv_phb4_root_port_realize(DeviceState 
*dev, Error **errp)
  {
  PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
  PCIDevice *pci = PCI_DEVICE(dev);
-PCIBus *bus = pci_get_bus(pci);
  PnvPHB4 *phb = NULL;
  Error *local_err = NULL;
  
-phb = (PnvPHB4 *) object_dynamic_cast(OBJECT(bus->qbus.parent),

-  TYPE_PNV_PHB4);
+/*
+ * dev->parent_bus gives access to the pnv-phb-root bus.
+ * The PnvPHB4 is the owner (parent) of the bus.
+ */
+if (dev && dev->parent_bus) {



Does it make sense to test 'dev' first when it's the device being realized?

  Fred





+phb = PNV_PHB4(dev->parent_bus->parent);
+}
  
  if (!phb) {

  error_setg(errp, "%s must be connected to pnv-phb4 buses", dev->id);




Re: [PATCH 02/11] ppc/pnv: attach phb3/phb4 root ports in QOM tree

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:

   /unattached (container)
(...)
 /device[2] (pnv-phb3-root-port)
   /bus master container[0] (memory-region)
   /bus master[0] (memory-region)
   /pci_bridge_io[0] (memory-region)
   /pci_bridge_io[1] (memory-region)
   /pci_bridge_mem[0] (memory-region)
   /pci_bridge_pci[0] (memory-region)
   /pci_bridge_pref_mem[0] (memory-region)
   /pci_bridge_vga_io_hi[0] (memory-region)
   /pci_bridge_vga_io_lo[0] (memory-region)
   /pci_bridge_vga_mem[0] (memory-region)
   /pcie.0 (PCIE)

Let's make changes in pnv_phb_attach_root_port() to attach the created
root ports to its corresponding PHB.

This is the result afterwards:

 /pnv-phb3[0] (pnv-phb3)
   /lsi (ics)
   /msi (phb3-msi)
   /msi32[0] (memory-region)
   /msi64[0] (memory-region)
   /pbcq (pnv-pbcq)
 (...)
   /phb3_iommu[0] (pnv-phb3-iommu-memory-region)
   /pnv-phb3-root.0 (pnv-phb3-root)
 /pnv-phb3-root-port[0] (pnv-phb3-root-port)
   /bus master container[0] (memory-region)
   /bus master[0] (memory-region)
   /pci_bridge_io[0] (memory-region)
   /pci_bridge_io[1] (memory-region)
   /pci_bridge_mem[0] (memory-region)
   /pci_bridge_pci[0] (memory-region)
   /pci_bridge_pref_mem[0] (memory-region)
   /pci_bridge_vga_io_hi[0] (memory-region)
   /pci_bridge_vga_io_lo[0] (memory-region)
   /pci_bridge_vga_mem[0] (memory-region)
   /pcie.0 (PCIE)

Signed-off-by: Daniel Henrique Barboza 
---



I've always wondered if there was a good reason to have them detached. 
Glad to see there was none :-)


Reviewed-by: Frederic Barrat 

  Fred



  hw/pci-host/pnv_phb3.c | 2 +-
  hw/pci-host/pnv_phb4.c | 2 +-
  hw/ppc/pnv.c   | 7 ++-
  include/hw/ppc/pnv.h   | 2 +-
  4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 26ac9b7123..4ba660f8b9 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1052,7 +1052,7 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
**errp)
  
  pci_setup_iommu(pci->bus, pnv_phb3_dma_iommu, phb);
  
-pnv_phb_attach_root_port(PCI_HOST_BRIDGE(phb), TYPE_PNV_PHB3_ROOT_PORT);

+pnv_phb_attach_root_port(pci, TYPE_PNV_PHB3_ROOT_PORT, phb->phb_id);
  }
  
  void pnv_phb3_update_regions(PnvPHB3 *phb)

diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 23ad8de7ee..ffd9d8a947 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1585,7 +1585,7 @@ static void pnv_phb4_realize(DeviceState *dev, Error 
**errp)
  pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
  
  /* Add a single Root port if running with defaults */

-pnv_phb_attach_root_port(pci, pecc->rp_model);
+pnv_phb_attach_root_port(pci, pecc->rp_model, phb->phb_id);
  
  /* Setup XIVE Source */

  if (phb->big_phb) {
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 7c08a78d6c..40e0cbd84d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1190,9 +1190,14 @@ static void pnv_chip_icp_realize(Pnv8Chip *chip8, Error 
**errp)
  }
  
  /* Attach a root port device */

-void pnv_phb_attach_root_port(PCIHostState *pci, const char *name)
+void pnv_phb_attach_root_port(PCIHostState *pci, const char *name, int index)
  {
  PCIDevice *root = pci_new(PCI_DEVFN(0, 0), name);
+g_autofree char *default_id = g_strdup_printf("%s[%d]", name, index);
+const char *dev_id = DEVICE(root)->id;
+
+object_property_add_child(OBJECT(pci->bus), dev_id ? dev_id : default_id,
+  OBJECT(root));
  
  pci_realize_and_unref(root, pci->bus, &error_fatal);

  }
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 86cb7d7f97..033890a23f 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -189,7 +189,7 @@ DECLARE_INSTANCE_CHECKER(PnvChip, PNV_CHIP_POWER10,
   TYPE_PNV_CHIP_POWER10)
  
  PowerPCCPU *pnv_chip_find_cpu(PnvChip *chip, uint32_t pir);

-void pnv_phb_attach_root_port(PCIHostState *pci, const char *name);
+void pnv_phb_attach_root_port(PCIHostState *pci, const char *name, int index);
  
  #define TYPE_PNV_MACHINE   MACHINE_TYPE_NAME("powernv")

  typedef struct PnvMachineClass PnvMachineClass;




Re: [PATCH 07/11] ppc/pnv: make pnv_chip_power8_pic_print_info() use chip8->phbs[]

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

It's inneficient to scroll all child objects when we have all PHBs
available in chip8->phbs[].

pnv_chip_power8_pic_print_info_child() ended up folded into
pic_print_info() for simplicity.

Signed-off-by: Daniel Henrique Barboza 
---



Reviewed-by: Frederic Barrat 

  Fred



  hw/ppc/pnv.c | 22 --
  1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index d70deffa1d..5e3323e950 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -652,25 +652,19 @@ static ISABus *pnv_isa_create(PnvChip *chip, Error **errp)
  return PNV_CHIP_GET_CLASS(chip)->isa_create(chip, errp);
  }
  
-static int pnv_chip_power8_pic_print_info_child(Object *child, void *opaque)

-{
-Monitor *mon = opaque;
-PnvPHB3 *phb3 = (PnvPHB3 *) object_dynamic_cast(child, TYPE_PNV_PHB3);
-
-if (phb3) {
-pnv_phb3_msi_pic_print_info(&phb3->msis, mon);
-ics_pic_print_info(&phb3->lsis, mon);
-}
-return 0;
-}
-
  static void pnv_chip_power8_pic_print_info(PnvChip *chip, Monitor *mon)
  {
  Pnv8Chip *chip8 = PNV8_CHIP(chip);
+int i;
  
  ics_pic_print_info(&chip8->psi.ics, mon);

-object_child_foreach(OBJECT(chip),
- pnv_chip_power8_pic_print_info_child, mon);
+
+for (i = 0; i < chip8->num_phbs; i++) {
+PnvPHB3 *phb3 = &chip8->phbs[i];
+
+pnv_phb3_msi_pic_print_info(&phb3->msis, mon);
+ics_pic_print_info(&phb3->lsis, mon);
+}
  }
  
  static int pnv_chip_power9_pic_print_info_child(Object *child, void *opaque)




Re: [PATCH 04/11] ppc/pnv: use dev instead of pci->qdev in root_port_realize()

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

We already have access to the 'dev' object.

Signed-off-by: Daniel Henrique Barboza 
---



Reviewed-by: Frederic Barrat 

  Fred



  hw/pci-host/pnv_phb3.c | 4 ++--
  hw/pci-host/pnv_phb4.c | 5 ++---
  2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 7901d8172c..bda23fd20b 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1157,8 +1157,8 @@ static void pnv_phb3_root_port_realize(DeviceState *dev, 
Error **errp)
  }
  
  /* Set unique chassis/slot values for the root port */

-qdev_prop_set_uint8(&pci->qdev, "chassis", phb->chip_id);
-qdev_prop_set_uint16(&pci->qdev, "slot", phb->phb_id);
+qdev_prop_set_uint8(dev, "chassis", phb->chip_id);
+qdev_prop_set_uint16(dev, "slot", phb->phb_id);
  
  rpc->parent_realize(dev, &local_err);

  if (local_err) {
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index bae9398d86..bfec8b9f6d 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1781,7 +1781,6 @@ static void pnv_phb4_root_port_reset(DeviceState *dev)
  static void pnv_phb4_root_port_realize(DeviceState *dev, Error **errp)
  {
  PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
-PCIDevice *pci = PCI_DEVICE(dev);
  PnvPHB4 *phb = NULL;
  Error *local_err = NULL;
  
@@ -1799,8 +1798,8 @@ static void pnv_phb4_root_port_realize(DeviceState *dev, Error **errp)

  }
  
  /* Set unique chassis/slot values for the root port */

-qdev_prop_set_uint8(&pci->qdev, "chassis", phb->chip_id);
-qdev_prop_set_uint16(&pci->qdev, "slot", phb->phb_id);
+qdev_prop_set_uint8(dev, "chassis", phb->chip_id);
+qdev_prop_set_uint16(dev, "slot", phb->phb_id);
  
  rpc->parent_realize(dev, &local_err);

  if (local_err) {




Re: [PULL 00/16] Kraxel 20220613 patches

2022-06-14 Thread Gerd Hoffmann
On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> On 6/13/22 04:36, Gerd Hoffmann wrote:
> > The following changes since commit dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> > 
> >Merge tag 'mips-20220611' of https://github.com/philmd/qemu into staging 
> > (2022-06-11 21:13:27 -0700)
> > 
> > are available in the Git repository at:
> > 
> >git://git.kraxel.org/qemu tags/kraxel-20220613-pull-request
> > 
> > for you to fetch changes up to 23b87f7a3a13e93e248eef8a4b7257548855a620:
> > 
> >ui: move 'pc-bios/keymaps' to 'ui/keymaps' (2022-06-13 10:59:25 +0200)
> > 
> > 
> > usb: add CanoKey device, fixes for ehci + redir
> > ui: fixes for gtk and cocoa, move keymaps (v2), rework refresh rate
> > virtio-gpu: scanout flush fix
> 
> This doesn't even configure:
> 
> ../src/ui/keymaps/meson.build:55:4: ERROR: File ar does not exist.

Hmm, build worked here and CI passed too.

I think this is one of those cases where the build directory must be
deleted because one subdirectory is replaced by a compatibility
symlink.

Or we drop the symlink idea and update the keymap loading code to check
both old and new location.  Daniel?

take care,
  Gerd




Re: [RFC PATCH v8 00/21] Net Control VQ support with asid in vDPA SVQ

2022-06-14 Thread Eugenio Perez Martin
On Tue, Jun 14, 2022 at 10:20 AM Jason Wang  wrote:
>
> On Tue, Jun 14, 2022 at 4:14 PM Eugenio Perez Martin
>  wrote:
> >
> > On Tue, Jun 14, 2022 at 10:02 AM Jason Wang  wrote:
> > >
> > > On Tue, Jun 14, 2022 at 12:32 AM Eugenio Perez Martin
> > >  wrote:
> > > >
> > > > On Wed, Jun 8, 2022 at 9:28 PM Eugenio Perez Martin 
> > > >  wrote:
> > > > >
> > > > > On Wed, Jun 8, 2022 at 7:51 AM Jason Wang  wrote:
> > > > > >
> > > > > >
> > > > > > 在 2022/5/20 03:12, Eugenio Pérez 写道:
> > > > > > > Control virtqueue is used by networking device for accepting 
> > > > > > > various
> > > > > > > commands from the driver. It's a must to support multiqueue and 
> > > > > > > other
> > > > > > > configurations.
> > > > > > >
> > > > > > > Shadow VirtQueue (SVQ) already makes possible migration of 
> > > > > > > virtqueue
> > > > > > > states, effectively intercepting them so qemu can track what 
> > > > > > > regions of memory
> > > > > > > are dirty because device action and needs migration. However, 
> > > > > > > this does not
> > > > > > > solve networking device state seen by the driver because CVQ 
> > > > > > > messages, like
> > > > > > > changes on MAC addresses from the driver.
> > > > > > >
> > > > > > > To solve that, this series uses SVQ infraestructure proposed to 
> > > > > > > intercept
> > > > > > > networking control messages used by the device. This way, qemu is 
> > > > > > > able to
> > > > > > > update VirtIONet device model and to migrate it.
> > > > > > >
> > > > > > > However, to intercept all queues would slow device data 
> > > > > > > forwarding. To solve
> > > > > > > that, only the CVQ must be intercepted all the time. This is 
> > > > > > > achieved using
> > > > > > > the ASID infraestructure, that allows different translations for 
> > > > > > > different
> > > > > > > virtqueues. The most updated kernel part of ASID is proposed at 
> > > > > > > [1].
> > > > > > >
> > > > > > > You can run qemu in two modes after applying this series: only 
> > > > > > > intercepting
> > > > > > > cvq with x-cvq-svq=on or intercept all the virtqueues adding 
> > > > > > > cmdline x-svq=on:
> > > > > > >
> > > > > > > -netdev 
> > > > > > > type=vhost-vdpa,vhostdev=/dev/vhost-vdpa-0,id=vhost-vdpa0,x-cvq-svq=on,x-svq=on
> > > > > > >
> > > > > > > First three patches enable the update of the virtio-net device 
> > > > > > > model for each
> > > > > > > CVQ message acknoledged by the device.
> > > > > > >
> > > > > > > Patches from 5 to 9 enables individual SVQ to copy the buffers to 
> > > > > > > QEMU's VA.
> > > > > > > This allows simplyfing the memory mapping, instead of map all the 
> > > > > > > guest's
> > > > > > > memory like in the data virtqueues.
> > > > > > >
> > > > > > > Patch 10 allows to inject control messages to the device. This 
> > > > > > > allows to set
> > > > > > > state to the device both at QEMU startup and at live migration 
> > > > > > > destination. In
> > > > > > > the future, this may also be used to emulate _F_ANNOUNCE.
> > > > > > >
> > > > > > > Patch 11 updates kernel headers, but it assign random numbers to 
> > > > > > > needed ioctls
> > > > > > > because they are still not accepted in the kernel.
> > > > > > >
> > > > > > > Patches 12-16 enables the set of the features of the net device 
> > > > > > > model to the
> > > > > > > vdpa device at device start.
> > > > > > >
> > > > > > > Last ones enables the sepparated ASID and SVQ.
> > > > > > >
> > > > > > > Comments are welcomed.
> > > > > >
> > > > > >
> > > > > > As discussed, I think we need to split this huge series into 
> > > > > > smaller ones:
> > > > > >
> > > > > > 1) shadow CVQ only, this makes rx-filter-event work
> > > > > > 2) ASID support for CVQ
> > > > > >
> > > > > > And for 1) we need consider whether or not it could be simplified.
> > > > > >
> > > > > > Or do it in reverse order, since if we do 1) first, we may have 
> > > > > > security
> > > > > > issues.
> > > > > >
> > > > >
> > > > > I'm ok with both, but I also think 2) before 1) might make more sense.
> > > > > There is no way to only shadow CVQ otherwise ATM.
> > > > >
> > > >
> > > > On second thought, that order is kind of harder.
> > > >
> > > > If we only map CVQ buffers, we need to either:
> > > > a. Copy them to controlled buffers
> > > > b. Track properly when to unmap them
> > >
> > > Just to make sure we're at the same page:
> > >
> > > I meant we can start with e.g having a dedicated ASID for CVQ but
> > > still using CVQ passthrough.
> > >
> >
> > That would imply duplicating all the memory listener updates to both
> > ASIDs. That part of the code needs to be reverted. I'm ok with that,
> > but I'm not sure if it's worth it to do it that way.
>
> I don't get why it is related to memory listeners. The only change is
>
> 1) read the groups
> 2) set cvq to be an independent asid
> 3) update CVQ's IOTLB with its own ASID
>

How to track the mappings of step 3) without a copy?

If we don't copy the buffers to qemu's IOVA, we

Re: [PATCH] hw/mem/nvdimm: fix error message for 'unarmed' flag

2022-06-14 Thread David Hildenbrand
On 14.06.22 10:54, Igor Mammedov wrote:
> On Mon, 13 Jun 2022 16:09:53 +0100
> Stefan Hajnoczi  wrote:
> 
>> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
>>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi  
>>> wrote:  

 On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:  
> In the ACPI specification [1], the 'unarmed' bit is set when a device
> cannot accept a persistent write. This means that when a memdev is
> read-only, the 'unarmed' flag must be turned on. The logic is correct,
> just changing the error message.
>
> [1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM State Flags" Bit 3
>
> Signed-off-by: Julia Suvorova 
> ---
>  hw/mem/nvdimm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)  

 Reviewed-by: Stefan Hajnoczi   
>>>
>>> It seems like Xiao is not active, whose tree should this patch go to?  

Is that a temporary or a permanent thing? Do we know?

> 
> Perhaps David can add himself as maintainer (i.e. put it
> under memory mantanership umbrella) and merge it 

Maybe it makes sense to combine NVDIMM with pc-dimm.c and
memory-device.c into a "MEMORY DEVICE" section. Then, remove "hw/mem/*"
from "ACPI/SMBIOS".

cxl_type3.c, npcm7xx_mc.c and sparse-mem.c in /hw/mem/ are a bit
different. We could add cxl_type3.c to "Compute Express Link".
npcm7xx_mc.c and sparse-mem.c should be already covered.

-- 
Thanks,

David / dhildenb




Re: [PATCH 05/11] ppc/pnv: make pnv_ics_get() use the chip8->phbs[] array

2022-06-14 Thread Cédric Le Goater

On 6/13/22 17:44, Daniel Henrique Barboza wrote:

The function is working today by getting all the child objects of the
chip, interacting with each of them to check whether the child is a PHB,
and then doing what needs to be done.

We have all the chip PHBs in the phbs[] array so interacting with all
child objects is unneeded.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/ppc/pnv.c | 30 ++
  1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 40e0cbd84d..05a8d5034f 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1944,41 +1944,39 @@ typedef struct ForeachPhb3Args {
  ICSState *ics;
  } ForeachPhb3Args;
  
-static int pnv_ics_get_child(Object *child, void *opaque)

+static void pnv_ics_get_phb_ics(PnvPHB3 *phb3, ForeachPhb3Args *args)
  {
-ForeachPhb3Args *args = opaque;
-PnvPHB3 *phb3 = (PnvPHB3 *) object_dynamic_cast(child, TYPE_PNV_PHB3);
+if (ics_valid_irq(&phb3->lsis, args->irq)) {
+args->ics = &phb3->lsis;
+}
  
-if (phb3) {

-if (ics_valid_irq(&phb3->lsis, args->irq)) {
-args->ics = &phb3->lsis;
-}
-if (ics_valid_irq(ICS(&phb3->msis), args->irq)) {
-args->ics = ICS(&phb3->msis);
-}
+if (ics_valid_irq(ICS(&phb3->msis), args->irq)) {
+args->ics = ICS(&phb3->msis);
  }
-return args->ics ? 1 : 0;
  }
  
  static ICSState *pnv_ics_get(XICSFabric *xi, int irq)

  {
  PnvMachineState *pnv = PNV_MACHINE(xi);
  ForeachPhb3Args args = { irq, NULL };
-int i;
+int i, j;
  
  for (i = 0; i < pnv->num_chips; i++) {

-PnvChip *chip = pnv->chips[i];
  Pnv8Chip *chip8 = PNV8_CHIP(pnv->chips[i]);
  
  if (ics_valid_irq(&chip8->psi.ics, irq)) {

  return &chip8->psi.ics;
  }
  
-object_child_foreach(OBJECT(chip), pnv_ics_get_child, &args);

-if (args.ics) {
-return args.ics;
+for (j = 0; j < chip8->num_phbs; j++) {
+pnv_ics_get_phb_ics(&chip8->phbs[j], &args);


If we don't need this function elsewhere, why keep it ?

Thanks,

C.


+
+if (args.ics) {
+return args.ics;
+}
  }
  }
+
  return NULL;
  }
  





Re: [PULL 00/16] Kraxel 20220613 patches

2022-06-14 Thread Daniel P . Berrangé
On Tue, Jun 14, 2022 at 11:40:38AM +0200, Gerd Hoffmann wrote:
> On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> > On 6/13/22 04:36, Gerd Hoffmann wrote:
> > > The following changes since commit 
> > > dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> > > 
> > >Merge tag 'mips-20220611' of https://github.com/philmd/qemu into 
> > > staging (2022-06-11 21:13:27 -0700)
> > > 
> > > are available in the Git repository at:
> > > 
> > >git://git.kraxel.org/qemu tags/kraxel-20220613-pull-request
> > > 
> > > for you to fetch changes up to 23b87f7a3a13e93e248eef8a4b7257548855a620:
> > > 
> > >ui: move 'pc-bios/keymaps' to 'ui/keymaps' (2022-06-13 10:59:25 +0200)
> > > 
> > > 
> > > usb: add CanoKey device, fixes for ehci + redir
> > > ui: fixes for gtk and cocoa, move keymaps (v2), rework refresh rate
> > > virtio-gpu: scanout flush fix
> > 
> > This doesn't even configure:
> > 
> > ../src/ui/keymaps/meson.build:55:4: ERROR: File ar does not exist.
> 
> Hmm, build worked here and CI passed too.
> 
> I think this is one of those cases where the build directory must be
> deleted because one subdirectory is replaced by a compatibility
> symlink.

Except 'configure' deals with that, as it explicitly rm -rf's the
symlink target:

symlink() {
  rm -rf "$2"
  mkdir -p "$(dirname "$2")"
  ln -s "$1" "$2"
}


so i'm pretty confused as to what's going wrong here still


With 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: [PATCH 02/11] ppc/pnv: attach phb3/phb4 root ports in QOM tree

2022-06-14 Thread Cédric Le Goater

On 6/14/22 11:09, Frederic Barrat wrote:



On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:

   /unattached (container)
(...)
 /device[2] (pnv-phb3-root-port)
   /bus master container[0] (memory-region)
   /bus master[0] (memory-region)
   /pci_bridge_io[0] (memory-region)
   /pci_bridge_io[1] (memory-region)
   /pci_bridge_mem[0] (memory-region)
   /pci_bridge_pci[0] (memory-region)
   /pci_bridge_pref_mem[0] (memory-region)
   /pci_bridge_vga_io_hi[0] (memory-region)
   /pci_bridge_vga_io_lo[0] (memory-region)
   /pci_bridge_vga_mem[0] (memory-region)
   /pcie.0 (PCIE)

Let's make changes in pnv_phb_attach_root_port() to attach the created
root ports to its corresponding PHB.

This is the result afterwards:

 /pnv-phb3[0] (pnv-phb3)
   /lsi (ics)
   /msi (phb3-msi)
   /msi32[0] (memory-region)
   /msi64[0] (memory-region)
   /pbcq (pnv-pbcq)
 (...)
   /phb3_iommu[0] (pnv-phb3-iommu-memory-region)
   /pnv-phb3-root.0 (pnv-phb3-root)
 /pnv-phb3-root-port[0] (pnv-phb3-root-port)
   /bus master container[0] (memory-region)
   /bus master[0] (memory-region)
   /pci_bridge_io[0] (memory-region)
   /pci_bridge_io[1] (memory-region)
   /pci_bridge_mem[0] (memory-region)
   /pci_bridge_pci[0] (memory-region)
   /pci_bridge_pref_mem[0] (memory-region)
   /pci_bridge_vga_io_hi[0] (memory-region)
   /pci_bridge_vga_io_lo[0] (memory-region)
   /pci_bridge_vga_mem[0] (memory-region)
   /pcie.0 (PCIE)

Signed-off-by: Daniel Henrique Barboza 
---



I've always wondered if there was a good reason to have them detached. Glad to 
see there was none :-)


Wasn't it for libvirt integration ?

C.




Reviewed-by: Frederic Barrat 

   Fred



  hw/pci-host/pnv_phb3.c | 2 +-
  hw/pci-host/pnv_phb4.c | 2 +-
  hw/ppc/pnv.c   | 7 ++-
  include/hw/ppc/pnv.h   | 2 +-
  4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 26ac9b7123..4ba660f8b9 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1052,7 +1052,7 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
**errp)
  pci_setup_iommu(pci->bus, pnv_phb3_dma_iommu, phb);
-    pnv_phb_attach_root_port(PCI_HOST_BRIDGE(phb), TYPE_PNV_PHB3_ROOT_PORT);
+    pnv_phb_attach_root_port(pci, TYPE_PNV_PHB3_ROOT_PORT, phb->phb_id);
  }
  void pnv_phb3_update_regions(PnvPHB3 *phb)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 23ad8de7ee..ffd9d8a947 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1585,7 +1585,7 @@ static void pnv_phb4_realize(DeviceState *dev, Error 
**errp)
  pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
  /* Add a single Root port if running with defaults */
-    pnv_phb_attach_root_port(pci, pecc->rp_model);
+    pnv_phb_attach_root_port(pci, pecc->rp_model, phb->phb_id);
  /* Setup XIVE Source */
  if (phb->big_phb) {
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 7c08a78d6c..40e0cbd84d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1190,9 +1190,14 @@ static void pnv_chip_icp_realize(Pnv8Chip *chip8, Error 
**errp)
  }
  /* Attach a root port device */
-void pnv_phb_attach_root_port(PCIHostState *pci, const char *name)
+void pnv_phb_attach_root_port(PCIHostState *pci, const char *name, int index)
  {
  PCIDevice *root = pci_new(PCI_DEVFN(0, 0), name);
+    g_autofree char *default_id = g_strdup_printf("%s[%d]", name, index);
+    const char *dev_id = DEVICE(root)->id;
+
+    object_property_add_child(OBJECT(pci->bus), dev_id ? dev_id : default_id,
+  OBJECT(root));
  pci_realize_and_unref(root, pci->bus, &error_fatal);
  }
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 86cb7d7f97..033890a23f 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -189,7 +189,7 @@ DECLARE_INSTANCE_CHECKER(PnvChip, PNV_CHIP_POWER10,
   TYPE_PNV_CHIP_POWER10)
  PowerPCCPU *pnv_chip_find_cpu(PnvChip *chip, uint32_t pir);
-void pnv_phb_attach_root_port(PCIHostState *pci, const char *name);
+void pnv_phb_attach_root_port(PCIHostState *pci, const char *name, int index);
  #define TYPE_PNV_MACHINE   MACHINE_TYPE_NAME("powernv")
  typedef struct PnvMachineClass PnvMachineClass;





Re: [PATCH 08/11] ppc/pnv: turn chip8->phbs[] into a PnvPHB3* array

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

When enabling user created PHBs (a change reverted by commit 9c10d86fee)
we were handling PHBs created by default versus by the user in different
manners. The only difference between these PHBs is that one will have a
valid phb3->chip that is assigned during pnv_chip_power8_realize(),
while the user created needs to search which chip it belongs to.

Aside from that there shouldn't be any difference. Making the default
PHBs behave in line with the user created ones will make it easier to
re-introduce them later on. It will also make the code easier to follow
since we are dealing with them in equal manner.

The first step is to turn chip8->phbs[] into a PnvPHB3 pointer array.
This will allow us to assign user created PHBs into it later on. The way
we initilize the default case is now more in line with that would happen
with the user created case: the object is created, parented by the chip
because pnv_xscom_dt() relies on it, and then assigned to the array.

Signed-off-by: Daniel Henrique Barboza 
---



This patch is more prep work for the user-created device instead of 
general cleanup like the previous ones, but I don't see anything wrong 
with it. So:


Reviewed-by: Frederic Barrat 

  Fred




  hw/ppc/pnv.c | 19 ++-
  include/hw/ppc/pnv.h |  6 +-
  2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 5e3323e950..6ce9e94e05 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -660,7 +660,7 @@ static void pnv_chip_power8_pic_print_info(PnvChip *chip, 
Monitor *mon)
  ics_pic_print_info(&chip8->psi.ics, mon);
  
  for (i = 0; i < chip8->num_phbs; i++) {

-PnvPHB3 *phb3 = &chip8->phbs[i];
+PnvPHB3 *phb3 = chip8->phbs[i];
  
  pnv_phb3_msi_pic_print_info(&phb3->msis, mon);

  ics_pic_print_info(&phb3->lsis, mon);
@@ -1149,7 +1149,16 @@ static void pnv_chip_power8_instance_init(Object *obj)
  chip8->num_phbs = pcc->num_phbs;
  
  for (i = 0; i < chip8->num_phbs; i++) {

-object_initialize_child(obj, "phb[*]", &chip8->phbs[i], TYPE_PNV_PHB3);
+PnvPHB3 *phb3 = PNV_PHB3(object_new(TYPE_PNV_PHB3));
+
+/*
+ * We need the chip to parent the PHB to allow the DT
+ * to build correctly (via pnv_xscom_dt()).
+ *
+ * TODO: the PHB should be parented by a PEC device.
+ */
+object_property_add_child(obj, "phb[*]", OBJECT(phb3));
+chip8->phbs[i] = phb3;
  }
  
  }

@@ -1278,7 +1287,7 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
Error **errp)
  
  /* PHB3 controllers */

  for (i = 0; i < chip8->num_phbs; i++) {
-PnvPHB3 *phb = &chip8->phbs[i];
+PnvPHB3 *phb = chip8->phbs[i];
  
  object_property_set_int(OBJECT(phb), "index", i, &error_fatal);

  object_property_set_int(OBJECT(phb), "chip-id", chip->chip_id,
@@ -1963,7 +1972,7 @@ static ICSState *pnv_ics_get(XICSFabric *xi, int irq)
  }
  
  for (j = 0; j < chip8->num_phbs; j++) {

-pnv_ics_get_phb_ics(&chip8->phbs[j], &args);
+pnv_ics_get_phb_ics(chip8->phbs[j], &args);
  
  if (args.ics) {

  return args.ics;
@@ -1996,7 +2005,7 @@ static void pnv_ics_resend(XICSFabric *xi)
  Pnv8Chip *chip8 = PNV8_CHIP(pnv->chips[i]);
  
  for (j = 0; j < chip8->num_phbs; j++) {

-PnvPHB3 *phb3 = &chip8->phbs[j];
+PnvPHB3 *phb3 = chip8->phbs[j];
  
  ics_resend(&phb3->lsis);

  ics_resend(ICS(&phb3->msis));
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 033890a23f..11f1089289 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -80,7 +80,11 @@ struct Pnv8Chip {
  PnvHomer homer;
  
  #define PNV8_CHIP_PHB3_MAX 4

-PnvPHB3  phbs[PNV8_CHIP_PHB3_MAX];
+/*
+ * The array is used to allow quick access to the phbs by
+ * pnv_ics_get_child() and pnv_ics_resend_child().
+ */
+PnvPHB3  *phbs[PNV8_CHIP_PHB3_MAX];
  uint32_t num_phbs;
  
  XICSFabric*xics;




Re: [PATCH 06/11] ppc/pnv: make pnv_ics_resend() use chip8->phbs[]

2022-06-14 Thread Cédric Le Goater

On 6/14/22 11:24, Frederic Barrat wrote:



On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

pnv_ics_resend() is scrolling through all the child objects of the chip
to search for the PHBs. It's faster and simpler to just use the phbs[]
array.

pnv_ics_resend_child() was folded into pnv_ics_resend() since it's too
simple to justify its own function.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/ppc/pnv.c | 22 +++---
  1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 05a8d5034f..d70deffa1d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1993,28 +1993,20 @@ PnvChip *pnv_get_chip(PnvMachineState *pnv, uint32_t 
chip_id)
  return NULL;
  }
-static int pnv_ics_resend_child(Object *child, void *opaque)
-{
-    PnvPHB3 *phb3 = (PnvPHB3 *) object_dynamic_cast(child, TYPE_PNV_PHB3);
-
-    if (phb3) {
-    ics_resend(&phb3->lsis);
-    ics_resend(ICS(&phb3->msis));
-    }
-    return 0;
-}
-
  static void pnv_ics_resend(XICSFabric *xi)
  {
  PnvMachineState *pnv = PNV_MACHINE(xi);
-    int i;
+    int i, j;
  for (i = 0; i < pnv->num_chips; i++) {
-    PnvChip *chip = pnv->chips[i];
  Pnv8Chip *chip8 = PNV8_CHIP(pnv->chips[i]);
-    ics_resend(&chip8->psi.ics);



That line shouldn't be dropped, right?


yes. that's a typo, which should break the console.

C.




   Fred



-    object_child_foreach(OBJECT(chip), pnv_ics_resend_child, NULL);
+    for (j = 0; j < chip8->num_phbs; j++) {
+    PnvPHB3 *phb3 = &chip8->phbs[j];
+
+    ics_resend(&phb3->lsis);
+    ics_resend(ICS(&phb3->msis));
+    }
  }
  }





Re: [PATCH 10/11] ppc/pnv: move PHB3 initialization to realize time

2022-06-14 Thread Frederic Barrat




On 13/06/2022 17:44, Daniel Henrique Barboza wrote:

There's nothing special that is being done in
pnv_chip_power8_instance_init() that can't be done during
pnv_chip_power8_realize(). Move the PHB creating and phbs[] assignment
to power8_realize().

We also need to assign a proper phb->chip parent and bus. This is done
by the PHB itself, in pnv_phb3_realize(), in a similar fashion that user
created PHB3s are going to do.

After all this we're left with logic that, aside from phb chip
assignment that are still being done in power8_realize(), behaves the
same for default and user created PHB3s.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/pci-host/pnv_phb3.c | 14 ++
  hw/ppc/pnv.c   | 24 +---
  2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index bda23fd20b..c1c73fb88d 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -998,6 +998,20 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
**errp)
  return;
  }
  
+/*

+ * We need the chip to parent the PHB to allow the DT
+ * to build correctly (via pnv_xscom_dt()).
+ *
+ * TODO: the PHB should be parented by a PHB3 PEC device.
+ */
+pnv_parent_qom_fixup(OBJECT(phb->chip), OBJECT(phb), phb->phb_id);
+



Wouldn't we get the same result in a cleaner way by adding the phb as a 
child of the chip in pnv_chip_power8_realize() ? Right next to when the 
PnvPHB3 object pointer is added to the chip8->phbs array


  Fred



+/*
+ * pnv-phb3 buses are child of the main-system-bus, same as
+ * the chip.
+ */
+pnv_parent_bus_fixup(DEVICE(phb->chip), dev);
+
  /* LSI sources */
  object_property_set_link(OBJECT(&phb->lsis), "xics", OBJECT(pnv),
   &error_abort);
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index d77c90d64a..e4080a98e1 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1130,8 +1130,6 @@ static void pnv_chip_power10_intc_print_info(PnvChip 
*chip, PowerPCCPU *cpu,
  static void pnv_chip_power8_instance_init(Object *obj)
  {
  Pnv8Chip *chip8 = PNV8_CHIP(obj);
-PnvChipClass *pcc = PNV_CHIP_GET_CLASS(obj);
-int i;
  
  object_property_add_link(obj, "xics", TYPE_XICS_FABRIC,

   (Object **)&chip8->xics,
@@ -1145,22 +1143,6 @@ static void pnv_chip_power8_instance_init(Object *obj)
  object_initialize_child(obj, "occ", &chip8->occ, TYPE_PNV8_OCC);
  
  object_initialize_child(obj, "homer", &chip8->homer, TYPE_PNV8_HOMER);

-
-chip8->num_phbs = pcc->num_phbs;
-
-for (i = 0; i < chip8->num_phbs; i++) {
-PnvPHB3 *phb3 = PNV_PHB3(object_new(TYPE_PNV_PHB3));
-
-/*
- * We need the chip to parent the PHB to allow the DT
- * to build correctly (via pnv_xscom_dt()).
- *
- * TODO: the PHB should be parented by a PEC device.
- */
-object_property_add_child(obj, "phb[*]", OBJECT(phb3));
-chip8->phbs[i] = phb3;
-}
-
  }
  
  static void pnv_chip_icp_realize(Pnv8Chip *chip8, Error **errp)

@@ -1286,8 +1268,12 @@ static void pnv_chip_power8_realize(DeviceState *dev, 
Error **errp)
  &chip8->homer.regs);
  
  /* PHB3 controllers */

+chip8->num_phbs = pcc->num_phbs;
+
  for (i = 0; i < chip8->num_phbs; i++) {
-PnvPHB3 *phb = chip8->phbs[i];
+PnvPHB3 *phb = PNV_PHB3(object_new(TYPE_PNV_PHB3));
+
+chip8->phbs[i] = phb;
  
  object_property_set_int(OBJECT(phb), "index", i, &error_fatal);

  object_property_set_int(OBJECT(phb), "chip-id", chip->chip_id,




[PULL 02/10] block/copy-before-write: add on-cbw-error open parameter

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

Currently, behavior on copy-before-write operation failure is simple:
report error to the guest.

Let's implement alternative behavior: break the whole copy-before-write
process (and corresponding backup job or NBD client) but keep guest
working. It's needed if we consider guest stability as more important.

The realisation is simple: on copy-before-write failure we set
s->snapshot_ret and continue guest operations. s->snapshot_ret being
set will lead to all further snapshot API requests. Note that all
in-flight snapshot-API requests may still success: we do wait for them
on BREAK_SNAPSHOT-failure path in cbw_do_copy_before_write().

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/copy-before-write.c | 32 ++--
 qapi/block-core.json  | 25 -
 2 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/block/copy-before-write.c b/block/copy-before-write.c
index e29c46cd7a..c8a11a09d2 100644
--- a/block/copy-before-write.c
+++ b/block/copy-before-write.c
@@ -41,6 +41,7 @@
 typedef struct BDRVCopyBeforeWriteState {
 BlockCopyState *bcs;
 BdrvChild *target;
+OnCbwError on_cbw_error;
 
 /*
  * @lock: protects access to @access_bitmap, @done_bitmap and
@@ -65,6 +66,14 @@ typedef struct BDRVCopyBeforeWriteState {
  * node. These areas must not be rewritten by guest.
  */
 BlockReqList frozen_read_reqs;
+
+/*
+ * @snapshot_error is normally zero. But on first copy-before-write failure
+ * when @on_cbw_error == ON_CBW_ERROR_BREAK_SNAPSHOT, @snapshot_error takes
+ * value of this error (<0). After that all in-flight and further
+ * snapshot-API requests will fail with that error.
+ */
+int snapshot_error;
 } BDRVCopyBeforeWriteState;
 
 static coroutine_fn int cbw_co_preadv(
@@ -95,16 +104,27 @@ static coroutine_fn int 
cbw_do_copy_before_write(BlockDriverState *bs,
 return 0;
 }
 
+if (s->snapshot_error) {
+return 0;
+}
+
 off = QEMU_ALIGN_DOWN(offset, cluster_size);
 end = QEMU_ALIGN_UP(offset + bytes, cluster_size);
 
 ret = block_copy(s->bcs, off, end - off, true);
-if (ret < 0) {
+if (ret < 0 && s->on_cbw_error == ON_CBW_ERROR_BREAK_GUEST_WRITE) {
 return ret;
 }
 
 WITH_QEMU_LOCK_GUARD(&s->lock) {
-bdrv_set_dirty_bitmap(s->done_bitmap, off, end - off);
+if (ret < 0) {
+assert(s->on_cbw_error == ON_CBW_ERROR_BREAK_SNAPSHOT);
+if (!s->snapshot_error) {
+s->snapshot_error = ret;
+}
+} else {
+bdrv_set_dirty_bitmap(s->done_bitmap, off, end - off);
+}
 reqlist_wait_all(&s->frozen_read_reqs, off, end - off, &s->lock);
 }
 
@@ -176,6 +196,11 @@ static BlockReq *cbw_snapshot_read_lock(BlockDriverState 
*bs,
 
 QEMU_LOCK_GUARD(&s->lock);
 
+if (s->snapshot_error) {
+g_free(req);
+return NULL;
+}
+
 if (bdrv_dirty_bitmap_next_zero(s->access_bitmap, offset, bytes) != -1) {
 g_free(req);
 return NULL;
@@ -351,6 +376,7 @@ static BlockdevOptions *cbw_parse_options(QDict *options, 
Error **errp)
  * object for original options.
  */
 qdict_extract_subqdict(options, NULL, "bitmap");
+qdict_del(options, "on-cbw-error");
 
 out:
 visit_free(v);
@@ -395,6 +421,8 @@ static int cbw_open(BlockDriverState *bs, QDict *options, 
int flags,
 return -EINVAL;
 }
 }
+s->on_cbw_error = opts->has_on_cbw_error ? opts->on_cbw_error :
+ON_CBW_ERROR_BREAK_GUEST_WRITE;
 
 bs->total_sectors = bs->file->bs->total_sectors;
 bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
diff --git a/qapi/block-core.json b/qapi/block-core.json
index f0383c7925..4abf26b42d 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -4155,6 +4155,25 @@
   'base': 'BlockdevOptionsGenericFormat',
   'data': { '*bottom': 'str' } }
 
+##
+# @OnCbwError:
+#
+# An enumeration of possible behaviors for copy-before-write operation
+# failures.
+#
+# @break-guest-write: report the error to the guest. This way, the guest
+# will not be able to overwrite areas that cannot be
+# backed up, so the backup process remains valid.
+#
+# @break-snapshot: continue guest write. Doing so will make the provided
+#  snapshot state invalid and any backup or export
+#  process based on it will finally fail.
+#
+# Since: 7.1
+##
+{ 'enum': 'OnCbwError',
+  'data': [ 'break-guest-write', 'break-snapshot' ] }
+
 ##
 # @BlockdevOptionsCbw:
 #
@@ -4176,11 +4195,15 @@
 #  modifications (or removing) of specified bitmap doesn't
 #  influence the filter. (Since 7.0)
 #
+# @on-cbw-error: Behavior on failure of copy-before-write operation.
+#Default is @break-guest-write. (Sin

[PULL 05/10] block/block-copy: block_copy(): add timeout_ns parameter

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

Add possibility to limit block_copy() call in time. To be used in the
next commit.

As timed-out block_copy() call will continue in background anyway (we
can't immediately cancel IO operation), it's important also give user a
possibility to pass a callback, to do some additional actions on
block-copy call finish.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/block-copy.c | 33 ++---
 block/copy-before-write.c  |  2 +-
 include/block/block-copy.h |  4 +++-
 3 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/block/block-copy.c b/block/block-copy.c
index ec46775ea5..bb947afdda 100644
--- a/block/block-copy.c
+++ b/block/block-copy.c
@@ -883,23 +883,42 @@ static int coroutine_fn 
block_copy_common(BlockCopyCallState *call_state)
 return ret;
 }
 
+static void coroutine_fn block_copy_async_co_entry(void *opaque)
+{
+block_copy_common(opaque);
+}
+
 int coroutine_fn block_copy(BlockCopyState *s, int64_t start, int64_t bytes,
-bool ignore_ratelimit)
+bool ignore_ratelimit, uint64_t timeout_ns,
+BlockCopyAsyncCallbackFunc cb,
+void *cb_opaque)
 {
-BlockCopyCallState call_state = {
+int ret;
+BlockCopyCallState *call_state = g_new(BlockCopyCallState, 1);
+
+*call_state = (BlockCopyCallState) {
 .s = s,
 .offset = start,
 .bytes = bytes,
 .ignore_ratelimit = ignore_ratelimit,
 .max_workers = BLOCK_COPY_MAX_WORKERS,
+.cb = cb,
+.cb_opaque = cb_opaque,
 };
 
-return block_copy_common(&call_state);
-}
+ret = qemu_co_timeout(block_copy_async_co_entry, call_state, timeout_ns,
+  g_free);
+if (ret < 0) {
+assert(ret == -ETIMEDOUT);
+block_copy_call_cancel(call_state);
+/* call_state will be freed by running coroutine. */
+return ret;
+}
 
-static void coroutine_fn block_copy_async_co_entry(void *opaque)
-{
-block_copy_common(opaque);
+ret = call_state->ret;
+g_free(call_state);
+
+return ret;
 }
 
 BlockCopyCallState *block_copy_async(BlockCopyState *s,
diff --git a/block/copy-before-write.c b/block/copy-before-write.c
index c8a11a09d2..fc13c7cd44 100644
--- a/block/copy-before-write.c
+++ b/block/copy-before-write.c
@@ -111,7 +111,7 @@ static coroutine_fn int 
cbw_do_copy_before_write(BlockDriverState *bs,
 off = QEMU_ALIGN_DOWN(offset, cluster_size);
 end = QEMU_ALIGN_UP(offset + bytes, cluster_size);
 
-ret = block_copy(s->bcs, off, end - off, true);
+ret = block_copy(s->bcs, off, end - off, true, 0, NULL, NULL);
 if (ret < 0 && s->on_cbw_error == ON_CBW_ERROR_BREAK_GUEST_WRITE) {
 return ret;
 }
diff --git a/include/block/block-copy.h b/include/block/block-copy.h
index 68bbd344b2..ba0b425d78 100644
--- a/include/block/block-copy.h
+++ b/include/block/block-copy.h
@@ -40,7 +40,9 @@ int64_t block_copy_reset_unallocated(BlockCopyState *s,
  int64_t offset, int64_t *count);
 
 int coroutine_fn block_copy(BlockCopyState *s, int64_t offset, int64_t bytes,
-bool ignore_ratelimit);
+bool ignore_ratelimit, uint64_t timeout_ns,
+BlockCopyAsyncCallbackFunc cb,
+void *cb_opaque);
 
 /*
  * Run block-copy in a coroutine, create corresponding BlockCopyCallState
-- 
2.25.1




[PULL 01/10] block/copy-before-write: refactor option parsing

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

We are going to add one more option of enum type. Let's refactor option
parsing so that we can simply work with BlockdevOptionsCbw object.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/copy-before-write.c | 56 ---
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/block/copy-before-write.c b/block/copy-before-write.c
index a8a06fdc09..e29c46cd7a 100644
--- a/block/copy-before-write.c
+++ b/block/copy-before-write.c
@@ -24,6 +24,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qapi/qmp/qjson.h"
 
 #include "sysemu/block-backend.h"
 #include "qemu/cutils.h"
@@ -328,46 +329,34 @@ static void cbw_child_perm(BlockDriverState *bs, 
BdrvChild *c,
 }
 }
 
-static bool cbw_parse_bitmap_option(QDict *options, BdrvDirtyBitmap **bitmap,
-Error **errp)
+static BlockdevOptions *cbw_parse_options(QDict *options, Error **errp)
 {
-QDict *bitmap_qdict = NULL;
-BlockDirtyBitmap *bmp_param = NULL;
+BlockdevOptions *opts = NULL;
 Visitor *v = NULL;
-bool ret = false;
 
-*bitmap = NULL;
+qdict_put_str(options, "driver", "copy-before-write");
 
-qdict_extract_subqdict(options, &bitmap_qdict, "bitmap.");
-if (!qdict_size(bitmap_qdict)) {
-ret = true;
-goto out;
-}
-
-v = qobject_input_visitor_new_flat_confused(bitmap_qdict, errp);
+v = qobject_input_visitor_new_flat_confused(options, errp);
 if (!v) {
 goto out;
 }
 
-visit_type_BlockDirtyBitmap(v, NULL, &bmp_param, errp);
-if (!bmp_param) {
+visit_type_BlockdevOptions(v, NULL, &opts, errp);
+if (!opts) {
 goto out;
 }
 
-*bitmap = block_dirty_bitmap_lookup(bmp_param->node, bmp_param->name, NULL,
-errp);
-if (!*bitmap) {
-goto out;
-}
-
-ret = true;
+/*
+ * Delete options which we are going to parse through BlockdevOptions
+ * object for original options.
+ */
+qdict_extract_subqdict(options, NULL, "bitmap");
 
 out:
-qapi_free_BlockDirtyBitmap(bmp_param);
 visit_free(v);
-qobject_unref(bitmap_qdict);
+qdict_del(options, "driver");
 
-return ret;
+return opts;
 }
 
 static int cbw_open(BlockDriverState *bs, QDict *options, int flags,
@@ -376,6 +365,15 @@ static int cbw_open(BlockDriverState *bs, QDict *options, 
int flags,
 BDRVCopyBeforeWriteState *s = bs->opaque;
 BdrvDirtyBitmap *bitmap = NULL;
 int64_t cluster_size;
+g_autoptr(BlockdevOptions) full_opts = NULL;
+BlockdevOptionsCbw *opts;
+
+full_opts = cbw_parse_options(options, errp);
+if (!full_opts) {
+return -EINVAL;
+}
+assert(full_opts->driver == BLOCKDEV_DRIVER_COPY_BEFORE_WRITE);
+opts = &full_opts->u.copy_before_write;
 
 bs->file = bdrv_open_child(NULL, options, "file", bs, &child_of_bds,
BDRV_CHILD_FILTERED | BDRV_CHILD_PRIMARY,
@@ -390,8 +388,12 @@ static int cbw_open(BlockDriverState *bs, QDict *options, 
int flags,
 return -EINVAL;
 }
 
-if (!cbw_parse_bitmap_option(options, &bitmap, errp)) {
-return -EINVAL;
+if (opts->has_bitmap) {
+bitmap = block_dirty_bitmap_lookup(opts->bitmap->node,
+   opts->bitmap->name, NULL, errp);
+if (!bitmap) {
+return -EINVAL;
+}
 }
 
 bs->total_sectors = bs->file->bs->total_sectors;
-- 
2.25.1




[PULL 06/10] block/copy-before-write: implement cbw-timeout option

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

In some scenarios, when copy-before-write operations lasts too long
time, it's better to cancel it.

Most useful would be to use the new option together with
on-cbw-error=break-snapshot: this way if cbw operation takes too long
time we'll just cancel backup process but do not disturb the guest too
much.

Note the tricky point of realization: we keep additional point in
bs->in_flight during block_copy operation even if it's timed-out.
Background "cancelled" block_copy operations will finish at some point
and will want to access state. We should care to not free the state in
.bdrv_close() earlier.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/copy-before-write.c | 23 ++-
 qapi/block-core.json  |  8 +++-
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/block/copy-before-write.c b/block/copy-before-write.c
index fc13c7cd44..1bc2e7f9ba 100644
--- a/block/copy-before-write.c
+++ b/block/copy-before-write.c
@@ -42,6 +42,7 @@ typedef struct BDRVCopyBeforeWriteState {
 BlockCopyState *bcs;
 BdrvChild *target;
 OnCbwError on_cbw_error;
+uint32_t cbw_timeout_ns;
 
 /*
  * @lock: protects access to @access_bitmap, @done_bitmap and
@@ -83,6 +84,14 @@ static coroutine_fn int cbw_co_preadv(
 return bdrv_co_preadv(bs->file, offset, bytes, qiov, flags);
 }
 
+static void block_copy_cb(void *opaque)
+{
+BlockDriverState *bs = opaque;
+
+bs->in_flight--;
+aio_wait_kick();
+}
+
 /*
  * Do copy-before-write operation.
  *
@@ -111,7 +120,16 @@ static coroutine_fn int 
cbw_do_copy_before_write(BlockDriverState *bs,
 off = QEMU_ALIGN_DOWN(offset, cluster_size);
 end = QEMU_ALIGN_UP(offset + bytes, cluster_size);
 
-ret = block_copy(s->bcs, off, end - off, true, 0, NULL, NULL);
+/*
+ * Increase in_flight, so that in case of timed-out block-copy, the
+ * remaining background block_copy() request (which can't be immediately
+ * cancelled by timeout) is presented in bs->in_flight. This way we are
+ * sure that on bs close() we'll previously wait for all timed-out but yet
+ * running block_copy calls.
+ */
+bs->in_flight++;
+ret = block_copy(s->bcs, off, end - off, true, s->cbw_timeout_ns,
+ block_copy_cb, bs);
 if (ret < 0 && s->on_cbw_error == ON_CBW_ERROR_BREAK_GUEST_WRITE) {
 return ret;
 }
@@ -377,6 +395,7 @@ static BlockdevOptions *cbw_parse_options(QDict *options, 
Error **errp)
  */
 qdict_extract_subqdict(options, NULL, "bitmap");
 qdict_del(options, "on-cbw-error");
+qdict_del(options, "cbw-timeout");
 
 out:
 visit_free(v);
@@ -423,6 +442,8 @@ static int cbw_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 s->on_cbw_error = opts->has_on_cbw_error ? opts->on_cbw_error :
 ON_CBW_ERROR_BREAK_GUEST_WRITE;
+s->cbw_timeout_ns = opts->has_cbw_timeout ?
+opts->cbw_timeout * NANOSECONDS_PER_SECOND : 0;
 
 bs->total_sectors = bs->file->bs->total_sectors;
 bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 4abf26b42d..9fc06e7862 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -4198,12 +4198,18 @@
 # @on-cbw-error: Behavior on failure of copy-before-write operation.
 #Default is @break-guest-write. (Since 7.1)
 #
+# @cbw-timeout: Zero means no limit. Non-zero sets the timeout in seconds
+#   for copy-before-write operation. When a timeout occurs,
+#   the respective copy-before-write operation will fail, and
+#   the @on-cbw-error parameter will decide how this failure
+#   is handled. Default 0. (Since 7.1)
+#
 # Since: 6.2
 ##
 { 'struct': 'BlockdevOptionsCbw',
   'base': 'BlockdevOptionsGenericFormat',
   'data': { 'target': 'BlockdevRef', '*bitmap': 'BlockDirtyBitmap',
-'*on-cbw-error': 'OnCbwError' } }
+'*on-cbw-error': 'OnCbwError', '*cbw-timeout': 'uint32' } }
 
 ##
 # @BlockdevOptions:
-- 
2.25.1




[PULL 00/10] Block jobs & NBD patches

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
The following changes since commit debd0753663bc89c86f5462a53268f2e3f680f60:

  Merge tag 'pull-testing-next-140622-1' of https://github.com/stsquad/qemu 
into staging (2022-06-13 21:10:57 -0700)

are available in the Git repository at:

  https://gitlab.com/vsementsov/qemu.git tags/pull-block-2022-06-14

for you to fetch changes up to 5aef6747a250f545ff53ba7e1a3ed7a3d166011a:

  MAINTAINERS: update Vladimir's address and repositories (2022-06-14 12:51:48 
+0300)


Block jobs & NBD patches

- add new options for copy-before-write filter
- new trace points for NBD
- prefer unsigned type for some 'in_flight' fields
- update my addresses in MAINTAINERS (already in Stefan's tree, but
  I think it's OK to send it with this PULL)


Note also, that I've recently updated my pgp key with new address and
new expire time.
Updated key is here: 
https://keys.openpgp.org/search?q=vsementsov%40yandex-team.ru



Denis V. Lunev (2):
  nbd: trace long NBD operations
  block: use 'unsigned' for in_flight field on driver state

Vladimir Sementsov-Ogievskiy (8):
  block/copy-before-write: refactor option parsing
  block/copy-before-write: add on-cbw-error open parameter
  iotests: add copy-before-write: on-cbw-error tests
  util: add qemu-co-timeout
  block/block-copy: block_copy(): add timeout_ns parameter
  block/copy-before-write: implement cbw-timeout option
  iotests: copy-before-write: add cases for cbw-timeout option
  MAINTAINERS: update Vladimir's address and repositories

 MAINTAINERS   |  22 +-
 block/block-copy.c|  33 ++-
 block/copy-before-write.c | 111 ++---
 block/mirror.c|   2 +-
 block/nbd.c   |   8 +-
 block/trace-events|   2 +
 include/block/block-copy.h|   4 +-
 include/qemu/coroutine.h  |  13 ++
 nbd/client-connection.c   |   2 +
 nbd/trace-events  |   3 +
 qapi/block-core.json  |  31 ++-
 tests/qemu-iotests/pylintrc   |   5 +
 tests/qemu-iotests/tests/copy-before-write| 213 ++
 .../qemu-iotests/tests/copy-before-write.out  |   5 +
 util/meson.build  |   1 +
 util/qemu-co-timeout.c|  89 
 16 files changed, 492 insertions(+), 52 deletions(-)
 create mode 100755 tests/qemu-iotests/tests/copy-before-write
 create mode 100644 tests/qemu-iotests/tests/copy-before-write.out
 create mode 100644 util/qemu-co-timeout.c

-- 
2.25.1




[PULL 08/10] nbd: trace long NBD operations

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: "Denis V. Lunev" 

At the moment there are 2 sources of lengthy operations if configured:
* open connection, which could retry inside and
* reconnect of already opened connection
These operations could be quite lengthy and cumbersome to catch thus
it would be quite natural to add trace points for them.

This patch is based on the original downstream work made by Vladimir.

Signed-off-by: Denis V. Lunev 
CC: Eric Blake 
CC: Vladimir Sementsov-Ogievskiy 
CC: Kevin Wolf 
CC: Hanna Reitz 
CC: Paolo Bonzini 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd.c | 6 +-
 block/trace-events  | 2 ++
 nbd/client-connection.c | 2 ++
 nbd/trace-events| 3 +++
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/block/nbd.c b/block/nbd.c
index 6085ab1d2c..bc8f128087 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -371,6 +371,7 @@ static bool nbd_client_connecting(BDRVNBDState *s)
 /* Called with s->requests_lock taken.  */
 static coroutine_fn void nbd_reconnect_attempt(BDRVNBDState *s)
 {
+int ret;
 bool blocking = s->state == NBD_CLIENT_CONNECTING_WAIT;
 
 /*
@@ -380,6 +381,8 @@ static coroutine_fn void nbd_reconnect_attempt(BDRVNBDState 
*s)
 assert(nbd_client_connecting(s));
 assert(s->in_flight == 1);
 
+trace_nbd_reconnect_attempt(s->bs->in_flight);
+
 if (blocking && !s->reconnect_delay_timer) {
 /*
  * It's the first reconnect attempt after switching to
@@ -401,7 +404,8 @@ static coroutine_fn void nbd_reconnect_attempt(BDRVNBDState 
*s)
 }
 
 qemu_mutex_unlock(&s->requests_lock);
-nbd_co_do_establish_connection(s->bs, blocking, NULL);
+ret = nbd_co_do_establish_connection(s->bs, blocking, NULL);
+trace_nbd_reconnect_attempt_result(ret, s->bs->in_flight);
 qemu_mutex_lock(&s->requests_lock);
 
 /*
diff --git a/block/trace-events b/block/trace-events
index 549090d453..48dbf10c66 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -172,6 +172,8 @@ nbd_read_reply_entry_fail(int ret, const char *err) "ret = 
%d, err: %s"
 nbd_co_request_fail(uint64_t from, uint32_t len, uint64_t handle, uint16_t 
flags, uint16_t type, const char *name, int ret, const char *err) "Request 
failed { .from = %" PRIu64", .len = %" PRIu32 ", .handle = %" PRIu64 ", .flags 
= 0x%" PRIx16 ", .type = %" PRIu16 " (%s) } ret = %d, err: %s"
 nbd_client_handshake(const char *export_name) "export '%s'"
 nbd_client_handshake_success(const char *export_name) "export '%s'"
+nbd_reconnect_attempt(unsigned in_flight) "in_flight %u"
+nbd_reconnect_attempt_result(int ret, unsigned in_flight) "ret %d in_flight %u"
 
 # ssh.c
 ssh_restart_coroutine(void *co) "co=%p"
diff --git a/nbd/client-connection.c b/nbd/client-connection.c
index 2a632931c3..0c5f917efa 100644
--- a/nbd/client-connection.c
+++ b/nbd/client-connection.c
@@ -23,6 +23,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "trace.h"
 
 #include "block/nbd.h"
 
@@ -210,6 +211,7 @@ static void *connect_thread_func(void *opaque)
 object_unref(OBJECT(conn->sioc));
 conn->sioc = NULL;
 if (conn->do_retry && !conn->detached) {
+trace_nbd_connect_thread_sleep(timeout);
 qemu_mutex_unlock(&conn->mutex);
 
 sleep(timeout);
diff --git a/nbd/trace-events b/nbd/trace-events
index c4919a2dd5..b7032ca277 100644
--- a/nbd/trace-events
+++ b/nbd/trace-events
@@ -73,3 +73,6 @@ nbd_co_receive_request_decode_type(uint64_t handle, uint16_t 
type, const char *n
 nbd_co_receive_request_payload_received(uint64_t handle, uint32_t len) 
"Payload received: handle = %" PRIu64 ", len = %" PRIu32
 nbd_co_receive_align_compliance(const char *op, uint64_t from, uint32_t len, 
uint32_t align) "client sent non-compliant unaligned %s request: from=0x%" 
PRIx64 ", len=0x%" PRIx32 ", align=0x%" PRIx32
 nbd_trip(void) "Reading request"
+
+# client-connection.c
+nbd_connect_thread_sleep(uint64_t timeout) "timeout %" PRIu64
-- 
2.25.1




[PULL 04/10] util: add qemu-co-timeout

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

Add new API, to make a time limited call of the coroutine.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/qemu/coroutine.h | 13 ++
 util/meson.build |  1 +
 util/qemu-co-timeout.c   | 89 
 3 files changed, 103 insertions(+)
 create mode 100644 util/qemu-co-timeout.c

diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
index d1548d5b11..08c5bb3c76 100644
--- a/include/qemu/coroutine.h
+++ b/include/qemu/coroutine.h
@@ -331,6 +331,19 @@ static inline void coroutine_fn 
qemu_co_sleep_ns(QEMUClockType type, int64_t ns)
 qemu_co_sleep_ns_wakeable(&w, type, ns);
 }
 
+typedef void CleanupFunc(void *opaque);
+/**
+ * Run entry in a coroutine and start timer. Wait for entry to finish or for
+ * timer to elapse, what happen first. If entry finished, return 0, if timer
+ * elapsed earlier, return -ETIMEDOUT.
+ *
+ * Be careful, entry execution is not canceled, user should handle it somehow.
+ * If @clean is provided, it's called after coroutine finish if timeout
+ * happened.
+ */
+int coroutine_fn qemu_co_timeout(CoroutineEntry *entry, void *opaque,
+ uint64_t timeout_ns, CleanupFunc clean);
+
 /**
  * Wake a coroutine if it is sleeping in qemu_co_sleep_ns. The timer will be
  * deleted. @sleep_state must be the variable whose address was given to
diff --git a/util/meson.build b/util/meson.build
index 8f16018cd4..9abd2f5bcc 100644
--- a/util/meson.build
+++ b/util/meson.build
@@ -85,6 +85,7 @@ if have_block
   util_ss.add(files('block-helpers.c'))
   util_ss.add(files('qemu-coroutine-sleep.c'))
   util_ss.add(files('qemu-co-shared-resource.c'))
+  util_ss.add(files('qemu-co-timeout.c'))
   util_ss.add(files('thread-pool.c', 'qemu-timer.c'))
   util_ss.add(files('readline.c'))
   util_ss.add(files('throttle.c'))
diff --git a/util/qemu-co-timeout.c b/util/qemu-co-timeout.c
new file mode 100644
index 00..00cd335649
--- /dev/null
+++ b/util/qemu-co-timeout.c
@@ -0,0 +1,89 @@
+/*
+ * Helper functionality for distributing a fixed total amount of
+ * an abstract resource among multiple coroutines.
+ *
+ * Copyright (c) 2022 Virtuozzo International GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/coroutine.h"
+#include "block/aio.h"
+
+typedef struct QemuCoTimeoutState {
+CoroutineEntry *entry;
+void *opaque;
+QemuCoSleep sleep_state;
+bool marker;
+CleanupFunc *clean;
+} QemuCoTimeoutState;
+
+static void coroutine_fn qemu_co_timeout_entry(void *opaque)
+{
+QemuCoTimeoutState *s = opaque;
+
+s->entry(s->opaque);
+
+if (s->marker) {
+assert(!s->sleep_state.to_wake);
+/* .marker set by qemu_co_timeout, it have been failed */
+if (s->clean) {
+s->clean(s->opaque);
+}
+g_free(s);
+} else {
+s->marker = true;
+qemu_co_sleep_wake(&s->sleep_state);
+}
+}
+
+int coroutine_fn qemu_co_timeout(CoroutineEntry *entry, void *opaque,
+ uint64_t timeout_ns, CleanupFunc clean)
+{
+QemuCoTimeoutState *s;
+Coroutine *co;
+
+if (timeout_ns == 0) {
+entry(opaque);
+return 0;
+}
+
+s = g_new(QemuCoTimeoutState, 1);
+*s = (QemuCoTimeoutState) {
+.entry = entry,
+.opaque = opaque,
+.clean = clean
+};
+
+co = qemu_coroutine_create(qemu_co_timeout_entry, s);
+
+aio_co_enter(qemu_get_current_aio_context(), co);
+qemu_co_sleep_ns_wakeable(&s->sleep_state, QEMU_CLOCK_REALTIME, 
timeout_ns);
+
+if (s->marker) {
+/* .marker set by qemu_co_timeout_entry, success */
+g_free(s);
+return 0;
+}
+
+/* Don't free s, as we can't cancel qemu_co_timeout_entry execution */
+s->marker = true;
+return -E

[PATCH 1/2] Trivial: 3 char repeat typos

2022-06-14 Thread Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" 

Inspired by Julia Lawall's fixing of Linux
kernel comments, I looked at qemu, although I did it manually.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/intc/openpic.c| 2 +-
 hw/net/imx_fec.c | 2 +-
 hw/pci/pcie_aer.c| 2 +-
 hw/pci/shpc.c| 3 ++-
 hw/ppc/spapr_caps.c  | 2 +-
 hw/scsi/spapr_vscsi.c| 2 +-
 qapi/net.json| 2 +-
 tools/virtiofsd/passthrough_ll.c | 2 +-
 ui/input.c   | 2 +-
 9 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/hw/intc/openpic.c b/hw/intc/openpic.c
index 49504e740f..b0787e8ee7 100644
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@ -729,7 +729,7 @@ static void openpic_tmr_set_tmr(OpenPICTimer *tmr, uint32_t 
val, bool enabled)
 }
 
 /*
- * Returns the currrent tccr value, i.e., timer value (in clocks) with
+ * Returns the current tccr value, i.e., timer value (in clocks) with
  * appropriate TOG.
  */
 static uint64_t openpic_tmr_get_timer(OpenPICTimer *tmr)
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index 0db9aaf76a..8c11b237de 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -438,7 +438,7 @@ static void imx_eth_update(IMXFECState *s)
  *   assignment fail.
  *
  * To ensure that all versions of Linux work, generate ENET_INT_MAC
- * interrrupts on both interrupt lines. This should be changed if and when
+ * interrupts on both interrupt lines. This should be changed if and when
  * qemu supports IOMUX.
  */
 if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] &
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 92bd0530dd..eff62f3945 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -323,7 +323,7 @@ static void pcie_aer_msg_root_port(PCIDevice *dev, const 
PCIEAERMsg *msg)
  */
 }
 
-/* Errro Message Received: Root Error Status register */
+/* Error Message Received: Root Error Status register */
 switch (msg->severity) {
 case PCI_ERR_ROOT_CMD_COR_EN:
 if (root_status & PCI_ERR_ROOT_COR_RCV) {
diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c
index f822f18b98..e71f3a7483 100644
--- a/hw/pci/shpc.c
+++ b/hw/pci/shpc.c
@@ -480,7 +480,8 @@ static const MemoryRegionOps shpc_mmio_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
 /* SHPC ECN requires dword accesses, but the original 1.0 spec doesn't.
- * It's easier to suppport all sizes than worry about it. */
+ * It's easier to support all sizes than worry about it.
+ */
 .min_access_size = 1,
 .max_access_size = 4,
 },
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 655ab856a0..b4283055c1 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -553,7 +553,7 @@ static void cap_ccf_assist_apply(SpaprMachineState *spapr, 
uint8_t val,
  * instruction is a harmless no-op.  It won't correctly
  * implement the cache count flush *but* if we have
  * count-cache-disabled in the host, that flush is
- * unnnecessary.  So, specifically allow this case.  This
+ * unnecessary.  So, specifically allow this case.  This
  * allows us to have better performance on POWER9 DD2.3,
  * while still working on POWER9 DD2.2 and POWER8 host
  * cpus.
diff --git a/hw/scsi/spapr_vscsi.c b/hw/scsi/spapr_vscsi.c
index a07a8e1523..e320ccaa23 100644
--- a/hw/scsi/spapr_vscsi.c
+++ b/hw/scsi/spapr_vscsi.c
@@ -1013,7 +1013,7 @@ static int vscsi_send_capabilities(VSCSIState *s, 
vscsi_req *req)
 }
 
 /*
- * Current implementation does not suppport any migration or
+ * Current implementation does not support any migration or
  * reservation capabilities. Construct the response telling the
  * guest not to use them.
  */
diff --git a/qapi/net.json b/qapi/net.json
index d6f7cfd4d6..9af11e9a3b 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -298,7 +298,7 @@
 #
 # @udp: use the udp version of l2tpv3 encapsulation
 #
-# @cookie64: use 64 bit coookies
+# @cookie64: use 64 bit cookies
 #
 # @counter: have sequence counter
 #
diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index b15c631ca5..7a73dfcce9 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2319,7 +2319,7 @@ static int do_lo_create(fuse_req_t req, struct lo_inode 
*parent_inode,
  * If security.selinux has not been remapped and selinux is enabled,
  * use fscreate to set context before file creation. If not, use
  * tmpfile method for regular files. Otherwise fallback to
- * non-atomic method of file creation and xattr settting.
+ * non-atomic method of file creation and xattr setting.
  */
 if (!mapped_name && lo->use_fscreate) {
 err = do_create_secctx_fscreate(req, parent_inode, name, mode, fi,
diff --git a/ui/i

[PULL 07/10] iotests: copy-before-write: add cases for cbw-timeout option

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

Add two simple test-cases: timeout failure with
break-snapshot-on-cbw-error behavior and similar with
break-guest-write-on-cbw-error behavior.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/tests/copy-before-write| 81 +++
 .../qemu-iotests/tests/copy-before-write.out  |  4 +-
 2 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/tests/copy-before-write 
b/tests/qemu-iotests/tests/copy-before-write
index 6c7638965e..f01f26f01c 100755
--- a/tests/qemu-iotests/tests/copy-before-write
+++ b/tests/qemu-iotests/tests/copy-before-write
@@ -126,6 +126,87 @@ read 1048576/1048576 bytes at offset 0
 1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 """)
 
+def do_cbw_timeout(self, on_cbw_error):
+result = self.vm.qmp('object-add', {
+'qom-type': 'throttle-group',
+'id': 'group0',
+'limits': {'bps-write': 300 * 1024}
+})
+self.assert_qmp(result, 'return', {})
+
+result = self.vm.qmp('blockdev-add', {
+'node-name': 'cbw',
+'driver': 'copy-before-write',
+'on-cbw-error': on_cbw_error,
+'cbw-timeout': 1,
+'file': {
+'driver': iotests.imgfmt,
+'file': {
+'driver': 'file',
+'filename': source_img,
+}
+},
+'target': {
+'driver': 'throttle',
+'throttle-group': 'group0',
+'file': {
+'driver': 'qcow2',
+'file': {
+'driver': 'file',
+'filename': temp_img
+}
+}
+}
+})
+self.assert_qmp(result, 'return', {})
+
+result = self.vm.qmp('blockdev-add', {
+'node-name': 'access',
+'driver': 'snapshot-access',
+'file': 'cbw'
+})
+self.assert_qmp(result, 'return', {})
+
+result = self.vm.qmp('human-monitor-command',
+ command_line='qemu-io cbw "write 0 512K"')
+self.assert_qmp(result, 'return', '')
+
+# We need second write to trigger throttling
+result = self.vm.qmp('human-monitor-command',
+ command_line='qemu-io cbw "write 512K 512K"')
+self.assert_qmp(result, 'return', '')
+
+result = self.vm.qmp('human-monitor-command',
+ command_line='qemu-io access "read 0 1M"')
+self.assert_qmp(result, 'return', '')
+
+self.vm.shutdown()
+log = self.vm.get_log()
+log = re.sub(r'^\[I \d+\.\d+\] OPENED\n', '', log)
+log = re.sub(r'\[I \+\d+\.\d+\] CLOSED\n?$', '', log)
+log = iotests.filter_qemu_io(log)
+return log
+
+def test_timeout_break_guest(self):
+log = self.do_cbw_timeout('break-guest-write')
+self.assertEqual(log, """\
+wrote 524288/524288 bytes at offset 0
+512 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+write failed: Connection timed out
+read 1048576/1048576 bytes at offset 0
+1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+""")
+
+def test_timeout_break_snapshot(self):
+log = self.do_cbw_timeout('break-snapshot')
+self.assertEqual(log, """\
+wrote 524288/524288 bytes at offset 0
+512 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 524288/524288 bytes at offset 524288
+512 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+read failed: Permission denied
+""")
+
 
 if __name__ == '__main__':
 iotests.main(supported_fmts=['qcow2'],
diff --git a/tests/qemu-iotests/tests/copy-before-write.out 
b/tests/qemu-iotests/tests/copy-before-write.out
index fbc63e62f8..89968f35d7 100644
--- a/tests/qemu-iotests/tests/copy-before-write.out
+++ b/tests/qemu-iotests/tests/copy-before-write.out
@@ -1,5 +1,5 @@
-..
+
 --
-Ran 2 tests
+Ran 4 tests
 
 OK
-- 
2.25.1




[PATCH 2/2] trivial typos: namesapce

2022-06-14 Thread Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" 

'namespace' is misspelled in a bunch of places.

Signed-off-by: Dr. David Alan Gilbert 
---
 hw/9pfs/9p-xattr-user.c | 8 
 hw/acpi/nvdimm.c| 2 +-
 hw/nvme/ctrl.c  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/9pfs/9p-xattr-user.c b/hw/9pfs/9p-xattr-user.c
index f2ae9582e6..535677ed60 100644
--- a/hw/9pfs/9p-xattr-user.c
+++ b/hw/9pfs/9p-xattr-user.c
@@ -27,7 +27,7 @@ static ssize_t mp_user_getxattr(FsContext *ctx, const char 
*path,
 {
 if (strncmp(name, "user.virtfs.", 12) == 0) {
 /*
- * Don't allow fetch of user.virtfs namesapce
+ * Don't allow fetch of user.virtfs namespace
  * in case of mapped security
  */
 errno = ENOATTR;
@@ -49,7 +49,7 @@ static ssize_t mp_user_listxattr(FsContext *ctx, const char 
*path,
 name_size -= 12;
 } else {
 /*
- * Don't allow fetch of user.virtfs namesapce
+ * Don't allow fetch of user.virtfs namespace
  * in case of mapped security
  */
 return 0;
@@ -74,7 +74,7 @@ static int mp_user_setxattr(FsContext *ctx, const char *path, 
const char *name,
 {
 if (strncmp(name, "user.virtfs.", 12) == 0) {
 /*
- * Don't allow fetch of user.virtfs namesapce
+ * Don't allow fetch of user.virtfs namespace
  * in case of mapped security
  */
 errno = EACCES;
@@ -88,7 +88,7 @@ static int mp_user_removexattr(FsContext *ctx,
 {
 if (strncmp(name, "user.virtfs.", 12) == 0) {
 /*
- * Don't allow fetch of user.virtfs namesapce
+ * Don't allow fetch of user.virtfs namespace
  * in case of mapped security
  */
 errno = EACCES;
diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 0d43da19ea..5f85b16327 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -476,7 +476,7 @@ struct NvdimmFuncGetLabelDataOut {
 /* the size of buffer filled by QEMU. */
 uint32_t len;
 uint32_t func_ret_status; /* return status code. */
-uint8_t out_buf[]; /* the data got via Get Namesapce Label function. */
+uint8_t out_buf[]; /* the data got via Get Namespace Label function. */
 } QEMU_PACKED;
 typedef struct NvdimmFuncGetLabelDataOut NvdimmFuncGetLabelDataOut;
 QEMU_BUILD_BUG_ON(sizeof(NvdimmFuncGetLabelDataOut) > NVDIMM_DSM_MEMORY_SIZE);
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index 1e6e0fcad9..770a38381a 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -71,7 +71,7 @@
  *   the SUBNQN field in the controller will report the NQN of the subsystem
  *   device. This also enables multi controller capability represented in
  *   Identify Controller data structure in CMIC (Controller Multi-path I/O and
- *   Namesapce Sharing Capabilities).
+ *   Namespace Sharing Capabilities).
  *
  * - `aerl`
  *   The Asynchronous Event Request Limit (AERL). Indicates the maximum number
-- 
2.36.1




[PULL 03/10] iotests: add copy-before-write: on-cbw-error tests

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy 

Add tests for new option of copy-before-write filter: on-cbw-error.

Note that we use QEMUMachine instead of VM class, because in further
commit we'll want to use throttling which doesn't work with -accel
qtest used by VM.

We also touch pylintrc to not break iotest 297.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/pylintrc   |   5 +
 tests/qemu-iotests/tests/copy-before-write| 132 ++
 .../qemu-iotests/tests/copy-before-write.out  |   5 +
 3 files changed, 142 insertions(+)
 create mode 100755 tests/qemu-iotests/tests/copy-before-write
 create mode 100644 tests/qemu-iotests/tests/copy-before-write.out

diff --git a/tests/qemu-iotests/pylintrc b/tests/qemu-iotests/pylintrc
index 32ab77b8bb..f4f823a991 100644
--- a/tests/qemu-iotests/pylintrc
+++ b/tests/qemu-iotests/pylintrc
@@ -51,3 +51,8 @@ notes=FIXME,
 
 # Maximum number of characters on a single line.
 max-line-length=79
+
+
+[SIMILARITIES]
+
+min-similarity-lines=6
diff --git a/tests/qemu-iotests/tests/copy-before-write 
b/tests/qemu-iotests/tests/copy-before-write
new file mode 100755
index 00..6c7638965e
--- /dev/null
+++ b/tests/qemu-iotests/tests/copy-before-write
@@ -0,0 +1,132 @@
+#!/usr/bin/env python3
+# group: auto backup
+#
+# Copyright (c) 2022 Virtuozzo International GmbH
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+import os
+import re
+
+from qemu.machine import QEMUMachine
+
+import iotests
+from iotests import qemu_img_create, qemu_io
+
+
+temp_img = os.path.join(iotests.test_dir, 'temp')
+source_img = os.path.join(iotests.test_dir, 'source')
+size = '1M'
+
+
+class TestCbwError(iotests.QMPTestCase):
+def tearDown(self):
+self.vm.shutdown()
+os.remove(temp_img)
+os.remove(source_img)
+
+def setUp(self):
+qemu_img_create('-f', iotests.imgfmt, source_img, size)
+qemu_img_create('-f', iotests.imgfmt, temp_img, size)
+qemu_io('-c', 'write 0 1M', source_img)
+
+self.vm = QEMUMachine(iotests.qemu_prog)
+self.vm.launch()
+
+def do_cbw_error(self, on_cbw_error):
+result = self.vm.qmp('blockdev-add', {
+'node-name': 'cbw',
+'driver': 'copy-before-write',
+'on-cbw-error': on_cbw_error,
+'file': {
+'driver': iotests.imgfmt,
+'file': {
+'driver': 'file',
+'filename': source_img,
+}
+},
+'target': {
+'driver': iotests.imgfmt,
+'file': {
+'driver': 'blkdebug',
+'image': {
+'driver': 'file',
+'filename': temp_img
+},
+'inject-error': [
+{
+'event': 'write_aio',
+'errno': 5,
+'immediately': False,
+'once': True
+}
+]
+}
+}
+})
+self.assert_qmp(result, 'return', {})
+
+result = self.vm.qmp('blockdev-add', {
+'node-name': 'access',
+'driver': 'snapshot-access',
+'file': 'cbw'
+})
+self.assert_qmp(result, 'return', {})
+
+result = self.vm.qmp('human-monitor-command',
+ command_line='qemu-io cbw "write 0 1M"')
+self.assert_qmp(result, 'return', '')
+
+result = self.vm.qmp('human-monitor-command',
+ command_line='qemu-io access "read 0 1M"')
+self.assert_qmp(result, 'return', '')
+
+self.vm.shutdown()
+log = self.vm.get_log()
+log = re.sub(r'^\[I \d+\.\d+\] OPENED\n', '', log)
+log = re.sub(r'\[I \+\d+\.\d+\] CLOSED\n?$', '', log)
+log = iotests.filter_qemu_io(log)
+return log
+
+def test_break_snapshot_on_cbw_error(self):
+"""break-snapshot behavior:
+Guest write succeed, but further snapshot-read fails, as snapshot is
+broken.
+"""
+log = self.do_cbw_error('break-snapshot')
+
+self.assertEqual(log, """\
+wrote 1048576/10485

[PULL 09/10] block: use 'unsigned' for in_flight field on driver state

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
From: "Denis V. Lunev" 

This patch makes in_flight field 'unsigned' for BDRVNBDState and
MirrorBlockJob. This matches the definition of this field on BDS
and is generically correct - we should never get negative value here.

Signed-off-by: Denis V. Lunev 
CC: John Snow 
CC: Vladimir Sementsov-Ogievskiy 
CC: Kevin Wolf 
CC: Hanna Reitz 
CC: Eric Blake 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/mirror.c | 2 +-
 block/nbd.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index d8ecb9efa2..3c4ab1159d 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -73,7 +73,7 @@ typedef struct MirrorBlockJob {
 
 uint64_t last_pause_ns;
 unsigned long *in_flight_bitmap;
-int in_flight;
+unsigned in_flight;
 int64_t bytes_in_flight;
 QTAILQ_HEAD(, MirrorOp) ops_in_flight;
 int ret;
diff --git a/block/nbd.c b/block/nbd.c
index bc8f128087..19e773d602 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -77,7 +77,7 @@ typedef struct BDRVNBDState {
 QemuMutex requests_lock;
 NBDClientState state;
 CoQueue free_sema;
-int in_flight;
+unsigned in_flight;
 NBDClientRequest requests[MAX_NBD_REQUESTS];
 QEMUTimer *reconnect_delay_timer;
 
-- 
2.25.1




[PULL 10/10] MAINTAINERS: update Vladimir's address and repositories

2022-06-14 Thread Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 MAINTAINERS | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0df25ed4b0..9e37bfe279 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2538,7 +2538,7 @@ F: scsi/*
 
 Block Jobs
 M: John Snow 
-M: Vladimir Sementsov-Ogievskiy 
+M: Vladimir Sementsov-Ogievskiy 
 L: qemu-bl...@nongnu.org
 S: Supported
 F: blockjob.c
@@ -2563,7 +2563,7 @@ F: block/aio_task.c
 F: util/qemu-co-shared-resource.c
 F: include/qemu/co-shared-resource.h
 T: git https://gitlab.com/jsnow/qemu.git jobs
-T: git https://src.openvz.org/scm/~vsementsov/qemu.git jobs
+T: git https://gitlab.com/vsementsov/qemu.git block
 
 Block QAPI, monitor, command line
 M: Markus Armbruster 
@@ -2584,7 +2584,7 @@ F: include/hw/cxl/
 
 Dirty Bitmaps
 M: Eric Blake 
-M: Vladimir Sementsov-Ogievskiy 
+M: Vladimir Sementsov-Ogievskiy 
 R: John Snow 
 L: qemu-bl...@nongnu.org
 S: Supported
@@ -2598,6 +2598,7 @@ F: util/hbitmap.c
 F: tests/unit/test-hbitmap.c
 F: docs/interop/bitmaps.rst
 T: git https://repo.or.cz/qemu/ericb.git bitmaps
+T: git https://gitlab.com/vsementsov/qemu.git block
 
 Character device backends
 M: Marc-André Lureau 
@@ -2808,16 +2809,17 @@ F: scripts/*.py
 F: tests/*.py
 
 Benchmark util
-M: Vladimir Sementsov-Ogievskiy 
+M: Vladimir Sementsov-Ogievskiy 
 S: Maintained
 F: scripts/simplebench/
-T: git https://src.openvz.org/scm/~vsementsov/qemu.git simplebench
+T: git https://gitlab.com/vsementsov/qemu.git simplebench
 
 Transactions helper
-M: Vladimir Sementsov-Ogievskiy 
+M: Vladimir Sementsov-Ogievskiy 
 S: Maintained
 F: include/qemu/transactions.h
 F: util/transactions.c
+T: git https://gitlab.com/vsementsov/qemu.git block
 
 QAPI
 M: Markus Armbruster 
@@ -3394,7 +3396,7 @@ F: block/iscsi-opts.c
 
 Network Block Device (NBD)
 M: Eric Blake 
-M: Vladimir Sementsov-Ogievskiy 
+M: Vladimir Sementsov-Ogievskiy 
 L: qemu-bl...@nongnu.org
 S: Maintained
 F: block/nbd*
@@ -3406,7 +3408,7 @@ F: docs/interop/nbd.txt
 F: docs/tools/qemu-nbd.rst
 F: tests/qemu-iotests/tests/*nbd*
 T: git https://repo.or.cz/qemu/ericb.git nbd
-T: git https://src.openvz.org/scm/~vsementsov/qemu.git nbd
+T: git https://gitlab.com/vsementsov/qemu.git block
 
 NFS
 M: Peter Lieven 
@@ -3491,13 +3493,13 @@ F: block/dmg.c
 parallels
 M: Stefan Hajnoczi 
 M: Denis V. Lunev 
-M: Vladimir Sementsov-Ogievskiy 
+M: Vladimir Sementsov-Ogievskiy 
 L: qemu-bl...@nongnu.org
 S: Supported
 F: block/parallels.c
 F: block/parallels-ext.c
 F: docs/interop/parallels.txt
-T: git https://src.openvz.org/scm/~vsementsov/qemu.git parallels
+T: git https://gitlab.com/vsementsov/qemu.git block
 
 qed
 M: Stefan Hajnoczi 
-- 
2.25.1




[PATCH 0/2] Two sets of trivials

2022-06-14 Thread Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" 

I've sent the 3 char set last month, but have updated
it a little; I cleaned up a comment style that was already
broken so checkpatch is happy.

The 'namesapce' is a new patch; it's amazing how many places
make the same typo!

Dave

Dr. David Alan Gilbert (2):
  Trivial: 3 char repeat typos
  trivial typos: namesapce

 hw/9pfs/9p-xattr-user.c  | 8 
 hw/acpi/nvdimm.c | 2 +-
 hw/intc/openpic.c| 2 +-
 hw/net/imx_fec.c | 2 +-
 hw/nvme/ctrl.c   | 2 +-
 hw/pci/pcie_aer.c| 2 +-
 hw/pci/shpc.c| 3 ++-
 hw/ppc/spapr_caps.c  | 2 +-
 hw/scsi/spapr_vscsi.c| 2 +-
 qapi/net.json| 2 +-
 tools/virtiofsd/passthrough_ll.c | 2 +-
 ui/input.c   | 2 +-
 12 files changed, 16 insertions(+), 15 deletions(-)

-- 
2.36.1




Re: [PATCH v2 07/11] vfio/migration: Implement VFIO migration protocol v2

2022-06-14 Thread Joao Martins
On 5/30/22 18:07, Avihai Horon wrote:
> +static int vfio_save_complete_precopy(QEMUFile *f, void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +enum vfio_device_mig_state recover_state;
> +int ret;
> +
> +/* We reach here with device state STOP or STOP_COPY only */
> +recover_state = VFIO_DEVICE_STATE_STOP;
> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_STOP_COPY,
> +   recover_state);
> +if (ret) {
> +return ret;
> +}
> +
> +do {
> +ret = vfio_save_block(f, vbasedev->migration);
> +if (ret < 0) {
> +return ret;
> +}
> +} while (!ret);
> +
> +qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
> +ret = qemu_file_get_error(f);
> +if (ret) {
> +return ret;
> +}
> +
> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_STOP,
> +   recover_state);

Is it expected that you are setting VFIO_DEVICE_STATE_STOP while
@recover_state is the same value (VFIO_DEVICE_STATE_STOP) ?

> +if (ret) {
> +return ret;
> +}
> +
> +trace_vfio_save_complete_precopy(vbasedev->name);
> +
> +return 0;
> +}
> +
>  static int vfio_v1_save_complete_precopy(QEMUFile *f, void *opaque)
>  {
>  VFIODevice *vbasedev = opaque;
> @@ -593,6 +775,14 @@ static void vfio_save_state(QEMUFile *f, void *opaque)
>  }
>  }
>  
> +static int vfio_load_setup(QEMUFile *f, void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +
> +return vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_RESUMING,
> +   vbasedev->migration->device_state);
> +}
> +
>  static int vfio_v1_load_setup(QEMUFile *f, void *opaque)
>  {
>  VFIODevice *vbasedev = opaque;
> @@ -620,6 +810,15 @@ static int vfio_v1_load_setup(QEMUFile *f, void *opaque)
>  return ret;
>  }
>  
> +static int vfio_load_cleanup(void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +
> +vfio_migration_cleanup(vbasedev);
> +trace_vfio_load_cleanup(vbasedev->name);
> +return 0;
> +}
> +
>  static int vfio_v1_load_cleanup(void *opaque)
>  {
>  VFIODevice *vbasedev = opaque;
> @@ -662,7 +861,11 @@ static int vfio_load_state(QEMUFile *f, void *opaque, 
> int version_id)
>  uint64_t data_size = qemu_get_be64(f);
>  
>  if (data_size) {
> -ret = vfio_v1_load_buffer(f, vbasedev, data_size);
> +if (vbasedev->migration->v2) {
> +ret = vfio_load_buffer(f, vbasedev, data_size);
> +} else {
> +ret = vfio_v1_load_buffer(f, vbasedev, data_size);
> +}
>  if (ret < 0) {
>  return ret;
>  }
> @@ -683,6 +886,16 @@ static int vfio_load_state(QEMUFile *f, void *opaque, 
> int version_id)
>  return ret;
>  }
>  
> +static SaveVMHandlers savevm_vfio_handlers = {
> +.save_setup = vfio_save_setup,
> +.save_cleanup = vfio_save_cleanup,
> +.save_live_complete_precopy = vfio_save_complete_precopy,
> +.save_state = vfio_save_state,
> +.load_setup = vfio_load_setup,
> +.load_cleanup = vfio_load_cleanup,
> +.load_state = vfio_load_state,
> +};
> +
>  static SaveVMHandlers savevm_vfio_v1_handlers = {
>  .save_setup = vfio_v1_save_setup,
>  .save_cleanup = vfio_v1_save_cleanup,
> @@ -697,6 +910,34 @@ static SaveVMHandlers savevm_vfio_v1_handlers = {
>  
>  /* -- */
>  
> +static void vfio_vmstate_change(void *opaque, bool running, RunState state)
> +{
> +VFIODevice *vbasedev = opaque;
> +enum vfio_device_mig_state new_state;
> +int ret;
> +
> +if (running) {
> +new_state = VFIO_DEVICE_STATE_RUNNING;
> +} else {
> +new_state = VFIO_DEVICE_STATE_STOP;
> +}
> +
> +ret = vfio_migration_set_state(vbasedev, new_state,
> +   VFIO_DEVICE_STATE_ERROR);
> +if (ret) {
> +/*
> + * Migration should be aborted in this case, but vm_state_notify()
> + * currently does not support reporting failures.
> + */
> +if (migrate_get_current()->to_dst_file) {
> +qemu_file_set_error(migrate_get_current()->to_dst_file, ret);
> +}
> +}
> +
> +trace_vfio_vmstate_change(vbasedev->name, running, RunState_str(state),
> +  new_state);
> +}
> +
>  static void vfio_v1_vmstate_change(void *opaque, bool running, RunState 
> state)
>  {
>  VFIODevice *vbasedev = opaque;
> @@ -770,12 +1011,17 @@ static void vfio_migration_state_notifier(Notifier 
> *notifier, void *data)
>  case MIGRATION_STATUS_CANCELLED:
>  case MIGRATION_STATUS_FAILED:
>  bytes_transferred = 0;
> -ret = vfio_migration_v1_set_state(vbasedev,
> -  ~(VFIO_DEVICE_STATE_V1_SAVING |
> -   

[PATCH 2/2] tap: initialize TAPState->enabled according to the actual state of queue

2022-06-14 Thread Andrey Ryabinin
Currently TAPState->enabled initialized as true. If fd was passed to qemu
in a disabled state it will cause an assert at the attempt to detach queue
in virtio_net_set_queues():

virtio_net_set_queues() :
r = peer_detach() -> tap_disable():
if (s->enabled == 0) {
   return 0;
} else {
   //Will return an error.
   ret = tap_fd_disable(s->fd);
   ...
   return ret;
assert(!r);

Initialize ->enabled according to the actual state of fd to fix this.

Signed-off-by: Andrey Ryabinin 
---
 net/tap-bsd.c |  5 +
 net/tap-linux.c   | 12 
 net/tap-solaris.c |  5 +
 net/tap.c |  2 +-
 net/tap_int.h |  1 +
 5 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/net/tap-bsd.c b/net/tap-bsd.c
index 005ce05c6e0..8c21f058c8c 100644
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -217,6 +217,11 @@ int tap_probe_vnet_hdr_len(int fd, int len)
 return 0;
 }
 
+bool tap_probe_enabled(int fd)
+{
+return true;
+}
+
 void tap_fd_set_vnet_hdr_len(int fd, int len)
 {
 }
diff --git a/net/tap-linux.c b/net/tap-linux.c
index 304ff45071d..6078ba03af6 100644
--- a/net/tap-linux.c
+++ b/net/tap-linux.c
@@ -193,6 +193,18 @@ int tap_probe_vnet_hdr_len(int fd, int len)
 return 1;
 }
 
+bool tap_probe_enabled(int fd)
+{
+struct ifreq ifr;
+
+if (ioctl(fd, TUNGETIFF, &ifr) != 0) {
+error_report("TUNGETIFF ioctl() failed: %s",
+ strerror(errno));
+return false;
+}
+return !(ifr.ifr_flags & IFF_DETACH_QUEUE);
+}
+
 void tap_fd_set_vnet_hdr_len(int fd, int len)
 {
 if (ioctl(fd, TUNSETVNETHDRSZ, &len) == -1) {
diff --git a/net/tap-solaris.c b/net/tap-solaris.c
index a44f8805c23..ccaa3334882 100644
--- a/net/tap-solaris.c
+++ b/net/tap-solaris.c
@@ -221,6 +221,11 @@ int tap_probe_vnet_hdr_len(int fd, int len)
 return 0;
 }
 
+bool tap_probe_enabled(int fd)
+{
+return true;
+}
+
 void tap_fd_set_vnet_hdr_len(int fd, int len)
 {
 }
diff --git a/net/tap.c b/net/tap.c
index b3ddfd4a74b..799f8ec7c76 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -399,7 +399,7 @@ static TAPState *net_tap_fd_init(NetClientState *peer,
 s->host_vnet_hdr_len = vnet_hdr ? sizeof(struct virtio_net_hdr) : 0;
 s->using_vnet_hdr = false;
 s->has_ufo = tap_probe_has_ufo(s->fd);
-s->enabled = true;
+s->enabled = tap_probe_enabled(s->fd);
 tap_set_offload(&s->nc, 0, 0, 0, 0, 0);
 /*
  * Make sure host header length is set correctly in tap:
diff --git a/net/tap_int.h b/net/tap_int.h
index 547f8a5a28f..b8fc3dfbfa7 100644
--- a/net/tap_int.h
+++ b/net/tap_int.h
@@ -37,6 +37,7 @@ void tap_set_sndbuf(int fd, const NetdevTapOptions *tap, 
Error **errp);
 int tap_probe_vnet_hdr(int fd, Error **errp);
 int tap_probe_vnet_hdr_len(int fd, int len);
 int tap_probe_has_ufo(int fd);
+bool tap_probe_enabled(int fd);
 void tap_fd_set_offload(int fd, int csum, int tso4, int tso6, int ecn, int 
ufo);
 void tap_fd_set_vnet_hdr_len(int fd, int len);
 int tap_fd_set_vnet_le(int fd, int vnet_is_le);
-- 
2.35.1




[PATCH 0/2] Make local migration with TAP network device possible

2022-06-14 Thread Andrey Ryabinin
Hi

These couple patches aims to  make possible local migration (within one host)
on the same TAP device used by source and destination QEMU

The scenario looks like this
 1. Create TAP devices and pass file descriptors to source QEMU
 2. Launch destination QEMU (-incoming defer) and pass same descriptors to it.
 3. Start migration


Regarding the first patch: It makes possible to receive file descriptor in 
non-blocking
state. But I probably didn't cover all FD users which might need to set 
blocking state after
the patch. So I'm hopping for the hints where else, besides 
fd_start_incoming_migration()
I need to put qemu_socket_set_block() calls.


Andrey Ryabinin (2):
  chardev: don't set O_NONBLOCK on SCM_RIGHTS file descriptors.
  tap: initialize TAPState->enabled according to the actual state of
queue

 chardev/char-socket.c |  3 ---
 io/channel-socket.c   |  3 ---
 migration/fd.c|  2 ++
 net/tap-bsd.c |  5 +
 net/tap-linux.c   | 12 
 net/tap-solaris.c |  5 +
 net/tap.c |  2 +-
 net/tap_int.h |  1 +
 8 files changed, 26 insertions(+), 7 deletions(-)

-- 
2.35.1




[PATCH 1/2] chardev: don't set O_NONBLOCK on SCM_RIGHTS file descriptors.

2022-06-14 Thread Andrey Ryabinin
This reverts commit 9b938c7262e4 ("chardev: clear O_NONBLOCK on SCM_RIGHTS file 
descriptors").
File descriptor passed to QEMU via 'getfd' QMP command always
changed to blocking mode. Instead of that, change blocking mode by QEMU
file descriptors users when necessary, e.g. like migration.

We need to preserve the state of the file descriptor in case it's still
used by an external process and before the QEMU itself started
using it.

E.g. our local migration scenario with TAP networking looks like this:
 1. Create TAP devices and pass file descriptors to source QEMU
 2. Launch destination QEMU (-incoming defer) and pass same descriptors to it.
 3. Start migration

In such scenario setting blocking state at stage (2) will hang source QEMU
since TAP fd suddenly become blocking.

Signed-off-by: Andrey Ryabinin 
---
 chardev/char-socket.c | 3 ---
 io/channel-socket.c   | 3 ---
 migration/fd.c| 2 ++
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index dc4e218eeb6..c9592fb5836 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -310,9 +310,6 @@ static ssize_t tcp_chr_recv(Chardev *chr, char *buf, size_t 
len)
 continue;
 }
 
-/* O_NONBLOCK is preserved across SCM_RIGHTS so reset it */
-qemu_socket_set_block(fd);
-
 #ifndef MSG_CMSG_CLOEXEC
 qemu_set_cloexec(fd);
 #endif
diff --git a/io/channel-socket.c b/io/channel-socket.c
index dc9c165de11..8b9679460dc 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -479,9 +479,6 @@ static void qio_channel_socket_copy_fds(struct msghdr *msg,
 continue;
 }
 
-/* O_NONBLOCK is preserved across SCM_RIGHTS so reset it */
-qemu_socket_set_block(fd);
-
 #ifndef MSG_CMSG_CLOEXEC
 qemu_set_cloexec(fd);
 #endif
diff --git a/migration/fd.c b/migration/fd.c
index 6f2f50475f4..793fffeb169 100644
--- a/migration/fd.c
+++ b/migration/fd.c
@@ -60,6 +60,8 @@ void fd_start_incoming_migration(const char *fdname, Error 
**errp)
 return;
 }
 
+qemu_socket_set_block(fd);
+
 trace_migration_fd_incoming(fd);
 
 ioc = qio_channel_new_fd(fd, errp);
-- 
2.35.1




Re: [PATCH 0/2] Make local migration with TAP network device possible

2022-06-14 Thread Daniel P . Berrangé
On Tue, Jun 14, 2022 at 02:18:41PM +0300, Andrey Ryabinin wrote:
> Hi
> 
> These couple patches aims to  make possible local migration (within one host)
> on the same TAP device used by source and destination QEMU
> 
> The scenario looks like this
>  1. Create TAP devices and pass file descriptors to source QEMU
>  2. Launch destination QEMU (-incoming defer) and pass same descriptors to it.
>  3. Start migration
> 
> 
> Regarding the first patch: It makes possible to receive file descriptor in 
> non-blocking
> state. But I probably didn't cover all FD users which might need to set 
> blocking state after
> the patch. So I'm hopping for the hints where else, besides 
> fd_start_incoming_migration()
> I need to put qemu_socket_set_block() calls.

You'll need to check all callers of

qio_channel_readv_full
qio_channel_readv_full_all
qio_channel_readv_full_all_eof

and identify which pass a non-NULL parameter for 'fds'. If the caller
does NOT have a qemu_setnonblock call on the FD it gets back, then you
have to assume it is expecting it in blocking mode and so need to
add qemu_setblock


With 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: [PATCH 01/11] ppc/pnv: move root port attach to pnv_phb4_realize()

2022-06-14 Thread Cédric Le Goater

On 6/13/22 17:44, Daniel Henrique Barboza wrote:

Creating a root port is something related to the PHB, not the PEC. It
also makes the logic more in line with what pnv-phb3 does.

Signed-off-by: Daniel Henrique Barboza 


Reviewed-by: Cédric Le Goater 

So the root port is back where it was.

Could we avoid the pci_new() and use object_initialize_child() instead ?

Thanks,

C.



---
  hw/pci-host/pnv_phb4.c | 4 
  hw/pci-host/pnv_phb4_pec.c | 3 ---
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 6594016121..23ad8de7ee 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1547,6 +1547,7 @@ static void pnv_phb4_instance_init(Object *obj)
  static void pnv_phb4_realize(DeviceState *dev, Error **errp)
  {
  PnvPHB4 *phb = PNV_PHB4(dev);
+PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(phb->pec);
  PCIHostState *pci = PCI_HOST_BRIDGE(dev);
  XiveSource *xsrc = &phb->xsrc;
  int nr_irqs;
@@ -1583,6 +1584,9 @@ static void pnv_phb4_realize(DeviceState *dev, Error 
**errp)
  pci_setup_iommu(pci->bus, pnv_phb4_dma_iommu, phb);
  pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
  
+/* Add a single Root port if running with defaults */

+pnv_phb_attach_root_port(pci, pecc->rp_model);
+
  /* Setup XIVE Source */
  if (phb->big_phb) {
  nr_irqs = PNV_PHB4_MAX_INTs;
diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
index 8b7e823fa5..c9aaf1c28e 100644
--- a/hw/pci-host/pnv_phb4_pec.c
+++ b/hw/pci-host/pnv_phb4_pec.c
@@ -130,9 +130,6 @@ static void pnv_pec_default_phb_realize(PnvPhb4PecState 
*pec,
  if (!sysbus_realize(SYS_BUS_DEVICE(phb), errp)) {
  return;
  }
-
-/* Add a single Root port if running with defaults */
-pnv_phb_attach_root_port(PCI_HOST_BRIDGE(phb), pecc->rp_model);
  }
  
  static void pnv_pec_realize(DeviceState *dev, Error **errp)





Re: [PATCH 02/11] ppc/pnv: attach phb3/phb4 root ports in QOM tree

2022-06-14 Thread Cédric Le Goater

On 6/13/22 17:44, Daniel Henrique Barboza wrote:

At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:

   /unattached (container)
(...)
 /device[2] (pnv-phb3-root-port)
   /bus master container[0] (memory-region)
   /bus master[0] (memory-region)
   /pci_bridge_io[0] (memory-region)
   /pci_bridge_io[1] (memory-region)
   /pci_bridge_mem[0] (memory-region)
   /pci_bridge_pci[0] (memory-region)
   /pci_bridge_pref_mem[0] (memory-region)
   /pci_bridge_vga_io_hi[0] (memory-region)
   /pci_bridge_vga_io_lo[0] (memory-region)
   /pci_bridge_vga_mem[0] (memory-region)
   /pcie.0 (PCIE)

Let's make changes in pnv_phb_attach_root_port() to attach the created
root ports to its corresponding PHB.

This is the result afterwards:

 /pnv-phb3[0] (pnv-phb3)
   /lsi (ics)
   /msi (phb3-msi)
   /msi32[0] (memory-region)
   /msi64[0] (memory-region)
   /pbcq (pnv-pbcq)
 (...)
   /phb3_iommu[0] (pnv-phb3-iommu-memory-region)
   /pnv-phb3-root.0 (pnv-phb3-root)
 /pnv-phb3-root-port[0] (pnv-phb3-root-port)
   /bus master container[0] (memory-region)
   /bus master[0] (memory-region)
   /pci_bridge_io[0] (memory-region)
   /pci_bridge_io[1] (memory-region)
   /pci_bridge_mem[0] (memory-region)
   /pci_bridge_pci[0] (memory-region)
   /pci_bridge_pref_mem[0] (memory-region)
   /pci_bridge_vga_io_hi[0] (memory-region)
   /pci_bridge_vga_io_lo[0] (memory-region)
   /pci_bridge_vga_mem[0] (memory-region)
   /pcie.0 (PCIE)

Signed-off-by: Daniel Henrique Barboza 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  hw/pci-host/pnv_phb3.c | 2 +-
  hw/pci-host/pnv_phb4.c | 2 +-
  hw/ppc/pnv.c   | 7 ++-
  include/hw/ppc/pnv.h   | 2 +-
  4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 26ac9b7123..4ba660f8b9 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1052,7 +1052,7 @@ static void pnv_phb3_realize(DeviceState *dev, Error 
**errp)
  
  pci_setup_iommu(pci->bus, pnv_phb3_dma_iommu, phb);
  
-pnv_phb_attach_root_port(PCI_HOST_BRIDGE(phb), TYPE_PNV_PHB3_ROOT_PORT);

+pnv_phb_attach_root_port(pci, TYPE_PNV_PHB3_ROOT_PORT, phb->phb_id);
  }
  
  void pnv_phb3_update_regions(PnvPHB3 *phb)

diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 23ad8de7ee..ffd9d8a947 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1585,7 +1585,7 @@ static void pnv_phb4_realize(DeviceState *dev, Error 
**errp)
  pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
  
  /* Add a single Root port if running with defaults */

-pnv_phb_attach_root_port(pci, pecc->rp_model);
+pnv_phb_attach_root_port(pci, pecc->rp_model, phb->phb_id);
  
  /* Setup XIVE Source */

  if (phb->big_phb) {
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 7c08a78d6c..40e0cbd84d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1190,9 +1190,14 @@ static void pnv_chip_icp_realize(Pnv8Chip *chip8, Error 
**errp)
  }
  
  /* Attach a root port device */

-void pnv_phb_attach_root_port(PCIHostState *pci, const char *name)
+void pnv_phb_attach_root_port(PCIHostState *pci, const char *name, int index)
  {
  PCIDevice *root = pci_new(PCI_DEVFN(0, 0), name);
+g_autofree char *default_id = g_strdup_printf("%s[%d]", name, index);
+const char *dev_id = DEVICE(root)->id;
+
+object_property_add_child(OBJECT(pci->bus), dev_id ? dev_id : default_id,
+  OBJECT(root));
  
  pci_realize_and_unref(root, pci->bus, &error_fatal);

  }
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 86cb7d7f97..033890a23f 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -189,7 +189,7 @@ DECLARE_INSTANCE_CHECKER(PnvChip, PNV_CHIP_POWER10,
   TYPE_PNV_CHIP_POWER10)
  
  PowerPCCPU *pnv_chip_find_cpu(PnvChip *chip, uint32_t pir);

-void pnv_phb_attach_root_port(PCIHostState *pci, const char *name);
+void pnv_phb_attach_root_port(PCIHostState *pci, const char *name, int index);
  
  #define TYPE_PNV_MACHINE   MACHINE_TYPE_NAME("powernv")

  typedef struct PnvMachineClass PnvMachineClass;





Re: [PATCH 03/11] ppc/pnv: use dev->parent_bus->parent to get the PHB

2022-06-14 Thread Cédric Le Goater

On 6/13/22 17:44, Daniel Henrique Barboza wrote:

It is not advisable to execute an object_dynamic_cast() to poke into
bus->qbus.parent and follow it up with a C cast into the PnvPHB type we
think we got.

A better way is to access the PnvPHB object via a QOM macro accessing
the existing parent links of the DeviceState. For a given
pnv-phb3/4-root-port 'dev', dev->parent_bus will give us the PHB bus,
and dev->parent_bus->parent is the PHB. Use the adequate QOM macro to
assert the type, and keep the NULL check in case we didn't get the
object we were expecting.

Signed-off-by: Daniel Henrique Barboza 
---
  hw/pci-host/pnv_phb3.c | 10 +++---
  hw/pci-host/pnv_phb4.c | 10 +++---
  2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 4ba660f8b9..7901d8172c 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -1139,12 +1139,16 @@ static void pnv_phb3_root_port_realize(DeviceState 
*dev, Error **errp)
  {
  PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
  PCIDevice *pci = PCI_DEVICE(dev);
-PCIBus *bus = pci_get_bus(pci);
  PnvPHB3 *phb = NULL;
  Error *local_err = NULL;
  
-phb = (PnvPHB3 *) object_dynamic_cast(OBJECT(bus->qbus.parent),

-  TYPE_PNV_PHB3);
+/*
+ * dev->parent_bus gives access to the pnv-phb-root bus.
+ * The PnvPHB3 is the owner (parent) of the bus.
+ */
+if (dev && dev->parent_bus) {
+phb = PNV_PHB3(dev->parent_bus->parent);
+}



Couldn't we simply use :

  phb = PNV_PHB3(bus);

?

Thanks,

C.


  if (!phb) {
  error_setg(errp,
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index ffd9d8a947..bae9398d86 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1782,12 +1782,16 @@ static void pnv_phb4_root_port_realize(DeviceState 
*dev, Error **errp)
  {
  PCIERootPortClass *rpc = PCIE_ROOT_PORT_GET_CLASS(dev);
  PCIDevice *pci = PCI_DEVICE(dev);
-PCIBus *bus = pci_get_bus(pci);
  PnvPHB4 *phb = NULL;
  Error *local_err = NULL;
  
-phb = (PnvPHB4 *) object_dynamic_cast(OBJECT(bus->qbus.parent),

-  TYPE_PNV_PHB4);
+/*
+ * dev->parent_bus gives access to the pnv-phb-root bus.
+ * The PnvPHB4 is the owner (parent) of the bus.
+ */
+if (dev && dev->parent_bus) {
+phb = PNV_PHB4(dev->parent_bus->parent);
+}
  
  if (!phb) {

  error_setg(errp, "%s must be connected to pnv-phb4 buses", dev->id);





Re: [PATCH] hw/mem/nvdimm: fix error message for 'unarmed' flag

2022-06-14 Thread Julia Suvorova
On Tue, Jun 14, 2022 at 11:50 AM David Hildenbrand  wrote:
>
> On 14.06.22 10:54, Igor Mammedov wrote:
> > On Mon, 13 Jun 2022 16:09:53 +0100
> > Stefan Hajnoczi  wrote:
> >
> >> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> >>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi  
> >>> wrote:
> 
>  On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > cannot accept a persistent write. This means that when a memdev is
> > read-only, the 'unarmed' flag must be turned on. The logic is correct,
> > just changing the error message.
> >
> > [1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM State Flags" Bit 3
> >
> > Signed-off-by: Julia Suvorova 
> > ---
> >  hw/mem/nvdimm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  Reviewed-by: Stefan Hajnoczi 
> >>>
> >>> It seems like Xiao is not active, whose tree should this patch go to?
>
> Is that a temporary or a permanent thing? Do we know?

No idea. But his last signed-off was three years ago.

> >
> > Perhaps David can add himself as maintainer (i.e. put it
> > under memory mantanership umbrella) and merge it
>
> Maybe it makes sense to combine NVDIMM with pc-dimm.c and
> memory-device.c into a "MEMORY DEVICE" section. Then, remove "hw/mem/*"
> from "ACPI/SMBIOS".
>
> cxl_type3.c, npcm7xx_mc.c and sparse-mem.c in /hw/mem/ are a bit
> different. We could add cxl_type3.c to "Compute Express Link".
> npcm7xx_mc.c and sparse-mem.c should be already covered.
>
> --
> Thanks,
>
> David / dhildenb
>




Re: [PULL 00/16] Kraxel 20220613 patches

2022-06-14 Thread Gerd Hoffmann
> > Hmm, build worked here and CI passed too.
> > 
> > I think this is one of those cases where the build directory must be
> > deleted because one subdirectory is replaced by a compatibility
> > symlink.
> 
> Except 'configure' deals with that, as it explicitly rm -rf's the
> symlink target:
> 
> symlink() {
>   rm -rf "$2"
>   mkdir -p "$(dirname "$2")"
>   ln -s "$1" "$2"
> }
> 
> so i'm pretty confused as to what's going wrong here still

'git rebase -x ./make.sh master queue/kraxel' not working (where make.sh
is a script effectively doing 'make -C build/$name' for multiple build
trees with different configurations).

'git status' lists ui/keymaps/* as deleted.
'git reset --hard' fixes it.

take care,
  Gerd




[PULL 01/15] ui/gtk-gl-area: implement GL context destruction

2022-06-14 Thread Gerd Hoffmann
From: Volker Rümelin 

The counterpart function for gd_gl_area_create_context() is
currently empty. Implement the gd_gl_area_destroy_context()
function to avoid GL context leaks.

Signed-off-by: Volker Rümelin 
Message-Id: <20220605085131.7711-1-vr_q...@t-online.de>
Signed-off-by: Gerd Hoffmann 
---
 ui/gtk-gl-area.c | 8 +++-
 ui/trace-events  | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c
index fc5a082eb846..0e20ea031d34 100644
--- a/ui/gtk-gl-area.c
+++ b/ui/gtk-gl-area.c
@@ -201,7 +201,13 @@ QEMUGLContext gd_gl_area_create_context(DisplayGLCtx *dgc,
 
 void gd_gl_area_destroy_context(DisplayGLCtx *dgc, QEMUGLContext ctx)
 {
-/* FIXME */
+GdkGLContext *current_ctx = gdk_gl_context_get_current();
+
+trace_gd_gl_area_destroy_context(ctx, current_ctx);
+if (ctx == current_ctx) {
+gdk_gl_context_clear_current();
+}
+g_clear_object(&ctx);
 }
 
 void gd_gl_area_scanout_texture(DisplayChangeListener *dcl,
diff --git a/ui/trace-events b/ui/trace-events
index f78b5e66061f..1040ba0f88c7 100644
--- a/ui/trace-events
+++ b/ui/trace-events
@@ -26,6 +26,7 @@ gd_key_event(const char *tab, int gdk_keycode, int qkeycode, 
const char *action)
 gd_grab(const char *tab, const char *device, const char *reason) "tab=%s, 
dev=%s, reason=%s"
 gd_ungrab(const char *tab, const char *device) "tab=%s, dev=%s"
 gd_keymap_windowing(const char *name) "backend=%s"
+gd_gl_area_destroy_context(void *ctx, void *current_ctx) "ctx=%p, 
current_ctx=%p"
 
 # vnc-auth-sasl.c
 # vnc-auth-vencrypt.c
-- 
2.36.1




[PULL 03/15] ui/cocoa: Fix poweroff request code

2022-06-14 Thread Gerd Hoffmann
From: Akihiko Odaki 

Signed-off-by: Akihiko Odaki 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20220529082508.89097-1-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann 
---
 ui/cocoa.m | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 09a62817f2a9..84c84e98fc5e 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -35,6 +35,7 @@
 #include "ui/kbd-state.h"
 #include "sysemu/sysemu.h"
 #include "sysemu/runstate.h"
+#include "sysemu/runstate-action.h"
 #include "sysemu/cpu-throttle.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-block.h"
@@ -1290,7 +1291,10 @@ - (void)applicationWillTerminate:(NSNotification 
*)aNotification
 {
 COCOA_DEBUG("QemuCocoaAppController: applicationWillTerminate\n");
 
-qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_UI);
+with_iothread_lock(^{
+shutdown_action = SHUTDOWN_ACTION_POWEROFF;
+qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_UI);
+});
 
 /*
  * Sleep here, because returning will cause OSX to kill us
-- 
2.36.1




[PULL 00/15] Kraxel 20220614 patches

2022-06-14 Thread Gerd Hoffmann
The following changes since commit debd0753663bc89c86f5462a53268f2e3f680f60:

  Merge tag 'pull-testing-next-140622-1' of https://github.com/stsquad/qemu 
into staging (2022-06-13 21:10:57 -0700)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/kraxel-20220614-pull-request

for you to fetch changes up to b95b56311a0890da0c9f7fc624529c3d7f8dbce0:

  virtio-gpu: Respect UI refresh rate for EDID (2022-06-14 10:34:37 +0200)


usb: add CanoKey device, fixes for ehci + redir
ui: fixes for gtk and cocoa, rework refresh rate
virtio-gpu: scanout flush fix



Akihiko Odaki (4):
  ui/cocoa: Fix poweroff request code
  ui/console: Do not return a value with ui_info
  ui: Deliver refresh rate via QemuUIInfo
  virtio-gpu: Respect UI refresh rate for EDID

Arnout Engelen (1):
  hw/usb/hcd-ehci: fix writeback order

Dongwon Kim (1):
  virtio-gpu: update done only on the scanout associated with rect

Hongren (Zenithal) Zheng (6):
  hw/usb: Add CanoKey Implementation
  hw/usb/canokey: Add trace events
  meson: Add CanoKey
  docs: Add CanoKey documentation
  docs/system/devices/usb: Add CanoKey to USB devices examples
  MAINTAINERS: add myself as CanoKey maintainer

Joelle van Dyne (1):
  usbredir: avoid queuing hello packet on snapshot restore

Volker Rümelin (2):
  ui/gtk-gl-area: implement GL context destruction
  ui/gtk-gl-area: create the requested GL context version

 meson_options.txt|   2 +
 hw/usb/canokey.h |  69 +++
 include/hw/virtio/virtio-gpu.h   |   1 +
 include/ui/console.h |   4 +-
 include/ui/gtk.h |   2 +-
 hw/display/virtio-gpu-base.c |   7 +-
 hw/display/virtio-gpu.c  |   4 +
 hw/display/virtio-vga.c  |   5 +-
 hw/display/xenfb.c   |  14 +-
 hw/usb/canokey.c | 313 +++
 hw/usb/hcd-ehci.c|   5 +-
 hw/usb/redirect.c|   3 +-
 hw/vfio/display.c|   8 +-
 ui/console.c |   6 -
 ui/gtk-egl.c |   4 +-
 ui/gtk-gl-area.c |  42 -
 ui/gtk.c |  45 +++--
 MAINTAINERS  |   8 +
 docs/system/device-emulation.rst |   1 +
 docs/system/devices/canokey.rst  | 168 +
 docs/system/devices/usb.rst  |   4 +
 hw/usb/Kconfig   |   5 +
 hw/usb/meson.build   |   5 +
 hw/usb/trace-events  |  16 ++
 meson.build  |   6 +
 scripts/meson-buildoptions.sh|   3 +
 ui/cocoa.m   |   6 +-
 ui/trace-events  |   2 +
 28 files changed, 707 insertions(+), 51 deletions(-)
 create mode 100644 hw/usb/canokey.h
 create mode 100644 hw/usb/canokey.c
 create mode 100644 docs/system/devices/canokey.rst

-- 
2.36.1




[PULL 07/15] docs: Add CanoKey documentation

2022-06-14 Thread Gerd Hoffmann
From: "Hongren (Zenithal) Zheng" 

Signed-off-by: Hongren (Zenithal) Zheng 
Message-Id: 
Signed-off-by: Gerd Hoffmann 
---
 docs/system/device-emulation.rst |   1 +
 docs/system/devices/canokey.rst  | 168 +++
 2 files changed, 169 insertions(+)
 create mode 100644 docs/system/devices/canokey.rst

diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
index 3b729b920d7c..05060060563f 100644
--- a/docs/system/device-emulation.rst
+++ b/docs/system/device-emulation.rst
@@ -92,3 +92,4 @@ Emulated Devices
devices/vhost-user.rst
devices/virtio-pmem.rst
devices/vhost-user-rng.rst
+   devices/canokey.rst
diff --git a/docs/system/devices/canokey.rst b/docs/system/devices/canokey.rst
new file mode 100644
index ..169f99b8eb82
--- /dev/null
+++ b/docs/system/devices/canokey.rst
@@ -0,0 +1,168 @@
+.. _canokey:
+
+CanoKey QEMU
+
+
+CanoKey [1]_ is an open-source secure key with supports of
+
+* U2F / FIDO2 with Ed25519 and HMAC-secret
+* OpenPGP Card V3.4 with RSA4096, Ed25519 and more [2]_
+* PIV (NIST SP 800-73-4)
+* HOTP / TOTP
+* NDEF
+
+All these platform-independent features are in canokey-core [3]_.
+
+For different platforms, CanoKey has different implementations,
+including both hardware implementions and virtual cards:
+
+* CanoKey STM32 [4]_
+* CanoKey Pigeon [5]_
+* (virt-card) CanoKey USB/IP
+* (virt-card) CanoKey FunctionFS
+
+In QEMU, yet another CanoKey virt-card is implemented.
+CanoKey QEMU exposes itself as a USB device to the guest OS.
+
+With the same software configuration as a hardware key,
+the guest OS can use all the functionalities of a secure key as if
+there was actually an hardware key plugged in.
+
+CanoKey QEMU provides much convenience for debuging:
+
+* libcanokey-qemu supports debuging output thus developers can
+  inspect what happens inside a secure key
+* CanoKey QEMU supports trace event thus event
+* QEMU USB stack supports pcap thus USB packet between the guest
+  and key can be captured and analysed
+
+Then for developers:
+
+* For developers on software with secure key support (e.g. FIDO2, OpenPGP),
+  they can see what happens inside the secure key
+* For secure key developers, USB packets between guest OS and CanoKey
+  can be easily captured and analysed
+
+Also since this is a virtual card, it can be easily used in CI for testing
+on code coping with secure key.
+
+Building
+
+
+libcanokey-qemu is required to use CanoKey QEMU.
+
+.. code-block:: shell
+
+git clone https://github.com/canokeys/canokey-qemu
+mkdir canokey-qemu/build
+pushd canokey-qemu/build
+
+If you want to install libcanokey-qemu in a different place,
+add ``-DCMAKE_INSTALL_PREFIX=/path/to/your/place`` to cmake below.
+
+.. code-block:: shell
+
+cmake ..
+make
+make install # may need sudo
+popd
+
+Then configuring and building:
+
+.. code-block:: shell
+
+# depending on your env, lib/pkgconfig can be lib64/pkgconfig
+export PKG_CONFIG_PATH=/path/to/your/place/lib/pkgconfig:$PKG_CONFIG_PATH
+./configure --enable-canokey && make
+
+Using CanoKey QEMU
+==
+
+CanoKey QEMU stores all its data on a file of the host specified by the 
argument
+when invoking qemu.
+
+.. parsed-literal::
+
+|qemu_system| -usb -device canokey,file=$HOME/.canokey-file
+
+Note: you should keep this file carefully as it may contain your private key!
+
+The first time when the file is used, it is created and initialized by CanoKey,
+afterwards CanoKey QEMU would just read this file.
+
+After the guest OS boots, you can check that there is a USB device.
+
+For example, If the guest OS is an Linux machine. You may invoke lsusb
+and find CanoKey QEMU there:
+
+.. code-block:: shell
+
+$ lsusb
+Bus 001 Device 002: ID 20a0:42d4 Clay Logic CanoKey QEMU
+
+You may setup the key as guided in [6]_. The console for the key is at [7]_.
+
+Debuging
+
+
+CanoKey QEMU consists of two parts, ``libcanokey-qemu.so`` and ``canokey.c``,
+the latter of which resides in QEMU. The former provides core functionality
+of a secure key while the latter provides platform-dependent functions:
+USB packet handling.
+
+If you want to trace what happens inside the secure key, when compiling
+libcanokey-qemu, you should add ``-DQEMU_DEBUG_OUTPUT=ON`` in cmake command
+line:
+
+.. code-block:: shell
+
+cmake .. -DQEMU_DEBUG_OUTPUT=ON
+
+If you want to trace events happened in canokey.c, use
+
+.. parsed-literal::
+
+|qemu_system| --trace "canokey_*" \\
+-usb -device canokey,file=$HOME/.canokey-file
+
+If you want to capture USB packets between the guest and the host, you can:
+
+.. parsed-literal::
+
+|qemu_system| -usb -device canokey,file=$HOME/.canokey-file,pcap=key.pcap
+
+Limitations
+===
+
+Currently libcanokey-qemu.so has dozens of global variables as it was 
originally
+designed for embedded systems. Thus one qemu instance can not have
+multiple CanoKey QEMU runn

[PULL 09/15] MAINTAINERS: add myself as CanoKey maintainer

2022-06-14 Thread Gerd Hoffmann
From: "Hongren (Zenithal) Zheng" 

Signed-off-by: Hongren (Zenithal) Zheng 
Message-Id: 
Signed-off-by: Gerd Hoffmann 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0df25ed4b0a3..4cf6174f9f37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2427,6 +2427,14 @@ F: hw/intc/s390_flic*.c
 F: include/hw/s390x/s390_flic.h
 L: qemu-s3...@nongnu.org
 
+CanoKey
+M: Hongren (Zenithal) Zheng 
+S: Maintained
+R: Canokeys.org 
+F: hw/usb/canokey.c
+F: hw/usb/canokey.h
+F: docs/system/devices/canokey.rst
+
 Subsystems
 --
 Overall Audio backends
-- 
2.36.1




[PULL 10/15] hw/usb/hcd-ehci: fix writeback order

2022-06-14 Thread Gerd Hoffmann
From: Arnout Engelen 

The 'active' bit passes control over a qTD between the guest and the
controller: set to 1 by guest to enable execution by the controller,
and the controller sets it to '0' to hand back control to the guest.

ehci_state_writeback write two dwords to main memory using DMA:
the third dword of the qTD (containing dt, total bytes to transfer,
cpage, cerr and status) and the fourth dword of the qTD (containing
the offset).

This commit makes sure the fourth dword is written before the third,
avoiding a race condition where a new offset written into the qTD
by the guest after it observed the status going to go to '0' gets
overwritten by a 'late' DMA writeback of the previous offset.

This race condition could lead to 'cpage out of range (5)' errors,
and reproduced by:

./qemu-system-x86_64 -enable-kvm -bios $SEABIOS/bios.bin -m 4096 -device 
usb-ehci -blockdev 
driver=file,read-only=on,filename=/home/aengelen/Downloads/openSUSE-Tumbleweed-DVD-i586-Snapshot20220428-Media.iso,node-name=iso
 -device usb-storage,drive=iso,bootindex=0 -chardev 
pipe,id=shell,path=/tmp/pipe -device virtio-serial -device 
virtconsole,chardev=shell -device virtio-rng-pci -serial mon:stdio -nographic

(press a key, select 'Installation' (2), and accept the default
values. On my machine the 'cpage out of range' is reproduced while
loading the Linux Kernel about once per 7 attempts. With the fix in
this commit it no longer fails)

This problem was previously reported as a seabios problem in
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/OUTHT5ISSQJGXPNTUPY3O5E5EPZJCHM3/
and as a nixos CI build failure in
https://github.com/NixOS/nixpkgs/issues/170803

Signed-off-by: Arnout Engelen 
Signed-off-by: Gerd Hoffmann 
---
 hw/usb/hcd-ehci.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 33a8a377bd95..d4da8dcb8d15 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -2011,7 +2011,10 @@ static int ehci_state_writeback(EHCIQueue *q)
 ehci_trace_qtd(q, NLPTR_GET(p->qtdaddr), (EHCIqtd *) &q->qh.next_qtd);
 qtd = (uint32_t *) &q->qh.next_qtd;
 addr = NLPTR_GET(p->qtdaddr);
-put_dwords(q->ehci, addr + 2 * sizeof(uint32_t), qtd + 2, 2);
+/* First write back the offset */
+put_dwords(q->ehci, addr + 3 * sizeof(uint32_t), qtd + 3, 1);
+/* Then write back the token, clearing the 'active' bit */
+put_dwords(q->ehci, addr + 2 * sizeof(uint32_t), qtd + 2, 1);
 ehci_free_packet(p);
 
 /*
-- 
2.36.1




[PULL 04/15] hw/usb: Add CanoKey Implementation

2022-06-14 Thread Gerd Hoffmann
From: "Hongren (Zenithal) Zheng" 

This commit added a new emulated device called CanoKey to QEMU.

CanoKey implements platform independent features in canokey-core
https://github.com/canokeys/canokey-core, and leaves the USB implementation
to the platform.

In this commit the USB part was implemented in QEMU using QEMU's USB APIs,
therefore the emulated CanoKey can communicate with the guest OS using USB.

Signed-off-by: Hongren (Zenithal) Zheng 
Message-Id: 
Signed-off-by: Gerd Hoffmann 
---
 hw/usb/canokey.h |  69 +++
 hw/usb/canokey.c | 300 +++
 2 files changed, 369 insertions(+)
 create mode 100644 hw/usb/canokey.h
 create mode 100644 hw/usb/canokey.c

diff --git a/hw/usb/canokey.h b/hw/usb/canokey.h
new file mode 100644
index ..24cf30420346
--- /dev/null
+++ b/hw/usb/canokey.h
@@ -0,0 +1,69 @@
+/*
+ * CanoKey QEMU device header.
+ *
+ * Copyright (c) 2021-2022 Canokeys.org 
+ * Written by Hongren (Zenithal) Zheng 
+ *
+ * This code is licensed under the Apache-2.0.
+ */
+
+#ifndef CANOKEY_H
+#define CANOKEY_H
+
+#include "hw/qdev-core.h"
+
+#define TYPE_CANOKEY "canokey"
+#define CANOKEY(obj) \
+OBJECT_CHECK(CanoKeyState, (obj), TYPE_CANOKEY)
+
+/*
+ * State of Canokey (i.e. hw/canokey.c)
+ */
+
+/* CTRL INTR BULK */
+#define CANOKEY_EP_NUM 3
+/* BULK/INTR IN can be up to 1352 bytes, e.g. get key info */
+#define CANOKEY_EP_IN_BUFFER_SIZE 2048
+/* BULK OUT can be up to 270 bytes, e.g. PIV import cert */
+#define CANOKEY_EP_OUT_BUFFER_SIZE 512
+
+typedef enum {
+CANOKEY_EP_IN_WAIT,
+CANOKEY_EP_IN_READY,
+CANOKEY_EP_IN_STALL
+} CanoKeyEPState;
+
+typedef struct CanoKeyState {
+USBDevice dev;
+
+/* IN packets from canokey device loop */
+uint8_t ep_in[CANOKEY_EP_NUM][CANOKEY_EP_IN_BUFFER_SIZE];
+/*
+ * See canokey_emu_transmit
+ *
+ * For large INTR IN, receive multiple data from canokey device loop
+ * in this case ep_in_size would increase with every call
+ */
+uint32_t ep_in_size[CANOKEY_EP_NUM];
+/*
+ * Used in canokey_handle_data
+ * for IN larger than p->iov.size, we would do multiple handle_data()
+ *
+ * The difference between ep_in_pos and ep_in_size:
+ * We first increase ep_in_size to fill ep_in buffer in device_loop,
+ * then use ep_in_pos to submit data from ep_in buffer in handle_data
+ */
+uint32_t ep_in_pos[CANOKEY_EP_NUM];
+CanoKeyEPState ep_in_state[CANOKEY_EP_NUM];
+
+/* OUT pointer to canokey recv buffer */
+uint8_t *ep_out[CANOKEY_EP_NUM];
+uint32_t ep_out_size[CANOKEY_EP_NUM];
+/* For large BULK OUT, multiple write to ep_out is needed */
+uint8_t ep_out_buffer[CANOKEY_EP_NUM][CANOKEY_EP_OUT_BUFFER_SIZE];
+
+/* Properties */
+char *file; /* canokey-file */
+} CanoKeyState;
+
+#endif /* CANOKEY_H */
diff --git a/hw/usb/canokey.c b/hw/usb/canokey.c
new file mode 100644
index ..6cb8b7cdb089
--- /dev/null
+++ b/hw/usb/canokey.c
@@ -0,0 +1,300 @@
+/*
+ * CanoKey QEMU device implementation.
+ *
+ * Copyright (c) 2021-2022 Canokeys.org 
+ * Written by Hongren (Zenithal) Zheng 
+ *
+ * This code is licensed under the Apache-2.0.
+ */
+
+#include "qemu/osdep.h"
+#include 
+
+#include "qemu/module.h"
+#include "qapi/error.h"
+#include "hw/usb.h"
+#include "hw/qdev-properties.h"
+#include "desc.h"
+#include "canokey.h"
+
+#define CANOKEY_EP_IN(ep) ((ep) & 0x7F)
+
+#define CANOKEY_VENDOR_NUM 0x20a0
+#define CANOKEY_PRODUCT_NUM0x42d2
+
+/*
+ * placeholder, canokey-qemu implements its own usb desc
+ * Namely we do not use usb_desc_handle_contorl
+ */
+enum {
+STR_MANUFACTURER = 1,
+STR_PRODUCT,
+STR_SERIALNUMBER
+};
+
+static const USBDescStrings desc_strings = {
+[STR_MANUFACTURER] = "canokeys.org",
+[STR_PRODUCT]  = "CanoKey QEMU",
+[STR_SERIALNUMBER] = "0"
+};
+
+static const USBDescDevice desc_device_canokey = {
+.bcdUSB= 0x0,
+.bMaxPacketSize0   = 16,
+.bNumConfigurations= 0,
+.confs = NULL,
+};
+
+static const USBDesc desc_canokey = {
+.id = {
+.idVendor  = CANOKEY_VENDOR_NUM,
+.idProduct = CANOKEY_PRODUCT_NUM,
+.bcdDevice = 0x0100,
+.iManufacturer = STR_MANUFACTURER,
+.iProduct  = STR_PRODUCT,
+.iSerialNumber = STR_SERIALNUMBER,
+},
+.full = &desc_device_canokey,
+.high = &desc_device_canokey,
+.str  = desc_strings,
+};
+
+
+/*
+ * libcanokey-qemu.so side functions
+ * All functions are called from canokey_emu_device_loop
+ */
+int canokey_emu_stall_ep(void *base, uint8_t ep)
+{
+CanoKeyState *key = base;
+uint8_t ep_in = CANOKEY_EP_IN(ep); /* INTR IN has ep 129 */
+key->ep_in_size[ep_in] = 0;
+key->ep_in_state[ep_in] = CANOKEY_EP_IN_STALL;
+return 0;
+}
+
+int canokey_emu_set_address(void *base, uint8_t addr)
+{
+CanoKeyState *key = base;
+key->dev.

[PULL 15/15] virtio-gpu: Respect UI refresh rate for EDID

2022-06-14 Thread Gerd Hoffmann
From: Akihiko Odaki 

Signed-off-by: Akihiko Odaki 
Message-Id: <20220226115516.59830-4-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann 
---
 include/hw/virtio/virtio-gpu.h | 1 +
 hw/display/virtio-gpu-base.c   | 1 +
 hw/display/virtio-gpu.c| 1 +
 3 files changed, 3 insertions(+)

diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index afff9e158e31..2e28507efe21 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -80,6 +80,7 @@ struct virtio_gpu_scanout {
 struct virtio_gpu_requested_state {
 uint16_t width_mm, height_mm;
 uint32_t width, height;
+uint32_t refresh_rate;
 int x, y;
 };
 
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index b21d6e5b0be8..a29f191aa82e 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -79,6 +79,7 @@ static void virtio_gpu_ui_info(void *opaque, uint32_t idx, 
QemuUIInfo *info)
 
 g->req_state[idx].x = info->xoff;
 g->req_state[idx].y = info->yoff;
+g->req_state[idx].refresh_rate = info->refresh_rate;
 g->req_state[idx].width = info->width;
 g->req_state[idx].height = info->height;
 g->req_state[idx].width_mm = info->width_mm;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 55c6dd576318..20cc703dcc6e 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -217,6 +217,7 @@ virtio_gpu_generate_edid(VirtIOGPU *g, int scanout,
 .height_mm = b->req_state[scanout].height_mm,
 .prefx = b->req_state[scanout].width,
 .prefy = b->req_state[scanout].height,
+.refresh_rate = b->req_state[scanout].refresh_rate,
 };
 
 edid->size = cpu_to_le32(sizeof(edid->edid));
-- 
2.36.1




[PULL 06/15] meson: Add CanoKey

2022-06-14 Thread Gerd Hoffmann
From: "Hongren (Zenithal) Zheng" 

Signed-off-by: Hongren (Zenithal) Zheng 
Message-Id: 
Signed-off-by: Gerd Hoffmann 
---
 meson_options.txt | 2 ++
 hw/usb/Kconfig| 5 +
 hw/usb/meson.build| 5 +
 meson.build   | 6 ++
 scripts/meson-buildoptions.sh | 3 +++
 5 files changed, 21 insertions(+)

diff --git a/meson_options.txt b/meson_options.txt
index 2de94af03712..0e8197386b99 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -189,6 +189,8 @@ option('spice_protocol', type : 'feature', value : 'auto',
description: 'Spice protocol support')
 option('u2f', type : 'feature', value : 'auto',
description: 'U2F emulation support')
+option('canokey', type : 'feature', value : 'auto',
+   description: 'CanoKey support')
 option('usb_redir', type : 'feature', value : 'auto',
description: 'libusbredir support')
 option('l2tpv3', type : 'feature', value : 'auto',
diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig
index 53f8283ffdc1..ce4f4339763e 100644
--- a/hw/usb/Kconfig
+++ b/hw/usb/Kconfig
@@ -119,6 +119,11 @@ config USB_U2F
 default y
 depends on USB
 
+config USB_CANOKEY
+bool
+default y
+depends on USB
+
 config IMX_USBPHY
 bool
 default y
diff --git a/hw/usb/meson.build b/hw/usb/meson.build
index de853d780dd8..793df42e2127 100644
--- a/hw/usb/meson.build
+++ b/hw/usb/meson.build
@@ -63,6 +63,11 @@ if u2f.found()
   softmmu_ss.add(when: 'CONFIG_USB_U2F', if_true: [u2f, 
files('u2f-emulated.c')])
 endif
 
+# CanoKey
+if canokey.found()
+  softmmu_ss.add(when: 'CONFIG_USB_CANOKEY', if_true: [canokey, 
files('canokey.c')])
+endif
+
 # usb redirect
 if usbredir.found()
   usbredir_ss = ss.source_set()
diff --git a/meson.build b/meson.build
index 21cd949082dc..0c2e11ff0715 100644
--- a/meson.build
+++ b/meson.build
@@ -1408,6 +1408,12 @@ if have_system
method: 'pkg-config',
kwargs: static_kwargs)
 endif
+canokey = not_found
+if have_system
+  canokey = dependency('canokey-qemu', required: get_option('canokey'),
+   method: 'pkg-config',
+   kwargs: static_kwargs)
+endif
 usbredir = not_found
 if not get_option('usb_redir').auto() or have_system
   usbredir = dependency('libusbredirparser-0.5', required: 
get_option('usb_redir'),
diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
index 00ea4d8cd169..1fc1d2e2c362 100644
--- a/scripts/meson-buildoptions.sh
+++ b/scripts/meson-buildoptions.sh
@@ -73,6 +73,7 @@ meson_options_help() {
   printf "%s\n" '  bpf eBPF support'
   printf "%s\n" '  brlapi  brlapi character device driver'
   printf "%s\n" '  bzip2   bzip2 support for DMG images'
+  printf "%s\n" '  canokey CanoKey support'
   printf "%s\n" '  cap-ng  cap_ng support'
   printf "%s\n" '  capstoneWhether and how to find the capstone 
library'
   printf "%s\n" '  cloop   cloop image format support'
@@ -204,6 +205,8 @@ _meson_option_parse() {
 --disable-brlapi) printf "%s" -Dbrlapi=disabled ;;
 --enable-bzip2) printf "%s" -Dbzip2=enabled ;;
 --disable-bzip2) printf "%s" -Dbzip2=disabled ;;
+--enable-canokey) printf "%s" -Dcanokey=enabled ;;
+--disable-canokey) printf "%s" -Dcanokey=disabled ;;
 --enable-cap-ng) printf "%s" -Dcap_ng=enabled ;;
 --disable-cap-ng) printf "%s" -Dcap_ng=disabled ;;
 --enable-capstone) printf "%s" -Dcapstone=enabled ;;
-- 
2.36.1




[PULL 13/15] ui/console: Do not return a value with ui_info

2022-06-14 Thread Gerd Hoffmann
From: Akihiko Odaki 

The returned value is not used and misleading.

Signed-off-by: Akihiko Odaki 
Message-Id: <20220226115516.59830-2-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann 
---
 include/ui/console.h | 2 +-
 hw/display/virtio-gpu-base.c | 6 +++---
 hw/display/virtio-vga.c  | 5 ++---
 hw/vfio/display.c| 8 +++-
 4 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index c44b28a972ca..642d6f5248cf 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -432,7 +432,7 @@ typedef struct GraphicHwOps {
 bool gfx_update_async; /* if true, calls graphic_hw_update_done() */
 void (*text_update)(void *opaque, console_ch_t *text);
 void (*update_interval)(void *opaque, uint64_t interval);
-int (*ui_info)(void *opaque, uint32_t head, QemuUIInfo *info);
+void (*ui_info)(void *opaque, uint32_t head, QemuUIInfo *info);
 void (*gl_block)(void *opaque, bool block);
 } GraphicHwOps;
 
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 790cec333c8c..b21d6e5b0be8 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -69,12 +69,12 @@ static void virtio_gpu_notify_event(VirtIOGPUBase *g, 
uint32_t event_type)
 virtio_notify_config(&g->parent_obj);
 }
 
-static int virtio_gpu_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
+static void virtio_gpu_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
 {
 VirtIOGPUBase *g = opaque;
 
 if (idx >= g->conf.max_outputs) {
-return -1;
+return;
 }
 
 g->req_state[idx].x = info->xoff;
@@ -92,7 +92,7 @@ static int virtio_gpu_ui_info(void *opaque, uint32_t idx, 
QemuUIInfo *info)
 
 /* send event to guest */
 virtio_gpu_notify_event(g, VIRTIO_GPU_EVENT_DISPLAY);
-return 0;
+return;
 }
 
 static void
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index c206b5da384b..4dcb34c4a740 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -47,15 +47,14 @@ static void virtio_vga_base_text_update(void *opaque, 
console_ch_t *chardata)
 }
 }
 
-static int virtio_vga_base_ui_info(void *opaque, uint32_t idx, QemuUIInfo 
*info)
+static void virtio_vga_base_ui_info(void *opaque, uint32_t idx, QemuUIInfo 
*info)
 {
 VirtIOVGABase *vvga = opaque;
 VirtIOGPUBase *g = vvga->vgpu;
 
 if (g->hw_ops->ui_info) {
-return g->hw_ops->ui_info(g, idx, info);
+g->hw_ops->ui_info(g, idx, info);
 }
-return -1;
 }
 
 static void virtio_vga_base_gl_block(void *opaque, bool block)
diff --git a/hw/vfio/display.c b/hw/vfio/display.c
index 89bc90508fb8..78f4d82c1c35 100644
--- a/hw/vfio/display.c
+++ b/hw/vfio/display.c
@@ -106,14 +106,14 @@ err:
 return;
 }
 
-static int vfio_display_edid_ui_info(void *opaque, uint32_t idx,
- QemuUIInfo *info)
+static void vfio_display_edid_ui_info(void *opaque, uint32_t idx,
+  QemuUIInfo *info)
 {
 VFIOPCIDevice *vdev = opaque;
 VFIODisplay *dpy = vdev->dpy;
 
 if (!dpy->edid_regs) {
-return 0;
+return;
 }
 
 if (info->width && info->height) {
@@ -121,8 +121,6 @@ static int vfio_display_edid_ui_info(void *opaque, uint32_t 
idx,
 } else {
 vfio_display_edid_update(vdev, false, 0, 0);
 }
-
-return 0;
 }
 
 static void vfio_display_edid_init(VFIOPCIDevice *vdev)
-- 
2.36.1




[PULL 08/15] docs/system/devices/usb: Add CanoKey to USB devices examples

2022-06-14 Thread Gerd Hoffmann
From: "Hongren (Zenithal) Zheng" 

Signed-off-by: Hongren (Zenithal) Zheng 
Message-Id: 
Signed-off-by: Gerd Hoffmann 
---
 docs/system/devices/usb.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/docs/system/devices/usb.rst b/docs/system/devices/usb.rst
index afb7d6c2268d..872d9167589b 100644
--- a/docs/system/devices/usb.rst
+++ b/docs/system/devices/usb.rst
@@ -199,6 +199,10 @@ option or the ``device_add`` monitor command. Available 
devices are:
 ``u2f-{emulated,passthru}``
Universal Second Factor device
 
+``canokey``
+   An Open-source Secure Key implementing FIDO2, OpenPGP, PIV and more.
+   For more information, see :ref:`canokey`.
+
 Physical port addressing
 
 
-- 
2.36.1




[PULL 05/15] hw/usb/canokey: Add trace events

2022-06-14 Thread Gerd Hoffmann
From: "Hongren (Zenithal) Zheng" 

Signed-off-by: Hongren (Zenithal) Zheng 
Message-Id: 
Signed-off-by: Gerd Hoffmann 
---
 hw/usb/canokey.c| 13 +
 hw/usb/trace-events | 16 
 2 files changed, 29 insertions(+)

diff --git a/hw/usb/canokey.c b/hw/usb/canokey.c
index 6cb8b7cdb089..4a08b1cbd776 100644
--- a/hw/usb/canokey.c
+++ b/hw/usb/canokey.c
@@ -14,6 +14,7 @@
 #include "qapi/error.h"
 #include "hw/usb.h"
 #include "hw/qdev-properties.h"
+#include "trace.h"
 #include "desc.h"
 #include "canokey.h"
 
@@ -66,6 +67,7 @@ static const USBDesc desc_canokey = {
  */
 int canokey_emu_stall_ep(void *base, uint8_t ep)
 {
+trace_canokey_emu_stall_ep(ep);
 CanoKeyState *key = base;
 uint8_t ep_in = CANOKEY_EP_IN(ep); /* INTR IN has ep 129 */
 key->ep_in_size[ep_in] = 0;
@@ -75,6 +77,7 @@ int canokey_emu_stall_ep(void *base, uint8_t ep)
 
 int canokey_emu_set_address(void *base, uint8_t addr)
 {
+trace_canokey_emu_set_address(addr);
 CanoKeyState *key = base;
 key->dev.addr = addr;
 return 0;
@@ -83,6 +86,7 @@ int canokey_emu_set_address(void *base, uint8_t addr)
 int canokey_emu_prepare_receive(
 void *base, uint8_t ep, uint8_t *pbuf, uint16_t size)
 {
+trace_canokey_emu_prepare_receive(ep, size);
 CanoKeyState *key = base;
 key->ep_out[ep] = pbuf;
 key->ep_out_size[ep] = size;
@@ -92,6 +96,7 @@ int canokey_emu_prepare_receive(
 int canokey_emu_transmit(
 void *base, uint8_t ep, const uint8_t *pbuf, uint16_t size)
 {
+trace_canokey_emu_transmit(ep, size);
 CanoKeyState *key = base;
 uint8_t ep_in = CANOKEY_EP_IN(ep); /* INTR IN has ep 129 */
 memcpy(key->ep_in[ep_in] + key->ep_in_size[ep_in],
@@ -125,6 +130,7 @@ uint32_t canokey_emu_get_rx_data_size(void *base, uint8_t 
ep)
  */
 static void canokey_handle_reset(USBDevice *dev)
 {
+trace_canokey_handle_reset();
 CanoKeyState *key = CANOKEY(dev);
 for (int i = 0; i != CANOKEY_EP_NUM; ++i) {
 key->ep_in_state[i] = CANOKEY_EP_IN_WAIT;
@@ -137,6 +143,7 @@ static void canokey_handle_reset(USBDevice *dev)
 static void canokey_handle_control(USBDevice *dev, USBPacket *p,
int request, int value, int index, int length, uint8_t *data)
 {
+trace_canokey_handle_control_setup(request, value, index, length);
 CanoKeyState *key = CANOKEY(dev);
 
 canokey_emu_setup(request, value, index, length);
@@ -144,6 +151,7 @@ static void canokey_handle_control(USBDevice *dev, 
USBPacket *p,
 uint32_t dir_in = request & DeviceRequest;
 if (!dir_in) {
 /* OUT */
+trace_canokey_handle_control_out();
 if (key->ep_out[0] != NULL) {
 memcpy(key->ep_out[0], data, length);
 }
@@ -163,6 +171,7 @@ static void canokey_handle_control(USBDevice *dev, 
USBPacket *p,
 case CANOKEY_EP_IN_READY:
 memcpy(data, key->ep_in[0], key->ep_in_size[0]);
 p->actual_length = key->ep_in_size[0];
+trace_canokey_handle_control_in(p->actual_length);
 /* reset state */
 key->ep_in_state[0] = CANOKEY_EP_IN_WAIT;
 key->ep_in_size[0] = 0;
@@ -182,6 +191,7 @@ static void canokey_handle_data(USBDevice *dev, USBPacket 
*p)
 uint32_t out_len;
 switch (p->pid) {
 case USB_TOKEN_OUT:
+trace_canokey_handle_data_out(ep_out, p->iov.size);
 usb_packet_copy(p, key->ep_out_buffer[ep_out], p->iov.size);
 out_pos = 0;
 while (out_pos != p->iov.size) {
@@ -226,6 +236,7 @@ static void canokey_handle_data(USBDevice *dev, USBPacket 
*p)
 key->ep_in_size[ep_in] = 0;
 key->ep_in_pos[ep_in] = 0;
 }
+trace_canokey_handle_data_in(ep_in, in_len);
 break;
 }
 break;
@@ -237,6 +248,7 @@ static void canokey_handle_data(USBDevice *dev, USBPacket 
*p)
 
 static void canokey_realize(USBDevice *base, Error **errp)
 {
+trace_canokey_realize();
 CanoKeyState *key = CANOKEY(base);
 
 if (key->file == NULL) {
@@ -260,6 +272,7 @@ static void canokey_realize(USBDevice *base, Error **errp)
 
 static void canokey_unrealize(USBDevice *base)
 {
+trace_canokey_unrealize();
 }
 
 static Property canokey_properties[] = {
diff --git a/hw/usb/trace-events b/hw/usb/trace-events
index 9773cb53300d..914ca7166829 100644
--- a/hw/usb/trace-events
+++ b/hw/usb/trace-events
@@ -345,3 +345,19 @@ usb_serial_set_baud(int bus, int addr, int baud) "dev 
%d:%u baud rate %d"
 usb_serial_set_data(int bus, int addr, int parity, int data, int stop) "dev 
%d:%u parity %c, data bits %d, stop bits %d"
 usb_serial_set_flow_control(int bus, int addr, int index) "dev %d:%u flow 
control %d"
 usb_serial_set_xonxoff(int bus, int addr, uint8_t xon, uint8_t xoff) "dev 
%d:%u xon 0x%x xoff 0x%x"
+
+# canokey.c
+canokey_emu_stall_ep(uint8_t ep) "ep %d"
+canokey_emu_set_address(uint8_t addr) "addr %d"
+canokey_emu_prepare_receive(uint8_t ep, uint16_t size) "ep %d size %d"
+canokey_emu_transmit(uint8_t e

Re: [PULL 00/16] Kraxel 20220613 patches

2022-06-14 Thread Gerd Hoffmann
On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> On 6/13/22 04:36, Gerd Hoffmann wrote:
> > The following changes since commit dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> > 
> >Merge tag 'mips-20220611' of https://github.com/philmd/qemu into staging 
> > (2022-06-11 21:13:27 -0700)
> > 
> > are available in the Git repository at:
> > 
> >git://git.kraxel.org/qemu tags/kraxel-20220613-pull-request
> > 
> > for you to fetch changes up to 23b87f7a3a13e93e248eef8a4b7257548855a620:
> > 
> >ui: move 'pc-bios/keymaps' to 'ui/keymaps' (2022-06-13 10:59:25 +0200)
> > 
> > 
> > usb: add CanoKey device, fixes for ehci + redir
> > ui: fixes for gtk and cocoa, move keymaps (v2), rework refresh rate
> > virtio-gpu: scanout flush fix
> 
> This doesn't even configure:
> 
> ../src/ui/keymaps/meson.build:55:4: ERROR: File ar does not exist.

dropped keymaps patch for now, new version sent.

take care,
  Gerd




[PULL 12/15] virtio-gpu: update done only on the scanout associated with rect

2022-06-14 Thread Gerd Hoffmann
From: Dongwon Kim 

It only needs to update the scanouts containing the rect area
coming with the resource-flush request from the guest.

Cc: Gerd Hoffmann 
Cc: Vivek Kasireddy 
Signed-off-by: Dongwon Kim 
Message-Id: <20220505214030.4261-1-dongwon@intel.com>
Signed-off-by: Gerd Hoffmann 
---
 hw/display/virtio-gpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cd4a56056fd9..55c6dd576318 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -514,6 +514,9 @@ static void virtio_gpu_resource_flush(VirtIOGPU *g,
 for (i = 0; i < g->parent_obj.conf.max_outputs; i++) {
 scanout = &g->parent_obj.scanout[i];
 if (scanout->resource_id == res->resource_id &&
+rf.r.x >= scanout->x && rf.r.y >= scanout->y &&
+rf.r.x + rf.r.width <= scanout->x + scanout->width &&
+rf.r.y + rf.r.height <= scanout->y + scanout->height &&
 console_has_gl(scanout->con)) {
 dpy_gl_update(scanout->con, 0, 0, scanout->width,
   scanout->height);
-- 
2.36.1




[PULL 11/15] usbredir: avoid queuing hello packet on snapshot restore

2022-06-14 Thread Gerd Hoffmann
From: Joelle van Dyne 

When launching QEMU with "-loadvm", usbredir_create_parser() should avoid
setting up the hello packet (just as with "-incoming". On the latest version
of libusbredir, usbredirparser_unserialize() will return error if the parser
is not "pristine."

Signed-off-by: Joelle van Dyne 
Message-Id: <20220507041850.98716-...@getutm.app>
Signed-off-by: Gerd Hoffmann 
---
 hw/usb/redirect.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index fd7df599bc0b..1bd30efc3ef0 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -1280,7 +1280,8 @@ static void usbredir_create_parser(USBRedirDevice *dev)
 }
 #endif
 
-if (runstate_check(RUN_STATE_INMIGRATE)) {
+if (runstate_check(RUN_STATE_INMIGRATE) ||
+runstate_check(RUN_STATE_PRELAUNCH)) {
 flags |= usbredirparser_fl_no_hello;
 }
 usbredirparser_init(dev->parser, VERSION, caps, USB_REDIR_CAPS_SIZE,
-- 
2.36.1




Re: [PATCH] target/ppc: cpu_init: Clean up stop state on cpu reset

2022-06-14 Thread Fabiano Rosas
Frederic Barrat  writes:

> The 'resume_as_sreset' attribute of a cpu can be set when a thread is
> entering a stop state on ppc books. It causes the thread to be
> re-routed to vector 0x100 when woken up by an exception. So it must be
> cleaned on reset or a thread might be re-routed unexpectedly after a
> reset, when it was not in a stop state and/or when the appropriate
> exception handler isn't set up yet.
>
> Signed-off-by: Frederic Barrat 

Reviewed-by: Fabiano Rosas 




[PULL 02/15] ui/gtk-gl-area: create the requested GL context version

2022-06-14 Thread Gerd Hoffmann
From: Volker Rümelin 

Since about 2018 virglrenderer (commit fa835b0f88 "vrend: don't
hardcode context version") tries to open the highest available GL
context version. This is done by creating the known GL context
versions from the highest to the lowest until (*create_gl_context)
returns a context != NULL.

This does not work properly with
the current QEMU gd_gl_area_create_context() function, because
gdk_gl_context_realize() on Wayland creates a version 3.0 legacy
context if the requested GL context version can't be created.

In order for virglrenderer to find the highest available GL
context version, return NULL if the created context version is
lower than the requested version.

This fixes the following error:
QEMU started with -device virtio-vga-gl -display gtk,gl=on.
Under Wayland, the guest window remains black and the following
information can be seen on the host.

gl_version 30 - compat profile
(qemu:5978): Gdk-WARNING **: 16:19:01.533:
  gdk_gl_context_set_required_version
  - GL context versions less than 3.2 are not supported.

(qemu:5978): Gdk-WARNING **: 16:19:01.537:
  gdk_gl_context_set_required_version -
  GL context versions less than 3.2 are not supported.

(qemu:5978): Gdk-WARNING **: 16:19:01.554:
  gdk_gl_context_set_required_version -
  GL context versions less than 3.2 are not supported.
vrend_renderer_fill_caps: Entering with stale GL error: 1282

To reproduce this error, an OpenGL driver is required on the host
that doesn't have the latest OpenGL extensions fully implemented.
An example for this is the Intel i965 driver on a Haswell processor.

Signed-off-by: Volker Rümelin 
Message-Id: <20220605085131.7711-2-vr_q...@t-online.de>
Signed-off-by: Gerd Hoffmann 
---
 ui/gtk-gl-area.c | 31 ++-
 ui/trace-events  |  1 +
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c
index 0e20ea031d34..2e0129c28cd4 100644
--- a/ui/gtk-gl-area.c
+++ b/ui/gtk-gl-area.c
@@ -170,6 +170,23 @@ void gd_gl_area_switch(DisplayChangeListener *dcl,
 }
 }
 
+static int gd_cmp_gl_context_version(int major, int minor, QEMUGLParams 
*params)
+{
+if (major > params->major_ver) {
+return 1;
+}
+if (major < params->major_ver) {
+return -1;
+}
+if (minor > params->minor_ver) {
+return 1;
+}
+if (minor < params->minor_ver) {
+return -1;
+}
+return 0;
+}
+
 QEMUGLContext gd_gl_area_create_context(DisplayGLCtx *dgc,
 QEMUGLParams *params)
 {
@@ -177,8 +194,8 @@ QEMUGLContext gd_gl_area_create_context(DisplayGLCtx *dgc,
 GdkWindow *window;
 GdkGLContext *ctx;
 GError *err = NULL;
+int major, minor;
 
-gtk_gl_area_make_current(GTK_GL_AREA(vc->gfx.drawing_area));
 window = gtk_widget_get_window(vc->gfx.drawing_area);
 ctx = gdk_window_create_gl_context(window, &err);
 if (err) {
@@ -196,6 +213,18 @@ QEMUGLContext gd_gl_area_create_context(DisplayGLCtx *dgc,
 g_clear_object(&ctx);
 return NULL;
 }
+
+gdk_gl_context_make_current(ctx);
+gdk_gl_context_get_version(ctx, &major, &minor);
+gdk_gl_context_clear_current();
+gtk_gl_area_make_current(GTK_GL_AREA(vc->gfx.drawing_area));
+
+if (gd_cmp_gl_context_version(major, minor, params) == -1) {
+/* created ctx version < requested version */
+g_clear_object(&ctx);
+}
+
+trace_gd_gl_area_create_context(ctx, params->major_ver, params->minor_ver);
 return ctx;
 }
 
diff --git a/ui/trace-events b/ui/trace-events
index 1040ba0f88c7..a922f00e10b4 100644
--- a/ui/trace-events
+++ b/ui/trace-events
@@ -26,6 +26,7 @@ gd_key_event(const char *tab, int gdk_keycode, int qkeycode, 
const char *action)
 gd_grab(const char *tab, const char *device, const char *reason) "tab=%s, 
dev=%s, reason=%s"
 gd_ungrab(const char *tab, const char *device) "tab=%s, dev=%s"
 gd_keymap_windowing(const char *name) "backend=%s"
+gd_gl_area_create_context(void *ctx, int major, int minor) "ctx=%p, major=%d, 
minor=%d"
 gd_gl_area_destroy_context(void *ctx, void *current_ctx) "ctx=%p, 
current_ctx=%p"
 
 # vnc-auth-sasl.c
-- 
2.36.1




[PULL 14/15] ui: Deliver refresh rate via QemuUIInfo

2022-06-14 Thread Gerd Hoffmann
From: Akihiko Odaki 

This change adds a new member, refresh_rate to QemuUIInfo in
include/ui/console.h. It represents the refresh rate of the
physical display backend, and it is more appropriate than
GUI update interval as the refresh rate which the emulated device
reports:
- sdl may set GUI update interval shorter than the refresh rate
  of the physical display to respond to user-generated events.
- sdl and vnc aggressively changes GUI update interval, but
  a guests is typically not designed to respond to frequent
  refresh rate changes, or frequent "display mode" changes in
  general. The frequency of refresh rate changes of the physical
  display backend matches better to the guest's expectation.

QemuUIInfo also has other members representing "display mode",
which makes it suitable for refresh rate representation. It has
a throttling of update notifications, and prevents frequent changes
of the display mode.

Signed-off-by: Akihiko Odaki 
Message-Id: <20220226115516.59830-3-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann 
---
 include/ui/console.h |  2 +-
 include/ui/gtk.h |  2 +-
 hw/display/xenfb.c   | 14 +++---
 ui/console.c |  6 --
 ui/gtk-egl.c |  4 ++--
 ui/gtk-gl-area.c |  3 +--
 ui/gtk.c | 45 +---
 7 files changed, 42 insertions(+), 34 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index 642d6f5248cf..b64d82436097 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -139,6 +139,7 @@ typedef struct QemuUIInfo {
 int   yoff;
 uint32_t  width;
 uint32_t  height;
+uint32_t  refresh_rate;
 } QemuUIInfo;
 
 /* cursor data format is 32bit RGBA */
@@ -431,7 +432,6 @@ typedef struct GraphicHwOps {
 void (*gfx_update)(void *opaque);
 bool gfx_update_async; /* if true, calls graphic_hw_update_done() */
 void (*text_update)(void *opaque, console_ch_t *text);
-void (*update_interval)(void *opaque, uint64_t interval);
 void (*ui_info)(void *opaque, uint32_t head, QemuUIInfo *info);
 void (*gl_block)(void *opaque, bool block);
 } GraphicHwOps;
diff --git a/include/ui/gtk.h b/include/ui/gtk.h
index 101b147d1b98..ae0f53740d19 100644
--- a/include/ui/gtk.h
+++ b/include/ui/gtk.h
@@ -155,7 +155,7 @@ extern bool gtk_use_gl_area;
 
 /* ui/gtk.c */
 void gd_update_windowsize(VirtualConsole *vc);
-int gd_monitor_update_interval(GtkWidget *widget);
+void gd_update_monitor_refresh_rate(VirtualConsole *vc, GtkWidget *widget);
 void gd_hw_gl_flushed(void *vc);
 
 /* ui/gtk-egl.c */
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index cea10fe3c780..50857cd97a0b 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -777,16 +777,24 @@ static void xenfb_update(void *opaque)
 xenfb->up_fullscreen = 0;
 }
 
-static void xenfb_update_interval(void *opaque, uint64_t interval)
+static void xenfb_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
 {
 struct XenFB *xenfb = opaque;
+uint32_t refresh_rate;
 
 if (xenfb->feature_update) {
 #ifdef XENFB_TYPE_REFRESH_PERIOD
 if (xenfb_queue_full(xenfb)) {
 return;
 }
-xenfb_send_refresh_period(xenfb, interval);
+
+refresh_rate = info->refresh_rate;
+if (!refresh_rate) {
+refresh_rate = 75;
+}
+
+/* T = 1 / f = 1 [s*Hz] / f = 1000*1000 [ms*mHz] / f */
+xenfb_send_refresh_period(xenfb, 1000 * 1000 / refresh_rate);
 #endif
 }
 }
@@ -983,5 +991,5 @@ struct XenDevOps xen_framebuffer_ops = {
 static const GraphicHwOps xenfb_ops = {
 .invalidate  = xenfb_invalidate,
 .gfx_update  = xenfb_update,
-.update_interval = xenfb_update_interval,
+.ui_info = xenfb_ui_info,
 };
diff --git a/ui/console.c b/ui/console.c
index 36c80cd1de85..9331b85203a0 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -160,7 +160,6 @@ static void gui_update(void *opaque)
 uint64_t dcl_interval;
 DisplayState *ds = opaque;
 DisplayChangeListener *dcl;
-QemuConsole *con;
 
 ds->refreshing = true;
 dpy_refresh(ds);
@@ -175,11 +174,6 @@ static void gui_update(void *opaque)
 }
 if (ds->update_interval != interval) {
 ds->update_interval = interval;
-QTAILQ_FOREACH(con, &consoles, next) {
-if (con->hw_ops->update_interval) {
-con->hw_ops->update_interval(con->hw, interval);
-}
-}
 trace_console_refresh(interval);
 }
 ds->last_update = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index e3bd4bc27431..b5bffbab2522 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -140,8 +140,8 @@ void gd_egl_refresh(DisplayChangeListener *dcl)
 {
 VirtualConsole *vc = container_of(dcl, VirtualConsole, gfx.dcl);
 
-vc->gfx.dcl.update_interval = gd_monitor_update_interval(
-vc->window ? vc->window : vc->gfx.drawing_area);
+gd_update_monitor_refresh_rate(
+vc, v

Re: [External] [PATCH v13 3/8] QIOChannelSocket: Implement io_writev zero copy flag & io_flush for CONFIG_LINUX

2022-06-14 Thread chuang xu


On 2022/5/13 下午2:28, Leonardo Bras wrote:

@@ -557,15 +578,31 @@ static ssize_t qio_channel_socket_writev(QIOChannel *ioc,
  memcpy(CMSG_DATA(cmsg), fds, fdsize);
  }
  
+#ifdef QEMU_MSG_ZEROCOPY

+if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY) {
+sflags = MSG_ZEROCOPY;
+}
+#endif
+
   retry:
-ret = sendmsg(sioc->fd, &msg, 0);
+ret = sendmsg(sioc->fd, &msg, sflags);
  if (ret <= 0) {
-if (errno == EAGAIN) {
+switch (errno) {
+case EAGAIN:
  return QIO_CHANNEL_ERR_BLOCK;
-}
-if (errno == EINTR) {
+case EINTR:
  goto retry;
+#ifdef QEMU_MSG_ZEROCOPY
+case ENOBUFS:
+if (sflags & MSG_ZEROCOPY) {
+error_setg_errno(errp, errno,
+ "Process can't lock enough memory for using 
MSG_ZEROCOPY");
+return -1;
+}
+break;
+#endif
  }
+
  error_setg_errno(errp, errno,
   "Unable to write to socket");
  return -1;


Hi, Leo.

There are some other questions I would like to discuss with you.

I tested the multifd zero_copy migration and found that sometimes even 
if max locked memory of qemu was set to 16GB(much greater than 
`MULTIFD_PACKET_SIZE`), the error "Process can't lock enough memory for 
using MSG_ZEROCOPY" would still be reported.


I noticed that the 
doc(https://www.kernel.org/doc/html/v5.12/networking/msg_zerocopy.html) 
says "A zerocopy failure will return -1 with errno ENOBUFS. This happens 
if the socket option was not set, _the socket exceeds its optmem limit_ 
or the user exceeds its ulimit on locked pages."


I also found that the RFC(https://lwn.net/Articles/715279/) says _"__The 
change to allocate notification skbuffs from optmem requires__ensuring 
that net.core.optmem is at least a few 100KB."_


On my host,  optmem was initially set to 20KB, I tried to change it to 
100KB (echo 102400 > /proc/sys/net/core/optmem_max) as the RFC says.Then 
I tested the multifd zero_copy migration repeatedly,and the error 
disappeared.


So when sendmsg returns -1 with errno ENOBUFS, should we distinguish 
between error ''socket exceeds optmem limit" and error "user exceeds 
ulimit on locked pages"? Or is there any better way to avoid this problem?


Best Regards,

chuang xu


Re: [PATCH 1/2] Trivial: 3 char repeat typos

2022-06-14 Thread Daniel Henrique Barboza




On 6/14/22 07:40, Dr. David Alan Gilbert (git) wrote:

From: "Dr. David Alan Gilbert" 

Inspired by Julia Lawall's fixing of Linux
kernel comments, I looked at qemu, although I did it manually.

Signed-off-by: Dr. David Alan Gilbert 
---


Reviewed-by: Daniel Henrique Barboza 


  hw/intc/openpic.c| 2 +-
  hw/net/imx_fec.c | 2 +-
  hw/pci/pcie_aer.c| 2 +-
  hw/pci/shpc.c| 3 ++-
  hw/ppc/spapr_caps.c  | 2 +-
  hw/scsi/spapr_vscsi.c| 2 +-
  qapi/net.json| 2 +-
  tools/virtiofsd/passthrough_ll.c | 2 +-
  ui/input.c   | 2 +-
  9 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/hw/intc/openpic.c b/hw/intc/openpic.c
index 49504e740f..b0787e8ee7 100644
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@ -729,7 +729,7 @@ static void openpic_tmr_set_tmr(OpenPICTimer *tmr, uint32_t 
val, bool enabled)
  }
  
  /*

- * Returns the currrent tccr value, i.e., timer value (in clocks) with
+ * Returns the current tccr value, i.e., timer value (in clocks) with
   * appropriate TOG.
   */
  static uint64_t openpic_tmr_get_timer(OpenPICTimer *tmr)
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index 0db9aaf76a..8c11b237de 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -438,7 +438,7 @@ static void imx_eth_update(IMXFECState *s)
   *   assignment fail.
   *
   * To ensure that all versions of Linux work, generate ENET_INT_MAC
- * interrrupts on both interrupt lines. This should be changed if and when
+ * interrupts on both interrupt lines. This should be changed if and when
   * qemu supports IOMUX.
   */
  if (s->regs[ENET_EIR] & s->regs[ENET_EIMR] &
diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
index 92bd0530dd..eff62f3945 100644
--- a/hw/pci/pcie_aer.c
+++ b/hw/pci/pcie_aer.c
@@ -323,7 +323,7 @@ static void pcie_aer_msg_root_port(PCIDevice *dev, const 
PCIEAERMsg *msg)
   */
  }
  
-/* Errro Message Received: Root Error Status register */

+/* Error Message Received: Root Error Status register */
  switch (msg->severity) {
  case PCI_ERR_ROOT_CMD_COR_EN:
  if (root_status & PCI_ERR_ROOT_COR_RCV) {
diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c
index f822f18b98..e71f3a7483 100644
--- a/hw/pci/shpc.c
+++ b/hw/pci/shpc.c
@@ -480,7 +480,8 @@ static const MemoryRegionOps shpc_mmio_ops = {
  .endianness = DEVICE_LITTLE_ENDIAN,
  .valid = {
  /* SHPC ECN requires dword accesses, but the original 1.0 spec 
doesn't.
- * It's easier to suppport all sizes than worry about it. */
+ * It's easier to support all sizes than worry about it.
+ */
  .min_access_size = 1,
  .max_access_size = 4,
  },
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 655ab856a0..b4283055c1 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -553,7 +553,7 @@ static void cap_ccf_assist_apply(SpaprMachineState *spapr, 
uint8_t val,
   * instruction is a harmless no-op.  It won't correctly
   * implement the cache count flush *but* if we have
   * count-cache-disabled in the host, that flush is
- * unnnecessary.  So, specifically allow this case.  This
+ * unnecessary.  So, specifically allow this case.  This
   * allows us to have better performance on POWER9 DD2.3,
   * while still working on POWER9 DD2.2 and POWER8 host
   * cpus.
diff --git a/hw/scsi/spapr_vscsi.c b/hw/scsi/spapr_vscsi.c
index a07a8e1523..e320ccaa23 100644
--- a/hw/scsi/spapr_vscsi.c
+++ b/hw/scsi/spapr_vscsi.c
@@ -1013,7 +1013,7 @@ static int vscsi_send_capabilities(VSCSIState *s, 
vscsi_req *req)
  }
  
  /*

- * Current implementation does not suppport any migration or
+ * Current implementation does not support any migration or
   * reservation capabilities. Construct the response telling the
   * guest not to use them.
   */
diff --git a/qapi/net.json b/qapi/net.json
index d6f7cfd4d6..9af11e9a3b 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -298,7 +298,7 @@
  #
  # @udp: use the udp version of l2tpv3 encapsulation
  #
-# @cookie64: use 64 bit coookies
+# @cookie64: use 64 bit cookies
  #
  # @counter: have sequence counter
  #
diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index b15c631ca5..7a73dfcce9 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2319,7 +2319,7 @@ static int do_lo_create(fuse_req_t req, struct lo_inode 
*parent_inode,
   * If security.selinux has not been remapped and selinux is enabled,
   * use fscreate to set context before file creation. If not, use
   * tmpfile method for regular files. Otherwise fallback to
- * non-atomic method of file creation and xattr settting.
+ * non-atomic method of file creation and xattr setting.

Re: [PATCH 2/2] docs: build-platforms: Clarify stance on minor releases and backports

2022-06-14 Thread Andrea Bolognani
On Wed, May 04, 2022 at 09:23:28AM +0100, Daniel P. Berrangé wrote:
> On Wed, May 04, 2022 at 01:01:03AM -0700, Andrea Bolognani wrote:
> > On Wed, Apr 20, 2022 at 09:18:47AM -0700, Andrea Bolognani wrote:
> > > On Wed, Apr 20, 2022 at 05:15:08PM +0100, Daniel P. Berrangé wrote:
> > > > On Wed, Apr 20, 2022 at 06:03:11PM +0200, Andrea Bolognani wrote:
> > > > > These changes match those made in the following libvirt commits:
> > > > >
> > > > >   2ac78307af docs: Clarify our stance on backported packages
> > > > >   78cffd450a docs: Spell out our policy concerning minor releases
> > > > >
> > > > > Since QEMU's platform support policy is based on libvirt's, it
> > > > > makes sense to mirror these recent changes made to the latter.
> > > > >
> > > > > The policy is not altered significantly - we're simply spelling
> > > > > out some rules that were likely already being implicitly
> > > > > enforced.
> > > >
> > > > Indeed, I think that's basically defacto the case already.
> > > >
> > > > Reviewed-by: Daniel P. Berrangé 
> > >
> > > Thanks! Are you going to bring these in through one of your trees, or
> > > do I need to bug someone else so that they will pick them up? :)
> >
> > I see these haven't gone in yet. Anything I can/should do to make
> > that happen?
>
> The tragedy of QEMU not having a central docs maintainer. I'll queue
> this one for my next pull request.

Still doesn't seem to have been merged. Not pressuring you or
anything, just making sure it doesn't slip through the cracks :)

-- 
Andrea Bolognani / Red Hat / Virtualization




Re: [PATCH] hw/mem/nvdimm: fix error message for 'unarmed' flag

2022-06-14 Thread Igor Mammedov
On Tue, 14 Jun 2022 11:50:43 +0200
David Hildenbrand  wrote:

> On 14.06.22 10:54, Igor Mammedov wrote:
> > On Mon, 13 Jun 2022 16:09:53 +0100
> > Stefan Hajnoczi  wrote:
> >   
> >> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:  
> >>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi  
> >>> wrote:
> 
>  On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > cannot accept a persistent write. This means that when a memdev is
> > read-only, the 'unarmed' flag must be turned on. The logic is correct,
> > just changing the error message.
> >
> > [1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM State Flags" Bit 3
> >
> > Signed-off-by: Julia Suvorova 
> > ---
> >  hw/mem/nvdimm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  Reviewed-by: Stefan Hajnoczi 
> >>>
> >>> It seems like Xiao is not active, whose tree should this patch go to?
> 
> Is that a temporary or a permanent thing? Do we know?
> 
> > 
> > Perhaps David can add himself as maintainer (i.e. put it
> > under memory mantanership umbrella) and merge it   
> 
> Maybe it makes sense to combine NVDIMM with pc-dimm.c and
> memory-device.c into a "MEMORY DEVICE" section. Then, remove "hw/mem/*"
> from "ACPI/SMBIOS".
just keep me on supporter list for them so I won't miss
patches that needs reviewing.

> cxl_type3.c, npcm7xx_mc.c and sparse-mem.c in /hw/mem/ are a bit
> different. We could add cxl_type3.c to "Compute Express Link".
> npcm7xx_mc.c and sparse-mem.c should be already covered. 
for cxl I'd add Michael as it's mostly all PCI stuff




Re: [PATCH 01/11] ppc/pnv: move root port attach to pnv_phb4_realize()

2022-06-14 Thread Daniel Henrique Barboza




On 6/14/22 09:02, Cédric Le Goater wrote:

On 6/13/22 17:44, Daniel Henrique Barboza wrote:

Creating a root port is something related to the PHB, not the PEC. It
also makes the logic more in line with what pnv-phb3 does.

Signed-off-by: Daniel Henrique Barboza 


Reviewed-by: Cédric Le Goater 

So the root port is back where it was.

Could we avoid the pci_new() and use object_initialize_child() instead ?



We could but then we would need to deal with yet another difference with
default versus user created devices, given that for user devices we can't
initialize_child(). And since we're also unifying the root ports later on
I'd rather wait to see how it turns out when everything is finished.


Tanks,

Daniel



Thanks,

C.



---
  hw/pci-host/pnv_phb4.c | 4 
  hw/pci-host/pnv_phb4_pec.c | 3 ---
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 6594016121..23ad8de7ee 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -1547,6 +1547,7 @@ static void pnv_phb4_instance_init(Object *obj)
  static void pnv_phb4_realize(DeviceState *dev, Error **errp)
  {
  PnvPHB4 *phb = PNV_PHB4(dev);
+    PnvPhb4PecClass *pecc = PNV_PHB4_PEC_GET_CLASS(phb->pec);
  PCIHostState *pci = PCI_HOST_BRIDGE(dev);
  XiveSource *xsrc = &phb->xsrc;
  int nr_irqs;
@@ -1583,6 +1584,9 @@ static void pnv_phb4_realize(DeviceState *dev, Error 
**errp)
  pci_setup_iommu(pci->bus, pnv_phb4_dma_iommu, phb);
  pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE;
+    /* Add a single Root port if running with defaults */
+    pnv_phb_attach_root_port(pci, pecc->rp_model);
+
  /* Setup XIVE Source */
  if (phb->big_phb) {
  nr_irqs = PNV_PHB4_MAX_INTs;
diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c
index 8b7e823fa5..c9aaf1c28e 100644
--- a/hw/pci-host/pnv_phb4_pec.c
+++ b/hw/pci-host/pnv_phb4_pec.c
@@ -130,9 +130,6 @@ static void pnv_pec_default_phb_realize(PnvPhb4PecState 
*pec,
  if (!sysbus_realize(SYS_BUS_DEVICE(phb), errp)) {
  return;
  }
-
-    /* Add a single Root port if running with defaults */
-    pnv_phb_attach_root_port(PCI_HOST_BRIDGE(phb), pecc->rp_model);
  }
  static void pnv_pec_realize(DeviceState *dev, Error **errp)






Re: [External] [PATCH v13 3/8] QIOChannelSocket: Implement io_writev zero copy flag & io_flush for CONFIG_LINUX

2022-06-14 Thread Dr. David Alan Gilbert
* chuang xu (xuchuangxc...@bytedance.com) wrote:
> 
> On 2022/5/13 下午2:28, Leonardo Bras wrote:
> > @@ -557,15 +578,31 @@ static ssize_t qio_channel_socket_writev(QIOChannel 
> > *ioc,
> >   memcpy(CMSG_DATA(cmsg), fds, fdsize);
> >   }
> > +#ifdef QEMU_MSG_ZEROCOPY
> > +if (flags & QIO_CHANNEL_WRITE_FLAG_ZERO_COPY) {
> > +sflags = MSG_ZEROCOPY;
> > +}
> > +#endif
> > +
> >retry:
> > -ret = sendmsg(sioc->fd, &msg, 0);
> > +ret = sendmsg(sioc->fd, &msg, sflags);
> >   if (ret <= 0) {
> > -if (errno == EAGAIN) {
> > +switch (errno) {
> > +case EAGAIN:
> >   return QIO_CHANNEL_ERR_BLOCK;
> > -}
> > -if (errno == EINTR) {
> > +case EINTR:
> >   goto retry;
> > +#ifdef QEMU_MSG_ZEROCOPY
> > +case ENOBUFS:
> > +if (sflags & MSG_ZEROCOPY) {
> > +error_setg_errno(errp, errno,
> > + "Process can't lock enough memory for 
> > using MSG_ZEROCOPY");
> > +return -1;
> > +}
> > +break;
> > +#endif
> >   }
> > +
> >   error_setg_errno(errp, errno,
> >"Unable to write to socket");
> >   return -1;
> 
> Hi, Leo.
> 
> There are some other questions I would like to discuss with you.
> 
> I tested the multifd zero_copy migration and found that sometimes even if
> max locked memory of qemu was set to 16GB(much greater than
> `MULTIFD_PACKET_SIZE`), the error "Process can't lock enough memory for
> using MSG_ZEROCOPY" would still be reported.
> 
> I noticed that the
> doc(https://www.kernel.org/doc/html/v5.12/networking/msg_zerocopy.html) says
> "A zerocopy failure will return -1 with errno ENOBUFS. This happens if the
> socket option was not set, _the socket exceeds its optmem limit_ or the user
> exceeds its ulimit on locked pages."
> 
> I also found that the RFC(https://lwn.net/Articles/715279/) says _"__The
> change to allocate notification skbuffs from optmem requires__ensuring that
> net.core.optmem is at least a few 100KB."_

Interesting.

> On my host,  optmem was initially set to 20KB, I tried to change it to 100KB
> (echo 102400 > /proc/sys/net/core/optmem_max) as the RFC says.Then I tested
> the multifd zero_copy migration repeatedly,and the error disappeared.
> 
> So when sendmsg returns -1 with errno ENOBUFS, should we distinguish between
> error ''socket exceeds optmem limit" and error "user exceeds ulimit on
> locked pages"? Or is there any better way to avoid this problem?

I don't think we can tell which one of them triggered the error; so the
only thing I can suggest is that we document the need for optmem_max
setting; I wonder how we get a better answer than 'a few 100KB'?
I guess it's something like the number of packets inflight *
sizeof(cmsghdr) ?

Dave

> Best Regards,
> 
> chuang xu
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH 2/5] tests/qemu-iotests: skip 108 when FUSE is not loaded

2022-06-14 Thread John Snow
On Tue, Jun 14, 2022 at 4:59 AM Daniel P. Berrangé  wrote:
>
> On Tue, Jun 14, 2022 at 06:46:35AM +0200, Thomas Huth wrote:
> > On 14/06/2022 03.50, John Snow wrote:
> > > In certain container environments we may not have FUSE at all, so skip
> > > the test in this circumstance too.
> > >
> > > Signed-off-by: John Snow 
> > > ---
> > >   tests/qemu-iotests/108 | 6 ++
> > >   1 file changed, 6 insertions(+)
> > >
> > > diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
> > > index 9e923d6a59f..e401c5e9933 100755
> > > --- a/tests/qemu-iotests/108
> > > +++ b/tests/qemu-iotests/108
> > > @@ -60,6 +60,12 @@ if sudo -n losetup &>/dev/null; then
> > >   else
> > >   loopdev=false
> > > +# Check for fuse support in the host environment:
> > > +lsmod | grep fuse &>/dev/null;
> >
> > That doesn't work if fuse has been linked statically into the kernel. Would
> > it make sense to test for /sys/fs/fuse instead?
> >
> > (OTOH, we likely hardly won't run this on statically linked kernels anyway,
> > so it might not matter too much)
>
> But more importantly 'lsmod' may not be installed in our container
> images. So checking /sys/fs/fuse avoids introducing a dep on the
> 'kmod' package.
>
> >
> > > +if [[ $? -ne 0 ]]; then
> >
> > I'd prefer single "[" instead of "[[" ... but since we're requiring bash
> > anyway, it likely doesn't matter.
>
> Or
>
> if  test $? != 0 ; then
>
> >
> > > +_notrun 'No Passwordless sudo nor FUSE kernel module'
> > > +fi
> > > +
> > >   # QSD --export fuse will either yield "Parameter 'id' is missing"
> > >   # or "Invalid parameter 'fuse'", depending on whether there is
> > >   # FUSE support or not.
> >

Good suggestions, thanks!

--js




Re: [PATCH v12 00/14] vfio-user server in QEMU

2022-06-14 Thread Jag Raman



> On Jun 14, 2022, at 3:06 AM, Stefan Hajnoczi  wrote:
> 
> On Mon, Jun 13, 2022 at 04:26:20PM -0400, Jagannathan Raman wrote:
>> This is v12 of the server side changes to enable vfio-user in QEMU.
>> 
>> Thanks so much for reviewing this series and sharing your feedback.
>> 
>> We made the following changes in this series:
>> [PATCH v12 13/14] vfio-user: handle device interrupts
>> - Renamed msi_set_irq_state() and msix_set_irq_state() as
>>   msi_set_mask() and msix_set_mask() respectively
>> - Added missing return statement for error case in msi_set_mask()
> 
> Thanks, applied to my block tree:
> https://gitlab.com/stefanha/qemu/commits/block

Thank you very much, Stefan! :)

> 
> Stefan




[PATCH] configure: cleanup -fno-pie detection

2022-06-14 Thread Paolo Bonzini
Place it only inside the 'if test "$pie" = "no"' conditional.

Signed-off-by: Paolo Bonzini 
---
 configure | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index f3dcbd10c3..e2b64334b5 100755
--- a/configure
+++ b/configure
@@ -1346,13 +1346,6 @@ static THREAD int tls_var;
 int main(void) { return tls_var; }
 EOF
 
-# Check we support -fno-pie and -no-pie first; we will need the former for
-# building ROMs, and both for everything if --disable-pie is passed.
-if compile_prog "-Werror -fno-pie" "-no-pie"; then
-  CFLAGS_NOPIE="-fno-pie"
-  LDFLAGS_NOPIE="-no-pie"
-fi
-
 if test "$static" = "yes"; then
   if test "$pie" != "no" && compile_prog "-Werror -fPIE -DPIE" "-static-pie"; 
then
 CONFIGURE_CFLAGS="-fPIE -DPIE $CONFIGURE_CFLAGS"
@@ -1365,8 +1358,10 @@ if test "$static" = "yes"; then
 pie="no"
   fi
 elif test "$pie" = "no"; then
-  CONFIGURE_CFLAGS="$CFLAGS_NOPIE $CONFIGURE_CFLAGS"
-  CONFIGURE_LDFLAGS="$LDFLAGS_NOPIE $CONFIGURE_LDFLAGS"
+  if compile_prog "-Werror -fno-pie" "-no-pie"; then
+CONFIGURE_CFLAGS="-fno-pie $CONFIGURE_CFLAGS"
+CONFIGURE_LDFLAGS="-no-pie $CONFIGURE_LDFLAGS"
+  fi
 elif compile_prog "-Werror -fPIE -DPIE" "-pie"; then
   CONFIGURE_CFLAGS="-fPIE -DPIE $CONFIGURE_CFLAGS"
   CONFIGURE_LDFLAGS="-pie $CONFIGURE_LDFLAGS"
-- 
2.36.1




Re: [PATCH 3/5] tests/vm: use 'cp' instead of 'ln' for temporary vm images

2022-06-14 Thread John Snow
On Tue, Jun 14, 2022 at 12:40 AM Thomas Huth  wrote:
>
> On 14/06/2022 03.50, John Snow wrote:
> > If the initial setup fails, you've permanently altered the state of the
> > downloaded image in an unknowable way. Use 'cp' like our other test
> > setup scripts do.
> >
> > Signed-off-by: John Snow 
> > ---
> >   tests/vm/centos | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/vm/centos b/tests/vm/centos
> > index 5c7bc1c1a9a..be4f6ff2f14 100755
> > --- a/tests/vm/centos
> > +++ b/tests/vm/centos
> > @@ -34,7 +34,7 @@ class CentosVM(basevm.BaseVM):
> >   def build_image(self, img):
> >   cimg = 
> > self._download_with_cache("https://cloud.centos.org/centos/8/x86_64/images/CentOS-8-GenericCloud-8.3.2011-20201204.2.x86_64.qcow2";)
> >   img_tmp = img + ".tmp"
> > -subprocess.check_call(["ln", "-f", cimg, img_tmp])
> > +subprocess.check_call(['cp', '-f', cimg, img_tmp])
>
> I wonder whether it would make sense to use "qemu-img create -b" instead to
> save some disk space?
>
> Anyway, your patch is certainly already an improvement, so:
>
> Reviewed-by: Thomas Huth 

I wondered the same, but decided to keep a smaller series this time
around. VM tests already use a lot of space, so I doubt this is adding
new constraints that didn't exist before. A more rigorous overhaul may
be in order, but not right now. (It looks like the config file stuff
to override defaults is not necessarily rigorously respected by the
different installer recipes.)

I think the caching of the fully set-up image needs work, too. In
practice we leave the image sitting around, but we seem to always
rebuild it no matter what, so it's not that useful. There's a few
things that can be done here to drastically speed up some things,
but... later.

--js




Re: [PATCH 4/5] tests/vm: switch CentOS 8 to CentOS 8 Stream

2022-06-14 Thread John Snow
On Tue, Jun 14, 2022 at 5:09 AM Daniel P. Berrangé  wrote:
>
> On Mon, Jun 13, 2022 at 09:50:43PM -0400, John Snow wrote:
> > The old CentOS image didn't work anymore because it was already EOL at
> > the beginning of 2022.
> >
> > Signed-off-by: John Snow 
> > ---
> >  tests/vm/centos | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tests/vm/centos b/tests/vm/centos
> > index be4f6ff2f14..f5bbdecf62d 100755
> > --- a/tests/vm/centos
> > +++ b/tests/vm/centos
> > @@ -1,8 +1,8 @@
> >  #!/usr/bin/env python3
> >  #
> > -# CentOS image
> > +# CentOS 8 Stream image
> >  #
> > -# Copyright 2018 Red Hat Inc.
> > +# Copyright 2018, 2022 Red Hat Inc.
> >  #
> >  # Authors:
> >  #  Fam Zheng 
> > @@ -18,7 +18,7 @@ import basevm
> >  import time
> >
> >  class CentosVM(basevm.BaseVM):
> > -name = "centos"
> > +name = "centos8s"
>
>
> What's the effect of this ?  It feels a little odd to set name to 'centos8s'
> here but have this file still called just 'centos' - I assume the 'name'
> variable was intended to always match the filename
>

Changes the logfile names in ~/.cache/qemu-vm, changes the hostname
config in gen_cloud_init_iso(), not much else.

You're right, though, I shouldn't change it in one place but not the
other ... I'll just leave it as "centos". I felt compelled briefly to
indicate it was "the newer, different CentOS" but with the old one
being EOL I suppose it's easy enough to infer.

--js




  1   2   >