Re: [RFC QEMU PATCH v9 2/2] virtio-pci: implement No_Soft_Reset bit

[Yan Vugenfirer]

On Wed, Apr 17, 2024 at 6:13 AM Chen, Jiqian  wrote:
>
> On 2024/4/16 23:45, Igor Mammedov wrote:
> > On Tue, 16 Apr 2024 15:01:27 +0800
> > Jiqian Chen  wrote:
> >
> >> In current code, when guest does S3, virtio-gpu are reset due to the
> >> bit No_Soft_Reset is not set. After resetting, the display resources
> >> of virtio-gpu are destroyed, then the display can't come back and only
> >> show blank after resuming.
> >
> > Just a high level question.
> > Typically when system goes into S3 all devices (modulo RAM) loose context
> > (aka powered off), and then it's upto device driver to recover whatever
> > was lost.
> No, what you said is just one situation that when system goes into S3 devices 
> loose context and fully reinitialized and be D0-uninitialized state.
> The other situation is the context must be maintained so that the devices can 
> quickly be D0-active state after resuming.
> There are some descriptions in PCIe specification in Chapter 5.3.1.4 D3 state:
> " Functional context is required to be maintained by Functions in the D3Hot 
> state if the No_Soft_Reset field in the PMCSR is
> Set. In this case, System Software is not required to re-initialize the 
> Function after a transition from D3Hot to D0 (the
> Function will be in the D0active state). If the No_Soft_Reset bit is Clear, 
> functional context is not required to be
> maintained by the Function in the D3Hot state, however it is not guaranteed 
> that functional context will be cleared and
> software must not depend on such behavior. As a result, in this case System 
> Software is required to fully re-initialize the
> Function after a transition to D0 as the Function will be in the 
> D0uninitialized state."
>
BTW: according to Windows documentation D3 Hot state implementation is
a must for real HW devices.
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/device-sleeping-states
"Device power states D1, D2, and D3 are the device low-power states.
Starting with Windows 8, D3 is divided into two substates, D3hot and
D3cold.

D1 and D2 are intermediate low-power states. Many classes of devices
do not define these states. All devices must define D3hot."

Best regards,
Yan.


> What's more, not all virtio devices' context can be recovered by driver after 
> resuming, like virtio-gpu, we have not enough information to re-create all
> display resources, that is discussed in my previous version email thread.
>
> > So why should we implement hw(qemu) workaround for a driver problem?
> I think this is not a workaround, No_Soft_Reset bit is also described in PCIe 
> specification, it can be set or not.
> And we can set this bit for the specific device which we want to maintain 
> context during S3.
>
> >
> >>
> >> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> >> this bit, if this bit is set, the devices resetting will not be done, and
> >> then the display can work after resuming.
> >>
> >> No_Soft_Reset bit is implemented for all virtio devices, and was tested
> >> only on virtio-gpu device. Set it false by default for safety.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >>  hw/virtio/virtio-pci.c | 37 ++
> >>  include/hw/virtio/virtio-pci.h |  5 +
> >>  2 files changed, 42 insertions(+)
> >>
> >> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> >> index a1b61308e7a0..82fa4defe5cd 100644
> >> --- a/hw/virtio/virtio-pci.c
> >> +++ b/hw/virtio/virtio-pci.c
> >> @@ -2230,6 +2230,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> >> Error **errp)
> >>  pcie_cap_lnkctl_init(pci_dev);
> >>  }
> >>
> >> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> >> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> >> + PCI_PM_CTRL_NO_SOFT_RESET);
> >> +}
> >> +
> >>  if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> >>  /* Init Power Management Control Register */
> >>  pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
> >> @@ -2292,11 +2297,37 @@ static void virtio_pci_reset(DeviceState *qdev)
> >>  }
> >>  }
> >>
> >> +static bool virtio_pci_no_soft_reset(PCIDevice *dev)
> >> +{
> >> +uint16_t pmcsr;
> >> +
> >> +if (!pci_is_express(dev) || !dev->exp.pm_cap) {
> >> +return false;
> >> +}
> >> +
> >> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> >> +
> >> +/*
> >> + * When No_Soft_Reset bit is set and the device
> >> + * is in D3hot state, don't reset device
> >> + */
> >> +return (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> >> +   (pmcsr & PCI_PM_CTRL_STATE_MASK) == 3;
> >> +}
> >> +
> >>  static void virtio_pci_bus_reset_hold(Object *obj)
> >>  {
> >>  PCIDevice *dev = PCI_DEVICE(obj);
> >>  DeviceState *qdev = DEVICE(obj);
> >>
> >> +/*
> >> + * Note that: a proposal to add SUSPEND bit is being discussed,
> >> + * may need to consider 

Re: Intention to work on GSoC project

[Sahil]

Hi,

Thank you for your reply.

On Tuesday, April 16, 2024 2:11:16 PM IST Eugenio Perez Martin wrote:
> [...]
> > After re-reading the linked articles, I think I have got some more
> > clarity. One confusion was related to the difference between vdpa
> > and vhost-vdpa.
> > 
> > So far what I have understood is that L0 acts as the host and L1
> > acts as the guest in this setup. I understand that the guest can't
> > see the vDPA device.
> > 
> > I now also understand that vdpa_sim is not a PCI device. I am also
> > under the impression that vdpa refers to the vdpa bus while
> > vhost-vdpa is the device. Is my understanding correct?
> > 
> > After running the commands in the blog [1], I see that there's a
> > vhost-vdpa-0 device under /dev.
> > 
> > I also have an entry "vdpa0" under /sys/bus/vdpa/devices/ which
> > is a symlink to /sys/devices/vdpa0. There's a dir "vhost-vdpa-0"
> > under "/sys/devices/vdpa0". Hypothetically, if vhost-vdpa-0 had
> > been a PCI device, then it would have been present under
> > /sys/bus/pci/devices, right?
> 
> Right. You'll check that scenario with the vp_vdpa one.
> 
> > Another source of confusion was the pci.0 option passed to the
> > qemu-kvm command. But I have understood this as well now:
> > "-device virtio-net-pci" is a pci device.
> > 
> > > > There's one more thing. In "use case 1" of "Running traffic with
> > > > vhost_vdpa in Guest" [1], running "modprobe pktgen" in the L1 VM
> > > > 
> > > > gives an error:
> > > > > module pktgen couldn't be found in
> > > > > /lib/modules/6.5.6-300.fc39.x86_64.
> > > > 
> > > > The kernel version is 6.5.6-300.fc39.x86_64. I haven't tried building
> > > > pktgen manually in L1. I'll try that and will check if vdpa_sim works
> > > > as expected after that.
> > > 
> > > Did you install kernel-modules-internal?
> > 
> > I just realized I had the wrong version of kernel-modules-internal
> > installed. It works after installing the right version.
> 
> Good! So you can move to vp_vdpa, or do you have more doubts
> about vdpa_sim?

I am ready to move on to vp_vdpa. I don't have any more doubts about
vdpa_sim as of now.

Thanks,
Sahil

RE: [PATCH v2 02/10] vfio: Introduce HIODLegacyVFIO device

[Duan, Zhenzhong]

>-Original Message-
>From: Cédric Le Goater 
>Subject: Re: [PATCH v2 02/10] vfio: Introduce HIODLegacyVFIO device
>
>Hello,
>
>On 4/16/24 05:41, Duan, Zhenzhong wrote:
>> Hi Cédric,
>>
>>> -Original Message-
>>> From: Cédric Le Goater 
>>> Subject: Re: [PATCH v2 02/10] vfio: Introduce HIODLegacyVFIO device
>>>
>>> On 4/8/24 10:12, Zhenzhong Duan wrote:
 HIODLegacyVFIO represents a host IOMMU device under VFIO legacy
 container backend.

 It includes a link to VFIODevice.

 Suggested-by: Eric Auger 
 Suggested-by: Cédric Le Goater 
 Signed-off-by: Zhenzhong Duan 
 ---
include/hw/vfio/vfio-common.h | 11 +++
hw/vfio/container.c   | 11 ++-
2 files changed, 21 insertions(+), 1 deletion(-)

 diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-
>>> common.h
 index b9da6c08ef..f30772f534 100644
 --- a/include/hw/vfio/vfio-common.h
 +++ b/include/hw/vfio/vfio-common.h
 @@ -31,6 +31,7 @@
#endif
#include "sysemu/sysemu.h"
#include "hw/vfio/vfio-container-base.h"
 +#include "sysemu/host_iommu_device.h"

#define VFIO_MSG_PREFIX "vfio %s: "

 @@ -147,6 +148,16 @@ typedef struct VFIOGroup {
bool ram_block_discard_allowed;
} VFIOGroup;

 +#define TYPE_HIOD_LEGACY_VFIO TYPE_HOST_IOMMU_DEVICE "-
>legacy-
>>> vfio"
>>>
>>> I would prefer to keep the prefix TYPE_HOST_IOMMU_DEVICE.
>>
>> Will do.
>>
>>>
 +OBJECT_DECLARE_SIMPLE_TYPE(HIODLegacyVFIO, HIOD_LEGACY_VFIO)
 +
 +/* Abstraction of VFIO legacy host IOMMU device */
 +struct HIODLegacyVFIO {
>>>
>>> same here
>>
>> Should I do the same for all the HostIOMMUDevice and
>HostIOMMUDeviceClass sub-structures?
>
>I would for type names. The main reason is for naming consistency, which is
>useful for grep and code analysis.

Got it.

>
>>
>> The reason I used 'HIOD' abbreviation is some function names become
>extremely long
>> and exceed 80 characters. E.g.:
>>
>> @@ -1148,9 +1148,9 @@ static void
>vfio_iommu_legacy_class_init(ObjectClass *klass, void *data)
>>   vioc->pci_hot_reset = vfio_legacy_pci_hot_reset;
>>   };
>>
>> -static int hiod_legacy_vfio_get_host_iommu_info(HostIOMMUDevice
>*hiod,
>> -void *data, uint32_t len,
>> -Error **errp)
>> +static int
>host_iommu_device_legacy_vfio_get_host_iommu_info(HostIOMMUDevice
>*hiod,
>> + void *data, 
>> uint32_t len,
>> + Error **errp)
>>   {
>>   VFIODevice *vbasedev = HIOD_LEGACY_VFIO(hiod)->vdev;
>>   /* iova_ranges is a sorted list */
>> @@ -1173,7 +1173,7 @@ static void
>hiod_legacy_vfio_class_init(ObjectClass *oc, void *data)
>>   {
>>   HostIOMMUDeviceClass *hioc = HOST_IOMMU_DEVICE_CLASS(oc);
>>
>> -hioc->get_host_iommu_info = hiod_legacy_vfio_get_host_iommu_info;
>> +hioc->get_host_iommu_info =
>host_iommu_device_legacy_vfio_get_host_iommu_info;
>>   };
>>
>> I didn't find other way to make it meet the 80 chars limitation. Any
>suggestions on this?
>
>Try :
>
>@@ -1177,7 +1177,8 @@ static void hiod_legacy_vfio_class_init(
>  {
>  HostIOMMUDeviceClass *hioc = HOST_IOMMU_DEVICE_CLASS(oc);
>
>-hioc->get_host_iommu_info = hiod_legacy_vfio_get_host_iommu_info;
>+hioc->get_host_iommu_info =
>+host_iommu_device_legacy_vfio_get_host_iommu_info;
>  };
>
>  static const TypeInfo types[] = {
>
>That said, I agree that 'host_iommu_device_legacy_vfio' routine prefix
>could be shortened to 'hiod_legacy_vfio'.

Got it.

Thanks
Zhenzhong

RE: [PATCH v2 3/5] intel_iommu: Add a framework to do compatibility check with host IOMMU cap/ecap

[Duan, Zhenzhong]

>-Original Message-
>From: Cédric Le Goater 
>Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
>compatibility check with host IOMMU cap/ecap
>
>Hello,
>
>On 4/16/24 09:09, Duan, Zhenzhong wrote:
>> Hi Cédric,
>>
>>> -Original Message-
>>> From: Cédric Le Goater 
>>> Subject: Re: [PATCH v2 3/5] intel_iommu: Add a framework to do
>>> compatibility check with host IOMMU cap/ecap
>>>
>>> On 4/8/24 10:44, Zhenzhong Duan wrote:
 From: Yi Liu 

 If check fails, the host side device(either vfio or vdpa device) should not
 be passed to guest.

 Implementation details for different backends will be in following
>patches.

 Signed-off-by: Yi Liu 
 Signed-off-by: Yi Sun 
 Signed-off-by: Zhenzhong Duan 
 ---
hw/i386/intel_iommu.c | 35
>>> +++
1 file changed, 35 insertions(+)

 diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
 index 4f84e2e801..a49b587c73 100644
 --- a/hw/i386/intel_iommu.c
 +++ b/hw/i386/intel_iommu.c
 @@ -35,6 +35,7 @@
#include "sysemu/kvm.h"
#include "sysemu/dma.h"
#include "sysemu/sysemu.h"
 +#include "sysemu/iommufd.h"
#include "hw/i386/apic_internal.h"
#include "kvm/kvm_i386.h"
#include "migration/vmstate.h"
 @@ -3819,6 +3820,32 @@ VTDAddressSpace
>>> *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus,
return vtd_dev_as;
}

 +static int vtd_check_legacy_hdev(IntelIOMMUState *s,
 + HostIOMMUDevice *hiod,
 + Error **errp)
 +{
 +return 0;
 +}
 +
 +static int vtd_check_iommufd_hdev(IntelIOMMUState *s,
 +  HostIOMMUDevice *hiod,
 +  Error **errp)
 +{
 +return 0;
 +}
 +
 +static int vtd_check_hdev(IntelIOMMUState *s,
>VTDHostIOMMUDevice
>>> *vtd_hdev,
 +  Error **errp)
 +{
 +HostIOMMUDevice *hiod = vtd_hdev->dev;
 +
 +if (object_dynamic_cast(OBJECT(hiod), TYPE_HIOD_IOMMUFD)) {
 +return vtd_check_iommufd_hdev(s, hiod, errp);
 +}
 +
 +return vtd_check_legacy_hdev(s, hiod, errp);
 +}
>>>
>>>
>>> I think we should be using the .get_host_iommu_info() class handler
>>> instead. Can we refactor the code slightly to avoid this check on
>>> the type ?
>>
>> There is some difficulty ini avoiding this check, the behavior of
>vtd_check_legacy_hdev
>> and vtd_check_iommufd_hdev are different especially after nesting
>support introduced.
>> vtd_check_iommufd_hdev() has much wider check over cap/ecap bits
>besides aw_bits.
>
>I think it is important to fully separate the vIOMMU model from the
>host IOMMU backing device. Could we introduce a new
>HostIOMMUDeviceClass
>handler .check_hdev() handler, which would call .get_host_iommu_info() ?

Understood, besides the new .check_hdev() handler, I think we also need a new 
interface
class TYPE_IOMMU_CHECK_HDEV which has two handlers 
check_[legacy|iommufd]_hdev(),
and different vIOMMUs have different implementation.

Then legacy and iommufd host device have different implementation of 
.check_hdev()
and calls into one of the two interface handlers.

Let me know if I misunderstand any of your point.

Thanks
Zhenzhong

>
>
>Thanks,
>
>C.
>
>
>> That the reason I have two functions to do different thing.
>> See:
>>
>https://github.com/yiliu1765/qemu/blob/zhenzhong/iommufd_nesting_rfc
>v2/hw/i386/intel_iommu.c#L5472
>>
>> Meanwhile in vtd_check_legacy_hdev(), when legacy VFIO device attaches
>to modern vIOMMU,
>> this is unsupported and error out early, it will not
>call .get_host_iommu_info().
>> I mean we don't need to unconditionally call .get_host_iommu_info() in
>some cases.
>>
>> Thanks
>> Zhenzhong

Re: [PATCH v9 13/20] virtio-net: Return an error when vhost cannot enable RSS

[Jason Wang]

On Tue, Apr 16, 2024 at 5:51 PM Yuri Benditovich
 wrote:
>
> On Tue, Apr 16, 2024 at 10:14 AM Jason Wang  wrote:
> >
> > On Tue, Apr 16, 2024 at 1:43 PM Yuri Benditovich
> >  wrote:
> > >
> > > On Tue, Apr 16, 2024 at 7:00 AM Jason Wang  wrote:
> > > >
> > > > On Mon, Apr 15, 2024 at 10:05 PM Yuri Benditovich
> > > >  wrote:
> > > > >
> > > > > On Wed, Apr 3, 2024 at 2:11 PM Akihiko Odaki 
> > > > >  wrote:
> > > > > >
> > > > > > vhost requires eBPF for RSS. When eBPF is not available, virtio-net
> > > > > > implicitly disables RSS even if the user explicitly requests it. 
> > > > > > Return
> > > > > > an error instead of implicitly disabling RSS if RSS is requested 
> > > > > > but not
> > > > > > available.
> > > > > >
> > > > > > Signed-off-by: Akihiko Odaki 
> > > > > > ---
> > > > > >  hw/net/virtio-net.c | 97 
> > > > > > ++---
> > > > > >  1 file changed, 48 insertions(+), 49 deletions(-)
> > > > > >
> > > > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > > > > index 61b49e335dea..3d53eba88cfc 100644
> > > > > > --- a/hw/net/virtio-net.c
> > > > > > +++ b/hw/net/virtio-net.c
> > > > > > @@ -793,9 +793,6 @@ static uint64_t 
> > > > > > virtio_net_get_features(VirtIODevice *vdev, uint64_t features,
> > > > > >  return features;
> > > > > >  }
> > > > > >
> > > > > > -if (!ebpf_rss_is_loaded(>ebpf_rss)) {
> > > > > > -virtio_clear_feature(, VIRTIO_NET_F_RSS);
> > > > > > -}
> > > > > >  features = vhost_net_get_features(get_vhost_net(nc->peer), 
> > > > > > features);
> > > > > >  vdev->backend_features = features;
> > > > > >
> > > > > > @@ -3591,6 +3588,50 @@ static bool 
> > > > > > failover_hide_primary_device(DeviceListener *listener,
> > > > > >  return qatomic_read(>failover_primary_hidden);
> > > > > >  }
> > > > > >
> > > > > > +static void virtio_net_device_unrealize(DeviceState *dev)
> > > > > > +{
> > > > > > +VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> > > > > > +VirtIONet *n = VIRTIO_NET(dev);
> > > > > > +int i, max_queue_pairs;
> > > > > > +
> > > > > > +if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
> > > > > > +virtio_net_unload_ebpf(n);
> > > > > > +}
> > > > > > +
> > > > > > +/* This will stop vhost backend if appropriate. */
> > > > > > +virtio_net_set_status(vdev, 0);
> > > > > > +
> > > > > > +g_free(n->netclient_name);
> > > > > > +n->netclient_name = NULL;
> > > > > > +g_free(n->netclient_type);
> > > > > > +n->netclient_type = NULL;
> > > > > > +
> > > > > > +g_free(n->mac_table.macs);
> > > > > > +g_free(n->vlans);
> > > > > > +
> > > > > > +if (n->failover) {
> > > > > > +qobject_unref(n->primary_opts);
> > > > > > +device_listener_unregister(>primary_listener);
> > > > > > +migration_remove_notifier(>migration_state);
> > > > > > +} else {
> > > > > > +assert(n->primary_opts == NULL);
> > > > > > +}
> > > > > > +
> > > > > > +max_queue_pairs = n->multiqueue ? n->max_queue_pairs : 1;
> > > > > > +for (i = 0; i < max_queue_pairs; i++) {
> > > > > > +virtio_net_del_queue(n, i);
> > > > > > +}
> > > > > > +/* delete also control vq */
> > > > > > +virtio_del_queue(vdev, max_queue_pairs * 2);
> > > > > > +qemu_announce_timer_del(>announce_timer, false);
> > > > > > +g_free(n->vqs);
> > > > > > +qemu_del_nic(n->nic);
> > > > > > +virtio_net_rsc_cleanup(n);
> > > > > > +g_free(n->rss_data.indirections_table);
> > > > > > +net_rx_pkt_uninit(n->rx_pkt);
> > > > > > +virtio_cleanup(vdev);
> > > > > > +}
> > > > > > +
> > > > > >  static void virtio_net_device_realize(DeviceState *dev, Error 
> > > > > > **errp)
> > > > > >  {
> > > > > >  VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> > > > > > @@ -3760,53 +3801,11 @@ static void 
> > > > > > virtio_net_device_realize(DeviceState *dev, Error **errp)
> > > > > >
> > > > > >  net_rx_pkt_init(>rx_pkt);
> > > > > >
> > > > > > -if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
> > > > > > -virtio_net_load_ebpf(n);
> > > > > > -}
> > > > > > -}
> > > > > > -
> > > > > > -static void virtio_net_device_unrealize(DeviceState *dev)
> > > > > > -{
> > > > > > -VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> > > > > > -VirtIONet *n = VIRTIO_NET(dev);
> > > > > > -int i, max_queue_pairs;
> > > > > > -
> > > > > > -if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
> > > > > > -virtio_net_unload_ebpf(n);
> > > > > > +if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS) &&
> > > > > > +!virtio_net_load_ebpf(n) && get_vhost_net(nc->peer)) {
> > > > > > +virtio_net_device_unrealize(dev);
> > > > > > +error_setg(errp, "Can't load eBPF RSS for vhost");
> > > > > >  }
> > > > >
> > > > > As I already mentioned, I think this is an extremely bad idea to
> > > > > fail to run 

[PATCH v6 2/3] ui/console: Introduce dpy_gl_qemu_dmabuf_set_..() helpers

[dongwon . kim]

From: Dongwon Kim 

To enhance security in accessing the QemuDmaBuf struct, new helper
functions for setting specific fields within the struct were introduced.
And all occurrences where these fields were previously set directly
have been updated to utilize these helper functions.

Suggested-by: Marc-André Lureau 
Cc: Philippe Mathieu-Daudé 
Cc: Vivek Kasireddy 
Signed-off-by: Dongwon Kim 
---
 include/ui/console.h |  5 +
 ui/console.c | 30 ++
 ui/egl-helpers.c | 16 +---
 ui/gtk-egl.c |  4 ++--
 ui/gtk-gl-area.c |  4 ++--
 ui/gtk.c |  2 +-
 6 files changed, 49 insertions(+), 12 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index 6292943a82..3d9d8b9fce 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -375,6 +375,11 @@ void *dpy_gl_qemu_dmabuf_get_sync(QemuDmaBuf *dmabuf);
 int32_t dpy_gl_qemu_dmabuf_get_fence_fd(QemuDmaBuf *dmabuf);
 bool dpy_gl_qemu_dmabuf_get_allow_fences(QemuDmaBuf *dmabuf);
 bool dpy_gl_qemu_dmabuf_get_draw_submitted(QemuDmaBuf *dmabuf);
+void dpy_gl_qemu_dmabuf_set_texture(QemuDmaBuf *dmabuf, uint32_t texture);
+void dpy_gl_qemu_dmabuf_set_fence_fd(QemuDmaBuf *dmabuf, int32_t fence_fd);
+void dpy_gl_qemu_dmabuf_set_sync(QemuDmaBuf *dmabuf, void *sync);
+void dpy_gl_qemu_dmabuf_set_draw_submitted(QemuDmaBuf *dmabuf, bool 
draw_submitted);
+void dpy_gl_qemu_dmabuf_set_fd(QemuDmaBuf *dmabuf, int32_t fd);
 void dpy_gl_release_dmabuf(QemuConsole *con,
QemuDmaBuf *dmabuf);
 void dpy_gl_update(QemuConsole *con,
diff --git a/ui/console.c b/ui/console.c
index 5d5635f783..d4ca9e6e0f 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1244,6 +1244,36 @@ bool dpy_gl_qemu_dmabuf_get_draw_submitted(QemuDmaBuf 
*dmabuf)
 return dmabuf->draw_submitted;
 }
 
+void dpy_gl_qemu_dmabuf_set_texture(QemuDmaBuf *dmabuf, uint32_t texture)
+{
+assert(dmabuf != NULL);
+dmabuf->texture = texture;
+}
+
+void dpy_gl_qemu_dmabuf_set_fence_fd(QemuDmaBuf *dmabuf, int32_t fence_fd)
+{
+assert(dmabuf != NULL);
+dmabuf->fence_fd = fence_fd;
+}
+
+void dpy_gl_qemu_dmabuf_set_sync(QemuDmaBuf *dmabuf, void *sync)
+{
+assert(dmabuf != NULL);
+dmabuf->sync = sync;
+}
+
+void dpy_gl_qemu_dmabuf_set_draw_submitted(QemuDmaBuf *dmabuf, bool 
draw_submitted)
+{
+assert(dmabuf != NULL);
+dmabuf->draw_submitted = draw_submitted;
+}
+
+void dpy_gl_qemu_dmabuf_set_fd(QemuDmaBuf *dmabuf, int32_t fd)
+{
+assert(dmabuf != NULL);
+dmabuf->fd = fd;
+}
+
 void dpy_gl_release_dmabuf(QemuConsole *con,
   QemuDmaBuf *dmabuf)
 {
diff --git a/ui/egl-helpers.c b/ui/egl-helpers.c
index 86d64c68ce..c71a2878c2 100644
--- a/ui/egl-helpers.c
+++ b/ui/egl-helpers.c
@@ -348,8 +348,8 @@ void egl_dmabuf_import_texture(QemuDmaBuf *dmabuf)
 return;
 }
 
-glGenTextures(1, >texture);
-texture = dpy_gl_qemu_dmabuf_get_texture(dmabuf);
+glGenTextures(1, );
+dpy_gl_qemu_dmabuf_set_texture(dmabuf, texture);
 glBindTexture(GL_TEXTURE_2D, texture);
 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
@@ -368,7 +368,7 @@ void egl_dmabuf_release_texture(QemuDmaBuf *dmabuf)
 }
 
 glDeleteTextures(1, );
-dmabuf->texture = 0;
+dpy_gl_qemu_dmabuf_set_texture(dmabuf, 0);
 }
 
 void egl_dmabuf_create_sync(QemuDmaBuf *dmabuf)
@@ -382,7 +382,7 @@ void egl_dmabuf_create_sync(QemuDmaBuf *dmabuf)
 sync = eglCreateSyncKHR(qemu_egl_display,
 EGL_SYNC_NATIVE_FENCE_ANDROID, NULL);
 if (sync != EGL_NO_SYNC_KHR) {
-dmabuf->sync = sync;
+dpy_gl_qemu_dmabuf_set_sync(dmabuf, sync);
 }
 }
 }
@@ -390,12 +390,14 @@ void egl_dmabuf_create_sync(QemuDmaBuf *dmabuf)
 void egl_dmabuf_create_fence(QemuDmaBuf *dmabuf)
 {
 void *sync = dpy_gl_qemu_dmabuf_get_sync(dmabuf);
+int fence_fd;
 
 if (sync) {
-dmabuf->fence_fd = eglDupNativeFenceFDANDROID(qemu_egl_display,
-  sync);
+fence_fd = eglDupNativeFenceFDANDROID(qemu_egl_display,
+  sync);
+dpy_gl_qemu_dmabuf_set_fence_fd(dmabuf, fence_fd);
 eglDestroySyncKHR(qemu_egl_display, sync);
-dmabuf->sync = NULL;
+dpy_gl_qemu_dmabuf_set_sync(dmabuf, NULL);
 }
 }
 
diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index c9469af9ed..7494a34d7c 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -87,7 +87,7 @@ void gd_egl_draw(VirtualConsole *vc)
 if (!dpy_gl_qemu_dmabuf_get_draw_submitted(dmabuf)) {
 return;
 } else {
-dmabuf->draw_submitted = false;
+dpy_gl_qemu_dmabuf_set_draw_submitted(dmabuf, false);
 }
 }
 #endif
@@ -381,7 +381,7 @@ void gd_egl_flush(DisplayChangeListener *dcl,
 if 

[PATCH v6 0/3] ui/console: Private QemuDmaBuf struct

[dongwon . kim]

From: Dongwon Kim 

This series introduces privacy enhancements to the QemuDmaBuf struct
and its contained data to bolster security. it accomplishes this by
introducing of helper functions for allocating, deallocating, and
accessing individual fields within the struct and replacing all direct
references to individual fields in the struct with methods using helpers
throughout the codebase.

This change was made based on a suggestion from Marc-André Lureau


(Resumitting same patch series with this new cover-leter)

v6: fixed some typos in patch - 
ui/console: Introduce dpy_gl_qemu_dmabuf_get_..() helpers)

Dongwon Kim (3):
  ui/console: Introduce dpy_gl_qemu_dmabuf_get_..() helpers
  ui/console: Introduce dpy_gl_qemu_dmabuf_set_..() helpers
  ui/console: Introduce dpy_gl_qemu_dmabuf_new() and free() helpers

 include/hw/vfio/vfio-common.h   |   2 +-
 include/hw/virtio/virtio-gpu.h  |   4 +-
 include/ui/console.h|  28 +
 hw/display/vhost-user-gpu.c |  32 +++---
 hw/display/virtio-gpu-udmabuf.c |  27 ++---
 hw/vfio/display.c   |  35 ---
 ui/console.c| 180 +++-
 ui/dbus-console.c   |   9 +-
 ui/dbus-listener.c  |  71 +++--
 ui/egl-headless.c   |  23 ++--
 ui/egl-helpers.c|  59 ++-
 ui/gtk-egl.c|  52 +
 ui/gtk-gl-area.c|  41 +---
 ui/gtk.c|   8 +-
 ui/spice-display.c  |  50 +
 15 files changed, 449 insertions(+), 172 deletions(-)

-- 
2.34.1

[PATCH v6 3/3] ui/console: Introduce dpy_gl_qemu_dmabuf_new() and free() helpers

[dongwon . kim]

From: Dongwon Kim 

This commit introduces utility functions for the creation and deallocation
of QemuDmaBuf instances. Additionally, it updates all relevant sections
of the codebase to utilize these new utility functions.

Suggested-by: Marc-André Lureau 
Cc: Philippe Mathieu-Daudé 
Cc: Vivek Kasireddy 
Signed-off-by: Dongwon Kim 
---
 include/hw/vfio/vfio-common.h   |  2 +-
 include/hw/virtio/virtio-gpu.h  |  4 ++--
 include/ui/console.h|  8 +++-
 hw/display/vhost-user-gpu.c | 32 +--
 hw/display/virtio-gpu-udmabuf.c | 24 +--
 hw/vfio/display.c   | 26 -
 ui/console.c| 34 +
 ui/dbus-listener.c  | 28 ---
 8 files changed, 95 insertions(+), 63 deletions(-)

diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index b9da6c08ef..d66e27db02 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -148,7 +148,7 @@ typedef struct VFIOGroup {
 } VFIOGroup;
 
 typedef struct VFIODMABuf {
-QemuDmaBuf buf;
+QemuDmaBuf *buf;
 uint32_t pos_x, pos_y, pos_updates;
 uint32_t hot_x, hot_y, hot_updates;
 int dmabuf_id;
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index ed44cdad6b..56d6e821bf 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -169,7 +169,7 @@ struct VirtIOGPUBaseClass {
 DEFINE_PROP_UINT32("yres", _state, _conf.yres, 800)
 
 typedef struct VGPUDMABuf {
-QemuDmaBuf buf;
+QemuDmaBuf *buf;
 uint32_t scanout_id;
 QTAILQ_ENTRY(VGPUDMABuf) next;
 } VGPUDMABuf;
@@ -238,7 +238,7 @@ struct VhostUserGPU {
 VhostUserBackend *vhost;
 int vhost_gpu_fd; /* closed by the chardev */
 CharBackend vhost_chr;
-QemuDmaBuf dmabuf[VIRTIO_GPU_MAX_SCANOUTS];
+QemuDmaBuf *dmabuf[VIRTIO_GPU_MAX_SCANOUTS];
 bool backend_blocked;
 };
 
diff --git a/include/ui/console.h b/include/ui/console.h
index 3d9d8b9fce..6d7c03b7c5 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -358,7 +358,13 @@ void dpy_gl_cursor_dmabuf(QemuConsole *con, QemuDmaBuf 
*dmabuf,
   bool have_hot, uint32_t hot_x, uint32_t hot_y);
 void dpy_gl_cursor_position(QemuConsole *con,
 uint32_t pos_x, uint32_t pos_y);
-
+QemuDmaBuf *dpy_gl_qemu_dmabuf_new(uint32_t width, uint32_t height,
+   uint32_t stride, uint32_t x,
+   uint32_t y, uint32_t backing_width,
+   uint32_t backing_height, uint32_t fourcc,
+   uint64_t modifier, uint32_t dmabuf_fd,
+   bool allow_fences, bool y0_top);
+void dpy_gl_qemu_dmabuf_free(QemuDmaBuf *dmabuf);
 int32_t dpy_gl_qemu_dmabuf_get_fd(QemuDmaBuf *dmabuf);
 uint32_t dpy_gl_qemu_dmabuf_get_width(QemuDmaBuf *dmabuf);
 uint32_t dpy_gl_qemu_dmabuf_get_height(QemuDmaBuf *dmabuf);
diff --git a/hw/display/vhost-user-gpu.c b/hw/display/vhost-user-gpu.c
index 87dcfbca10..4d8461e94a 100644
--- a/hw/display/vhost-user-gpu.c
+++ b/hw/display/vhost-user-gpu.c
@@ -250,6 +250,7 @@ vhost_user_gpu_handle_display(VhostUserGPU *g, 
VhostUserGpuMsg *msg)
 VhostUserGpuDMABUFScanout *m = >payload.dmabuf_scanout;
 int fd = qemu_chr_fe_get_msgfd(>vhost_chr);
 int old_fd;
+uint64_t modifier = 0;
 QemuDmaBuf *dmabuf;
 
 if (m->scanout_id >= g->parent_obj.conf.max_outputs) {
@@ -262,31 +263,34 @@ vhost_user_gpu_handle_display(VhostUserGPU *g, 
VhostUserGpuMsg *msg)
 
 g->parent_obj.enable = 1;
 con = g->parent_obj.scanout[m->scanout_id].con;
-dmabuf = >dmabuf[m->scanout_id];
-old_fd = dpy_gl_qemu_dmabuf_get_fd(dmabuf);
-if (old_fd >= 0) {
-close(old_fd);
-dmabuf->fd = -1;
+dmabuf = g->dmabuf[m->scanout_id];
+if (dmabuf) {
+old_fd = dpy_gl_qemu_dmabuf_get_fd(dmabuf);
+if (old_fd >= 0) {
+close(old_fd);
+dpy_gl_qemu_dmabuf_set_fd(dmabuf, -1);
+}
 }
 dpy_gl_release_dmabuf(con, dmabuf);
+g_clear_pointer(, dpy_gl_qemu_dmabuf_free);
 if (fd == -1) {
 dpy_gl_scanout_disable(con);
 break;
 }
-*dmabuf = (QemuDmaBuf) {
-.fd = fd,
-.width = m->fd_width,
-.height = m->fd_height,
-.stride = m->fd_stride,
-.fourcc = m->fd_drm_fourcc,
-.y0_top = m->fd_flags & VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP,
-};
+
 if (msg->request == VHOST_USER_GPU_DMABUF_SCANOUT2) {
 VhostUserGpuDMABUFScanout2 *m2 = >payload.dmabuf_scanout2;
-dmabuf->modifier = m2->modifier;
+modifier = m2->modifier;
 }
 
+dmabuf = 

[PATCH v6 1/3] ui/console: Introduce dpy_gl_qemu_dmabuf_get_..() helpers

[dongwon . kim]

From: Dongwon Kim 

This commit introduces dpy_gl_qemu_dmabuf_get_... helpers to extract
specific fields from the QemuDmaBuf struct. It also updates all instances
where fields within the QemuDmaBuf struct are directly accessed, replacing
them with calls to these new helper functions.

v6: fix typos in helper names in ui/spice-display.c

Suggested-by: Marc-André Lureau 
Cc: Philippe Mathieu-Daudé 
Cc: Vivek Kasireddy 
Signed-off-by: Dongwon Kim 
---
 include/ui/console.h|  17 +
 hw/display/vhost-user-gpu.c |   6 +-
 hw/display/virtio-gpu-udmabuf.c |   7 +-
 hw/vfio/display.c   |  15 +++--
 ui/console.c| 116 +++-
 ui/dbus-console.c   |   9 ++-
 ui/dbus-listener.c  |  43 +++-
 ui/egl-headless.c   |  23 +--
 ui/egl-helpers.c|  47 +++--
 ui/gtk-egl.c|  48 -
 ui/gtk-gl-area.c|  37 ++
 ui/gtk.c|   6 +-
 ui/spice-display.c  |  50 --
 13 files changed, 316 insertions(+), 108 deletions(-)

diff --git a/include/ui/console.h b/include/ui/console.h
index 0bc7a00ac0..6292943a82 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -358,6 +358,23 @@ void dpy_gl_cursor_dmabuf(QemuConsole *con, QemuDmaBuf 
*dmabuf,
   bool have_hot, uint32_t hot_x, uint32_t hot_y);
 void dpy_gl_cursor_position(QemuConsole *con,
 uint32_t pos_x, uint32_t pos_y);
+
+int32_t dpy_gl_qemu_dmabuf_get_fd(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_width(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_height(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_stride(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_fourcc(QemuDmaBuf *dmabuf);
+uint64_t dpy_gl_qemu_dmabuf_get_modifier(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_texture(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_x(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_y(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_backing_width(QemuDmaBuf *dmabuf);
+uint32_t dpy_gl_qemu_dmabuf_get_backing_height(QemuDmaBuf *dmabuf);
+bool dpy_gl_qemu_dmabuf_get_y0_top(QemuDmaBuf *dmabuf);
+void *dpy_gl_qemu_dmabuf_get_sync(QemuDmaBuf *dmabuf);
+int32_t dpy_gl_qemu_dmabuf_get_fence_fd(QemuDmaBuf *dmabuf);
+bool dpy_gl_qemu_dmabuf_get_allow_fences(QemuDmaBuf *dmabuf);
+bool dpy_gl_qemu_dmabuf_get_draw_submitted(QemuDmaBuf *dmabuf);
 void dpy_gl_release_dmabuf(QemuConsole *con,
QemuDmaBuf *dmabuf);
 void dpy_gl_update(QemuConsole *con,
diff --git a/hw/display/vhost-user-gpu.c b/hw/display/vhost-user-gpu.c
index 709c8a02a1..87dcfbca10 100644
--- a/hw/display/vhost-user-gpu.c
+++ b/hw/display/vhost-user-gpu.c
@@ -249,6 +249,7 @@ vhost_user_gpu_handle_display(VhostUserGPU *g, 
VhostUserGpuMsg *msg)
 case VHOST_USER_GPU_DMABUF_SCANOUT: {
 VhostUserGpuDMABUFScanout *m = >payload.dmabuf_scanout;
 int fd = qemu_chr_fe_get_msgfd(>vhost_chr);
+int old_fd;
 QemuDmaBuf *dmabuf;
 
 if (m->scanout_id >= g->parent_obj.conf.max_outputs) {
@@ -262,8 +263,9 @@ vhost_user_gpu_handle_display(VhostUserGPU *g, 
VhostUserGpuMsg *msg)
 g->parent_obj.enable = 1;
 con = g->parent_obj.scanout[m->scanout_id].con;
 dmabuf = >dmabuf[m->scanout_id];
-if (dmabuf->fd >= 0) {
-close(dmabuf->fd);
+old_fd = dpy_gl_qemu_dmabuf_get_fd(dmabuf);
+if (old_fd >= 0) {
+close(old_fd);
 dmabuf->fd = -1;
 }
 dpy_gl_release_dmabuf(con, dmabuf);
diff --git a/hw/display/virtio-gpu-udmabuf.c b/hw/display/virtio-gpu-udmabuf.c
index d51184d658..e3f358b575 100644
--- a/hw/display/virtio-gpu-udmabuf.c
+++ b/hw/display/virtio-gpu-udmabuf.c
@@ -206,6 +206,7 @@ int virtio_gpu_update_dmabuf(VirtIOGPU *g,
 {
 struct virtio_gpu_scanout *scanout = >parent_obj.scanout[scanout_id];
 VGPUDMABuf *new_primary, *old_primary = NULL;
+uint32_t width, height;
 
 new_primary = virtio_gpu_create_dmabuf(g, scanout_id, res, fb, r);
 if (!new_primary) {
@@ -216,10 +217,10 @@ int virtio_gpu_update_dmabuf(VirtIOGPU *g,
 old_primary = g->dmabuf.primary[scanout_id];
 }
 
+width = dpy_gl_qemu_dmabuf_get_width(_primary->buf);
+height = dpy_gl_qemu_dmabuf_get_height(_primary->buf);
 g->dmabuf.primary[scanout_id] = new_primary;
-qemu_console_resize(scanout->con,
-new_primary->buf.width,
-new_primary->buf.height);
+qemu_console_resize(scanout->con, width, height);
 dpy_gl_scanout_dmabuf(scanout->con, _primary->buf);
 
 if (old_primary) {
diff --git a/hw/vfio/display.c b/hw/vfio/display.c
index 1aa440c663..f9c39cbd51 100644
--- a/hw/vfio/display.c
+++ b/hw/vfio/display.c
@@ -259,9 +259,13 @@ static VFIODMABuf *vfio_display_get_dmabuf(VFIOPCIDevice 

Re: [RFC QEMU PATCH v9 2/2] virtio-pci: implement No_Soft_Reset bit

[Chen, Jiqian]

On 2024/4/16 23:45, Igor Mammedov wrote:
> On Tue, 16 Apr 2024 15:01:27 +0800
> Jiqian Chen  wrote:
> 
>> In current code, when guest does S3, virtio-gpu are reset due to the
>> bit No_Soft_Reset is not set. After resetting, the display resources
>> of virtio-gpu are destroyed, then the display can't come back and only
>> show blank after resuming.
> 
> Just a high level question.
> Typically when system goes into S3 all devices (modulo RAM) loose context
> (aka powered off), and then it's upto device driver to recover whatever
> was lost.
No, what you said is just one situation that when system goes into S3 devices 
loose context and fully reinitialized and be D0-uninitialized state.
The other situation is the context must be maintained so that the devices can 
quickly be D0-active state after resuming.
There are some descriptions in PCIe specification in Chapter 5.3.1.4 D3 state:
" Functional context is required to be maintained by Functions in the D3Hot 
state if the No_Soft_Reset field in the PMCSR is
Set. In this case, System Software is not required to re-initialize the 
Function after a transition from D3Hot to D0 (the
Function will be in the D0active state). If the No_Soft_Reset bit is Clear, 
functional context is not required to be
maintained by the Function in the D3Hot state, however it is not guaranteed 
that functional context will be cleared and
software must not depend on such behavior. As a result, in this case System 
Software is required to fully re-initialize the
Function after a transition to D0 as the Function will be in the 
D0uninitialized state."

What's more, not all virtio devices' context can be recovered by driver after 
resuming, like virtio-gpu, we have not enough information to re-create all
display resources, that is discussed in my previous version email thread.

> So why should we implement hw(qemu) workaround for a driver problem?
I think this is not a workaround, No_Soft_Reset bit is also described in PCIe 
specification, it can be set or not.
And we can set this bit for the specific device which we want to maintain 
context during S3.

> 
>>
>> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
>> this bit, if this bit is set, the devices resetting will not be done, and
>> then the display can work after resuming.
>>
>> No_Soft_Reset bit is implemented for all virtio devices, and was tested
>> only on virtio-gpu device. Set it false by default for safety.
>>
>> Signed-off-by: Jiqian Chen 
>> ---
>>  hw/virtio/virtio-pci.c | 37 ++
>>  include/hw/virtio/virtio-pci.h |  5 +
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
>> index a1b61308e7a0..82fa4defe5cd 100644
>> --- a/hw/virtio/virtio-pci.c
>> +++ b/hw/virtio/virtio-pci.c
>> @@ -2230,6 +2230,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
>> Error **errp)
>>  pcie_cap_lnkctl_init(pci_dev);
>>  }
>>  
>> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
>> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
>> + PCI_PM_CTRL_NO_SOFT_RESET);
>> +}
>> +
>>  if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
>>  /* Init Power Management Control Register */
>>  pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
>> @@ -2292,11 +2297,37 @@ static void virtio_pci_reset(DeviceState *qdev)
>>  }
>>  }
>>  
>> +static bool virtio_pci_no_soft_reset(PCIDevice *dev)
>> +{
>> +uint16_t pmcsr;
>> +
>> +if (!pci_is_express(dev) || !dev->exp.pm_cap) {
>> +return false;
>> +}
>> +
>> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
>> +
>> +/*
>> + * When No_Soft_Reset bit is set and the device
>> + * is in D3hot state, don't reset device
>> + */
>> +return (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
>> +   (pmcsr & PCI_PM_CTRL_STATE_MASK) == 3;
>> +}
>> +
>>  static void virtio_pci_bus_reset_hold(Object *obj)
>>  {
>>  PCIDevice *dev = PCI_DEVICE(obj);
>>  DeviceState *qdev = DEVICE(obj);
>>  
>> +/*
>> + * Note that: a proposal to add SUSPEND bit is being discussed,
>> + * may need to consider the state of SUSPEND bit in future
>> + */
>> +if (virtio_pci_no_soft_reset(dev)) {
>> +return;
>> +}
>> +
>>  virtio_pci_reset(qdev);
>>  
>>  if (pci_is_express(dev)) {
>> @@ -2336,6 +2367,12 @@ static Property virtio_pci_properties[] = {
>>  VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
>>  DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
>>  VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
>> +/*
>> + * for safety, set this false by default, if change it to true,
>> + * need to consider compatible for old machine
>> + */
>> +DEFINE_PROP_BIT("pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
>> +

Re: [PATCH] migration/colo: Fix bdrv_graph_rdlock_main_loop: Assertion `!qemu_in_coroutine()' failed.

[Zhijian Li (Fujitsu)]

On 17/04/2024 10:44, Li Zhijian wrote:
> bdrv_activate_all() should not be called from the coroutine context, move
> it to the QEMU thread colo_process_incoming_thread() with the bql_lock
> protected.
> 
> The backtrace is as follows:
>   #4  0x561af7948362 in bdrv_graph_rdlock_main_loop () at 
> ../block/graph-lock.c:260
>   #5  0x561af7907a68 in graph_lockable_auto_lock_mainloop 
> (x=0x7fd29810be7b) at /patch/to/qemu/include/block/graph-lock.h:259
>   #6  0x561af79167d1 in bdrv_activate_all (errp=0x7fd29810bed0) at 
> ../block.c:6906
>   #7  0x561af762b4af in colo_incoming_co () at ../migration/colo.c:935
>   #8  0x561af7607e57 in process_incoming_migration_co (opaque=0x0) at 
> ../migration/migration.c:793
>   #9  0x561af7adbeeb in coroutine_trampoline (i0=-106876144, i1=22042) at 
> ../util/coroutine-ucontext.c:175
>   #10 0x7fd2a5cf21c0 in  () at /lib64/libc.so.6
> 
> CC: Fabiano Rosas
> Closes:https://gitlab.com/qemu-project/qemu/-/issues/2277
> Fixes: 2b3912f135 ("block: Mark bdrv_first_blk() and bdrv_is_root_node() 
> GRAPH_RDLOCK")
> Signed-off-by: Li Zhijian
> ---
>   migration/colo.c | 17 +
>   1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/migration/colo.c b/migration/colo.c
> index 84632a603e..94942fba32 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -835,6 +835,15 @@ static void *colo_process_incoming_thread(void *opaque)
>   return NULL;
>   }
>   
> +/* Make sure all file formats throw away their mutable metadata */
> +bql_lock();
> +bdrv_activate_all(_err);
> +if (local_err) {

Here bql_unlock() is missing, posted V2 to fix it.

Thanks
Zhijian



> +error_report_err(local_err);
> +return NULL;
> +}
> +bql_unlock();
> +

[PATCH v2] migration/colo: Fix bdrv_graph_rdlock_main_loop: Assertion `!qemu_in_coroutine()' failed.

[Li Zhijian via]

bdrv_activate_all() should not be called from the coroutine context, move
it to the QEMU thread colo_process_incoming_thread() with the bql_lock
protected.

The backtrace is as follows:
 #4  0x561af7948362 in bdrv_graph_rdlock_main_loop () at 
../block/graph-lock.c:260
 #5  0x561af7907a68 in graph_lockable_auto_lock_mainloop (x=0x7fd29810be7b) 
at /patch/to/qemu/include/block/graph-lock.h:259
 #6  0x561af79167d1 in bdrv_activate_all (errp=0x7fd29810bed0) at 
../block.c:6906
 #7  0x561af762b4af in colo_incoming_co () at ../migration/colo.c:935
 #8  0x561af7607e57 in process_incoming_migration_co (opaque=0x0) at 
../migration/migration.c:793
 #9  0x561af7adbeeb in coroutine_trampoline (i0=-106876144, i1=22042) at 
../util/coroutine-ucontext.c:175
 #10 0x7fd2a5cf21c0 in  () at /lib64/libc.so.6

CC: Fabiano Rosas 
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2277
Fixes: 2b3912f135 ("block: Mark bdrv_first_blk() and bdrv_is_root_node() 
GRAPH_RDLOCK")
Signed-off-by: Li Zhijian 
---
V2: fix missing bql_unlock() in error path.
---
 migration/colo.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/migration/colo.c b/migration/colo.c
index 84632a603e..5600a43d78 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -835,6 +835,16 @@ static void *colo_process_incoming_thread(void *opaque)
 return NULL;
 }
 
+/* Make sure all file formats throw away their mutable metadata */
+bql_lock();
+bdrv_activate_all(_err);
+if (local_err) {
+bql_unlock();
+error_report_err(local_err);
+return NULL;
+}
+bql_unlock();
+
 failover_init_state();
 
 mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
@@ -922,7 +932,6 @@ out:
 int coroutine_fn colo_incoming_co(void)
 {
 MigrationIncomingState *mis = migration_incoming_get_current();
-Error *local_err = NULL;
 QemuThread th;
 
 assert(bql_locked());
@@ -931,13 +940,6 @@ int coroutine_fn colo_incoming_co(void)
 return 0;
 }
 
-/* Make sure all file formats throw away their mutable metadata */
-bdrv_activate_all(_err);
-if (local_err) {
-error_report_err(local_err);
-return -EINVAL;
-}
-
 qemu_thread_create(, "COLO incoming", colo_process_incoming_thread,
mis, QEMU_THREAD_JOINABLE);
 
-- 
2.31.1

Re: [PATCH v8] virtio-pci: fix use of a released vector

[Cindy Lu]

On Tue, Apr 16, 2024 at 11:21 AM Jason Wang  wrote:
>
> On Mon, Apr 15, 2024 at 6:41 PM Cindy Lu  wrote:
> >
> > On Mon, Apr 15, 2024 at 5:34 PM Michael S. Tsirkin  wrote:
> > >
> > > From: Cindy Lu 
> > >
> > > During the booting process of the non-standard image, the behavior of the
> > > called function in qemu is as follows:
> > >
> > > 1. vhost_net_stop() was triggered by guest image. This will call the 
> > > function
> > > virtio_pci_set_guest_notifiers() with assgin= false,
> > > virtio_pci_set_guest_notifiers(） will release the irqfd for vector 0
> > >
> > > 2. virtio_reset() was triggered, this will set configure vector to 
> > > VIRTIO_NO_VECTOR
> > >
> > > 3.vhost_net_start() was called (at this time, the configure vector is
> > > still VIRTIO_NO_VECTOR) and then call virtio_pci_set_guest_notifiers() 
> > > with
> > > assgin=true, so the irqfd for vector 0 is still not "init" during this 
> > > process
> > >
> > > 4. The system continues to boot and sets the vector back to 0. After that
> > > msix_fire_vector_notifier() was triggered to unmask the vector 0 and  
> > > meet the crash
> > >
> > > To fix the issue, we need to support changing the vector after 
> > > VIRTIO_CONFIG_S_DRIVER_OK is set.
> > >
> > > (gdb) bt
> > > 0  __pthread_kill_implementation (threadid=, 
> > > signo=signo@entry=6, no_tid=no_tid@entry=0)
> > > at pthread_kill.c:44
> > > 1  0x7fc87148ec53 in __pthread_kill_internal (signo=6, 
> > > threadid=) at pthread_kill.c:78
> > > 2  0x7fc87143e956 in __GI_raise (sig=sig@entry=6) at 
> > > ../sysdeps/posix/raise.c:26
> > > 3  0x7fc8714287f4 in __GI_abort () at abort.c:79
> > > 4  0x7fc87142871b in __assert_fail_base
> > > (fmt=0x7fc8715bbde0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
> > > assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d 
> > > "../accel/kvm/kvm-all.c", line=1837, function=) at 
> > > assert.c:92
> > > 5  0x7fc871437536 in __GI___assert_fail
> > > (assertion=0x5606413efd53 "ret == 0", file=0x5606413ef87d 
> > > "../accel/kvm/kvm-all.c", line=1837, function=0x5606413f06f0 
> > > <__PRETTY_FUNCTION__.19> "kvm_irqchip_commit_routes") at assert.c:101
> > > 6  0x560640f884b5 in kvm_irqchip_commit_routes (s=0x560642cae1f0) at 
> > > ../accel/kvm/kvm-all.c:1837
> > > 7  0x560640c98f8e in virtio_pci_one_vector_unmask
> > > (proxy=0x560643c65f00, queue_no=4294967295, vector=0, msg=..., 
> > > n=0x560643c6e4c8)
> > > at ../hw/virtio/virtio-pci.c:1005
> > > 8  0x560640c99201 in virtio_pci_vector_unmask (dev=0x560643c65f00, 
> > > vector=0, msg=...)
> > > at ../hw/virtio/virtio-pci.c:1070
> > > 9  0x560640bc402e in msix_fire_vector_notifier (dev=0x560643c65f00, 
> > > vector=0, is_masked=false)
> > > at ../hw/pci/msix.c:120
> > > 10 0x560640bc40f1 in msix_handle_mask_update (dev=0x560643c65f00, 
> > > vector=0, was_masked=true)
> > > at ../hw/pci/msix.c:140
> > > 11 0x560640bc4503 in msix_table_mmio_write (opaque=0x560643c65f00, 
> > > addr=12, val=0, size=4)
> > > at ../hw/pci/msix.c:231
> > > 12 0x560640f26d83 in memory_region_write_accessor
> > > (mr=0x560643c66540, addr=12, value=0x7fc86b7bc628, size=4, shift=0, 
> > > mask=4294967295, attrs=...)
> > > at ../system/memory.c:497
> > > 13 0x560640f270a6 in access_with_adjusted_size
> > >
> > >  (addr=12, value=0x7fc86b7bc628, size=4, access_size_min=1, 
> > > access_size_max=4, access_fn=0x560640f26c8d 
> > > , mr=0x560643c66540, attrs=...) at 
> > > ../system/memory.c:573
> > > 14 0x560640f2a2b5 in memory_region_dispatch_write (mr=0x560643c66540, 
> > > addr=12, data=0, op=MO_32, attrs=...)
> > > at ../system/memory.c:1521
> > > 15 0x560640f37bac in flatview_write_continue
> > > (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., ptr=0x7fc871e9c028, 
> > > len=4, addr1=12, l=4, mr=0x560643c66540)
> > > at ../system/physmem.c:2714
> > > 16 0x560640f37d0f in flatview_write
> > > (fv=0x7fc65805e0b0, addr=4273803276, attrs=..., buf=0x7fc871e9c028, 
> > > len=4) at ../system/physmem.c:2756
> > > 17 0x560640f380bf in address_space_write
> > > (as=0x560642161ae0 , addr=4273803276, 
> > > attrs=..., buf=0x7fc871e9c028, len=4)
> > > at ../system/physmem.c:2863
> > > 18 0x560640f3812c in address_space_rw
> > > (as=0x560642161ae0 , addr=4273803276, 
> > > attrs=..., buf=0x7fc871e9c028, len=4, is_write=true) at 
> > > ../system/physmem.c:2873
> > > --Type  for more, q to quit, c to continue without paging--
> > > 19 0x560640f8aa55 in kvm_cpu_exec (cpu=0x560642f205e0) at 
> > > ../accel/kvm/kvm-all.c:2915
> > > 20 0x560640f8d731 in kvm_vcpu_thread_fn (arg=0x560642f205e0) at 
> > > ../accel/kvm/kvm-accel-ops.c:51
> > > 21 0x5606411949f4 in qemu_thread_start (args=0x560642f292b0) at 
> > > ../util/qemu-thread-posix.c:541
> > > 22 0x7fc87148cdcd in start_thread (arg=) at 
> > > pthread_create.c:442
> > > 23 0x7fc871512630 in clone3 () at 
> > > 

[PATCH] migration/colo: Fix bdrv_graph_rdlock_main_loop: Assertion `!qemu_in_coroutine()' failed.

[Li Zhijian via]

bdrv_activate_all() should not be called from the coroutine context, move
it to the QEMU thread colo_process_incoming_thread() with the bql_lock
protected.

The backtrace is as follows:
 #4  0x561af7948362 in bdrv_graph_rdlock_main_loop () at 
../block/graph-lock.c:260
 #5  0x561af7907a68 in graph_lockable_auto_lock_mainloop (x=0x7fd29810be7b) 
at /patch/to/qemu/include/block/graph-lock.h:259
 #6  0x561af79167d1 in bdrv_activate_all (errp=0x7fd29810bed0) at 
../block.c:6906
 #7  0x561af762b4af in colo_incoming_co () at ../migration/colo.c:935
 #8  0x561af7607e57 in process_incoming_migration_co (opaque=0x0) at 
../migration/migration.c:793
 #9  0x561af7adbeeb in coroutine_trampoline (i0=-106876144, i1=22042) at 
../util/coroutine-ucontext.c:175
 #10 0x7fd2a5cf21c0 in  () at /lib64/libc.so.6

CC: Fabiano Rosas 
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2277
Fixes: 2b3912f135 ("block: Mark bdrv_first_blk() and bdrv_is_root_node() 
GRAPH_RDLOCK")
Signed-off-by: Li Zhijian 
---
 migration/colo.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/migration/colo.c b/migration/colo.c
index 84632a603e..94942fba32 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -835,6 +835,15 @@ static void *colo_process_incoming_thread(void *opaque)
 return NULL;
 }
 
+/* Make sure all file formats throw away their mutable metadata */
+bql_lock();
+bdrv_activate_all(_err);
+if (local_err) {
+error_report_err(local_err);
+return NULL;
+}
+bql_unlock();
+
 failover_init_state();
 
 mis->to_src_file = qemu_file_get_return_path(mis->from_src_file);
@@ -922,7 +931,6 @@ out:
 int coroutine_fn colo_incoming_co(void)
 {
 MigrationIncomingState *mis = migration_incoming_get_current();
-Error *local_err = NULL;
 QemuThread th;
 
 assert(bql_locked());
@@ -931,13 +939,6 @@ int coroutine_fn colo_incoming_co(void)
 return 0;
 }
 
-/* Make sure all file formats throw away their mutable metadata */
-bdrv_activate_all(_err);
-if (local_err) {
-error_report_err(local_err);
-return -EINVAL;
-}
-
 qemu_thread_create(, "COLO incoming", colo_process_incoming_thread,
mis, QEMU_THREAD_JOINABLE);
 
-- 
2.31.1

Re: [PATCH for-9.1 v3 2/2] trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

[Richard Henderson]

On 4/16/24 16:04, Daniel Henrique Barboza wrote:

Privileged spec section 4.1.9 mentions:

"When a trap is taken into S-mode, stval is written with
exception-specific information to assist software in handling the trap.
(...)

If stval is written with a nonzero value when a breakpoint,
address-misaligned, access-fault, or page-fault exception occurs on an
instruction fetch, load, or store, then stval will contain the faulting
virtual address."

A similar text is found for mtval in section 3.1.16.

Setting mtval/stval in this scenario is optional, but some softwares read
these regs when handling ebreaks.

Write 'badaddr' in all ebreak breakpoints to write the appropriate
'tval' during riscv_do_cpu_interrrupt().

Signed-off-by: Daniel Henrique Barboza
---
  target/riscv/insn_trans/trans_privileged.c.inc | 2 ++
  1 file changed, 2 insertions(+)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH 0/7] plugins: Use unwind info for special gdb registers

[Richard Henderson]

On 4/16/24 17:35, Pierrick Bouvier wrote:

On 4/15/24 21:06, Richard Henderson wrote:

Based-on: 20240404230611.21231-1-richard.hender...@linaro.org
("[PATCH v2 00/21] Rewrite plugin code generation")

This is an attempt to fix
https://gitlab.com/qemu-project/qemu/-/issues/2208
("PC is not updated for each instruction in TCG plugins")

I have only updated target/i386 so far, but basically all targets
need updating for the new callbacks.  Extra points to anyone who
sees how to avoid the extra code duplication.  :-)



Thanks for the series Richard. It looks good to me.

Besides reviewing individual commits, I have a more general question.
 From some discussions we had, it seems like that previously gdb stub was correctly 
updating all register values, and that it has been dropped at some point.


Normally gdbstub does not run in the middle of a TB -- we end normally (single-step, 
breakpoint) or raise an exception (watchpoint).  Only then, after TCG state has been made 
consistent, does gdbstub have access to the CPUState.




Was it for performance reasons, or an architectural change in QEMU?
Is gdb stub the right way to poke register values for plugins?

I don't know exactly why some registers are not updated correctly in this context, but it 
seems like we are trying to fix this afterward, instead of identifying root cause.


The one or two registers are not updated continuously for performance reasons.  And 
because they are not updated during initial code generation, it's not easy to do so later 
with plugin injection.  But recovering that data is what the unwind info is for -- a bit 
expensive to access that way, but overall less, with the expectation that it is rare.



r~

Re: [PATCH for-9.0] ppc440_pcix: Do not expose a bridge device on PCI bus

[Nicholas Piggin]

On Tue Apr 16, 2024 at 7:43 PM AEST, BALATON Zoltan wrote:
> On Tue, 16 Apr 2024, Nicholas Piggin wrote:
> > On Wed Apr 10, 2024 at 9:03 PM AEST, BALATON Zoltan wrote:
> >> On Wed, 10 Apr 2024, Nicholas Piggin wrote:
> >>> On Wed Apr 10, 2024 at 9:55 AM AEST, BALATON Zoltan wrote:
>  Real 460EX SoC apparently does not expose a bridge device and having
>  it appear on PCI bus confuses an AmigaOS file system driver that uses
>  this to detect which machine it is running on. Since values written
>  here by firmware are never read, just ignore these writes and drop the
>  bridge device.
> 
>  Signed-off-by: BALATON Zoltan 
>  ---
>  This is only used by sam460ex and this fixes an issue with AmigaOS on
>  this machine so I'd like this to be merged for 9.0 please.
> >>>
> >>> Is it a regression? Does it have a fixes: or resolves: tag?
> >>>
> >>> Unless we broke it in this cycle, I would be inclined to wait,
> >>> and we can ask to put it in stable.
> >>
> >> It's not something that broke in this cycle but since this does not affect
> >> anything else than sam460ex I think it's OK to change this for 9.0. The
> >> changes to 440 tlb in this cycle made sam460ex more useful to run AmigaOS
> >> and this fixes the file system driver on it so it would make 9.0 really
> >> usable. Otherwise people would have to wait longer until August or install
> >> a stable update. Since this has low chance to break anything (tested with
> >> AmogaOS and Linux and MorphOS does not boot due to do_io changes anyway) I
> >> don't think we have to wait with this.
> >
> > Hey, travelling / at a conference / on vacation for the next couple of
> > weeks.
> >
> > It's just a bit late for hard freeze IMO, since we didn't break it
> > before the prior release or a bad security / crash bug. Will put it in
> > 9.1.
>
> Philippe already queued this (and another) patch. This fixes AmigaOS on 
> sam460ex which became usable with the tlbwe changes in this cycle but it's 
> not really usable without a file system driver that this patch fixes. 
> Please allow this in 9.0 so users who want to try it don't have to wait a 
> few months more. Sorry for sending it this late but it was reported late 
> and took time to debug it.

No worries, I don't have a problem with the patch so if Philippe
thinks it's okay then I'm fine with that.

Thanks,
Nick

Re: [PATCH 0/7] plugins: Use unwind info for special gdb registers

[Pierrick Bouvier]

On 4/15/24 21:06, Richard Henderson wrote:

Based-on: 20240404230611.21231-1-richard.hender...@linaro.org
("[PATCH v2 00/21] Rewrite plugin code generation")

This is an attempt to fix
https://gitlab.com/qemu-project/qemu/-/issues/2208
("PC is not updated for each instruction in TCG plugins")

I have only updated target/i386 so far, but basically all targets
need updating for the new callbacks.  Extra points to anyone who
sees how to avoid the extra code duplication.  :-)



Thanks for the series Richard. It looks good to me.

Besides reviewing individual commits, I have a more general question.
From some discussions we had, it seems like that previously gdb stub 
was correctly updating all register values, and that it has been dropped 
at some point.


Was it for performance reasons, or an architectural change in QEMU?
Is gdb stub the right way to poke register values for plugins?

I don't know exactly why some registers are not updated correctly in 
this context, but it seems like we are trying to fix this afterward, 
instead of identifying root cause.


Sorry if my question is irrelevant, I'm trying to understand the full 
context here.


Thanks,
Pierrick



r~


Richard Henderson (7):
   tcg: Introduce INDEX_op_plugin_pc
   accel/tcg: Set CPUState.plugin_ra before all plugin callbacks
   accel/tcg: Return the TranslationBlock from cpu_unwind_state_data
   plugins: Introduce TCGCPUOps callbacks for mid-tb register reads
   target/i386: Split out gdb-internal.h
   target/i386: Introduce cpu_compute_eflags_ccop
   target/i386: Implement TCGCPUOps for plugin register reads

  include/exec/cpu-common.h |  9 +++--
  include/hw/core/cpu.h |  1 +
  include/hw/core/tcg-cpu-ops.h | 13 +++
  include/tcg/tcg-op-common.h   |  1 +
  include/tcg/tcg-opc.h |  1 +
  target/i386/cpu.h |  2 +
  target/i386/gdb-internal.h| 65 +++
  accel/tcg/plugin-gen.c| 50 +---
  accel/tcg/translate-all.c |  9 +++--
  plugins/api.c | 36 +-
  target/i386/gdbstub.c |  1 +
  target/i386/helper.c  |  6 ++-
  target/i386/tcg/cc_helper.c   | 10 +
  target/i386/tcg/tcg-cpu.c | 72 +++
  tcg/tcg-op.c  |  5 +++
  tcg/tcg.c | 10 +
  16 files changed, 258 insertions(+), 33 deletions(-)
  create mode 100644 target/i386/gdb-internal.h

Re: [PATCH for-9.0 v3 2/2] qtest/virtio-9p-test.c: remove g_test_slow() gate

[Daniel Henrique Barboza]

On 4/16/24 16:54, Michael Tokarev wrote:

27.03.2024 17:20, Daniel Henrique Barboza :

Commit 558f5c42ef gated the local tests with g_test_slow() to skip them
in 'make check'. The reported issue back then was this following CI
problem:

https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html

This problem ended up being fixed after it was detected with the
recently added risc-v machine nodes [1]. virtio-9p-test.c is now
creating and removing temporary dirs for each test run, instead of
creating a single dir for the entire qos-test scope.

We're now able to run these tests with 'make check' in the CI, so let's
go ahead and re-enable them.

This reverts commit 558f5c42efded3e0d0b20a90bce2a9a14580d824.

[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html


This makes tests being unable to complete on a tmpfs.  It looks like
9pfs tests needs another tweak here.

# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-798502.sock 
-qtest-log /dev/null -chardev socket,path=/tmp/qtest-798502.qmp,id=char0 -mon 
chardev=char0,mode=control -display none -audio none -M pc  -fsdev 
local,id=fsdev0,path='/tmp/q/master/qtest-9p-local-9LHRL2',security_model=mapped-xattr
 -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
Received response 7 (RLERROR) instead of 73 (RMKDIR)
Rlerror has errno 95 (Operation not supported)
**
ERROR:../../../build/qemu/master/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv:
 assertion failed (hdr.id == id): (7 == 73)

This is when I build it on /tmp/ which is a tmpfs.  When I build
it on a real filesystem, it works fine.

Apparently xattrs aren't supported on a tmpfs.


Hmmm not sure how to proceed here since I'm not a 9p expert by any means. I'll
let Christian decide what to do.

If we can't figure it out we might need to re-introduce the gate again. Thanks,


Daniel



/mjt

[PATCH for-9.1 v3 0/2] target/riscv: set tval in breakpoints

[Daniel Henrique Barboza]

Hi,

This new version has a change suggested by Richard in v2. No other
changes made.

Changes from v2:
- patch 2:
  - use tcg_constant_tl() instead of loading a temp and doing a
movi_tl()
- v2 link: 
https://lore.kernel.org/qemu-riscv/20240416194132.1843699-1-dbarb...@ventanamicro.com/


Daniel Henrique Barboza (2):
  target/riscv/debug: set tval=pc in breakpoint exceptions
  trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

 target/riscv/cpu_helper.c  | 1 +
 target/riscv/debug.c   | 3 +++
 target/riscv/insn_trans/trans_privileged.c.inc | 2 ++
 3 files changed, 6 insertions(+)

-- 
2.44.0

[PATCH for-9.1 v3 2/2] trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

[Daniel Henrique Barboza]

Privileged spec section 4.1.9 mentions:

"When a trap is taken into S-mode, stval is written with
exception-specific information to assist software in handling the trap.
(...)

If stval is written with a nonzero value when a breakpoint,
address-misaligned, access-fault, or page-fault exception occurs on an
instruction fetch, load, or store, then stval will contain the faulting
virtual address."

A similar text is found for mtval in section 3.1.16.

Setting mtval/stval in this scenario is optional, but some softwares read
these regs when handling ebreaks.

Write 'badaddr' in all ebreak breakpoints to write the appropriate
'tval' during riscv_do_cpu_interrrupt().

Signed-off-by: Daniel Henrique Barboza 
---
 target/riscv/insn_trans/trans_privileged.c.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/riscv/insn_trans/trans_privileged.c.inc 
b/target/riscv/insn_trans/trans_privileged.c.inc
index 620ab54eb0..bc5263a4e0 100644
--- a/target/riscv/insn_trans/trans_privileged.c.inc
+++ b/target/riscv/insn_trans/trans_privileged.c.inc
@@ -62,6 +62,8 @@ static bool trans_ebreak(DisasContext *ctx, arg_ebreak *a)
 if (pre == 0x01f01013 && ebreak == 0x00100073 && post == 0x40705013) {
 generate_exception(ctx, RISCV_EXCP_SEMIHOST);
 } else {
+tcg_gen_st_tl(tcg_constant_tl(ebreak_addr), tcg_env,
+  offsetof(CPURISCVState, badaddr));
 generate_exception(ctx, RISCV_EXCP_BREAKPOINT);
 }
 return true;
-- 
2.44.0

[PATCH for-9.1 v3 1/2] target/riscv/debug: set tval=pc in breakpoint exceptions

[Daniel Henrique Barboza]

We're not setting (s/m)tval when triggering breakpoints of type 2
(mcontrol) and 6 (mcontrol6). According to the debug spec section
5.7.12, "Match Control Type 6":

"The Privileged Spec says that breakpoint exceptions that occur on
instruction fetches, loads, or stores update the tval CSR with either
zero or the faulting virtual address. The faulting virtual address for
an mcontrol6 trigger with action = 0 is the address being accessed and
which caused that trigger to fire."

A similar text is also found in the Debug spec section 5.7.11 w.r.t.
mcontrol.

Note that what we're doing ATM is not violating the spec, but it's
simple enough to set mtval/stval and it makes life easier for any
software that relies on this info.

Given that we always use action = 0, save the faulting address for the
mcontrol and mcontrol6 trigger breakpoints into env->badaddr, which is
used as as scratch area for traps with address information. 'tval' is
then set during riscv_cpu_do_interrupt().

Signed-off-by: Daniel Henrique Barboza 
---
 target/riscv/cpu_helper.c | 1 +
 target/riscv/debug.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index fc090d729a..f9c6d7053b 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1717,6 +1717,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 tval = env->bins;
 break;
 case RISCV_EXCP_BREAKPOINT:
+tval = env->badaddr;
 if (cs->watchpoint_hit) {
 tval = cs->watchpoint_hit->hitaddr;
 cs->watchpoint_hit = NULL;
diff --git a/target/riscv/debug.c b/target/riscv/debug.c
index e30d99cc2f..b110370ea6 100644
--- a/target/riscv/debug.c
+++ b/target/riscv/debug.c
@@ -798,6 +798,7 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
 if ((ctrl & TYPE2_EXEC) && (bp->pc == pc)) {
 /* check U/S/M bit against current privilege level */
 if ((ctrl >> 3) & BIT(env->priv)) {
+env->badaddr = pc;
 return true;
 }
 }
@@ -810,11 +811,13 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
 if (env->virt_enabled) {
 /* check VU/VS bit against current privilege level */
 if ((ctrl >> 23) & BIT(env->priv)) {
+env->badaddr = pc;
 return true;
 }
 } else {
 /* check U/S/M bit against current privilege level */
 if ((ctrl >> 3) & BIT(env->priv)) {
+env->badaddr = pc;
 return true;
 }
 }
-- 
2.44.0

[ANNOUNCE] QEMU 9.0.0-rc4 is now available

[Michael Roth]

Hello,

On behalf of the QEMU Team, I'd like to announce the availability of the
fifth release candidate for the QEMU 9.0 release. This release is meant
for testing purposes and should not be used in a production environment.

  http://download.qemu.org/qemu-9.0.0-rc4.tar.xz
  http://download.qemu.org/qemu-9.0.0-rc4.tar.xz.sig

  http://download.qemu.org/qemu-9.0.0-rc4.tar.bz2
  http://download.qemu.org/qemu-9.0.0-rc4.tar.bz2.sig

A note from the maintainer:

  rc4 contains a handful of final fixes; we hope to do the final
  release next week on the 23rd.

You can help improve the quality of the QEMU 9.0 release by testing this
release and reporting bugs using our GitLab issue tracker:

  https://gitlab.com/qemu-project/qemu/-/milestones/11

The release plan, as well a documented known issues for release
candidates, are available at:

  http://wiki.qemu.org/Planning/9.0

Please add entries to the ChangeLog for the 9.0 release below:

  http://wiki.qemu.org/ChangeLog/9.0

Thank you to everyone involved!

Changes since rc3:

62dbe54c24: Update version for v9.0.0-rc4 release (Peter Maydell)
a12214d1c4: usb-storage: Fix BlockConf defaults (Kevin Wolf)
6e4aceba20: hw/pci-host/ppc440_pcix: Do not expose a bridge device on PCI bus 
(BALATON Zoltan)
f33274265a: hw/isa/vt82c686: Keep track of PIRQ/PINT pins separately (BALATON 
Zoltan)
2ce6cff94d: virtio-pci: fix use of a released vector (Cindy Lu)
2786a3f8d3: target/sparc: Use GET_ASI_CODE for ASI_KERNELTXT and ASI_USERTXT 
(Richard Henderson)
2d6d995709: meson.build: Disable -fzero-call-used-regs on OpenBSD (Thomas Huth)
f9a7c4478c: Makefile: fix use of -j without an argument (Matheus Tavares 
Bernardino)

Re: [PATCH for-9.1 v2 2/2] trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

[Richard Henderson]

On 4/16/24 12:41, Daniel Henrique Barboza wrote:

@@ -62,6 +62,10 @@ static bool trans_ebreak(DisasContext *ctx, arg_ebreak *a)
  if (pre == 0x01f01013 && ebreak == 0x00100073 && post == 0x40705013) {
  generate_exception(ctx, RISCV_EXCP_SEMIHOST);
  } else {
+TCGv temp = tcg_temp_new();
+tcg_gen_movi_tl(temp, ebreak_addr);
+tcg_gen_st_tl(temp, tcg_env, offsetof(CPURISCVState, badaddr));


tcg_gen_st_tl(tcg_constant_tl(ebreak_addr), ...)


r~

Re: [PATCH 4/7] qcow2: make subclusters discardable

[Andrey Drobyshev]

On 10/27/23 14:10, Jean-Louis Dupond wrote:
> [...]
> 
> I've checked all the code paths, and as far as I see it nowhere breaks
> the discard_no_unref option.
> It's important that we don't introduce new code paths that can make
> holes in the qcow2 image when this option is enabled :)
> 
> If you can confirm my conclusion, that would be great.
> 
> 
> Thanks
> Jean-Louis
> 

Hi Jean-Louis,

I've finally got to working on v2 for this series.  However I'm failing
to get a grasp on what this option is supposed to be doing and what are
we trying to avoid here.

Consider this simple example:

# cd build
# ./qemu-img create -f qcow2   unref.qcow2 192K
# ./qemu-img create -f qcow2 nounref.qcow2 192K
# ./qemu-io -c "write 0 192K"   unref.qcow2
# ./qemu-io -c "write 0 192K" nounref.qcow2
#
# strace -fv -e fallocate ./qemu-io -c "discard 64K 64K" unref.qcow2
[pid 887710] fallocate(9, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,
393216, 65536) = 0
discard 65536/65536 bytes at offset 65536
64 KiB, 1 ops; 00.00 sec (252.123 MiB/sec and 4033.9660 ops/sec)
#
# strace -fv -e fallocate ./qemu-io -c "reopen -o discard-no-unref=on"
-c "discard 64K 64K" nounref.qcow2
# [pid 887789] fallocate(9, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,
393216, 65536) = 0
discard 65536/65536 bytes at offset 65536
64 KiB, 1 ops; 00.00 sec (345.457 MiB/sec and 5527.3049 ops/sec)
#
# ./qemu-img check unref.qcow2

No errors were found on the image.
2/3 = 66.67% allocated, 50.00% fragmented, 0.00% compressed clusters
Image end offset: 524288
# ./qemu-img check nounref.qcow2
No errors were found on the image.
3/3 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 524288
#
# ls -la *.qcow2

-rw-r--r-- 1 root root 524288 Apr 16 22:42 nounref.qcow2
-rw-r--r-- 1 root root 524288 Apr 16 22:41 unref.qcow2
# du --block-size=1 *.qcow2
397312  nounref.qcow2
397312  unref.qcow2

I understand that by keeping the L2 entry we achieve that cluster
remains formally allocated, but no matter whether "discard-no-unref"
option is enabled fallocate(FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE) is
being called leaving a hole in the file (e.g. file becomes sparse).
However you say in the comment above that we can't allow making new
holes in the file when this option is enabled.  How does that correlate
and what do we achieve?  And which logic do you think we need to follow
when discarding separate subclusters?

Andrey

Re: [PATCH v2 3/4] hw/i2c: Convert to spec v7 terminology (automatically)

[Miles Glenn]

Looks good.  Thanks for taking care of that for us!

-Glenn

Reviewed-by: Glenn Miles 

On Tue, 2024-04-16 at 20:47 +0200, Philippe Mathieu-Daudé wrote:
> One of the biggest change from I2C spec v6 -> v7 is:
> 
>   • Updated the terms "master/slave" to "controller/target"
> 
> Since it follows the inclusive terminology from the "Conscious
> Language in your Open Source Projects" guidelines [*], replace
> the I2C terminology.
> 
> Mechanical transformation running:
> 
>   $ cat i2c_rename.txt | while read old new; do \
>   sed -i -e "s/$old/$new/g" $(git grep -l $old); \
> done
> 
> Having:
> 
>   $ cat i2c_rename.txt
>   i2c_bus_master i2c_bus_controller
>   i2c_schedule_pending_master i2c_schedule_pending_controller
>   I2CPendingMasters I2CPendingControllers
>   I2CPendingMaster I2CPendingController
>   pending_masters pending_controllers
>   i2c-slave i2c-target
>   I2C_SLAVE_CLASS I2C_TARGET_CLASS
>   I2C_SLAVE_GET_CLASS I2C_TARGET_GET_CLASS
>   I2CSlaveClass I2CTargetClass
>   I2CSlave I2CTarget
>   TYPE_I2C_SLAVE TYPE_I2C_TARGET
>   I2C_SLAVE I2C_TARGET
>   i2c_slave_new i2c_target_new
>   i2c_slave_create_simple i2c_target_create_simple
>   i2c_slave_realize_and_unref i2c_target_realize_and_unref
>   i2c_slave_set_address i2c_target_set_address
>   VMSTATE_I2C_SLAVE VMSTATE_I2C_TARGET
>   vmstate_i2c_slave vmstate_i2c_target
> 
> [*] 
> https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md
> 
> Inspired-by: Wolfram Sang 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/display/i2c-ddc.h |   2 +-
>  include/hw/gpio/pca9552.h|   2 +-
>  include/hw/gpio/pca9554.h|   2 +-
>  include/hw/i2c/aspeed_i2c.h  |   4 +-
>  include/hw/i2c/i2c.h |  66 -
>  include/hw/i2c/i2c_mux_pca954x.h |   2 +-
>  include/hw/i2c/smbus_slave.h |   4 +-
>  include/hw/nvram/eeprom_at24c.h  |   4 +-
>  include/hw/sensor/tmp105.h   |   2 +-
>  hw/arm/aspeed.c  | 232 +++
> 
>  hw/arm/bananapi_m2u.c|   2 +-
>  hw/arm/cubieboard.c  |   2 +-
>  hw/arm/musicpal.c|   6 +-
>  hw/arm/npcm7xx_boards.c  |  44 +++---
>  hw/arm/nseries.c |   6 +-
>  hw/arm/pxa2xx.c  |  36 ++---
>  hw/arm/realview.c|   2 +-
>  hw/arm/spitz.c   |  12 +-
>  hw/arm/stellaris.c   |   2 +-
>  hw/arm/tosa.c|  14 +-
>  hw/arm/versatilepb.c |   2 +-
>  hw/arm/vexpress.c|   2 +-
>  hw/arm/z2.c  |  20 +--
>  hw/audio/wm8750.c|  18 +--
>  hw/display/ati.c |   4 +-
>  hw/display/i2c-ddc.c |  10 +-
>  hw/display/sii9022.c |  16 +--
>  hw/display/sm501.c   |   2 +-
>  hw/display/ssd0303.c |  14 +-
>  hw/display/xlnx_dp.c |   2 +-
>  hw/gpio/max7310.c|  14 +-
>  hw/gpio/pca9552.c|  14 +-
>  hw/gpio/pca9554.c|  14 +-
>  hw/gpio/pcf8574.c|  12 +-
>  hw/i2c/aspeed_i2c.c  |  16 +--
>  hw/i2c/core.c|  88 ++--
>  hw/i2c/i2c_mux_pca954x.c |   6 +-
>  hw/i2c/imx_i2c.c |   2 +-
>  hw/i2c/smbus_slave.c |  12 +-
>  hw/input/lm832x.c|  14 +-
>  hw/misc/axp2xx.c |  14 +-
>  hw/misc/i2c-echo.c   |  14 +-
>  hw/nvram/eeprom_at24c.c  |  22 +--
>  hw/ppc/e500.c|   2 +-
>  hw/ppc/pnv.c |   4 +-
>  hw/ppc/sam460ex.c|   2 +-
>  hw/rtc/ds1338.c  |  14 +-
>  hw/rtc/m41t80.c  |  12 +-
>  hw/rtc/twl92230.c|  16 +--
>  hw/sensor/dps310.c   |  14 +-
>  hw/sensor/emc141x.c  |  16 +--
>  hw/sensor/lsm303dlhc_mag.c   |  16 +--
>  hw/sensor/tmp105.c   |  16 +--
>  hw/sensor/tmp421.c   |  20 +--
>  hw/tpm/tpm_tis_i2c.c |  12 +-
>  55 files changed, 461 insertions(+), 461 deletions(-)
> 
> diff --git a/include/hw/display/i2c-ddc.h b/include/hw/display/i2c-
> ddc.h
> index 94b5880587..faf3cd84fa 100644
> --- a/include/hw/display/i2c-ddc.h
> +++ b/include/hw/display/i2c-ddc.h
> @@ -26,7 +26,7 @@
>  /* A simple I2C slave which just returns the contents of its EDID
> blob. */
>  struct I2CDDCState {
>  /*< private >*/
> -I2CSlave i2c;
> +I2CTarget i2c;
>  /*< public >*/
>  bool firstbyte;
>  uint8_t reg;
> diff --git a/include/hw/gpio/pca9552.h b/include/hw/gpio/pca9552.h
> index c36525f0c3..d7f07a44e0 100644
> --- a/include/hw/gpio/pca9552.h
> +++ b/include/hw/gpio/pca9552.h
> @@ -23,7 +23,7 @@ DECLARE_INSTANCE_CHECKER(PCA955xState, PCA955X,
>  
>  struct PCA955xState {
>  /*< private >*/
> -I2CSlave i2c;
> +I2CTarget i2c;
>  /*< public >*/
>  
>  uint8_t len;
> diff --git a/include/hw/gpio/pca9554.h 

Re: [PATCH for-9.0 v3 2/2] qtest/virtio-9p-test.c: remove g_test_slow() gate

[Michael Tokarev]

27.03.2024 17:20, Daniel Henrique Barboza :

Commit 558f5c42ef gated the local tests with g_test_slow() to skip them
in 'make check'. The reported issue back then was this following CI
problem:

https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html

This problem ended up being fixed after it was detected with the
recently added risc-v machine nodes [1]. virtio-9p-test.c is now
creating and removing temporary dirs for each test run, instead of
creating a single dir for the entire qos-test scope.

We're now able to run these tests with 'make check' in the CI, so let's
go ahead and re-enable them.

This reverts commit 558f5c42efded3e0d0b20a90bce2a9a14580d824.

[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html


This makes tests being unable to complete on a tmpfs.  It looks like
9pfs tests needs another tweak here.

# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-798502.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-798502.qmp,id=char0 
-mon chardev=char0,mode=control -display none -audio none -M pc  -fsdev 
local,id=fsdev0,path='/tmp/q/master/qtest-9p-local-9LHRL2',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest 
-accel qtest

Received response 7 (RLERROR) instead of 73 (RMKDIR)
Rlerror has errno 95 (Operation not supported)
**
ERROR:../../../build/qemu/master/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv:
 assertion failed (hdr.id == id): (7 == 73)

This is when I build it on /tmp/ which is a tmpfs.  When I build
it on a real filesystem, it works fine.

Apparently xattrs aren't supported on a tmpfs.

/mjt

[PATCH for-9.1 v2 1/2] target/riscv/debug: set tval=pc in breakpoint exceptions

[Daniel Henrique Barboza]

We're not setting (s/m)tval when triggering breakpoints of type 2
(mcontrol) and 6 (mcontrol6). According to the debug spec section
5.7.12, "Match Control Type 6":

"The Privileged Spec says that breakpoint exceptions that occur on
instruction fetches, loads, or stores update the tval CSR with either
zero or the faulting virtual address. The faulting virtual address for
an mcontrol6 trigger with action = 0 is the address being accessed and
which caused that trigger to fire."

A similar text is also found in the Debug spec section 5.7.11 w.r.t.
mcontrol.

Note that what we're doing ATM is not violating the spec, but it's
simple enough to set mtval/stval and it makes life easier for any
software that relies on this info.

Given that we always use action = 0, save the faulting address for the
mcontrol and mcontrol6 trigger breakpoints into env->badaddr, which is
used as as scratch area for traps with address information. 'tval' is
then set during riscv_cpu_do_interrupt().

Signed-off-by: Daniel Henrique Barboza 
---
 target/riscv/cpu_helper.c | 1 +
 target/riscv/debug.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index fc090d729a..f9c6d7053b 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1717,6 +1717,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 tval = env->bins;
 break;
 case RISCV_EXCP_BREAKPOINT:
+tval = env->badaddr;
 if (cs->watchpoint_hit) {
 tval = cs->watchpoint_hit->hitaddr;
 cs->watchpoint_hit = NULL;
diff --git a/target/riscv/debug.c b/target/riscv/debug.c
index e30d99cc2f..b110370ea6 100644
--- a/target/riscv/debug.c
+++ b/target/riscv/debug.c
@@ -798,6 +798,7 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
 if ((ctrl & TYPE2_EXEC) && (bp->pc == pc)) {
 /* check U/S/M bit against current privilege level */
 if ((ctrl >> 3) & BIT(env->priv)) {
+env->badaddr = pc;
 return true;
 }
 }
@@ -810,11 +811,13 @@ bool riscv_cpu_debug_check_breakpoint(CPUState *cs)
 if (env->virt_enabled) {
 /* check VU/VS bit against current privilege level */
 if ((ctrl >> 23) & BIT(env->priv)) {
+env->badaddr = pc;
 return true;
 }
 } else {
 /* check U/S/M bit against current privilege level */
 if ((ctrl >> 3) & BIT(env->priv)) {
+env->badaddr = pc;
 return true;
 }
 }
-- 
2.44.0

[PATCH for-9.1 v2 2/2] trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

[Daniel Henrique Barboza]

Privileged spec section 4.1.9 mentions:

"When a trap is taken into S-mode, stval is written with
exception-specific information to assist software in handling the trap.
(...)

If stval is written with a nonzero value when a breakpoint,
address-misaligned, access-fault, or page-fault exception occurs on an
instruction fetch, load, or store, then stval will contain the faulting
virtual address."

A similar text is found for mtval in section 3.1.16.

Setting mtval/stval in this scenario is optional, but some softwares read
these regs when handling ebreaks.

Write 'badaddr' in all ebreak breakpoints to write the appropriate
'tval' during riscv_do_cpu_interrrupt().

Signed-off-by: Daniel Henrique Barboza 
---
 target/riscv/insn_trans/trans_privileged.c.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/riscv/insn_trans/trans_privileged.c.inc 
b/target/riscv/insn_trans/trans_privileged.c.inc
index 620ab54eb0..b89e3bd5b5 100644
--- a/target/riscv/insn_trans/trans_privileged.c.inc
+++ b/target/riscv/insn_trans/trans_privileged.c.inc
@@ -62,6 +62,10 @@ static bool trans_ebreak(DisasContext *ctx, arg_ebreak *a)
 if (pre == 0x01f01013 && ebreak == 0x00100073 && post == 0x40705013) {
 generate_exception(ctx, RISCV_EXCP_SEMIHOST);
 } else {
+TCGv temp = tcg_temp_new();
+tcg_gen_movi_tl(temp, ebreak_addr);
+tcg_gen_st_tl(temp, tcg_env, offsetof(CPURISCVState, badaddr));
+
 generate_exception(ctx, RISCV_EXCP_BREAKPOINT);
 }
 return true;
-- 
2.44.0

[PATCH for-9.1 v2 0/2] target/riscv: set (m|s)tval on

[Daniel Henrique Barboza]

Hi,

This is a re-send of the patch sent as a 9.0 bugfix in [1], now reframed
as a non-bug fix chabge,

A new patch (2) was added to handle a similar scenario with ebreak and tval.

Changes from v1:
- patch 1:
  - rewrite commit msg to make it clear that this is a non-bug
fix change
- new patch (2):
  -  set mtval/stval during ebreak
- v1 link: 
https://lore.kernel.org/qemu-riscv/20240320093221.220854-1-dbarb...@ventanamicro.com/

Daniel Henrique Barboza (2):
  target/riscv/debug: set tval=pc in breakpoint exceptions
  trans_privileged.c.inc: set (m|s)tval on ebreak breakpoint

 target/riscv/cpu_helper.c  | 1 +
 target/riscv/debug.c   | 3 +++
 target/riscv/insn_trans/trans_privileged.c.inc | 4 
 3 files changed, 8 insertions(+)

-- 
2.44.0

Re: [PATCH 8/8] target/ppc: Move logical fixed-point instructions to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

Moving the below instructions to decodetree specification :

andi[s]., {ori, xori}[s]: D-form

{and, andc, nand, or, orc, nor, xor, eqv}[.],
exts{b, h, w}[.],  cnt{l, t}z{w, d}[.],
popcnt{b, w, d},  prty{w, d}, cmp, bpermd   : X-form

With this patch, all the fixed-point logical instructions have been
moved to decodetree.
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,op' flag.

Signed-off-by: Chinmay Rath
---
  target/ppc/helper.h|   8 +-
  target/ppc/insn32.decode   |  38 +++
  target/ppc/int_helper.c|  10 +-
  target/ppc/translate.c | 359 -
  target/ppc/translate/fixedpoint-impl.c.inc | 269 +++
  5 files changed, 316 insertions(+), 368 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH 7/8] target/ppc: Move cmp{rb, eqb}, tw[i], td[i], isel instructions to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

Moving the following instructions to decodetree specification :

cmp{rb, eqb}, t{w, d}   : X-form
t{w, d}i: D-form
isel: A-form

The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured using the '-d in_asm,op' flag.

Signed-off-by: Chinmay Rath 


A faithful reorg of the existing code, so,
Reviewed-by: Richard Henderson 

Notes for improvement:


+static bool trans_CMPRB(DisasContext *ctx, arg_CMPRB *a)
+{
+TCGv_i32 src1 = tcg_temp_new_i32();
+TCGv_i32 src2 = tcg_temp_new_i32();
+TCGv_i32 src2lo = tcg_temp_new_i32();
+TCGv_i32 src2hi = tcg_temp_new_i32();
+TCGv_i32 crf = cpu_crf[a->bf];
+
+REQUIRE_INSNS_FLAGS2(ctx, ISA300);
+tcg_gen_trunc_tl_i32(src1, cpu_gpr[a->ra]);
+tcg_gen_trunc_tl_i32(src2, cpu_gpr[a->rb]);
+
+tcg_gen_andi_i32(src1, src1, 0xFF);
+tcg_gen_ext8u_i32(src2lo, src2);
+tcg_gen_shri_i32(src2, src2, 8);
+tcg_gen_ext8u_i32(src2hi, src2);


tcg_gen_extract_i32(src2hi, src2, 8, 8);


+
+tcg_gen_setcond_i32(TCG_COND_LEU, src2lo, src2lo, src1);
+tcg_gen_setcond_i32(TCG_COND_LEU, src2hi, src1, src2hi);
+tcg_gen_and_i32(crf, src2lo, src2hi);
+
+if (a->l) {
+tcg_gen_shri_i32(src2, src2, 8);
+tcg_gen_ext8u_i32(src2lo, src2);


tcg_gen_extract_i32(src2lo, src2, 16, 8);


+tcg_gen_shri_i32(src2, src2, 8);
+tcg_gen_ext8u_i32(src2hi, src2);


tcg_gen_extract_i32(src2hi, src2, 24, 8);


+/*
+ * Fixed-Point Trap Instructions
+ */
+
+static bool trans_TW(DisasContext *ctx, arg_TW *a)
+{
+TCGv_i32 t0;
+
+if (check_unconditional_trap(ctx, a->rt)) {
+return true;
+}
+t0 = tcg_constant_i32(a->rt);
+gen_helper_TW(tcg_env, cpu_gpr[a->ra], cpu_gpr[a->rb], t0);
+return true;
+}
+
+static bool trans_TWI(DisasContext *ctx, arg_TWI *a)
+{
+TCGv t0;
+TCGv_i32 t1;
+
+if (check_unconditional_trap(ctx, a->rt)) {
+return true;
+}
+t0 = tcg_constant_tl(a->si);
+t1 = tcg_constant_i32(a->rt);
+gen_helper_TW(tcg_env, cpu_gpr[a->ra], t0, t1);
+return true;
+}
+
+static bool trans_TD(DisasContext *ctx, arg_TD *a)
+{
+TCGv_i32 t0;
+
+REQUIRE_64BIT(ctx);
+if (check_unconditional_trap(ctx, a->rt)) {
+return true;
+}
+t0 = tcg_constant_i32(a->rt);
+gen_helper_TD(tcg_env, cpu_gpr[a->ra], cpu_gpr[a->rb], t0);
+return true;
+}
+
+static bool trans_TDI(DisasContext *ctx, arg_TDI *a)
+{
+TCGv t0;
+TCGv_i32 t1;
+
+REQUIRE_64BIT(ctx);
+if (check_unconditional_trap(ctx, a->rt)) {
+return true;
+}
+t0 = tcg_constant_tl(a->si);
+t1 = tcg_constant_i32(a->rt);
+gen_helper_TD(tcg_env, cpu_gpr[a->ra], t0, t1);
+return true;
+}


See target/sparc/translate.c, delay_exception, for a method of implementing 
compare-and-trap inline with no inline branch penalty.


static void do_conditional_trap(DisasContext *ctx, unsigned to, TCGv a, TCGv b)
{
static const TCGCond ucond[8] = {
TCG_COND_NEVER, TCG_COND_GTU, TCG_COND_LTU, TCG_COND_NE,
TCG_COND_EQ,TCG_COND_GEU, TCG_COND_LEU, TCG_COND_ALWAYS,
};
static const TCGCond scond[8] = {
TCG_COND_NEVER, TCG_COND_EQ,  TCG_COND_GT,  TCG_COND_GE,
TCG_COND_LT,TCG_COND_LE,  TCG_COND_NE,  TCG_COND_ALWAYS,
};

TCGCond uc = ucond[to & 7];
TCGCond sc = scond[to >> 2];

/* There is overlap with EQ; we may not need both comparisons. */
if (!(to & 0x18)) {
sc = TCG_COND_NEVER;
} else if (!(to & 0x03)) {
uc = TCG_COND_NEVER;
}

if (uc == TCG_COND_ALWAYS || sc == TCG_COND_ALWAYS) {
unconditional trap;
return true;
}
if (uc == TCG_COND_NEVER && sc == TCG_COND_NEVER) {
return true;
}

e = delay_exception(ctx, POWERPC_EXCP_TRAP);

if (uc != TCG_COND_NEVER) {
tcg_gen_brcond_tl(uc, a, b, e->lab);
}
if (sc != TCG_COND_NEVER) {
tcg_gen_brcond_tl(sc, a, b, e->lab);
}
return true;
}

bool trans_TW(...)
{
TCGv a = tcg_temp_new();
TCGv b = tcg_temp_new();

/* Note that consistent sign extensions work for unsigned comparisons. */
tcg_gen_exts_i32_tl(a, ra);
tcg_gen_exts_i32_tl(b, rb);
return do_conditional_trap(ctx, to, a, b);
}

etc.


r~

[PATCH v4 10/22] hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded

[Philippe Mathieu-Daudé]

PCMachineClass::smbios_uuid_encoded was only used by the
pc-i440fx-2.1 machine, which got removed. It is now always
true, remove it.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/fw_cfg.c | 3 +--
 hw/i386/pc.c | 1 -
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b528f17904..c2d9af36b2 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -109,7 +109,6 @@ struct PCMachineClass {
 /* SMBIOS compat: */
 bool smbios_defaults;
 bool smbios_legacy_mode;
-bool smbios_uuid_encoded;
 SmbiosEntryPointType default_smbios_ep_type;
 
 /* RAM / address space compat: */
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index d802d2787f..f7c2501161 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,8 +63,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
*fw_cfg,
 
 if (pcmc->smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_defaults("QEMU", mc->desc, mc->name,
-pcmc->smbios_uuid_encoded);
+smbios_set_defaults("QEMU", mc->desc, mc->name, true);
 }
 
 /* tell smbios about cpuid version and features */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index cd6335d6b4..2bf1bfd5b2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1778,7 +1778,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->has_acpi_build = true;
 pcmc->rsdp_in_ram = true;
 pcmc->smbios_defaults = true;
-pcmc->smbios_uuid_encoded = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
 pcmc->enforce_aligned_dimm = true;
-- 
2.41.0

[PATCH v4 09/22] target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'

[Philippe Mathieu-Daudé]

x86_cpu_change_kvm_default() was only used out of kvm-cpu.c by
the pc-i440fx-2.1 machine, which got removed. Make it static,
and remove its declaration. "kvm-cpu.h" is now empty, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 target/i386/kvm/kvm-cpu.h | 41 ---
 target/i386/kvm/kvm-cpu.c |  3 +--
 2 files changed, 1 insertion(+), 43 deletions(-)
 delete mode 100644 target/i386/kvm/kvm-cpu.h

diff --git a/target/i386/kvm/kvm-cpu.h b/target/i386/kvm/kvm-cpu.h
deleted file mode 100644
index e858ca21e5..00
--- a/target/i386/kvm/kvm-cpu.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * i386 KVM CPU type and functions
- *
- *  Copyright (c) 2003 Fabrice Bellard
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see .
- */
-
-#ifndef KVM_CPU_H
-#define KVM_CPU_H
-
-#ifdef CONFIG_KVM
-/*
- * Change the value of a KVM-specific default
- *
- * If value is NULL, no default will be set and the original
- * value from the CPU model table will be kept.
- *
- * It is valid to call this function only for properties that
- * are already present in the kvm_default_props table.
- */
-void x86_cpu_change_kvm_default(const char *prop, const char *value);
-
-#else /* !CONFIG_KVM */
-
-#define x86_cpu_change_kvm_default(a, b)
-
-#endif /* CONFIG_KVM */
-
-#endif /* KVM_CPU_H */
diff --git a/target/i386/kvm/kvm-cpu.c b/target/i386/kvm/kvm-cpu.c
index 9c791b7b05..cb8c73d20c 100644
--- a/target/i386/kvm/kvm-cpu.c
+++ b/target/i386/kvm/kvm-cpu.c
@@ -10,7 +10,6 @@
 #include "qemu/osdep.h"
 #include "cpu.h"
 #include "host-cpu.h"
-#include "kvm-cpu.h"
 #include "qapi/error.h"
 #include "sysemu/sysemu.h"
 #include "hw/boards.h"
@@ -144,7 +143,7 @@ static PropValue kvm_default_props[] = {
 /*
  * Only for builtin_x86_defs models initialized with x86_register_cpudef_types.
  */
-void x86_cpu_change_kvm_default(const char *prop, const char *value)
+static void x86_cpu_change_kvm_default(const char *prop, const char *value)
 {
 PropValue *pv;
 for (pv = kvm_default_props; pv->prop; pv++) {
-- 
2.41.0

[PATCH v4 22/22] hw/i386/pc: Replace PCMachineClass::acpi_data_size by PC_ACPI_DATA_SIZE

[Philippe Mathieu-Daudé]

PCMachineClass::acpi_data_size was only used by the pc-i440fx-2.0
machine, which got removed. Since it is constant, replace the class
field by a definition (local to hw/i386/pc.c, since not used
elsewhere).

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 include/hw/i386/pc.h |  4 
 hw/i386/pc.c | 19 ---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 96ccb4583f..0ad971782c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -74,9 +74,6 @@ typedef struct PCMachineState {
  *
  * Compat fields:
  *
- * @acpi_data_size: Size of the chunk of memory at the top of RAM
- *  for the BIOS ACPI tables and other BIOS
- *  datastructures.
  * @gigabyte_align: Make sure that guest addresses aligned at
  *  1Gbyte boundaries get mapped to host
  *  addresses aligned at 1Gbyte boundaries. This
@@ -100,7 +97,6 @@ struct PCMachineClass {
 
 /* ACPI compat: */
 bool has_acpi_build;
-unsigned acpi_data_size;
 int pci_root_uid;
 
 /* SMBIOS compat: */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2e2146f42b..0be8f08c47 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,6 +256,16 @@ GlobalProperty pc_compat_2_4[] = {
 };
 const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
 
+/*
+ * @PC_ACPI_DATA_SIZE:
+ * Size of the chunk of memory at the top of RAM for the BIOS ACPI tables
+ * and other BIOS datastructures.
+ *
+ * BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K
+ * reported to be used at the moment, 32K should be enough for a while.
+ */
+#define PC_ACPI_DATA_SIZE (0x2 + 0x8000)
+
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
@@ -634,8 +644,7 @@ void xen_load_linux(PCMachineState *pcms)
 fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, x86ms->boot_cpus);
 rom_set_fw(fw_cfg);
 
-x86_load_linux(x86ms, fw_cfg, pcmc->acpi_data_size,
-   pcmc->pvh_enabled);
+x86_load_linux(x86ms, fw_cfg, PC_ACPI_DATA_SIZE, pcmc->pvh_enabled);
 for (i = 0; i < nb_option_roms; i++) {
 assert(!strcmp(option_rom[i].name, "linuxboot.bin") ||
!strcmp(option_rom[i].name, "linuxboot_dma.bin") ||
@@ -969,8 +978,7 @@ void pc_memory_init(PCMachineState *pcms,
 }
 
 if (linux_boot) {
-x86_load_linux(x86ms, fw_cfg, pcmc->acpi_data_size,
-   pcmc->pvh_enabled);
+x86_load_linux(x86ms, fw_cfg, PC_ACPI_DATA_SIZE, pcmc->pvh_enabled);
 }
 
 for (i = 0; i < nb_option_roms; i++) {
@@ -1724,9 +1732,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
 pcmc->enforce_amd_1tb_hole = true;
-/* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
- * to be used at the moment, 32K should be enough for a while.  */
-pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->pvh_enabled = true;
 pcmc->kvmclock_create_always = true;
 x86mc->apic_xrupt_override = true;
-- 
2.41.0

[PATCH v4 11/22] hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()

[Philippe Mathieu-Daudé]

'uuid_encoded' is always true, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 include/hw/firmware/smbios.h | 3 +--
 hw/arm/virt.c| 3 +--
 hw/i386/fw_cfg.c | 2 +-
 hw/loongarch/virt.c  | 2 +-
 hw/riscv/virt.c  | 2 +-
 hw/smbios/smbios.c   | 6 ++
 6 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 8d3fb2fb3b..f066ab7262 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -331,8 +331,7 @@ void smbios_add_usr_blob_size(size_t size);
 void smbios_entry_add(QemuOpts *opts, Error **errp);
 void smbios_set_cpuid(uint32_t version, uint32_t features);
 void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version,
- bool uuid_encoded);
+ const char *version);
 void smbios_set_default_processor_family(uint16_t processor_family);
 uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
 void smbios_get_tables(MachineState *ms,
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a9a913aead..a55ef916cb 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1650,8 +1650,7 @@ static void virt_build_smbios(VirtMachineState *vms)
 }
 
 smbios_set_defaults("QEMU", product,
-vmc->smbios_old_sys_ver ? "1.0" : mc->name,
-true);
+vmc->smbios_old_sys_ver ? "1.0" : mc->name);
 
 /* build the array of physical mem area from base_memmap */
 mem_array.address = vms->memmap[VIRT_MEM].base;
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index f7c2501161..ecc4047a4b 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,7 +63,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
*fw_cfg,
 
 if (pcmc->smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_defaults("QEMU", mc->desc, mc->name, true);
+smbios_set_defaults("QEMU", mc->desc, mc->name);
 }
 
 /* tell smbios about cpuid version and features */
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 441d764843..00d3005e54 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -355,7 +355,7 @@ static void virt_build_smbios(LoongArchMachineState *lams)
 return;
 }
 
-smbios_set_defaults("QEMU", product, mc->name, true);
+smbios_set_defaults("QEMU", product, mc->name);
 
 smbios_get_tables(ms, SMBIOS_ENTRY_POINT_TYPE_64,
   NULL, 0,
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index d171e74f7b..1ed9b0552e 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1277,7 +1277,7 @@ static void virt_build_smbios(RISCVVirtState *s)
 product = "KVM Virtual Machine";
 }
 
-smbios_set_defaults("QEMU", product, mc->name, true);
+smbios_set_defaults("QEMU", product, mc->name);
 
 if (riscv_is_32bit(>soc[0])) {
 smbios_set_default_processor_family(0x200);
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index eed5787b15..8261eb716f 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -30,7 +30,7 @@
 #include "hw/pci/pci_device.h"
 #include "smbios_build.h"
 
-static bool smbios_uuid_encoded = true;
+static const bool smbios_uuid_encoded = true;
 /*
  * SMBIOS tables provided by user with '-smbios file=' option
  */
@@ -1017,11 +1017,9 @@ void smbios_set_default_processor_family(uint16_t 
processor_family)
 }
 
 void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version,
- bool uuid_encoded)
+ const char *version)
 {
 smbios_have_defaults = true;
-smbios_uuid_encoded = uuid_encoded;
 
 SMBIOS_SET_DEFAULT(smbios_type1.manufacturer, manufacturer);
 SMBIOS_SET_DEFAULT(smbios_type1.product, product);
-- 
2.41.0

[PATCH v4 06/22] hw/acpi/ich9: Remove 'memory-hotplug-support' property

[Philippe Mathieu-Daudé]

No external code sets the 'memory-hotplug-support'
property, remove it.

Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 hw/acpi/ich9.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 573d032e8e..9b605af21a 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -351,21 +351,6 @@ static void ich9_pm_get_gpe0_blk(Object *obj, Visitor *v, 
const char *name,
 visit_type_uint32(v, name, , errp);
 }
 
-static bool ich9_pm_get_memory_hotplug_support(Object *obj, Error **errp)
-{
-ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
-
-return s->pm.acpi_memory_hotplug.is_enabled;
-}
-
-static void ich9_pm_set_memory_hotplug_support(Object *obj, bool value,
-   Error **errp)
-{
-ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
-
-s->pm.acpi_memory_hotplug.is_enabled = value;
-}
-
 static bool ich9_pm_get_cpu_hotplug_legacy(Object *obj, Error **errp)
 {
 ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
@@ -445,9 +430,6 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs *pm)
 NULL, NULL, pm);
 object_property_add_uint32_ptr(obj, ACPI_PM_PROP_GPE0_BLK_LEN,
_len, OBJ_PROP_FLAG_READ);
-object_property_add_bool(obj, "memory-hotplug-support",
- ich9_pm_get_memory_hotplug_support,
- ich9_pm_set_memory_hotplug_support);
 object_property_add_bool(obj, "cpu-hotplug-legacy",
  ich9_pm_get_cpu_hotplug_legacy,
  ich9_pm_set_cpu_hotplug_legacy);
-- 
2.41.0

[PATCH v4 08/22] hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.1 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c|  7 ---
 hw/i386/pc_piix.c   | 23 ---
 5 files changed, 2 insertions(+), 35 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index b09ae3d55d..a2a1b9d337 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
+``pc-i440fx-2.2`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
 

 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 51119e623f..01c55103d3 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.1`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 4ad724601a..b528f17904 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -281,9 +281,6 @@ extern const size_t pc_compat_2_3_len;
 extern GlobalProperty pc_compat_2_2[];
 extern const size_t pc_compat_2_2_len;
 
-extern GlobalProperty pc_compat_2_1[];
-extern const size_t pc_compat_2_1_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 172814f604..cd6335d6b4 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -304,13 +304,6 @@ GlobalProperty pc_compat_2_2[] = {
 };
 const size_t pc_compat_2_2_len = G_N_ELEMENTS(pc_compat_2_2);
 
-GlobalProperty pc_compat_2_1[] = {
-PC_CPU_MODEL_IDS("2.1.0")
-{ "coreduo" "-" TYPE_X86_CPU, "vmx", "on" },
-{ "core2duo" "-" TYPE_X86_CPU, "vmx", "on" },
-};
-const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9e1bca7b17..dcf50684a4 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -66,7 +66,6 @@
 #include "hw/hyperv/vmbus-bridge.h"
 #include "hw/mem/nvdimm.h"
 #include "hw/i386/acpi-build.h"
-#include "kvm/kvm-cpu.h"
 #include "target/i386/cpu.h"
 
 #define XEN_IOAPIC_NUM_PIRQS 128ULL
@@ -435,12 +434,6 @@ static void pc_compat_2_2_fn(MachineState *machine)
 pc_compat_2_3_fn(machine);
 }
 
-static void pc_compat_2_1_fn(MachineState *machine)
-{
-pc_compat_2_2_fn(machine);
-x86_cpu_change_kvm_default("svm", NULL);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -851,22 +844,6 @@ static void pc_i440fx_2_2_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_2, "pc-i440fx-2.2", pc_compat_2_2_fn,
   pc_i440fx_2_2_machine_options);
 
-static void pc_i440fx_2_1_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_2_machine_options(m);
-m->hw_version = "2.1.0";
-m->default_display = NULL;
-compat_props_add(m->compat_props, hw_compat_2_1, hw_compat_2_1_len);
-compat_props_add(m->compat_props, pc_compat_2_1, pc_compat_2_1_len);
-pcmc->smbios_uuid_encoded = false;
-pcmc->enforce_aligned_dimm = false;
-}
-
-DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
-  pc_i440fx_2_1_machine_options);
-
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-- 
2.41.0

[PATCH v4 19/22] hw/i386/acpi: Remove AcpiBuildState::rsdp field

[Philippe Mathieu-Daudé]

AcpiBuildState::rsdp is always NULL, remove it,
simplifying acpi_build_update().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 hw/i386/acpi-build.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ed0adb0e82..6f9925d176 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2459,7 +2459,6 @@ struct AcpiBuildState {
 MemoryRegion *table_mr;
 /* Is table patched? */
 uint8_t patched;
-void *rsdp;
 MemoryRegion *rsdp_mr;
 MemoryRegion *linker_mr;
 } AcpiBuildState;
@@ -2715,11 +2714,7 @@ static void acpi_build_update(void *build_opaque)
 
 acpi_ram_update(build_state->table_mr, tables.table_data);
 
-if (build_state->rsdp) {
-memcpy(build_state->rsdp, tables.rsdp->data, 
acpi_data_len(tables.rsdp));
-} else {
-acpi_ram_update(build_state->rsdp_mr, tables.rsdp);
-}
+acpi_ram_update(build_state->rsdp_mr, tables.rsdp);
 
 acpi_ram_update(build_state->linker_mr, tables.linker->cmd_blob);
 acpi_build_tables_cleanup(, true);
@@ -2805,7 +2800,6 @@ void acpi_setup(void)
tables.vmgenid);
 }
 
-build_state->rsdp = NULL;
 build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
  build_state, tables.rsdp,
  ACPI_BUILD_RSDP_FILE);
-- 
2.41.0

[PATCH v4 21/22] target/i386: Remove X86CPU::kvm_no_smi_migration field

[Philippe Mathieu-Daudé]

X86CPU::kvm_no_smi_migration was only used by the
pc-i440fx-2.3 machine, which got removed. Remove it
and simplify kvm_put_vcpu_events().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 target/i386/cpu.h | 3 ---
 target/i386/cpu.c | 2 --
 target/i386/kvm/kvm.c | 7 +--
 3 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 6b05738079..5b016d6667 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2018,9 +2018,6 @@ struct ArchCPU {
 /* if set, limit maximum value for phys_bits when host_phys_bits is true */
 uint8_t host_phys_bits_limit;
 
-/* Stop SMI delivery for migration compatibility with old machines */
-bool kvm_no_smi_migration;
-
 /* Forcefully disable KVM PV features not exposed in guest CPUIDs */
 bool kvm_pv_enforce_cpuid;
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 33760a2ee1..f9991e7398 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7905,8 +7905,6 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_BOOL("x-vendor-cpuid-only", X86CPU, vendor_cpuid_only, true),
 DEFINE_PROP_BOOL("lmce", X86CPU, enable_lmce, false),
 DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true),
-DEFINE_PROP_BOOL("kvm-no-smi-migration", X86CPU, kvm_no_smi_migration,
- false),
 DEFINE_PROP_BOOL("kvm-pv-enforce-cpuid", X86CPU, kvm_pv_enforce_cpuid,
  false),
 DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index e68cbe9293..88f4a7da33 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -4337,6 +4337,7 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level)
 events.sipi_vector = env->sipi_vector;
 
 if (has_msr_smbase) {
+events.flags |= KVM_VCPUEVENT_VALID_SMM;
 events.smi.smm = !!(env->hflags & HF_SMM_MASK);
 events.smi.smm_inside_nmi = !!(env->hflags2 & HF2_SMM_INSIDE_NMI_MASK);
 if (kvm_irqchip_in_kernel()) {
@@ -4351,12 +4352,6 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level)
 events.smi.pending = 0;
 events.smi.latched_init = 0;
 }
-/* Stop SMI delivery on old machine types to avoid a reboot
- * on an inward migration of an old VM.
- */
-if (!cpu->kvm_no_smi_migration) {
-events.flags |= KVM_VCPUEVENT_VALID_SMM;
-}
 }
 
 if (level >= KVM_PUT_RESET_STATE) {
-- 
2.41.0

[PATCH v4 20/22] hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.3 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/about/deprecated.rst   |  4 ++--
 docs/about/removed-features.rst |  2 +-
 hw/i386/pc.c| 25 -
 hw/i386/pc_piix.c   | 19 ---
 4 files changed, 3 insertions(+), 47 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 75bf0f4886..cb6ca372f2 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,8 +219,8 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.3`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
-
+``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
+''
 
 These old machine types are quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 4664974a8b..0caa6a63e4 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.3`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a1b0e94523..2e2146f42b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,31 +256,6 @@ GlobalProperty pc_compat_2_4[] = {
 };
 const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
 
-GlobalProperty pc_compat_2_3[] = {
-PC_CPU_MODEL_IDS("2.3.0")
-{ TYPE_X86_CPU, "arat", "off" },
-{ "qemu64" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "kvm64" "-" TYPE_X86_CPU, "min-level", "5" },
-{ "pentium3" "-" TYPE_X86_CPU, "min-level", "2" },
-{ "n270" "-" TYPE_X86_CPU, "min-level", "5" },
-{ "Conroe" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "Penryn" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "Nehalem" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "n270" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Penryn" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Conroe" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Nehalem" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Westmere" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "SandyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "IvyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Haswell" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Haswell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Broadwell" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Broadwell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ TYPE_X86_CPU, "kvm-no-smi-migration", "on" },
-};
-const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 30bcd86ee6..370d130a6d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -421,14 +421,6 @@ static void pc_set_south_bridge(Object *obj, int value, 
Error **errp)
  * hw_compat_*, pc_compat_*, or * pc_*_machine_options().
  */
 
-static void pc_compat_2_3_fn(MachineState *machine)
-{
-X86MachineState *x86ms = X86_MACHINE(machine);
-if (kvm_enabled()) {
-x86ms->smm = ON_OFF_AUTO_OFF;
-}
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -812,17 +804,6 @@ static void pc_i440fx_2_4_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
   pc_i440fx_2_4_machine_options)
 
-static void pc_i440fx_2_3_machine_options(MachineClass *m)
-{
-pc_i440fx_2_4_machine_options(m);
-m->hw_version = "2.3.0";
-compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
-compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
-}
-
-DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
-  pc_i440fx_2_3_machine_options);
-
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-- 
2.41.0

[PATCH v4 07/22] hw/acpi/ich9: Remove dead code related to 'acpi_memory_hotplug'

[Philippe Mathieu-Daudé]

acpi_memory_hotplug::is_enabled is set to %true once via
ich9_lpc_initfn() -> ich9_pm_add_properties(). No need to
check it, so remove now dead code.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 hw/acpi/ich9.c | 28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 9b605af21a..02d8546bd3 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -153,17 +153,10 @@ static int ich9_pm_post_load(void *opaque, int version_id)
  .offset = vmstate_offset_pointer(_state, _field, uint8_t),  \
  }
 
-static bool vmstate_test_use_memhp(void *opaque)
-{
-ICH9LPCPMRegs *s = opaque;
-return s->acpi_memory_hotplug.is_enabled;
-}
-
 static const VMStateDescription vmstate_memhp_state = {
 .name = "ich9_pm/memhp",
 .version_id = 1,
 .minimum_version_id = 1,
-.needed = vmstate_test_use_memhp,
 .fields = (const VMStateField[]) {
 VMSTATE_MEMORY_HOTPLUG(acpi_memory_hotplug, ICH9LPCPMRegs),
 VMSTATE_END_OF_LIST()
@@ -335,11 +328,9 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm, 
qemu_irq sci_irq)
 legacy_acpi_cpu_hotplug_init(pci_address_space_io(lpc_pci),
 OBJECT(lpc_pci), >gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
 
-if (pm->acpi_memory_hotplug.is_enabled) {
-acpi_memory_hotplug_init(pci_address_space_io(lpc_pci), 
OBJECT(lpc_pci),
- >acpi_memory_hotplug,
- ACPI_MEMORY_HOTPLUG_BASE);
-}
+acpi_memory_hotplug_init(pci_address_space_io(lpc_pci), OBJECT(lpc_pci),
+ >acpi_memory_hotplug,
+ ACPI_MEMORY_HOTPLUG_BASE);
 }
 
 static void ich9_pm_get_gpe0_blk(Object *obj, Visitor *v, const char *name,
@@ -460,12 +451,7 @@ void ich9_pm_device_pre_plug_cb(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
-!lpc->pm.acpi_memory_hotplug.is_enabled) {
-error_setg(errp,
-   "memory hotplug is not enabled: %s.memory-hotplug-support "
-   "is not set", object_get_typename(OBJECT(lpc)));
-} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 uint64_t negotiated = lpc->smi_negotiated_features;
 
 if (negotiated & BIT_ULL(ICH9_LPC_SMI_F_BROADCAST_BIT) &&
@@ -509,8 +495,7 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler 
*hotplug_dev,
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 acpi_memory_unplug_request_cb(hotplug_dev,
   >pm.acpi_memory_hotplug, dev,
   errp);
@@ -545,8 +530,7 @@ void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 acpi_memory_unplug_cb(>pm.acpi_memory_hotplug, dev, errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!lpc->pm.cpu_hotplug_legacy) {
-- 
2.41.0

[PATCH v4 17/22] hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob

[Philippe Mathieu-Daudé]

PCMachineClass::resizable_acpi_blob was only used by the
pc-i440fx-2.2 machine, which got removed. It is now always
true. Remove it, simplifying acpi_build().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 include/hw/i386/pc.h |  3 ---
 hw/i386/acpi-build.c | 10 --
 hw/i386/pc.c |  1 -
 3 files changed, 14 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index df97df6ca7..10a8ffa0de 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -124,9 +124,6 @@ struct PCMachineClass {
 /* create kvmclock device even when KVM PV features are not exposed */
 bool kvmclock_create_always;
 
-/* resizable acpi blob compat */
-bool resizable_acpi_blob;
-
 /*
  * whether the machine type implements broken 32-bit address space bound
  * check for memory.
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a6f8203460..ab2d4d8dcb 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2688,16 +2688,6 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
  * keep the table size stable for all (max_cpus, max_memory_slots)
  * combinations.
  */
-/* Make sure we have a buffer in case we need to resize the tables. */
-if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
-!pcmc->resizable_acpi_blob) {
-/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
 acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
 
 acpi_align_size(tables->linker->cmd_blob, ACPI_BUILD_ALIGN_SIZE);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 18bef7c85e..c4a7885a3b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1755,7 +1755,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->pvh_enabled = true;
 pcmc->kvmclock_create_always = true;
-pcmc->resizable_acpi_blob = true;
 x86mc->apic_xrupt_override = true;
 assert(!mc->get_hotplug_handler);
 mc->get_hotplug_handler = pc_get_hotplug_handler;
-- 
2.41.0

[PATCH v4 05/22] hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size

[Philippe Mathieu-Daudé]

PCMachineClass::legacy_acpi_table_size was only used by the
pc-i440fx-2.0 machine, which got removed. Remove it and simplify
acpi_build().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 include/hw/i386/pc.h |  1 -
 hw/i386/acpi-build.c | 62 +---
 2 files changed, 12 insertions(+), 51 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 67856f54c3..4ad724601a 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -103,7 +103,6 @@ struct PCMachineClass {
 /* ACPI compat: */
 bool has_acpi_build;
 bool rsdp_in_ram;
-int legacy_acpi_table_size;
 unsigned acpi_data_size;
 int pci_root_uid;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 53f804ac16..a6f8203460 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2499,13 +2499,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 X86MachineState *x86ms = X86_MACHINE(machine);
 DeviceState *iommu = pcms->iommu;
 GArray *table_offsets;
-unsigned facs, dsdt, rsdt, fadt;
+unsigned facs, dsdt, rsdt;
 AcpiPmInfo pm;
 AcpiMiscInfo misc;
 AcpiMcfgInfo mcfg;
 Range pci_hole = {}, pci_hole64 = {};
 uint8_t *u;
-size_t aml_len = 0;
 GArray *tables_blob = tables->table_data;
 AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
 Object *vmgenid_dev;
@@ -2551,19 +2550,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 build_dsdt(tables_blob, tables->linker, , ,
_hole, _hole64, machine);
 
-/* Count the size of the DSDT and SSDT, we will need it for legacy
- * sizing of ACPI tables.
- */
-aml_len += tables_blob->len - dsdt;
-
 /* ACPI tables pointed to by RSDT */
-fadt = tables_blob->len;
 acpi_add_table(table_offsets, tables_blob);
 pm.fadt.facs_tbl_offset = 
 pm.fadt.dsdt_tbl_offset = 
 pm.fadt.xdsdt_tbl_offset = 
 build_fadt(tables_blob, tables->linker, , oem_id, oem_table_id);
-aml_len += tables_blob->len - fadt;
 
 acpi_add_table(table_offsets, tables_blob);
 acpi_build_madt(tables_blob, tables->linker, x86ms,
@@ -2694,49 +2686,19 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
  * too simple to be enough.  4k turned out to be too small an
  * alignment very soon, and in fact it is almost impossible to
  * keep the table size stable for all (max_cpus, max_memory_slots)
- * combinations.  So the table size is always 64k for pc-i440fx-2.1
- * and we give an error if the table grows beyond that limit.
- *
- * We still have the problem of migrating from "-M pc-i440fx-2.0".  For
- * that, we exploit the fact that QEMU 2.1 generates _smaller_ tables
- * than 2.0 and we can always pad the smaller tables with zeros.  We can
- * then use the exact size of the 2.0 tables.
- *
- * All this is for PIIX4, since QEMU 2.0 didn't support Q35 migration.
+ * combinations.
  */
-if (pcmc->legacy_acpi_table_size) {
-/* Subtracting aml_len gives the size of fixed tables.  Then add the
- * size of the PIIX4 DSDT/SSDT in QEMU 2.0.
- */
-int legacy_aml_len =
-pcmc->legacy_acpi_table_size +
-ACPI_BUILD_LEGACY_CPU_AML_SIZE * x86ms->apic_id_limit;
-int legacy_table_size =
-ROUND_UP(tables_blob->len - aml_len + legacy_aml_len,
- ACPI_BUILD_ALIGN_SIZE);
-if ((tables_blob->len > legacy_table_size) &&
-!pcmc->resizable_acpi_blob) {
-/* Should happen only with PCI bridges and -M pc-i440fx-2.0.  */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, legacy_table_size);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
-g_array_set_size(tables_blob, legacy_table_size);
-} else {
-/* Make sure we have a buffer in case we need to resize the tables. */
-if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
-!pcmc->resizable_acpi_blob) {
-/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots. 
 */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
-acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
+/* Make sure we have a buffer in case we need to resize the tables. */
+if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
+!pcmc->resizable_acpi_blob) {
+/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
+

[PATCH v4 18/22] hw/i386/pc: Remove PCMachineClass::rsdp_in_ram

[Philippe Mathieu-Daudé]

PCMachineClass::rsdp_in_ram was only used by the
pc-i440fx-2.2 machine, which got removed. It is
now always true. Remove it, simplifying acpi_setup().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 include/hw/i386/pc.h |  1 -
 hw/i386/acpi-build.c | 35 ---
 hw/i386/pc.c |  1 -
 3 files changed, 4 insertions(+), 33 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 10a8ffa0de..96ccb4583f 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -100,7 +100,6 @@ struct PCMachineClass {
 
 /* ACPI compat: */
 bool has_acpi_build;
-bool rsdp_in_ram;
 unsigned acpi_data_size;
 int pci_root_uid;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ab2d4d8dcb..ed0adb0e82 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2495,7 +2495,6 @@ static
 void acpi_build(AcpiBuildTables *tables, MachineState *machine)
 {
 PCMachineState *pcms = PC_MACHINE(machine);
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(machine);
 DeviceState *iommu = pcms->iommu;
 GArray *table_offsets;
@@ -2667,16 +2666,6 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 .rsdt_tbl_offset = ,
 };
 build_rsdp(tables->rsdp, tables->linker, _data);
-if (!pcmc->rsdp_in_ram) {
-/* We used to allocate some extra space for RSDP revision 2 but
- * only used the RSDP revision 0 space. The extra bytes were
- * zeroed out and not used.
- * Here we continue wasting those extra 16 bytes to make sure we
- * don't break migration for machine types 2.2 and older due to
- * RSDP blob size mismatch.
- */
-build_append_int_noprefix(tables->rsdp, 0, 16);
-}
 }
 
 /* We'll expose it all to Guest so we want to reduce
@@ -2755,7 +2744,6 @@ static const VMStateDescription vmstate_acpi_build = {
 void acpi_setup(void)
 {
 PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(pcms);
 AcpiBuildTables tables;
 AcpiBuildState *build_state;
@@ -2817,25 +2805,10 @@ void acpi_setup(void)
tables.vmgenid);
 }
 
-if (!pcmc->rsdp_in_ram) {
-/*
- * Keep for compatibility with old machine types.
- * Though RSDP is small, its contents isn't immutable, so
- * we'll update it along with the rest of tables on guest access.
- */
-uint32_t rsdp_size = acpi_data_len(tables.rsdp);
-
-build_state->rsdp = g_memdup(tables.rsdp->data, rsdp_size);
-fw_cfg_add_file_callback(x86ms->fw_cfg, ACPI_BUILD_RSDP_FILE,
- acpi_build_update, NULL, build_state,
- build_state->rsdp, rsdp_size, true);
-build_state->rsdp_mr = NULL;
-} else {
-build_state->rsdp = NULL;
-build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
- build_state, tables.rsdp,
- ACPI_BUILD_RSDP_FILE);
-}
+build_state->rsdp = NULL;
+build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
+ build_state, tables.rsdp,
+ ACPI_BUILD_RSDP_FILE);
 
 qemu_register_reset(acpi_build_reset, build_state);
 acpi_build_reset(build_state);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c4a7885a3b..a1b0e94523 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1745,7 +1745,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 
 pcmc->pci_enabled = true;
 pcmc->has_acpi_build = true;
-pcmc->rsdp_in_ram = true;
 pcmc->smbios_defaults = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-- 
2.41.0

[PATCH v4 14/22] hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()

[Philippe Mathieu-Daudé]

'legacy_align' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Reviewed-by: Zhao Liu 
---
 include/hw/mem/pc-dimm.h | 3 +--
 hw/arm/virt.c| 2 +-
 hw/i386/pc.c | 2 +-
 hw/loongarch/virt.c  | 2 +-
 hw/mem/pc-dimm.c | 6 ++
 hw/ppc/spapr.c   | 2 +-
 6 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
index 322bebe555..fe0f3ea963 100644
--- a/include/hw/mem/pc-dimm.h
+++ b/include/hw/mem/pc-dimm.h
@@ -66,8 +66,7 @@ struct PCDIMMDeviceClass {
 void (*unrealize)(PCDIMMDevice *dimm);
 };
 
-void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine,
-  const uint64_t *legacy_align, Error **errp);
+void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine, Error **errp);
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine);
 void pc_dimm_unplug(PCDIMMDevice *dimm, MachineState *machine);
 #endif
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a55ef916cb..7af05a6a2d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2736,7 +2736,7 @@ static void virt_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void virt_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c7bfdfc1e1..9ba21b9967 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1309,7 +1309,7 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 00d3005e54..af71bd2a99 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -1025,7 +1025,7 @@ static bool memhp_type_supported(DeviceState *dev)
 static void virt_mem_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
  Error **errp)
 {
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void virt_machine_device_pre_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 37f1f4ccfd..836384a90f 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -44,8 +44,7 @@ static MemoryRegion *pc_dimm_get_memory_region(PCDIMMDevice 
*dimm, Error **errp)
 return host_memory_backend_get_memory(dimm->hostmem);
 }
 
-void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine,
-  const uint64_t *legacy_align, Error **errp)
+void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine, Error **errp)
 {
 Error *local_err = NULL;
 int slot;
@@ -70,8 +69,7 @@ void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState 
*machine,
 _abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
 
-memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, legacy_align,
-   errp);
+memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, NULL, errp);
 }
 
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index e9bc97fee0..f147876dc9 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3668,7 +3668,7 @@ static void spapr_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), errp);
 }
 
 struct SpaprDimmState {
-- 
2.41.0

[PATCH v4 16/22] hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.2 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c| 23 ---
 hw/i386/pc_piix.c   | 21 -
 5 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index a2a1b9d337..75bf0f4886 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.2`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
+``pc-i440fx-2.3`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
 

 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 01c55103d3..4664974a8b 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.1`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 231aae92ed..df97df6ca7 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -274,9 +274,6 @@ extern const size_t pc_compat_2_4_len;
 extern GlobalProperty pc_compat_2_3[];
 extern const size_t pc_compat_2_3_len;
 
-extern GlobalProperty pc_compat_2_2[];
-extern const size_t pc_compat_2_2_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 633724f177..18bef7c85e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -281,29 +281,6 @@ GlobalProperty pc_compat_2_3[] = {
 };
 const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
 
-GlobalProperty pc_compat_2_2[] = {
-PC_CPU_MODEL_IDS("2.2.0")
-{ "kvm64" "-" TYPE_X86_CPU, "vme", "off" },
-{ "kvm32" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Conroe" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Penryn" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Nehalem" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Westmere" "-" TYPE_X86_CPU, "vme", "off" },
-{ "SandyBridge" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G1" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G2" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G3" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G4" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G5" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "f16c", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "rdrand", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "f16c", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "rdrand", "off" },
-};
-const size_t pc_compat_2_2_len = G_N_ELEMENTS(pc_compat_2_2);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index dcf50684a4..30bcd86ee6 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -429,11 +429,6 @@ static void pc_compat_2_3_fn(MachineState *machine)
 }
 }
 
-static void pc_compat_2_2_fn(MachineState *machine)
-{
-pc_compat_2_3_fn(machine);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -828,22 +823,6 @@ static void pc_i440fx_2_3_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
   pc_i440fx_2_3_machine_options);
 
-static void pc_i440fx_2_2_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_3_machine_options(m);
-m->hw_version = "2.2.0";
-m->default_machine_opts = "firmware=bios-256k.bin,suppress-vmdesc=on";
-compat_props_add(m->compat_props, hw_compat_2_2, hw_compat_2_2_len);
-compat_props_add(m->compat_props, pc_compat_2_2, pc_compat_2_2_len);
-pcmc->rsdp_in_ram = false;
-pcmc->resizable_acpi_blob = false;
-}
-
-DEFINE_I440FX_MACHINE(v2_2, "pc-i440fx-2.2", 

[PATCH v4 01/22] hw/i386/pc: Deprecate 2.4 to 2.12 pc-i440fx machines

[Philippe Mathieu-Daudé]

Similarly to the commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated",
deprecate the 2.4 to 2.12 machines.

Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 docs/about/deprecated.rst | 4 ++--
 hw/i386/pc_piix.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..47234da329 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,8 +219,8 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
-'
+``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
+
 
 These old machine types are quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 18ba076609..817d99c0ce 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -727,6 +727,7 @@ DEFINE_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
 static void pc_i440fx_2_12_machine_options(MachineClass *m)
 {
 pc_i440fx_3_0_machine_options(m);
+m->deprecation_reason = "old and unattended - use a newer version instead";
 compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
 compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
 }
@@ -832,7 +833,6 @@ static void pc_i440fx_2_3_machine_options(MachineClass *m)
 {
 pc_i440fx_2_4_machine_options(m);
 m->hw_version = "2.3.0";
-m->deprecation_reason = "old and unattended - use a newer version instead";
 compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
 compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
 }
-- 
2.41.0

[PATCH v4 15/22] hw/mem/memory-device: Remove legacy_align from memory_device_pre_plug()

[Philippe Mathieu-Daudé]

'legacy_align' is always NULL, remove it, simplifying
memory_device_pre_plug().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Reviewed-by: Zhao Liu 
---
 include/hw/mem/memory-device.h |  2 +-
 hw/i386/pc.c   |  3 +--
 hw/mem/memory-device.c | 12 
 hw/mem/pc-dimm.c   |  2 +-
 hw/virtio/virtio-md-pci.c  |  2 +-
 5 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/include/hw/mem/memory-device.h b/include/hw/mem/memory-device.h
index e0571c8a31..c0a58087cc 100644
--- a/include/hw/mem/memory-device.h
+++ b/include/hw/mem/memory-device.h
@@ -169,7 +169,7 @@ uint64_t get_plugged_memory_size(void);
 unsigned int memory_devices_get_reserved_memslots(void);
 bool memory_devices_memslot_auto_decision_active(void);
 void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp);
+Error **errp);
 void memory_device_plug(MemoryDeviceState *md, MachineState *ms);
 void memory_device_unplug(MemoryDeviceState *md, MachineState *ms);
 uint64_t memory_device_get_region_size(const MemoryDeviceState *md,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 9ba21b9967..633724f177 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1377,8 +1377,7 @@ static void pc_hv_balloon_pre_plug(HotplugHandler 
*hotplug_dev,
 {
 /* The vmbus handler has no hotplug handler; we should never end up here. 
*/
 g_assert(!dev->hotplugged);
-memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), NULL,
-   errp);
+memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void pc_hv_balloon_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c
index e098585cda..a5f279adcc 100644
--- a/hw/mem/memory-device.c
+++ b/hw/mem/memory-device.c
@@ -345,7 +345,7 @@ uint64_t get_plugged_memory_size(void)
 }
 
 void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp)
+Error **errp)
 {
 const MemoryDeviceClass *mdc = MEMORY_DEVICE_GET_CLASS(md);
 Error *local_err = NULL;
@@ -388,14 +388,10 @@ void memory_device_pre_plug(MemoryDeviceState *md, 
MachineState *ms,
 return;
 }
 
-if (legacy_align) {
-align = *legacy_align;
-} else {
-if (mdc->get_min_alignment) {
-align = mdc->get_min_alignment(md);
-}
-align = MAX(align, memory_region_get_alignment(mr));
+if (mdc->get_min_alignment) {
+align = mdc->get_min_alignment(md);
 }
+align = MAX(align, memory_region_get_alignment(mr));
 addr = mdc->get_addr(md);
 addr = memory_device_get_free_addr(ms, !addr ? NULL : , align,
memory_region_size(mr), _err);
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 836384a90f..27919ca45d 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -69,7 +69,7 @@ void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState 
*machine, Error **errp)
 _abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
 
-memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, NULL, errp);
+memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, errp);
 }
 
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine)
diff --git a/hw/virtio/virtio-md-pci.c b/hw/virtio/virtio-md-pci.c
index 62bfb7920b..9ec5067662 100644
--- a/hw/virtio/virtio-md-pci.c
+++ b/hw/virtio/virtio-md-pci.c
@@ -37,7 +37,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState 
*ms, Error **errp)
  * First, see if we can plug this memory device at all. If that
  * succeeds, branch of to the actual hotplug handler.
  */
-memory_device_pre_plug(md, ms, NULL, _err);
+memory_device_pre_plug(md, ms, _err);
 if (!local_err && bus_handler) {
 hotplug_handler_pre_plug(bus_handler, dev, _err);
 }
-- 
2.41.0

[PATCH v4 12/22] hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()

[Philippe Mathieu-Daudé]

'smbios_encode_uuid' is always true, remove it,
simplifying smbios_encode_uuid().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 hw/smbios/smbios.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 8261eb716f..3b7703489d 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -30,7 +30,6 @@
 #include "hw/pci/pci_device.h"
 #include "smbios_build.h"
 
-static const bool smbios_uuid_encoded = true;
 /*
  * SMBIOS tables provided by user with '-smbios file=' option
  */
@@ -600,11 +599,9 @@ static void smbios_build_type_0_table(void)
 static void smbios_encode_uuid(struct smbios_uuid *uuid, QemuUUID *in)
 {
 memcpy(uuid, in, 16);
-if (smbios_uuid_encoded) {
-uuid->time_low = bswap32(uuid->time_low);
-uuid->time_mid = bswap16(uuid->time_mid);
-uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
-}
+uuid->time_low = bswap32(uuid->time_low);
+uuid->time_mid = bswap16(uuid->time_mid);
+uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
 }
 
 static void smbios_build_type_1_table(void)
-- 
2.41.0

[PATCH v4 02/22] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

[Philippe Mathieu-Daudé]

The pc-i440fx-2.0 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Reviewed-by: Zhao Liu 
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c| 15 -
 hw/i386/pc_piix.c   | 37 -
 5 files changed, 2 insertions(+), 57 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 47234da329..b09ae3d55d 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
+``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up 
to ``pc-i440fx-2.12`` (since 9.1)
 

 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index f9cf874f7b..51119e623f 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-1.7`` (removed in 4.0 up to 8.2)
+``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 27a68071d7..67856f54c3 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -285,9 +285,6 @@ extern const size_t pc_compat_2_2_len;
 extern GlobalProperty pc_compat_2_1[];
 extern const size_t pc_compat_2_1_len;
 
-extern GlobalProperty pc_compat_2_0[];
-extern const size_t pc_compat_2_0_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5c21b0c4db..172814f604 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -311,21 +311,6 @@ GlobalProperty pc_compat_2_1[] = {
 };
 const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
 
-GlobalProperty pc_compat_2_0[] = {
-PC_CPU_MODEL_IDS("2.0.0")
-{ "virtio-scsi-pci", "any_layout", "off" },
-{ "PIIX4_PM", "memory-hotplug-support", "off" },
-{ "apic", "version", "0x11" },
-{ "nec-usb-xhci", "superspeed-ports-first", "off" },
-{ "nec-usb-xhci", "force-pcie-endcap", "on" },
-{ "pci-serial", "prog_if", "0" },
-{ "pci-serial-2x", "prog_if", "0" },
-{ "pci-serial-4x", "prog_if", "0" },
-{ "virtio-net-pci", "guest_announce", "off" },
-{ "ICH9-LPC", "memory-hotplug-support", "off" },
-};
-const size_t pc_compat_2_0_len = G_N_ELEMENTS(pc_compat_2_0);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 817d99c0ce..9e1bca7b17 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -441,11 +441,6 @@ static void pc_compat_2_1_fn(MachineState *machine)
 x86_cpu_change_kvm_default("svm", NULL);
 }
 
-static void pc_compat_2_0_fn(MachineState *machine)
-{
-pc_compat_2_1_fn(machine);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -872,38 +867,6 @@ static void pc_i440fx_2_1_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
   pc_i440fx_2_1_machine_options);
 
-static void pc_i440fx_2_0_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_1_machine_options(m);
-m->hw_version = "2.0.0";
-compat_props_add(m->compat_props, pc_compat_2_0, pc_compat_2_0_len);
-pcmc->smbios_legacy_mode = true;
-pcmc->has_reserved_memory = false;
-/* This value depends on the actual DSDT and SSDT compiled into
- * the source QEMU; unfortunately it depends on the binary and
- * not on the machine type, so we cannot make pc-i440fx-1.7 work on
- * both QEMU 1.7 and QEMU 2.0.
- *
- * Large variations cause migration to fail for more than one
- * consecutive value of the "-smp" maxcpus option.
- *
- * For small variations of the kind caused by different iasl versions,
- * the 4k rounding usually leaves slack.  However, there could be still
- * one or two values that break.  For QEMU 1.7 and QEMU 2.0 the
- * slack is 

[PATCH v4 13/22] hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm

[Philippe Mathieu-Daudé]

PCMachineClass::enforce_aligned_dimm was only used by the
pc-i440fx-2.1 machine, which got removed. It is now always
true. Remove it, simplifying pc_get_device_memory_range().
Update the comment in Avocado test_phybits_low_pse36().

Reviewed-by: Zhao Liu 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h  |  3 ---
 hw/i386/pc.c  | 14 +++---
 tests/avocado/mem-addr-space-check.py |  9 -
 3 files changed, 7 insertions(+), 19 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index c2d9af36b2..231aae92ed 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -74,8 +74,6 @@ typedef struct PCMachineState {
  *
  * Compat fields:
  *
- * @enforce_aligned_dimm: check that DIMM's address/size is aligned by
- *backend's alignment value if provided
  * @acpi_data_size: Size of the chunk of memory at the top of RAM
  *  for the BIOS ACPI tables and other BIOS
  *  datastructures.
@@ -114,7 +112,6 @@ struct PCMachineClass {
 /* RAM / address space compat: */
 bool gigabyte_align;
 bool has_reserved_memory;
-bool enforce_aligned_dimm;
 bool broken_reserved_end;
 bool enforce_amd_1tb_hole;
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2bf1bfd5b2..c7bfdfc1e1 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -716,7 +716,6 @@ static void pc_get_device_memory_range(PCMachineState *pcms,
hwaddr *base,
ram_addr_t *device_mem_size)
 {
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 MachineState *machine = MACHINE(pcms);
 ram_addr_t size;
 hwaddr addr;
@@ -724,10 +723,8 @@ static void pc_get_device_memory_range(PCMachineState 
*pcms,
 size = machine->maxram_size - machine->ram_size;
 addr = ROUND_UP(pc_above_4g_end(pcms), 1 * GiB);
 
-if (pcmc->enforce_aligned_dimm) {
-/* size device region assuming 1G page max alignment per slot */
-size += (1 * GiB) * machine->ram_slots;
-}
+/* size device region assuming 1G page max alignment per slot */
+size += (1 * GiB) * machine->ram_slots;
 
 *base = addr;
 *device_mem_size = size;
@@ -1285,12 +1282,9 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq 
*i8259_irqs)
 static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
Error **errp)
 {
-const PCMachineState *pcms = PC_MACHINE(hotplug_dev);
 const X86MachineState *x86ms = X86_MACHINE(hotplug_dev);
-const PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 const MachineState *ms = MACHINE(hotplug_dev);
 const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
-const uint64_t legacy_align = TARGET_PAGE_SIZE;
 Error *local_err = NULL;
 
 /*
@@ -1315,8 +1309,7 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev),
- pcmc->enforce_aligned_dimm ? NULL : _align, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
@@ -1780,7 +1773,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->smbios_defaults = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-pcmc->enforce_aligned_dimm = true;
 pcmc->enforce_amd_1tb_hole = true;
 /* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
  * to be used at the moment, 32K should be enough for a while.  */
diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
index af019969c0..85541ea051 100644
--- a/tests/avocado/mem-addr-space-check.py
+++ b/tests/avocado/mem-addr-space-check.py
@@ -31,11 +31,10 @@ def test_phybits_low_pse36(self):
 at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
 we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
 hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
-for dimm alignment for all newer machines (see enforce_aligned_dimm
-property for pc machines and pc_get_device_memory_range()). That leaves
-total hotpluggable actual memory size of 59 GiB. If the VM is started
-with 0.5 GiB of memory, maxmem should be set to a maximum value of
-59.5 GiB to ensure that the processor can address all memory directly.
+for dimm alignment for all machines. That leaves total hotpluggable
+actual memory size of 59 GiB. If the VM is started with 0.5 GiB of
+memory, maxmem should be set to a maximum value of 59.5 GiB to ensure
+that the processor can address all memory directly.
 Note that 64-bit pci hole size is 0 in this case. If maxmem is set to
 59.6G, QEMU 

[PATCH v4 03/22] hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag

[Philippe Mathieu-Daudé]

XHCI_FLAG_FORCE_PCIE_ENDCAP was only used by the
pc-i440fx-2.0 machine, which got removed. Remove it
and simplify usb_xhci_pci_realize().

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 hw/usb/hcd-xhci.h | 1 -
 hw/usb/hcd-xhci-nec.c | 2 --
 hw/usb/hcd-xhci-pci.c | 3 +--
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 98f598382a..1efa4858fb 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -37,7 +37,6 @@ typedef struct XHCIEPContext XHCIEPContext;
 
 enum xhci_flags {
 XHCI_FLAG_SS_FIRST = 1,
-XHCI_FLAG_FORCE_PCIE_ENDCAP,
 XHCI_FLAG_ENABLE_STREAMS,
 };
 
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index 328e5bfe7c..5d5b069cf9 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -43,8 +43,6 @@ static Property nec_xhci_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT("superspeed-ports-first", XHCINecState, flags,
 XHCI_FLAG_SS_FIRST, true),
-DEFINE_PROP_BIT("force-pcie-endcap", XHCINecState, flags,
-XHCI_FLAG_FORCE_PCIE_ENDCAP, false),
 DEFINE_PROP_UINT32("intrs", XHCINecState, intrs, XHCI_MAXINTRS),
 DEFINE_PROP_UINT32("slots", XHCINecState, slots, XHCI_MAXSLOTS),
 DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 4423983308..cbad96f393 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -148,8 +148,7 @@ static void usb_xhci_pci_realize(struct PCIDevice *dev, 
Error **errp)
  PCI_BASE_ADDRESS_MEM_TYPE_64,
  >xhci.mem);
 
-if (pci_bus_is_express(pci_get_bus(dev)) ||
-xhci_get_flag(>xhci, XHCI_FLAG_FORCE_PCIE_ENDCAP)) {
+if (pci_bus_is_express(pci_get_bus(dev))) {
 ret = pcie_endpoint_cap_init(dev, 0xa0);
 assert(ret > 0);
 }
-- 
2.41.0

[PATCH v4 00/22] hw/i386: Remove deprecated pc-i440fx-2.0 -> 2.3 machines

[Philippe Mathieu-Daudé]

Series fully reviewed.

Since v3:
- Deprecate up to 2.12 (Thomas)

Since v2:
- Addressed Zhao review comments

Since v1:
- Addressed Zhao and Thomas review comments

Kill legacy code, because we need to evolve.

I ended there via dynamic machine -> ICH9 -> legacy ACPI...

This should also help Igor cleanups:
http://lore.kernel.org/qemu-devel/20240326171632.3cc75...@imammedo.users.ipa.redhat.com/

Philippe Mathieu-Daudé (22):
  hw/i386/pc: Deprecate 2.4 to 2.12 pc-i440fx machines
  hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine
  hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag
  hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag
  hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size
  hw/acpi/ich9: Remove 'memory-hotplug-support' property
  hw/acpi/ich9: Remove dead code related to 'acpi_memory_hotplug'
  hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine
  target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'
  hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded
  hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()
  hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()
  hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm
  hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()
  hw/mem/memory-device: Remove legacy_align from
memory_device_pre_plug()
  hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine
  hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob
  hw/i386/pc: Remove PCMachineClass::rsdp_in_ram
  hw/i386/acpi: Remove AcpiBuildState::rsdp field
  hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine
  target/i386: Remove X86CPU::kvm_no_smi_migration field
  hw/i386/pc: Replace PCMachineClass::acpi_data_size by
PC_ACPI_DATA_SIZE

 docs/about/deprecated.rst |   4 +-
 docs/about/removed-features.rst   |   2 +-
 hw/usb/hcd-xhci.h |   4 +-
 include/hw/firmware/smbios.h  |   3 +-
 include/hw/i386/pc.h  |  22 --
 include/hw/mem/memory-device.h|   2 +-
 include/hw/mem/pc-dimm.h  |   3 +-
 target/i386/cpu.h |   3 -
 target/i386/kvm/kvm-cpu.h |  41 --
 hw/acpi/ich9.c|  46 ++-
 hw/arm/virt.c |   5 +-
 hw/i386/acpi-build.c  |  95 ++-
 hw/i386/fw_cfg.c  |   3 +-
 hw/i386/pc.c  | 107 --
 hw/i386/pc_piix.c | 102 +---
 hw/loongarch/virt.c   |   4 +-
 hw/mem/memory-device.c|  12 +--
 hw/mem/pc-dimm.c  |   6 +-
 hw/ppc/spapr.c|   2 +-
 hw/riscv/virt.c   |   2 +-
 hw/smbios/smbios.c|  13 +---
 hw/usb/hcd-xhci-nec.c |   4 -
 hw/usb/hcd-xhci-pci.c |   4 +-
 hw/usb/hcd-xhci.c |  42 ++
 hw/virtio/virtio-md-pci.c |   2 +-
 target/i386/cpu.c |   2 -
 target/i386/kvm/kvm-cpu.c |   3 +-
 target/i386/kvm/kvm.c |   7 +-
 tests/avocado/mem-addr-space-check.py |   9 +--
 29 files changed, 69 insertions(+), 485 deletions(-)
 delete mode 100644 target/i386/kvm/kvm-cpu.h

-- 
2.41.0

[PATCH v4 04/22] hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag

[Philippe Mathieu-Daudé]

XHCI_FLAG_SS_FIRST was only used by the pc-i440fx-2.0 machine,
which got removed. Remove it and simplify various functions in
hcd-xhci.c.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Zhao Liu 
---
 hw/usb/hcd-xhci.h |  3 +--
 hw/usb/hcd-xhci-nec.c |  2 --
 hw/usb/hcd-xhci-pci.c |  1 -
 hw/usb/hcd-xhci.c | 42 --
 4 files changed, 9 insertions(+), 39 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 1efa4858fb..fe16d7ad05 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -36,8 +36,7 @@ typedef struct XHCIStreamContext XHCIStreamContext;
 typedef struct XHCIEPContext XHCIEPContext;
 
 enum xhci_flags {
-XHCI_FLAG_SS_FIRST = 1,
-XHCI_FLAG_ENABLE_STREAMS,
+XHCI_FLAG_ENABLE_STREAMS = 1,
 };
 
 typedef enum TRBType {
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index 5d5b069cf9..0c063b3697 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -41,8 +41,6 @@ struct XHCINecState {
 static Property nec_xhci_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO("msi", XHCIPciState, msi, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
-DEFINE_PROP_BIT("superspeed-ports-first", XHCINecState, flags,
-XHCI_FLAG_SS_FIRST, true),
 DEFINE_PROP_UINT32("intrs", XHCINecState, intrs, XHCI_MAXINTRS),
 DEFINE_PROP_UINT32("slots", XHCINecState, slots, XHCI_MAXSLOTS),
 DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index cbad96f393..264d7ebb77 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -242,7 +242,6 @@ static void qemu_xhci_instance_init(Object *obj)
 s->msix = ON_OFF_AUTO_AUTO;
 xhci->numintrs = XHCI_MAXINTRS;
 xhci->numslots = XHCI_MAXSLOTS;
-xhci_set_flag(xhci, XHCI_FLAG_SS_FIRST);
 }
 
 static const TypeInfo qemu_xhci_info = {
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index ad40232eb6..b6411f0bda 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -541,18 +541,10 @@ static XHCIPort *xhci_lookup_port(XHCIState *xhci, struct 
USBPort *uport)
 case USB_SPEED_LOW:
 case USB_SPEED_FULL:
 case USB_SPEED_HIGH:
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-index = uport->index + xhci->numports_3;
-} else {
-index = uport->index;
-}
+index = uport->index + xhci->numports_3;
 break;
 case USB_SPEED_SUPER:
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-index = uport->index;
-} else {
-index = uport->index + xhci->numports_2;
-}
+index = uport->index;
 break;
 default:
 return NULL;
@@ -2779,11 +2771,7 @@ static uint64_t xhci_cap_read(void *ptr, hwaddr reg, 
unsigned size)
 ret = 0x20425355; /* "USB " */
 break;
 case 0x28: /* Supported Protocol:08 */
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-ret = (xhci->numports_2<<8) | (xhci->numports_3+1);
-} else {
-ret = (xhci->numports_2<<8) | 1;
-}
+ret = (xhci->numports_2 << 8) | (xhci->numports_3 + 1);
 break;
 case 0x2c: /* Supported Protocol:0c */
 ret = 0x; /* reserved */
@@ -2795,11 +2783,7 @@ static uint64_t xhci_cap_read(void *ptr, hwaddr reg, 
unsigned size)
 ret = 0x20425355; /* "USB " */
 break;
 case 0x38: /* Supported Protocol:08 */
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-ret = (xhci->numports_3<<8) | 1;
-} else {
-ret = (xhci->numports_3<<8) | (xhci->numports_2+1);
-}
+ret = (xhci->numports_3 << 8) | 1;
 break;
 case 0x3c: /* Supported Protocol:0c */
 ret = 0x; /* reserved */
@@ -3349,13 +,8 @@ static void usb_xhci_init(XHCIState *xhci)
 for (i = 0; i < usbports; i++) {
 speedmask = 0;
 if (i < xhci->numports_2) {
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-port = >ports[i + xhci->numports_3];
-port->portnr = i + 1 + xhci->numports_3;
-} else {
-port = >ports[i];
-port->portnr = i + 1;
-}
+port = >ports[i + xhci->numports_3];
+port->portnr = i + 1 + xhci->numports_3;
 port->uport = >uports[i];
 port->speedmask =
 USB_SPEED_MASK_LOW  |
@@ -3366,13 +3345,8 @@ static void usb_xhci_init(XHCIState *xhci)
 speedmask |= port->speedmask;
 }
 if (i < xhci->numports_3) {
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-port = >ports[i];
-port->portnr = i + 1;
-} else {
-port = >ports[i + xhci->numports_2];
-port->portnr = i + 1 + xhci->numports_2;
-}
+port = >ports[i];
+ 

[PATCH v2 4/4] hw/i2c: Convert to spec v7 terminology (manually)

[Philippe Mathieu-Daudé]

See previous commit for rationale.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i2c/i2c.h | 52 ++--
 hw/i2c/core.c|  2 +-
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
index 75c8154138..8908267c17 100644
--- a/include/hw/i2c/i2c.h
+++ b/include/hw/i2c/i2c.h
@@ -6,8 +6,8 @@
 
 /*
  * The QEMU I2C implementation only supports simple transfers that complete
- * immediately.  It does not support slave devices that need to be able to
- * defer their response (eg. CPU slave interfaces where the data is supplied
+ * immediately.  It does not support target devices that need to be able to
+ * defer their response (eg. CPU target interfaces where the data is supplied
  * by the device driver in response to an interrupt).
  */
 
@@ -28,23 +28,23 @@ OBJECT_DECLARE_TYPE(I2CTarget, I2CTargetClass,
 struct I2CTargetClass {
 DeviceClass parent_class;
 
-/* Master to slave. Returns non-zero for a NAK, 0 for success. */
+/* Controller to target. Returns non-zero for a NAK, 0 for success. */
 int (*send)(I2CTarget *s, uint8_t data);
 
 /*
- * Master to slave (asynchronous).
- * Receiving slave must call i2c_ack().
+ * Controller to target (asynchronous).
+ * Receiving target must call i2c_ack().
  */
 void (*send_async)(I2CTarget *s, uint8_t data);
 
 /*
- * Slave to master.  This cannot fail, the device should always
+ * Target to controller.  This cannot fail, the device should always
  * return something here.
  */
 uint8_t (*recv)(I2CTarget *s);
 
 /*
- * Notify the slave of a bus state change.  For start event,
+ * Notify the target of a bus state change.  For start event,
  * returns non-zero to NAK an operation.  For other events the
  * return code is not used and should be zero.
  */
@@ -96,7 +96,7 @@ struct I2CBus {
 uint8_t saved_address;
 bool broadcast;
 
-/* Set from slave currently mastering the bus. */
+/* Set from target currently controlling the bus. */
 QEMUBH *bh;
 };
 
@@ -107,7 +107,7 @@ int i2c_bus_busy(I2CBus *bus);
  * i2c_start_transfer: start a transfer on an I2C bus.
  *
  * @bus: #I2CBus to be used
- * @address: address of the slave
+ * @address: address of the target
  * @is_recv: indicates the transfer direction
  *
  * When @is_recv is a known boolean constant, use the
@@ -121,7 +121,7 @@ int i2c_start_transfer(I2CBus *bus, uint8_t address, bool 
is_recv);
  * i2c_start_recv: start a 'receive' transfer on an I2C bus.
  *
  * @bus: #I2CBus to be used
- * @address: address of the slave
+ * @address: address of the target
  *
  * Returns: 0 on success, -1 on error
  */
@@ -131,7 +131,7 @@ int i2c_start_recv(I2CBus *bus, uint8_t address);
  * i2c_start_send: start a 'send' transfer on an I2C bus.
  *
  * @bus: #I2CBus to be used
- * @address: address of the slave
+ * @address: address of the target
  *
  * Returns: 0 on success, -1 on error
  */
@@ -141,7 +141,7 @@ int i2c_start_send(I2CBus *bus, uint8_t address);
  * i2c_start_send_async: start an asynchronous 'send' transfer on an I2C bus.
  *
  * @bus: #I2CBus to be used
- * @address: address of the slave
+ * @address: address of the target
  *
  * Return: 0 on success, -1 on error
  */
@@ -161,9 +161,9 @@ bool i2c_scan_bus(I2CBus *bus, uint8_t address, bool 
broadcast,
   I2CNodeList *current_devs);
 
 /**
- * Create an I2C slave device on the heap.
+ * Create an I2C target device on the heap.
  * @name: a device type name
- * @addr: I2C address of the slave when put on a bus
+ * @addr: I2C address of the target when put on a bus
  *
  * This only initializes the device state structure and allows
  * properties to be set. Type @name must exist. The device still
@@ -172,10 +172,10 @@ bool i2c_scan_bus(I2CBus *bus, uint8_t address, bool 
broadcast,
 I2CTarget *i2c_target_new(const char *name, uint8_t addr);
 
 /**
- * Create and realize an I2C slave device on the heap.
+ * Create and realize an I2C target device on the heap.
  * @bus: I2C bus to put it on
- * @name: I2C slave device type name
- * @addr: I2C address of the slave when put on a bus
+ * @name: I2C target device type name
+ * @addr: I2C address of the target when put on a bus
  *
  * Create the device state structure, initialize it, put it on the
  * specified @bus, and drop the reference to it (the device is realized).
@@ -184,10 +184,10 @@ I2CTarget *i2c_target_create_simple(I2CBus *bus,
 const char *name, uint8_t addr);
 
 /**
- * Realize and drop a reference an I2C slave device
- * @dev: I2C slave device to realize
+ * Realize and drop a reference an I2C target device
+ * @dev: I2C target device to realize
  * @bus: I2C bus to put it on
- * @addr: I2C address of the slave on the bus
+ * @addr: I2C address of the target on the bus
  * @errp: pointer to NULL initialized error object
  *
  * 

[PATCH v2 0/4] hw/i2c: Convert to spec v7 (inclusive) terminology

[Philippe Mathieu-Daudé]

Since v1:
- Convert TYPE_I2C_TARGET definition (Paolo)

Mechanical (mostly) conversion inspired by Wolfram [*] to
use inclusive terminology, similarly to the other renames
we did 3 years ago, shortly before the I2C spec v7 was
published.

This series convert core I2C. Following will convert the
devices and SMBus.

[*] 
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/

Philippe Mathieu-Daudé (4):
  hw/i2c: Fix checkpatch block comment warnings
  hw/i2c: Fix checkpatch line over 80 chars warnings
  hw/i2c: Convert to spec v7 terminology (automatically)
  hw/i2c: Convert to spec v7 terminology (manually)

 include/hw/display/i2c-ddc.h |   2 +-
 include/hw/gpio/pca9552.h|   2 +-
 include/hw/gpio/pca9554.h|   2 +-
 include/hw/i2c/aspeed_i2c.h  |   4 +-
 include/hw/i2c/i2c.h | 123 ++---
 include/hw/i2c/i2c_mux_pca954x.h |   2 +-
 include/hw/i2c/smbus_slave.h |   4 +-
 include/hw/nvram/eeprom_at24c.h  |   8 +-
 include/hw/sensor/tmp105.h   |   2 +-
 hw/arm/aspeed.c  | 290 +--
 hw/arm/bananapi_m2u.c|   2 +-
 hw/arm/cubieboard.c  |   2 +-
 hw/arm/musicpal.c|   6 +-
 hw/arm/npcm7xx_boards.c  |  44 ++---
 hw/arm/nseries.c |   6 +-
 hw/arm/pxa2xx.c  |  36 ++--
 hw/arm/realview.c|   2 +-
 hw/arm/spitz.c   |  12 +-
 hw/arm/stellaris.c   |   2 +-
 hw/arm/tosa.c|  14 +-
 hw/arm/versatilepb.c |   2 +-
 hw/arm/vexpress.c|   2 +-
 hw/arm/z2.c  |  20 +--
 hw/audio/wm8750.c|  18 +-
 hw/display/ati.c |   4 +-
 hw/display/i2c-ddc.c |  10 +-
 hw/display/sii9022.c |  16 +-
 hw/display/sm501.c   |   2 +-
 hw/display/ssd0303.c |  14 +-
 hw/display/xlnx_dp.c |   2 +-
 hw/gpio/max7310.c|  14 +-
 hw/gpio/pca9552.c|  14 +-
 hw/gpio/pca9554.c|  14 +-
 hw/gpio/pcf8574.c|  12 +-
 hw/i2c/aspeed_i2c.c  |  16 +-
 hw/i2c/core.c|  90 +-
 hw/i2c/i2c_mux_pca954x.c |   6 +-
 hw/i2c/imx_i2c.c |   2 +-
 hw/i2c/smbus_slave.c |  12 +-
 hw/input/lm832x.c|  14 +-
 hw/misc/axp2xx.c |  14 +-
 hw/misc/i2c-echo.c   |  14 +-
 hw/nvram/eeprom_at24c.c  |  26 +--
 hw/ppc/e500.c|   2 +-
 hw/ppc/pnv.c |   4 +-
 hw/ppc/sam460ex.c|   2 +-
 hw/rtc/ds1338.c  |  14 +-
 hw/rtc/m41t80.c  |  12 +-
 hw/rtc/twl92230.c|  16 +-
 hw/sensor/dps310.c   |  14 +-
 hw/sensor/emc141x.c  |  16 +-
 hw/sensor/lsm303dlhc_mag.c   |  16 +-
 hw/sensor/tmp105.c   |  16 +-
 hw/sensor/tmp421.c   |  20 +--
 hw/tpm/tpm_tis_i2c.c |  12 +-
 55 files changed, 541 insertions(+), 506 deletions(-)

-- 
2.41.0

[PATCH v2 3/4] hw/i2c: Convert to spec v7 terminology (automatically)

[Philippe Mathieu-Daudé]

One of the biggest change from I2C spec v6 -> v7 is:

  • Updated the terms "master/slave" to "controller/target"

Since it follows the inclusive terminology from the "Conscious
Language in your Open Source Projects" guidelines [*], replace
the I2C terminology.

Mechanical transformation running:

  $ cat i2c_rename.txt | while read old new; do \
  sed -i -e "s/$old/$new/g" $(git grep -l $old); \
done

Having:

  $ cat i2c_rename.txt
  i2c_bus_master i2c_bus_controller
  i2c_schedule_pending_master i2c_schedule_pending_controller
  I2CPendingMasters I2CPendingControllers
  I2CPendingMaster I2CPendingController
  pending_masters pending_controllers
  i2c-slave i2c-target
  I2C_SLAVE_CLASS I2C_TARGET_CLASS
  I2C_SLAVE_GET_CLASS I2C_TARGET_GET_CLASS
  I2CSlaveClass I2CTargetClass
  I2CSlave I2CTarget
  TYPE_I2C_SLAVE TYPE_I2C_TARGET
  I2C_SLAVE I2C_TARGET
  i2c_slave_new i2c_target_new
  i2c_slave_create_simple i2c_target_create_simple
  i2c_slave_realize_and_unref i2c_target_realize_and_unref
  i2c_slave_set_address i2c_target_set_address
  VMSTATE_I2C_SLAVE VMSTATE_I2C_TARGET
  vmstate_i2c_slave vmstate_i2c_target

[*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md

Inspired-by: Wolfram Sang 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/display/i2c-ddc.h |   2 +-
 include/hw/gpio/pca9552.h|   2 +-
 include/hw/gpio/pca9554.h|   2 +-
 include/hw/i2c/aspeed_i2c.h  |   4 +-
 include/hw/i2c/i2c.h |  66 -
 include/hw/i2c/i2c_mux_pca954x.h |   2 +-
 include/hw/i2c/smbus_slave.h |   4 +-
 include/hw/nvram/eeprom_at24c.h  |   4 +-
 include/hw/sensor/tmp105.h   |   2 +-
 hw/arm/aspeed.c  | 232 +++
 hw/arm/bananapi_m2u.c|   2 +-
 hw/arm/cubieboard.c  |   2 +-
 hw/arm/musicpal.c|   6 +-
 hw/arm/npcm7xx_boards.c  |  44 +++---
 hw/arm/nseries.c |   6 +-
 hw/arm/pxa2xx.c  |  36 ++---
 hw/arm/realview.c|   2 +-
 hw/arm/spitz.c   |  12 +-
 hw/arm/stellaris.c   |   2 +-
 hw/arm/tosa.c|  14 +-
 hw/arm/versatilepb.c |   2 +-
 hw/arm/vexpress.c|   2 +-
 hw/arm/z2.c  |  20 +--
 hw/audio/wm8750.c|  18 +--
 hw/display/ati.c |   4 +-
 hw/display/i2c-ddc.c |  10 +-
 hw/display/sii9022.c |  16 +--
 hw/display/sm501.c   |   2 +-
 hw/display/ssd0303.c |  14 +-
 hw/display/xlnx_dp.c |   2 +-
 hw/gpio/max7310.c|  14 +-
 hw/gpio/pca9552.c|  14 +-
 hw/gpio/pca9554.c|  14 +-
 hw/gpio/pcf8574.c|  12 +-
 hw/i2c/aspeed_i2c.c  |  16 +--
 hw/i2c/core.c|  88 ++--
 hw/i2c/i2c_mux_pca954x.c |   6 +-
 hw/i2c/imx_i2c.c |   2 +-
 hw/i2c/smbus_slave.c |  12 +-
 hw/input/lm832x.c|  14 +-
 hw/misc/axp2xx.c |  14 +-
 hw/misc/i2c-echo.c   |  14 +-
 hw/nvram/eeprom_at24c.c  |  22 +--
 hw/ppc/e500.c|   2 +-
 hw/ppc/pnv.c |   4 +-
 hw/ppc/sam460ex.c|   2 +-
 hw/rtc/ds1338.c  |  14 +-
 hw/rtc/m41t80.c  |  12 +-
 hw/rtc/twl92230.c|  16 +--
 hw/sensor/dps310.c   |  14 +-
 hw/sensor/emc141x.c  |  16 +--
 hw/sensor/lsm303dlhc_mag.c   |  16 +--
 hw/sensor/tmp105.c   |  16 +--
 hw/sensor/tmp421.c   |  20 +--
 hw/tpm/tpm_tis_i2c.c |  12 +-
 55 files changed, 461 insertions(+), 461 deletions(-)

diff --git a/include/hw/display/i2c-ddc.h b/include/hw/display/i2c-ddc.h
index 94b5880587..faf3cd84fa 100644
--- a/include/hw/display/i2c-ddc.h
+++ b/include/hw/display/i2c-ddc.h
@@ -26,7 +26,7 @@
 /* A simple I2C slave which just returns the contents of its EDID blob. */
 struct I2CDDCState {
 /*< private >*/
-I2CSlave i2c;
+I2CTarget i2c;
 /*< public >*/
 bool firstbyte;
 uint8_t reg;
diff --git a/include/hw/gpio/pca9552.h b/include/hw/gpio/pca9552.h
index c36525f0c3..d7f07a44e0 100644
--- a/include/hw/gpio/pca9552.h
+++ b/include/hw/gpio/pca9552.h
@@ -23,7 +23,7 @@ DECLARE_INSTANCE_CHECKER(PCA955xState, PCA955X,
 
 struct PCA955xState {
 /*< private >*/
-I2CSlave i2c;
+I2CTarget i2c;
 /*< public >*/
 
 uint8_t len;
diff --git a/include/hw/gpio/pca9554.h b/include/hw/gpio/pca9554.h
index 54bfc4c4c7..0b528a0033 100644
--- a/include/hw/gpio/pca9554.h
+++ b/include/hw/gpio/pca9554.h
@@ -21,7 +21,7 @@ DECLARE_INSTANCE_CHECKER(PCA9554State, PCA9554,
 
 struct PCA9554State {
 /*< private >*/
-I2CSlave i2c;
+I2CTarget i2c;
 /*< public >*/
 
 uint8_t len;
diff --git a/include/hw/i2c/aspeed_i2c.h b/include/hw/i2c/aspeed_i2c.h
index 

[PATCH v2 2/4] hw/i2c: Fix checkpatch line over 80 chars warnings

[Philippe Mathieu-Daudé]

We are going to modify these lines, fix their style
in order to avoid checkpatch.pl warnings:

  WARNING: line over 80 characters

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i2c/i2c.h|  11 ++-
 include/hw/nvram/eeprom_at24c.h |   6 +-
 hw/arm/aspeed.c | 140 +++-
 hw/nvram/eeprom_at24c.c |   6 +-
 4 files changed, 98 insertions(+), 65 deletions(-)

diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
index c18a69e4b6..a1b3f4d179 100644
--- a/include/hw/i2c/i2c.h
+++ b/include/hw/i2c/i2c.h
@@ -31,7 +31,10 @@ struct I2CSlaveClass {
 /* Master to slave. Returns non-zero for a NAK, 0 for success. */
 int (*send)(I2CSlave *s, uint8_t data);
 
-/* Master to slave (asynchronous). Receiving slave must call i2c_ack(). */
+/*
+ * Master to slave (asynchronous).
+ * Receiving slave must call i2c_ack().
+ */
 void (*send_async)(I2CSlave *s, uint8_t data);
 
 /*
@@ -83,7 +86,8 @@ struct I2CPendingMaster {
 };
 
 typedef QLIST_HEAD(I2CNodeList, I2CNode) I2CNodeList;
-typedef QSIMPLEQ_HEAD(I2CPendingMasters, I2CPendingMaster) I2CPendingMasters;
+typedef QSIMPLEQ_HEAD(I2CPendingMasters, I2CPendingMaster)
+I2CPendingMasters;
 
 struct I2CBus {
 BusState qbus;
@@ -176,7 +180,8 @@ I2CSlave *i2c_slave_new(const char *name, uint8_t addr);
  * Create the device state structure, initialize it, put it on the
  * specified @bus, and drop the reference to it (the device is realized).
  */
-I2CSlave *i2c_slave_create_simple(I2CBus *bus, const char *name, uint8_t addr);
+I2CSlave *i2c_slave_create_simple(I2CBus *bus,
+  const char *name, uint8_t addr);
 
 /**
  * Realize and drop a reference an I2C slave device
diff --git a/include/hw/nvram/eeprom_at24c.h b/include/hw/nvram/eeprom_at24c.h
index acb9857b2a..9d29f0a69a 100644
--- a/include/hw/nvram/eeprom_at24c.h
+++ b/include/hw/nvram/eeprom_at24c.h
@@ -33,7 +33,9 @@ I2CSlave *at24c_eeprom_init(I2CBus *bus, uint8_t address, 
uint32_t rom_size);
  * @bus, and drop the reference to it (the device is realized). Copies the data
  * from @init_rom to the beginning of the EEPROM memory buffer.
  */
-I2CSlave *at24c_eeprom_init_rom(I2CBus *bus, uint8_t address, uint32_t 
rom_size,
-const uint8_t *init_rom, uint32_t 
init_rom_size);
+I2CSlave *at24c_eeprom_init_rom(I2CBus *bus,
+uint8_t address, uint32_t rom_size,
+const uint8_t *init_rom,
+uint32_t init_rom_size);
 
 #endif
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 93ca87fda2..8279ad748a 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -649,18 +649,23 @@ static void witherspoon_bmc_i2c_init(AspeedMachineState 
*bmc)
 qdev_connect_gpio_out(dev, pca1_leds[i].gpio_id,
   qdev_get_gpio_in(DEVICE(led), 0));
 }
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 3), "dps310", 0x76);
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 3), "max31785", 
0x52);
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 4), "tmp423", 0x4c);
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 5), "tmp423", 0x4c);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 3),
+"dps310", 0x76);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 3),
+"max31785", 0x52);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 4),
+"tmp423", 0x4c);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 5),
+"tmp423", 0x4c);
 
 /* The Witherspoon expects a TMP275 but a TMP105 is compatible */
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 9), TYPE_TMP105,
- 0x4a);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 9),
+TYPE_TMP105, 0x4a);
 
 /* The witherspoon board expects Epson RX8900 I2C RTC but a ds1338 is
  * good enough */
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 11), "ds1338", 0x32);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 11),
+"ds1338", 0x32);
 
 smbus_eeprom_init_one(aspeed_i2c_get_bus(>i2c, 11), 0x51,
   eeprom_buf);
@@ -717,19 +722,20 @@ static void fp5280g2_bmc_i2c_init(AspeedMachineState *bmc)
 at24c_eeprom_init(aspeed_i2c_get_bus(>i2c, 1), 0x50, 32768);
 
 /* The fp5280g2 expects a TMP112 but a TMP105 is compatible */
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 2), TYPE_TMP105,
- 0x48);
-i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 2), TYPE_TMP105,
- 0x49);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 2),
+TYPE_TMP105, 0x48);
+i2c_slave_create_simple(aspeed_i2c_get_bus(>i2c, 2),
+TYPE_TMP105, 0x49);
 
 i2c_mux = 

[PATCH v2 1/4] hw/i2c: Fix checkpatch block comment warnings

[Philippe Mathieu-Daudé]

We are going to modify these lines, fix their style
in order to avoid checkpatch.pl warnings:

  WARNING: Block comments use a leading /* on a separate line
  WARNING: Block comments use * on subsequent lines
  WARNING: Block comments use a trailing */ on a separate line

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i2c/i2c.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
index 2a3abacd1b..c18a69e4b6 100644
--- a/include/hw/i2c/i2c.h
+++ b/include/hw/i2c/i2c.h
@@ -4,10 +4,12 @@
 #include "hw/qdev-core.h"
 #include "qom/object.h"
 
-/* The QEMU I2C implementation only supports simple transfers that complete
-   immediately.  It does not support slave devices that need to be able to
-   defer their response (eg. CPU slave interfaces where the data is supplied
-   by the device driver in response to an interrupt).  */
+/*
+ * The QEMU I2C implementation only supports simple transfers that complete
+ * immediately.  It does not support slave devices that need to be able to
+ * defer their response (eg. CPU slave interfaces where the data is supplied
+ * by the device driver in response to an interrupt).
+ */
 
 enum i2c_event {
 I2C_START_RECV,
-- 
2.41.0

Re: [PATCH] virtio-pci: Fix the failure process in kvm_virtio_pci_vector_use_one()

[Michael S. Tsirkin]

On Tue, Apr 16, 2024 at 02:14:57PM +0100, Peter Maydell wrote:
> On Tue, 16 Apr 2024 at 13:41, Cindy Lu  wrote:
> >
> > On Tue, Apr 16, 2024 at 8:30 PM Peter Maydell  
> > wrote:
> > >
> > > On Tue, 16 Apr 2024 at 13:29, Cindy Lu  wrote:
> > > >
> > > > In function kvm_virtio_pci_vector_use_one(), in the undo label,
> > > > the function will get the vector incorrectly while using
> > > > VIRTIO_CONFIG_IRQ_IDX
> > > > To fix this, we remove this label and simplify the failure process

And then what happens?  It's unclear whether it's a real or
theoretical issue.

> > > > Fixes: f9a09ca3ea ("vhost: add support for configure interrupt")
> > > > Cc: qemu-sta...@nongnu.org
> > > > Signed-off-by: Cindy Lu 
> > > > ---
> > > >  hw/virtio/virtio-pci.c | 19 +++
> > > >  1 file changed, 3 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> > > > index b138fa127a..565bdb0897 100644
> > > > --- a/hw/virtio/virtio-pci.c
> > > > +++ b/hw/virtio/virtio-pci.c
> > > > @@ -892,7 +892,7 @@ static int 
> > > > kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int queue_no)
> > > >  }
> > > >  ret = kvm_virtio_pci_vq_vector_use(proxy, vector);
> > > >  if (ret < 0) {
> > > > -goto undo;
> > > > +return ret;
> > > >  }
> > > >  /*
> > > >   * If guest supports masking, set up irqfd now.
> > > > @@ -902,25 +902,12 @@ static int 
> > > > kvm_virtio_pci_vector_use_one(VirtIOPCIProxy *proxy, int queue_no)
> > > >  ret = kvm_virtio_pci_irqfd_use(proxy, n, vector);
> > > >  if (ret < 0) {
> > > >  kvm_virtio_pci_vq_vector_release(proxy, vector);
> > > > -goto undo;
> > > > +kvm_virtio_pci_irqfd_release(proxy, n, vector);
> > >
> > > Are you sure this is right? The kvm_virtio_pci_irqfd_use()
> > > just failed, so why do we need to call
> > > kvm_virtio_pci_irqfd_release() ?
> 
> > This version should be correct.  when kvm_virtio_pci_irqfd_use() fail
> > we need to call kvm_virtio_pci_vq_vector_release() and
> > kvm_virtio_pci_irqfd_release()
> > but for kvm_virtio_pci_vq_vector_use fail we can simple return,
> 
> But *why* do we need to call kvm_virtio_pci_irqfd_release()?
> 
> In most API designs, this kind of pairing of "get/use/allocate
> something" and "free/release something" function only
> requires you to do the "release" if the "get" succeeded,
> because if the "get" fails it's supposed to fail in way that
> means "I didn't do anything". Is this API not following that
> standard pattern ?


I am just as puzzled.

> > in old version there is a error in failure process.
> > while the kvm_virtio_pci_vq_vector_use fail it  call the
> > kvm_virtio_pci_irqfd_release,but at this time this is irqfd
> > is not using now
> 
> thanks
> -- PMM

Re: [PATCH 6/8] target/ppc: Move div/mod fixed-point insns (64 bits operands) to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

Moving the below instructions to decodetree specification :

divd[u, e, eu][o][.]: XO-form
mod{sd, ud} : X-form

With this patch, all the fixed-point arithmetic instructions have been
moved to decodetree.
The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured using the '-d in_asm,op' flag.
Also, remaned do_divwe method in fixedpoint-impl.c.inc to do_dive because it is
now used to divide doubleword operands as well, and not just words.

Signed-off-by: Chinmay Rath
---
  target/ppc/helper.h|  4 +-
  target/ppc/insn32.decode   |  8 +++
  target/ppc/int_helper.c|  4 +-
  target/ppc/translate.c | 65 ++
  target/ppc/translate/fixedpoint-impl.c.inc | 29 +-
  5 files changed, 42 insertions(+), 68 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH 5/8] target/ppc: Move multiply fixed-point insns (64-bit operands) to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

+static bool trans_MADDHDU(DisasContext *ctx, arg_MADDHDU *a)

...

+tcg_gen_movi_i64(t1, 0);


Drop the movi.


+tcg_gen_add2_i64(t1, cpu_gpr[a->vrt], lo, hi, cpu_gpr[a->rc], t1);


Use tcg_constant_i64(0).

With that,
Reviewed-by: Richard Henderson 


r~

Re: [PATCH RFC] prevent overflow in xlnx_dpdma_desc_get_source_address()

[Edgar E. Iglesias]

+ To: Fred

On Tue, 16 Apr 2024 at 19:56, Alexandra Diupina 
wrote:

> Peter, thank you! I agree with you that
> as mentioned in the documentation
> https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field,
> we should take 32 bits of the address from one field
> (for example, case 1, SRC_ADDR2_EXT - in code it is desc->source_address2)
> and 16 bits (high or low) of the address from another field
> (ADDR_EXT_23 - in code it is desc->address_extension_23, we need [15:0]
> bits)
> and combine them to make a 48 bit address.
>
> Therefore, I suggest making the following changes to the code
> so that it matches the documentation:
>
> static uint64_t xlnx_dpdma_desc_get_source_address(DPDMADescriptor *desc,
>   uint8_t frag)
> {
>  uint64_t addr = 0;
>  assert(frag < 5);
>
>  switch (frag) {
>  case 0:
>  addr = (uint64_t)desc->source_address
>  + (extract64(desc->address_extension, 16, 16) << 32);
>  break;
>  case 1:
>  addr = (uint64_t)desc->source_address2
>  + (extract64(desc->address_extension_23, 0, 16) << 32);
>  break;
>  case 2:
>  addr = (uint64_t)desc->source_address3
>  + (extract64(desc->address_extension_23, 16, 16) << 32);
>  break;
>  case 3:
>  addr = (uint64_t)desc->source_address4
>  + (extract64(desc->address_extension_45, 0, 16) << 32);
>  break;
>  case 4:
>  addr = (uint64_t)desc->source_address5
>  + (extract64(desc->address_extension_45, 16, 16) << 32);
>  break;
>  default:
>  addr = 0;
>  break;
>  }
>
>  return addr;
> }
>
>
> This change adds a type cast and also uses extract64() instead of
> extract32()
> to avoid integer overflow on addition (there was a typo in the previous
> letter).
> Also in extract64() extracts a bit field with a length of 16 bits
> instead of 12,
> the shift is changed to 32 so that the extracted field fits into bits
> [47:32] of the final address.
>
> if this calculation is correct, I'm ready to create a second version of
> the patch.
>
>
>
>
> 12/04/24 13:06, Peter Maydell пишет:
> > On Fri, 12 Apr 2024 at 09:13, Alexandra Diupina 
> wrote:
> >> Overflow can occur in a situation where desc->source_address
> >> has a maximum value (pow(2, 32) - 1), so add a cast to a
> >> larger type before the assignment.
> >>
> >> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> >>
> >> Fixes: d3c6369a96 ("introduce xlnx-dpdma")
> >> Signed-off-by: Alexandra Diupina 
> >> ---
> >>   hw/dma/xlnx_dpdma.c | 20 ++--
> >>   1 file changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/hw/dma/xlnx_dpdma.c b/hw/dma/xlnx_dpdma.c
> >> index 1f5cd64ed1..224259225c 100644
> >> --- a/hw/dma/xlnx_dpdma.c
> >> +++ b/hw/dma/xlnx_dpdma.c
> >> @@ -175,24 +175,24 @@ static uint64_t
> xlnx_dpdma_desc_get_source_address(DPDMADescriptor *desc,
> >>
> >>   switch (frag) {
> >>   case 0:
> >> -addr = desc->source_address
> >> -+ (extract32(desc->address_extension, 16, 12) << 20);
> >> +addr = (uint64_t)(desc->source_address
> >> ++ (extract32(desc->address_extension, 16, 12) << 20));
> > Unless I'm confused, this cast doesn't help, because we
> > will have already done a 32-bit addition of desc->source_address
> > and the value from the address_extension part, so it doesn't
> > change the result.
> >
> > If we want to do the addition at 64 bits then using extract64()
> > would be the simplest way to arrange for that.
> >
> > However, I can't figure out what this code is trying to do and
> > make that line up with the data sheet; maybe this isn't the
> > right datasheet for this device?
> >
> > https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field
> >
> > The datasheet suggests that we should take 32 bits of the address
> > from one field (here desc->source_address) and 16 bits of the
> > address from another (here desc->address_extension's high bits)
> > and combine them to make a 48 bit address. But this code is only
> > looking at 12 bits of the high 16 in address_extension, and it
> > doesn't shift them right enough to put them into bits [47:32]
> > of the final address.
> >
> > Xilinx folks: what hardware is this modelling, and is it
> > really the right behaviour?
> >
> > Also, this device looks like it has a host-endianness bug: the
> > DPDMADescriptor struct is read directly from guest memory in
> > dma_memory_read(), but the device never does anything to swap
> > the fields from guest memory order to host memory order. So
> > this is likely broken on big-endian hosts.
> >
> > thanks
> > -- PMM
>
>
>

Re: Qemu for TC377

[Sameer Kalliadan Poyil]

Hi Bastian,

Thanks for the information. I thought that I can do some prototyping before
the HW arrives. :)

 Yes I am interested for your bare metal program boot_to_main run it on
TSIM.
Is Infineon TSIM free? I searched it and I didn't find any download link.
Could you please give a link for that if it is from Infineon?

s it(TSIM)  trace32 simulator ? *https://repo.lauterbach.com/download_demo.html
 *?

This page *https://wiki.qemu.org/Documentation/Platforms/TriCore
* shows SCU is under
development.

Could you let me know who is developing it ? is  it possible to take an
existing SCU and modify according to AURIX data sheet? I see that UART is
possible to for Tricore like the one developed for ARM versatile platform

Here is the link
*https://mail.gnu.org/archive/html/qemu-devel/2016-10/msg04514.htm
*l

I have aurix development trial version and able to compile a UART
project using Tasking compiler and tried to run it on qemu, but I don't see
any logs in the qemu terminal as you said there is no peripherals
implemented

qemu-system-tricore -machine KIT_AURIX_TC277_TRB -cpu tc27x -m 6M
-nographic -kernel ASCLIN_Shell_UART_1_KIT_TC277_TFT.elf  -serial stdio
-append "console=ttyAMA0 console=ttyS0"


Also do you know if there is a virtual UART framework to communicate
between two Qemu instances or two TSIM instances running similar OS or
different OS? I need to do prototype testing RPMSg communication between
MCU and SOC using external physical UART/SPI which can be tested using
vritual UART using two qemu instances.



Regards,
Sameer

On Mon, Apr 15, 2024 at 7:51 AM Bastian Koppelmann <
kbast...@mail.uni-paderborn.de> wrote:

> Hi Sameer,
> On Sun, Apr 14, 2024 at 06:15:56PM +0200, Philippe Mathieu-Daudé wrote:
> > Hi Sameer,
> >
> > On 13/4/24 14:52, Sameer Kalliadan Poyil wrote:
> > > Hello All,
> > > I see that Latest qemu supports for tricore TC277 and TC377
> > > image.png
> > > But when I downloaded source code and checked for TC377 related file ,
> I
> > > didn't find anything
> > >
> > > I want to run RTOS/bare metal code on TC377 . could you please let me
> > > know how to start qemu on TC377 ?
> > > Here is the latest version of qemu i have , I didn't download 9.0
> >
> > $ qemu-system-tricore -cpu help
> > Available CPUs:
> >   tc1796
> >   tc1797
> >   tc27x
> >   tc37x
> > $
> >
> > Try 'qemu-system-tricore -machine KIT_AURIX_TC277_TRB -cpu tc37x',
> > this should start a TC377 SoC on an AURIX board (~KIT_A2G_TC377_TRB).
>
> This is the closest you will get to TC377 board.
>
> I'm not sure if QEMU is the best choice for you, if you want run a RTOS, as
> qemu-system-tricore is lacking:
>
> - peripherals like SCU, SystemTimer that are a bare minimum to run a RTOS
>
> - Simulation of time: When your RTOS runs periodic tasks you might get
> wrong
>   results, as QEMU does not simulate time accurately. The real CPU would
>   see time pass differently than QEMU. We make a best guess using the wall
> time.
>
> I think for now Infineons TSIM is a better choice, as it does not lack the
> points above. However it has significantly less performance compared to
> QEMU.
>
> If you are only interested in running bare metal software, check out my
> 'boot_to_main' test [1]. The Makefile [2] shows you how to build it using
> tricore-gcc [3] and how to run it in QEMU. Also tricore-gdb [4] might be
> interesting for you.
>
> If you have further questions, feel free to ask me.
>
> Cheers,
> Bastian
>
> [1]
> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/tcg/tricore/c/test_boot_to_main.c?ref_type=heads
> [2]
> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/tcg/tricore/Makefile.softmmu-target?ref_type=heads
> [3] https://github.com/bkoppelmann/package_494
> [4] https://github.com/volumit/gdb-tricore
>

Re: [PATCH 4/8] target/ppc: Move neg, darn, mod{sw, uw} to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

Moving the below instructions to decodetree specification :

neg[o][.]   : XO-form
mod{sw, uw}, darn   : X-form

The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,op' flag.

Signed-off-by: Chinmay Rath
---
  target/ppc/helper.h|  4 +-
  target/ppc/insn32.decode   |  8 
  target/ppc/int_helper.c|  4 +-
  target/ppc/translate.c | 56 --
  target/ppc/translate/fixedpoint-impl.c.inc | 44 +
  5 files changed, 56 insertions(+), 60 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [Stable-8.2.3 00/87] Patch Round-up for stable 8.2.3, freeze on 2024-04-20

[Michael Tokarev]

16.04.2024 20:34, Cole Robinson wrote:


We have a couple patches in f40 that are bug fixes, avoids a crash on
invalid maxcpus for ppc64 guests. First is a prep patch. bug details in
patch 2

commit 2df5c1f5b014126595a26c6797089d284a3b211c
Author: Harsh Prateek Bora 
Date:   Wed Jan 24 10:30:55 2024 +1000

 ppc/spapr: Introduce SPAPR_IRQ_NR_IPIS to refer IRQ range for CPU IPIs.

commit c4f91d7b7be76c47015521ab0109c6e998a369b0
Author: Harsh Prateek Bora 
Date:   Wed Jan 24 10:30:55 2024 +1000

 ppc/spapr: Initialize max_cpus limit to SPAPR_IRQ_NR_IPIS.


Aha!

It's fun I noticed these two at the time but forgot to include them.

Queued up now.

Thanks,

/mjt

Re: [PATCH 3/8] target/ppc: Move divw[u, e, eu] instructions to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

Moving the following instructions to decodetree specification :
 divw[u, e, eu][o][.]   : XO-form

The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,op' flag.

Signed-off-by: Chinmay Rath
---
  target/ppc/helper.h|  4 +--
  target/ppc/insn32.decode   |  5 
  target/ppc/int_helper.c|  4 +--
  target/ppc/translate.c | 31 --
  target/ppc/translate/fixedpoint-impl.c.inc | 24 +
  5 files changed, 33 insertions(+), 35 deletions(-)


Reviewed-by: Richard Henderson 


r~

Re: Add 'info pg' command to monitor

[Don Porter]

On 4/16/24 13:03, Peter Maydell wrote:

On Tue, 16 Apr 2024 at 17:53, Don Porter  wrote:

There is still a lot I am learning about the code base, but it seems
that qemu_get_guest_memory_mapping() does most of what one would need.
It currently only returns the "leaves" of the page table tree in a list.

What if I extend this function with an optional argument to either
1) return the interior nodes of the page table in additional lists (and
then parse+print in the monitor code), or
2) inline the monitor printing in the arch-specific hook, and pass a
flag to get_guest_memory_mapping() that turns on/off the statements that
pretty print the page tables?

It looks like most CPUs implement this function as part of checkpointing.

As far as I can see only x86 implements the get_memory_mapping
function, so once again somebody has added some bit of
functionality that does a walk of the page tables that is
x86 only and that shares no code with any of the other
page table walking code :-(


My mistake - get_memory_mappings() is only implemented in x86.

In doing some searching of the code, many architectures implement 
mmu_translate() and
get_physical_address() functions, but they are not standardized. I also 
see your larger point

about replicating page walking code in x86.

I imagine you have something in mind that abstracts things like the 
height of the radix tree,

entries per node, checking permissions, printing the contents, etc.

Perhaps I should start by trying to merge the x86 page walking code into 
one set of common
helper functions, get more feedback (perhaps on a new patch thread?), 
and then consider

how to abstract across architectures after getting feedback on this?

In looking at x86 code, I see the following places where there is page 
table walking code to

potentially merge:

* target/i386/monitor.c - existing info commands

* target/i386/helper.c - get_phys_page_attrs_debug

* target/i386/arch_memory_mapping.c - implements get_memory_mapping

* tcg/sysemu/excp_helper.c: implements mmu_translate() and 
get_physical_address()


Thanks,

Don

Re: [PATCH 2/8] target/ppc: Make divw[u] handler method decodetree compatible.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

The handler methods for divw[u] instructions internally use Rc(ctx->opcode),
for extraction of Rc field of instructions, which poses a problem if we move
the above said instructions to decodetree, as the ctx->opcode field is not
popluated in decodetree. Hence, making it decodetree compatible, so that the
mentioned insns can be safely move to decodetree specs.

Signed-off-by: Chinmay Rath
---
  target/ppc/translate.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)


Reviewed-by: Richard Henderson 


+static inline void gen_op_arith_divw(DisasContext *ctx, TCGv ret,
+ TCGv arg1, TCGv arg2, bool sign,
+ bool compute_ov, bool compute_rc0)


Could drop the inline at the same time.
Let the compiler decide.


r~

Re: [PATCH RFC] prevent overflow in xlnx_dpdma_desc_get_source_address()

[Alexandra Diupina]

Peter, thank you! I agree with you that
as mentioned in the documentation
https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field,
we should take 32 bits of the address from one field
(for example, case 1, SRC_ADDR2_EXT - in code it is desc->source_address2)
and 16 bits (high or low) of the address from another field
(ADDR_EXT_23 - in code it is desc->address_extension_23, we need [15:0] 
bits)

and combine them to make a 48 bit address.

Therefore, I suggest making the following changes to the code
so that it matches the documentation:

static uint64_t xlnx_dpdma_desc_get_source_address(DPDMADescriptor *desc,
 uint8_t frag)
{
    uint64_t addr = 0;
    assert(frag < 5);

    switch (frag) {
    case 0:
    addr = (uint64_t)desc->source_address
    + (extract64(desc->address_extension, 16, 16) << 32);
    break;
    case 1:
    addr = (uint64_t)desc->source_address2
    + (extract64(desc->address_extension_23, 0, 16) << 32);
    break;
    case 2:
    addr = (uint64_t)desc->source_address3
    + (extract64(desc->address_extension_23, 16, 16) << 32);
    break;
    case 3:
    addr = (uint64_t)desc->source_address4
    + (extract64(desc->address_extension_45, 0, 16) << 32);
    break;
    case 4:
    addr = (uint64_t)desc->source_address5
    + (extract64(desc->address_extension_45, 16, 16) << 32);
    break;
    default:
    addr = 0;
    break;
    }

    return addr;
}


This change adds a type cast and also uses extract64() instead of 
extract32()
to avoid integer overflow on addition (there was a typo in the previous 
letter).
Also in extract64() extracts a bit field with a length of 16 bits 
instead of 12,
the shift is changed to 32 so that the extracted field fits into bits 
[47:32] of the final address.


if this calculation is correct, I'm ready to create a second version of 
the patch.





12/04/24 13:06, Peter Maydell пишет:

On Fri, 12 Apr 2024 at 09:13, Alexandra Diupina  wrote:

Overflow can occur in a situation where desc->source_address
has a maximum value (pow(2, 32) - 1), so add a cast to a
larger type before the assignment.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: d3c6369a96 ("introduce xlnx-dpdma")
Signed-off-by: Alexandra Diupina 
---
  hw/dma/xlnx_dpdma.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/dma/xlnx_dpdma.c b/hw/dma/xlnx_dpdma.c
index 1f5cd64ed1..224259225c 100644
--- a/hw/dma/xlnx_dpdma.c
+++ b/hw/dma/xlnx_dpdma.c
@@ -175,24 +175,24 @@ static uint64_t 
xlnx_dpdma_desc_get_source_address(DPDMADescriptor *desc,

  switch (frag) {
  case 0:
-addr = desc->source_address
-+ (extract32(desc->address_extension, 16, 12) << 20);
+addr = (uint64_t)(desc->source_address
++ (extract32(desc->address_extension, 16, 12) << 20));

Unless I'm confused, this cast doesn't help, because we
will have already done a 32-bit addition of desc->source_address
and the value from the address_extension part, so it doesn't
change the result.

If we want to do the addition at 64 bits then using extract64()
would be the simplest way to arrange for that.

However, I can't figure out what this code is trying to do and
make that line up with the data sheet; maybe this isn't the
right datasheet for this device?

https://docs.amd.com/r/en-US/ug1085-zynq-ultrascale-trm/ADDR_EXT-Field

The datasheet suggests that we should take 32 bits of the address
from one field (here desc->source_address) and 16 bits of the
address from another (here desc->address_extension's high bits)
and combine them to make a 48 bit address. But this code is only
looking at 12 bits of the high 16 in address_extension, and it
doesn't shift them right enough to put them into bits [47:32]
of the final address.

Xilinx folks: what hardware is this modelling, and is it
really the right behaviour?

Also, this device looks like it has a host-endianness bug: the
DPDMADescriptor struct is read directly from guest memory in
dma_memory_read(), but the device never does anything to swap
the fields from guest memory order to host memory order. So
this is likely broken on big-endian hosts.

thanks
-- PMM

Re: [PATCH 1/8] target/ppc: Move mul{li, lw, lwo, hw, hwu} instructions to decodetree.

[Richard Henderson]

On 4/15/24 23:39, Chinmay Rath wrote:

Moving the following instructions to decodetree specification :
mulli   : D-form
mul{lw, lwo, hw, hwu}[.]: XO-form

The changes were verified by validating that the tcg ops generated by those
instructions remain the same, which were captured with the '-d in_asm,op' flag.

Signed-off-by: Chinmay Rath 
---
  target/ppc/insn32.decode   |  9 +++
  target/ppc/translate.c | 89 --
  target/ppc/translate/fixedpoint-impl.c.inc | 71 +
  3 files changed, 80 insertions(+), 89 deletions(-)


This is an accurate reorg of the current code, so
Reviewed-by: Richard Henderson 

However, as follow-up, the code generation could be cleaned up:



+static bool trans_MULLW(DisasContext *ctx, arg_MULLW *a)
+{
+#if defined(TARGET_PPC64)
+TCGv_i64 t0, t1;
+t0 = tcg_temp_new_i64();
+t1 = tcg_temp_new_i64();
+tcg_gen_ext32s_tl(t0, cpu_gpr[a->ra]);
+tcg_gen_ext32s_tl(t1, cpu_gpr[a->rb]);
+tcg_gen_mul_i64(cpu_gpr[a->rt], t0, t1);
+#else
+tcg_gen_mul_i32(cpu_gpr[a->rt], cpu_gpr[a->ra], cpu_gpr[a->rb]);
+#endif
+if (unlikely(a->rc)) {
+gen_set_Rc0(ctx, cpu_gpr[a->rt]);
+}
+return true;
+}


Without ifdefs:

TCGv t0 = tcg_temp_new();
TCGv t1 = tcg_temp_new();

tcg_gen_ext32s_tl(t0, ra);
tcg_gen_ext32s_tl(t1, rb);
tcg_gen_mul_tl(rt, t0, t1);

For ppc32, ext32s_tl will turn into a mov, which will be optimized away.  So ideal code 
generation for both modes.




+static bool trans_MULLWO(DisasContext *ctx, arg_MULLWO *a)
+{
+TCGv_i32 t0 = tcg_temp_new_i32();
+TCGv_i32 t1 = tcg_temp_new_i32();
+
+tcg_gen_trunc_tl_i32(t0, cpu_gpr[a->ra]);
+tcg_gen_trunc_tl_i32(t1, cpu_gpr[a->rb]);
+tcg_gen_muls2_i32(t0, t1, t0, t1);
+#if defined(TARGET_PPC64)
+tcg_gen_concat_i32_i64(cpu_gpr[a->rt], t0, t1);
+#else
+tcg_gen_mov_i32(cpu_gpr[a->rt], t0);
+#endif
+
+tcg_gen_sari_i32(t0, t0, 31);
+tcg_gen_setcond_i32(TCG_COND_NE, t0, t0, t1);
+tcg_gen_extu_i32_tl(cpu_ov, t0);


Usually hosts need to create the full 64-bit product and then break it apart for 
tcg_gen_muls2_i32, so split followed immediately by concatenate isn't great.



TCGv t0 = tcg_temp_new();
TCGv t1 = tcg_temp_new();

#ifdef TARGET_PPC64
tcg_gen_ext32s_i64(t0, ra);
tcg_gen_ext32s_i64(t1, rb);
tcg_gen_mul_i64(rt, t0, t1);
tcg_gen_sextract_i64(t0, rt, 31, 1);
tcg_gen_sari_i64(t1, rt, 32);
#else
tcg_gen_muls2_i32(rt, t1, ra, rb);
tcg_gen_sari_i32(t0, rt, 31);
#endif
tcg_gen_setcond_tl(TCG_COND_NE, cpu_ov, t0, t1);



+if (is_isa300(ctx)) {
+tcg_gen_mov_tl(cpu_ov32, cpu_ov);
+}
+tcg_gen_or_tl(cpu_so, cpu_so, cpu_ov);
+
+if (unlikely(a->rc)) {
+gen_set_Rc0(ctx, cpu_gpr[a->rt]);
+}
+return true;
+}



r~

Re: [Stable-8.2.3 00/87] Patch Round-up for stable 8.2.3, freeze on 2024-04-20

[Cole Robinson]

On 4/10/24 3:21 AM, Michael Tokarev wrote:
> The following patches are queued for QEMU stable v8.2.3:
> 
>   https://gitlab.com/qemu-project/qemu/-/commits/staging-8.2
> 
> Patch freeze is 2024-04-20, and the release is planned for 2024-04-22:
> 
>   https://wiki.qemu.org/Planning/8.2
> 
> Please respond here or CC qemu-sta...@nongnu.org on any additional patches
> you think should (or shouldn't) be included in the release.
> 
> The changes which are staging for inclusion, with the original commit hash
> from master branch, are given below the bottom line.
> 
> Thanks!
> 
> /mjt
> 

We have a couple patches in f40 that are bug fixes, avoids a crash on
invalid maxcpus for ppc64 guests. First is a prep patch. bug details in
patch 2

commit 2df5c1f5b014126595a26c6797089d284a3b211c
Author: Harsh Prateek Bora 
Date:   Wed Jan 24 10:30:55 2024 +1000

ppc/spapr: Introduce SPAPR_IRQ_NR_IPIS to refer IRQ range for CPU IPIs.

commit c4f91d7b7be76c47015521ab0109c6e998a369b0
Author: Harsh Prateek Bora 
Date:   Wed Jan 24 10:30:55 2024 +1000

ppc/spapr: Initialize max_cpus limit to SPAPR_IRQ_NR_IPIS.


Thanks,
Cole

Re: [PATCH v6 09/12] hw/cxl/events: Add qmp interfaces to add/release dynamic capacity extents

[Gregory Price]

On Tue, Apr 16, 2024 at 03:58:22PM +0100, Jonathan Cameron wrote:
> On Mon, 15 Apr 2024 13:06:04 -0700
> fan  wrote:
> 
> > From ce75be83e915fbc4dd6e489f976665b81174002b Mon Sep 17 00:00:00 2001
> > From: Fan Ni 
> > Date: Tue, 20 Feb 2024 09:48:31 -0800
> > Subject: [PATCH 09/13] hw/cxl/events: Add qmp interfaces to add/release
> >  dynamic capacity extents
> > 
> > +
> > +if (num_extents > 1) {
> > +error_setg(errp,
> > +   "TODO: remove the check once kernel support More flag");
> Not our problem :)  For now we can just test the kernel by passing in single
> extents via separate commands.
> 
> I don't want to carry unnecessary limitations in qemu.
> 

Probably worth popping in to say some out of band discussions around the
`more bit` suggest it may be a while before it is supported.

Allowing QEMU to send more bit messages to the kernel would be extremely
helpful for validation that the kernel won't blow up if/when a real
device implements it.  So yes, please allow it!

~Gregory

Re: [PATCH v6 10/12] hw/mem/cxl_type3: Add dpa range validation for accesses to DC regions

[Gregory Price]

On Tue, Apr 16, 2024 at 04:00:56PM +0100, Jonathan Cameron wrote:
> On Mon, 15 Apr 2024 10:37:00 -0700
> fan  wrote:
> 
> > On Fri, Apr 12, 2024 at 06:54:42PM -0400, Gregory Price wrote:
> > > On Mon, Mar 25, 2024 at 12:02:28PM -0700, nifan@gmail.com wrote:  
> > > > From: Fan Ni 
> > > > 
> > > > All dpa ranges in the DC regions are invalid to access until an extent
> > > > covering the range has been added. Add a bitmap for each region to
> > > > record whether a DC block in the region has been backed by DC extent.
> > > > For the bitmap, a bit in the bitmap represents a DC block. When a DC
> > > > extent is added, all the bits of the blocks in the extent will be set,
> > > > which will be cleared when the extent is released.
> > > > 
> > > > Reviewed-by: Jonathan Cameron 
> > > > Signed-off-by: Fan Ni 
> > > > ---
> > > >  hw/cxl/cxl-mailbox-utils.c  |  6 +++
> > > >  hw/mem/cxl_type3.c  | 76 +
> > > >  include/hw/cxl/cxl_device.h |  7 
> > > >  3 files changed, 89 insertions(+)
> > > > 
> > > > diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
> > > > index 7094e007b9..a0d2239176 100644
> > > > --- a/hw/cxl/cxl-mailbox-utils.c
> > > > +++ b/hw/cxl/cxl-mailbox-utils.c
> > > > @@ -1620,6 +1620,7 @@ static CXLRetCode cmd_dcd_add_dyn_cap_rsp(const 
> > > > struct cxl_cmd *cmd,
> > > >  
> > > >  cxl_insert_extent_to_extent_list(extent_list, dpa, len, NULL, 
> > > > 0);
> > > >  ct3d->dc.total_extent_count += 1;
> > > > +ct3_set_region_block_backed(ct3d, dpa, len);
> > > >  
> > > >  ent = QTAILQ_FIRST(>dc.extents_pending);
> > > >  cxl_remove_extent_from_extent_list(>dc.extents_pending, 
> > > > ent);  
> > > 
> > > while looking at the MHD code, we had decided to "reserve" the blocks in
> > > the bitmap in the call to `qmp_cxl_process_dynamic_capacity` in order to
> > > prevent a potential double-allocation (basically we need to sanity check
> > > that two hosts aren't reserving the region PRIOR to the host being
> > > notified).
> > > 
> > > I did not see any checks in the `qmp_cxl_process_dynamic_capacity` path
> > > to prevent pending extents from being double-allocated.  Is this an
> > > explicit choice?
> > > 
> > > I can see, for example, why you may want to allow the following in the
> > > pending list: [Add X, Remove X, Add X].  I just want to know if this is
> > > intentional or not. If not, you may consider adding a pending check
> > > during the sanity check phase of `qmp_cxl_process_dynamic_capacity`
> > > 
> > > ~Gregory  
> > 
> > First, for remove request, pending list is not involved. See cxl r3.1,
> > 9.13.3.3. Pending basically means "pending to add". 
> > So for the above example, in the pending list, you can see [Add x, add x] 
> > if the
> > event is not processed in time.
> > Second, from the spec, I cannot find any text saying we cannot issue
> > another add extent X if it is still pending.
> 
> I think there is text saying that the capacity is not released for reuse
> by the device until it receives a response from the host.   Whilst
> it's not explicit on offers to the same host, I'm not sure that matters.
> So I don't think it is suppose to queue multiple extents...
> 
> 

It definitely should not release capacity until it receives a response,
because the host could tell the device to kick rocks (which would be
reasonable under a variety of circumstances).

~Gregory

Re: [PATCH v2 3/6] hw/ppc: SPI controller model - sequencer and shifter

[Chalapathi V]

On 16-04-2024 15:09, Cédric Le Goater wrote:

Hello,

Please rephrase the subject to something like:

  "ppc/pnv: Extend SPI model ..."

Using a verb is preferable.

Sure. Will update. Thank You.


On 4/9/24 19:56, Chalapathi V wrote:

In this commit SPI shift engine and sequencer logic is implemented.
Shift engine performs serialization and de-serialization according to 
the

control by the sequencer and according to the setup defined in the
configuration registers. Sequencer implements the main control logic and
FSM to handle data transmit and data receive control of the shift 
engine.


Signed-off-by: Chalapathi V 
---
  include/hw/ppc/pnv_spi_controller.h |   72 ++
  hw/ppc/pnv_spi_controller.c | 1311 ++-
  2 files changed, 1382 insertions(+), 1 deletion(-)

diff --git a/include/hw/ppc/pnv_spi_controller.h 
b/include/hw/ppc/pnv_spi_controller.h

index 5ec50fb14c..ee8e7a17da 100644
--- a/include/hw/ppc/pnv_spi_controller.h
+++ b/include/hw/ppc/pnv_spi_controller.h
@@ -8,6 +8,14 @@
   * This model Supports a connection to a single SPI responder.
   * Introduced for P10 to provide access to SPI seeproms, TPM, flash 
device

   * and an ADC controller.
+ *
+ * All SPI function control is mapped into the SPI register space to 
enable

+ * full control by firmware.
+ *
+ * SPI Controller has sequencer and shift engine. The SPI shift engine
+ * performs serialization and de-serialization according to the 
control by
+ * the sequencer and according to the setup defined in the 
configuration

+ * registers and the SPI sequencer implements the main control logic.
   */
  #include "hw/ssi/ssi.h"
  @@ -21,6 +29,7 @@
  #define SPI_CONTROLLER_REG_SIZE 8
    typedef struct SSIBus SSIBus;
+typedef struct xfer_buffer xfer_buffer;


Please use CamelCase names for typedef. The forward declaration doesn't
seem useful.

Sure. Will remove and test.



  #define TYPE_PNV_SPI_BUS "pnv-spi-bus"
  OBJECT_DECLARE_SIMPLE_TYPE(PnvSPIBus, PNV_SPI_BUS)
@@ -33,6 +42,21 @@ typedef struct PnvSPIBus {
  uint32_t id;
  } PnvSPIBus;
  +/* xfer_buffer */
+typedef struct xfer_buffer {
+
+    uint32_t    len;
+    uint8_t    *data;
+
+} xfer_buffer;
+
+uint8_t *xfer_buffer_write_ptr(xfer_buffer *payload, uint32_t offset,
+    uint32_t length);
+void xfer_buffer_read_ptr(xfer_buffer *payload, uint8_t **read_buf,
+    uint32_t offset, uint32_t length);
+xfer_buffer *xfer_buffer_new(void);
+void xfer_buffer_free(xfer_buffer *payload);
+


I don't think these helper routines need to be defined in the header file
of the PnvPsi model. They look internal to me.

Sure. Will move them.



  typedef struct PnvSpiController {
  DeviceState parent;
  @@ -40,6 +64,39 @@ typedef struct PnvSpiController {
  MemoryRegion    xscom_spic_regs;
  /* SPI controller object number */
  uint32_t    spic_num;
+    uint8_t responder_select;
+    /* To verify if shift_n1 happens prior to shift_n2 */
+    bool    shift_n1_done;
+    /*
+ * Internal flags for the first and last indicators for the SPI
+ * interface methods
+ */
+    uint8_t first;
+    uint8_t last;
+    /* Loop counter for branch operation opcode Ex/Fx */
+    uint8_t loop_counter_1;
+    uint8_t loop_counter_2;
+    /* N1/N2_bits specifies the size of the N1/N2 segment of a frame 
in bits.*/

+    uint8_t N1_bits;
+    uint8_t N2_bits;
+    /* Number of bytes in a payload for the N1/N2 frame segment.*/
+    uint8_t N1_bytes;
+    uint8_t N2_bytes;
+    /* Number of N1/N2 bytes marked for transmit */
+    uint8_t N1_tx;
+    uint8_t N2_tx;
+    /* Number of N1/N2 bytes marked for receive */
+    uint8_t N1_rx;
+    uint8_t N2_rx;
+    /*
+ * Setting this attribute to true will cause the engine to 
reverse the
+ * bit order of each byte it appends to a payload before sending 
the
+ * payload to a device. There may be cases where an end device 
expects
+ * a reversed order, like in the case of the Nuvoton TPM device. 
The
+ * order of bytes in the payload is not reversed, only the order 
of the

+ * 8 bits in each payload byte.
+ */
+    bool    reverse_bits;
    /* SPI Controller registers */
  uint64_t    error_reg;
@@ -52,4 +109,19 @@ typedef struct PnvSpiController {
  uint8_t sequencer_operation_reg[SPI_CONTROLLER_REG_SIZE];
  uint64_t    status_reg;
  } PnvSpiController;
+
+void log_all_N_counts(PnvSpiController *spi_controller);
+void spi_response(PnvSpiController *spi_controller, int bits,
+    xfer_buffer *rsp_payload);
+void operation_sequencer(PnvSpiController *spi_controller);
+bool operation_shiftn1(PnvSpiController *spi_controller, uint8_t 
opcode,

+   xfer_buffer **payload, bool send_n1_alone);
+bool operation_shiftn2(PnvSpiController *spi_controller, uint8_t 
opcode,

+   

Re: Add 'info pg' command to monitor

[Peter Maydell]

On Tue, 16 Apr 2024 at 17:53, Don Porter  wrote:
> There is still a lot I am learning about the code base, but it seems
> that qemu_get_guest_memory_mapping() does most of what one would need.
> It currently only returns the "leaves" of the page table tree in a list.
>
> What if I extend this function with an optional argument to either
> 1) return the interior nodes of the page table in additional lists (and
> then parse+print in the monitor code), or
> 2) inline the monitor printing in the arch-specific hook, and pass a
> flag to get_guest_memory_mapping() that turns on/off the statements that
> pretty print the page tables?
>
> It looks like most CPUs implement this function as part of checkpointing.

As far as I can see only x86 implements the get_memory_mapping
function, so once again somebody has added some bit of
functionality that does a walk of the page tables that is
x86 only and that shares no code with any of the other
page table walking code :-(

thanks
-- PMM

Re: [PATCH v2 2/6] hw/ppc: SPI controller model - registers implementation

[Chalapathi V]

On 15-04-2024 20:44, Cédric Le Goater wrote:

Hello Chalapathi

The subject could be rephrased to : "ppc/pnv: Add SPI controller model".

On 4/9/24 19:56, Chalapathi V wrote:
SPI controller device model supports a connection to a single SPI 
responder.
This provide access to SPI seeproms, TPM, flash device and an ADC 
controller.


All SPI function control is mapped into the SPI register space to 
enable full
control by firmware. In this commit SPI configuration component is 
modelled
which contains all SPI configuration and status registers as well as 
the hold

registers for data to be sent or having been received.

An existing QEMU SSI framework is used and SSI_BUS is created.

Signed-off-by: Chalapathi V 
---
  include/hw/ppc/pnv_spi_controller.h  |  55 +
  include/hw/ppc/pnv_spi_controller_regs.h | 114 ++


These two files should be under hw/ssi/ and include/hw/ssi/. Please
remove '_controller'.

Sure. Thank You.



  include/hw/ppc/pnv_xscom.h |   3 +
  hw/ppc/pnv_spi_controller.c  | 278 +++
  hw/ppc/Kconfig   |   1 +
  hw/ppc/meson.build   |   1 +
  6 files changed, 452 insertions(+)
  create mode 100644 include/hw/ppc/pnv_spi_controller.h
  create mode 100644 include/hw/ppc/pnv_spi_controller_regs.h
  create mode 100644 hw/ppc/pnv_spi_controller.c

diff --git a/include/hw/ppc/pnv_spi_controller.h 
b/include/hw/ppc/pnv_spi_controller.h

new file mode 100644
index 00..5ec50fb14c
--- /dev/null
+++ b/include/hw/ppc/pnv_spi_controller.h
@@ -0,0 +1,55 @@
+/*
+ * QEMU PowerPC SPI Controller model
+ *
+ * Copyright (c) 2024, IBM Corporation.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This model Supports a connection to a single SPI responder.
+ * Introduced for P10 to provide access to SPI seeproms, TPM, flash 
device

+ * and an ADC controller.
+ */
+#include "hw/ssi/ssi.h"
+
+#ifndef PPC_PNV_SPI_CONTROLLER_H
+#define PPC_PNV_SPI_CONTROLLER_H
+
+#define TYPE_PNV_SPI_CONTROLLER "pnv-spi-controller"
+#define PNV_SPICONTROLLER(obj) \
+    OBJECT_CHECK(PnvSpiController, (obj), TYPE_PNV_SPI_CONTROLLER)


You could use OBJECT_DECLARE_SIMPLE_TYPE ? Anyhow, I would prefer
naming the macro PNV_SPI_CONTROLLER.


+#define SPI_CONTROLLER_REG_SIZE 8
+
+typedef struct SSIBus SSIBus;


why ?

I might have got compile time errors. I will recheck and update. Thank You.




+
+#define TYPE_PNV_SPI_BUS "pnv-spi-bus"
+OBJECT_DECLARE_SIMPLE_TYPE(PnvSPIBus, PNV_SPI_BUS)
+
+typedef struct PnvSPIBus {


I don't think this extra PnvSPIBus model is useful.


+    SysBusDevice parent_obj;
+
+    SSIBus *ssi_bus;
+    qemu_irq *cs_line;


These two attributes could live under PnvSpiController.
This is added to have a SysBusDevice parent so that I can use the 
busname in command line for TPM. I will add these in PnvSpiController 
with SysBusDevice parent and test.



+    uint32_t id;


and this one would become useless.


+} PnvSPIBus;

+typedef struct PnvSpiController {
+    DeviceState parent;
+
+    PnvSPIBus   bus;
+    MemoryRegion    xscom_spic_regs;
+    /* SPI controller object number */
+    uint32_t    spic_num;
+
+    /* SPI Controller registers */
+    uint64_t    error_reg;
+    uint64_t    counter_config_reg;
+    uint64_t    config_reg1;
+    uint64_t    clock_config_reset_control;
+    uint64_t    memory_mapping_reg;
+    uint64_t    transmit_data_reg;
+    uint64_t    receive_data_reg;
+    uint8_t sequencer_operation_reg[SPI_CONTROLLER_REG_SIZE];
+    uint64_t    status_reg;


You could use an array of uint64_t also.

Sure. I will try and check.




+} PnvSpiController;
+#endif /* PPC_PNV_SPI_CONTROLLER_H */
diff --git a/include/hw/ppc/pnv_spi_controller_regs.h 
b/include/hw/ppc/pnv_spi_controller_regs.h

new file mode 100644
index 00..6f613aca5e
--- /dev/null
+++ b/include/hw/ppc/pnv_spi_controller_regs.h
@@ -0,0 +1,114 @@
+/*
+ * QEMU PowerPC SPI Controller model
+ *
+ * Copyright (c) 2023, IBM Corporation.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef SPI_CONTROLLER_REGS_H
+#define SPI_CONTROLLER_REGS_H
+
+/* Error Register */
+#define ERROR_REG   0x00
+
+/* counter_config_reg */
+#define COUNTER_CONFIG_REG  0x01
+#define COUNTER_CONFIG_REG_SHIFT_COUNT_N1   PPC_BITMASK(0, 7)
+#define COUNTER_CONFIG_REG_SHIFT_COUNT_N2   PPC_BITMASK(8, 15)
+#define COUNTER_CONFIG_REG_COUNT_COMPARE1   PPC_BITMASK(24, 31)
+#define COUNTER_CONFIG_REG_COUNT_COMPARE2   PPC_BITMASK(32, 39)
+#define COUNTER_CONFIG_REG_N1_COUNT_CONTROL PPC_BITMASK(48, 51)
+#define COUNTER_CONFIG_REG_N2_COUNT_CONTROL PPC_BITMASK(52, 55)
+
+/* config_reg */
+#define CONFIG_REG1 0x02
+
+/* clock_config_reset_control_ecc_enable_reg */
+#define CLOCK_CONFIG_REG    0x03
+#define CLOCK_CONFIG_RESET_CONTROL_HARD_RESET 0x0084;
+#define 

Re: Add 'info pg' command to monitor

[Don Porter]

On 4/15/24 12:37, Peter Maydell wrote:

On Mon, 15 Apr 2024 at 17:09, Don Porter  wrote:

This patch set adds an 'info pg' command to the monitor, which prints
a nicer view of the page tables.  A project in my graduate OS course
involves implementing x86 page table support, and my students have
found this helpful for debugging.
So, my issue with this is that it's x86 specific, and it adds
yet another monitor command that is doing "show some kind of debug
info related to the guest page tables", along with "info mem"
and "info tlb". Plus it is yet another lump of code that's
walking the guest page tables and interpreting them.

What I'd really like to see is some infrastructure that is
at least somewhat guest-architecture-agnostic, so we can
minimise what a guest architecture needs to implement (and
then make providing that mandatory).

The other thing I'd like to see is perhaps some investigation of
whether there's any way to implement something useful by
using/extending the existing get_phys_page_attrs_debug() and
similar functions, so that you don't have to write one lot
of page-table-walking code for QEMU to use when it's executing
guest code and a separate lot (that's bound to get out of
sync or not support new functionality/changes) that's only
handling these monitor debug commands. There's a lot of
complexity in figuring out things like permissions in a
modern architecture...

thanks
-- PMM
  


Thank you for the feedback!

There is still a lot I am learning about the code base, but it seems 
that qemu_get_guest_memory_mapping() does most of what one would need.  
It currently only returns the "leaves" of the page table tree in a list.


What if I extend this function with an optional argument to either
1) return the interior nodes of the page table in additional lists (and 
then parse+print in the monitor code), or
2) inline the monitor printing in the arch-specific hook, and pass a 
flag to get_guest_memory_mapping() that turns on/off the statements that 
pretty print the page tables?


It looks like most CPUs implement this function as part of checkpointing.

Thoughts?

Don

Re: [PATCH v6 09/12] hw/cxl/events: Add qmp interfaces to add/release dynamic capacity extents

[fan]

On Tue, Apr 16, 2024 at 03:58:22PM +0100, Jonathan Cameron wrote:
> On Mon, 15 Apr 2024 13:06:04 -0700
> fan  wrote:
> 
> > From ce75be83e915fbc4dd6e489f976665b81174002b Mon Sep 17 00:00:00 2001
> > From: Fan Ni 
> > Date: Tue, 20 Feb 2024 09:48:31 -0800
> > Subject: [PATCH 09/13] hw/cxl/events: Add qmp interfaces to add/release
> >  dynamic capacity extents
> > 
> > To simulate FM functionalities for initiating Dynamic Capacity Add
> > (Opcode 5604h) and Dynamic Capacity Release (Opcode 5605h) as in CXL spec
> > r3.1 7.6.7.6.5 and 7.6.7.6.6, we implemented two QMP interfaces to issue
> > add/release dynamic capacity extents requests.
> > 
> > With the change, we allow to release an extent only when its DPA range
> > is contained by a single accepted extent in the device. That is to say,
> > extent superset release is not supported yet.
> > 
> > 1. Add dynamic capacity extents:
> > 
> > For example, the command to add two continuous extents (each 128MiB long)
> > to region 0 (starting at DPA offset 0) looks like below:
> > 
> > { "execute": "qmp_capabilities" }
> > 
> > { "execute": "cxl-add-dynamic-capacity",
> >   "arguments": {
> >   "path": "/machine/peripheral/cxl-dcd0",
> >   "hid": 0,
> >   "selection-policy": 2,
> >   "region-id": 0,
> >   "tag": "",
> >   "extents": [
> >   {
> >   "offset": 0,
> >   "len": 134217728
> >   },
> >   {
> >   "offset": 134217728,
> >   "len": 134217728
> >   }
> >   ]
> >   }
> > }
> > 
> > 2. Release dynamic capacity extents:
> > 
> > For example, the command to release an extent of size 128MiB from region 0
> > (DPA offset 128MiB) looks like below:
> > 
> > { "execute": "cxl-release-dynamic-capacity",
> >   "arguments": {
> >   "path": "/machine/peripheral/cxl-dcd0",
> >   "hid": 0,
> >   "flags": 1,
> >   "region-id": 0,
> >   "tag": "",
> >   "extents": [
> >   {
> >   "offset": 134217728,
> >   "len": 134217728
> >   }
> >   ]
> >   }
> > }
> > 
> > Signed-off-by: Fan Ni 
> 
> Nice!  A few small comments inline - particularly don't be nice to the
> kernel by blocking things it doesn't understand yet ;)
> 
> Jonathan
> 
> > ---
> >  hw/cxl/cxl-mailbox-utils.c  |  65 ++--
> >  hw/mem/cxl_type3.c  | 310 +++-
> >  hw/mem/cxl_type3_stubs.c|  20 +++
> >  include/hw/cxl/cxl_device.h |  22 +++
> >  include/hw/cxl/cxl_events.h |  18 +++
> >  qapi/cxl.json   |  69 
> >  6 files changed, 491 insertions(+), 13 deletions(-)
> > 
> > diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
> > index cd9092b6bf..839ae836a1 100644
> > --- a/hw/cxl/cxl-mailbox-utils.c
> > +++ b/hw/cxl/cxl-mailbox-utils.c
> 
> >  /*
> >   * CXL r3.1 Table 8-168: Add Dynamic Capacity Response Input Payload
> >   * CXL r3.1 Table 8-170: Release Dynamic Capacity Input Payload
> > @@ -1541,6 +1579,7 @@ static CXLRetCode 
> > cxl_dcd_add_dyn_cap_rsp_dry_run(CXLType3Dev *ct3d,
> >  {
> >  uint32_t i;
> >  CXLDCExtent *ent;
> > +CXLDCExtentGroup *ext_group;
> >  uint64_t dpa, len;
> >  Range range1, range2;
> >  
> > @@ -1551,9 +1590,13 @@ static CXLRetCode 
> > cxl_dcd_add_dyn_cap_rsp_dry_run(CXLType3Dev *ct3d,
> >  range_init_nofail(, dpa, len);
> >  
> >  /*
> > - * TODO: once the pending extent list is added, check against
> > - * the list will be added here.
> > + * The host-accepted DPA range must be contained by the first 
> > extent
> > + * group in the pending list
> >   */
> > +ext_group = QTAILQ_FIRST(>dc.extents_pending);
> > +if (!cxl_extents_contains_dpa_range(_group->list, dpa, len)) {
> > +return CXL_MBOX_INVALID_PA;
> > +}
> >  
> >  /* to-be-added range should not overlap with range already 
> > accepted */
> >  QTAILQ_FOREACH(ent, >dc.extents, node) {
> > @@ -1588,26 +1631,26 @@ static CXLRetCode cmd_dcd_add_dyn_cap_rsp(const 
> > struct cxl_cmd *cmd,
> >  CXLRetCode ret;
> >  
> >  if (in->num_entries_updated == 0) {
> > -/*
> > - * TODO: once the pending list is introduced, extents in the 
> > beginning
> > - * will get wiped out.
> > - */
> > +cxl_extent_group_list_delete_front(>dc.extents_pending);
> >  return CXL_MBOX_SUCCESS;
> >  }
> >  
> >  /* Adding extents causes exceeding device's extent tracking ability. */
> >  if (in->num_entries_updated + ct3d->dc.total_extent_count >
> >  CXL_NUM_EXTENTS_SUPPORTED) {
> > +cxl_extent_group_list_delete_front(>dc.extents_pending);
> >  return CXL_MBOX_RESOURCES_EXHAUSTED;
> >  }
> >  
> >  ret = cxl_detect_malformed_extent_list(ct3d, in);
> >  if (ret != CXL_MBOX_SUCCESS) {
> > +cxl_extent_group_list_delete_front(>dc.extents_pending);
> 
> If it's a bad message from the host, I don't think the 

Re: [PATCH v3 15/16] test/avocado/machine_aspeed.py: Add AST2700 test case

[Cédric Le Goater]

On 4/16/24 11:19, Jamin Lin wrote:

Add a test case to test Aspeed OpenBMC SDK v09.01 on AST2700 board.

It loads u-boot-nodtb.bin, u-boot.dtb, tfa and optee-os
images to dram first which base address is 0x4.
Then, boot and launch 4 cpu cores.

```
qemu-system-aarch64 -machine ast2700-evb
 -device loader,force-raw=on,addr=0x4,file=workdir/u-boot-nodtb.bin 
\
 -device loader,force-raw=on,addr=uboot_dtb_load_addr,file=u-boot.dtb\
 -device loader,force-raw=on,addr=0x43000,file=workdir/bl31.bin\
 -device 
loader,force-raw=on,addr=0x43008,file=workdir/optee/tee-raw.bin\
 -device loader,cpu-num=0,addr=0x43000 \
 -device loader,cpu-num=1,addr=0x43000 \
 -device loader,cpu-num=2,addr=0x43000 \
 -device loader,cpu-num=3,addr=0x43000 \
 -smp 4 \
 -drive file=workdir/image-bmc,format=raw,if=mtd
```

A test image is downloaded from the ASPEED Forked OpenBMC GitHub release 
repository :
https://github.com/AspeedTech-BMC/openbmc/releases/

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  tests/avocado/machine_aspeed.py | 62 +
  1 file changed, 62 insertions(+)

diff --git a/tests/avocado/machine_aspeed.py b/tests/avocado/machine_aspeed.py
index cec0181424..3a20644fb2 100644
--- a/tests/avocado/machine_aspeed.py
+++ b/tests/avocado/machine_aspeed.py
@@ -311,6 +311,17 @@ def do_test_arm_aspeed_sdk_start(self, image):
  self, 'boot', '## Loading kernel from FIT Image')
  self.wait_for_console_pattern('Starting kernel ...')
  
+def do_test_aarch64_aspeed_sdk_start(self, image):

+self.vm.set_console()
+self.vm.add_args('-drive', 'file=' + image + ',if=mtd,format=raw')
+
+self.vm.launch()
+
+self.wait_for_console_pattern('U-Boot 2023.10')
+self.wait_for_console_pattern('## Loading kernel from FIT Image')
+self.wait_for_console_pattern('Starting kernel ...')
+self.wait_for_console_pattern("systemd[1]: Hostname set to")
+
  @skipUnless(os.getenv('QEMU_TEST_FLAKY_TESTS'), 'Test is unstable on 
GitLab')
  
  def test_arm_ast2500_evb_sdk(self):

@@ -375,3 +386,54 @@ def test_arm_ast2600_evb_sdk(self):
   'i2c i2c-5: new_device: Instantiated device ds1307 at 0x32');
  year = time.strftime("%Y")
  self.ssh_command_output_contains('/sbin/hwclock -f /dev/rtc1', year);
+
+def test_aarch64_ast2700_evb_sdk_v09_01(self):
+"""
+:avocado: tags=arch:aarch64
+:avocado: tags=machine:ast2700-evb
+"""
+
+image_url = ('https://github.com/AspeedTech-BMC/openbmc/releases/'
+ 'download/v09.01/ast2700-default-obmc.tar.gz')
+image_hash = 
'b1cc0fd73c7650d34c9c8459a243f52a91e9e27144b8608b2645ab19461d1e07'
+image_path = self.fetch_asset(image_url, asset_hash=image_hash,
+  algorithm='sha256')
+archive.extract(image_path, self.workdir)
+
+num_cpu = 4
+image_dir = self.workdir + '/ast2700-default/'
+uboot_size = os.path.getsize(image_dir + 'u-boot-nodtb.bin')
+uboot_dtb_load_addr = hex(0x4 + uboot_size)
+
+load_images_list = [
+{
+'addr': '0x4',
+'file': image_dir + 'u-boot-nodtb.bin'
+},
+{
+'addr': str(uboot_dtb_load_addr),
+'file': image_dir + 'u-boot.dtb'
+},
+{
+'addr': '0x43000',
+'file': image_dir + 'bl31.bin'
+},
+{
+'addr': '0x43008',
+'file': image_dir + 'optee/tee-raw.bin'
+}
+]
+
+for load_image in load_images_list:
+addr = load_image['addr']
+file = load_image['file']
+self.vm.add_args('-device',
+ f'loader,force-raw=on,addr={addr},file={file}')
+
+for i in range(num_cpu):
+self.vm.add_args('-device',
+ f'loader,addr=0x43000,cpu-num={i}')
+
+self.vm.add_args('-smp', str(num_cpu))
+self.do_test_aarch64_aspeed_sdk_start(image_dir + 'image-bmc')
+

Re: [PATCH v6 10/12] hw/mem/cxl_type3: Add dpa range validation for accesses to DC regions

[fan]

On Tue, Apr 16, 2024 at 04:00:56PM +0100, Jonathan Cameron wrote:
> On Mon, 15 Apr 2024 10:37:00 -0700
> fan  wrote:
> 
> > On Fri, Apr 12, 2024 at 06:54:42PM -0400, Gregory Price wrote:
> > > On Mon, Mar 25, 2024 at 12:02:28PM -0700, nifan@gmail.com wrote:  
> > > > From: Fan Ni 
> > > > 
> > > > All dpa ranges in the DC regions are invalid to access until an extent
> > > > covering the range has been added. Add a bitmap for each region to
> > > > record whether a DC block in the region has been backed by DC extent.
> > > > For the bitmap, a bit in the bitmap represents a DC block. When a DC
> > > > extent is added, all the bits of the blocks in the extent will be set,
> > > > which will be cleared when the extent is released.
> > > > 
> > > > Reviewed-by: Jonathan Cameron 
> > > > Signed-off-by: Fan Ni 
> > > > ---
> > > >  hw/cxl/cxl-mailbox-utils.c  |  6 +++
> > > >  hw/mem/cxl_type3.c  | 76 +
> > > >  include/hw/cxl/cxl_device.h |  7 
> > > >  3 files changed, 89 insertions(+)
> > > > 
> > > > diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
> > > > index 7094e007b9..a0d2239176 100644
> > > > --- a/hw/cxl/cxl-mailbox-utils.c
> > > > +++ b/hw/cxl/cxl-mailbox-utils.c
> > > > @@ -1620,6 +1620,7 @@ static CXLRetCode cmd_dcd_add_dyn_cap_rsp(const 
> > > > struct cxl_cmd *cmd,
> > > >  
> > > >  cxl_insert_extent_to_extent_list(extent_list, dpa, len, NULL, 
> > > > 0);
> > > >  ct3d->dc.total_extent_count += 1;
> > > > +ct3_set_region_block_backed(ct3d, dpa, len);
> > > >  
> > > >  ent = QTAILQ_FIRST(>dc.extents_pending);
> > > >  cxl_remove_extent_from_extent_list(>dc.extents_pending, 
> > > > ent);  
> > > 
> > > while looking at the MHD code, we had decided to "reserve" the blocks in
> > > the bitmap in the call to `qmp_cxl_process_dynamic_capacity` in order to
> > > prevent a potential double-allocation (basically we need to sanity check
> > > that two hosts aren't reserving the region PRIOR to the host being
> > > notified).
> > > 
> > > I did not see any checks in the `qmp_cxl_process_dynamic_capacity` path
> > > to prevent pending extents from being double-allocated.  Is this an
> > > explicit choice?
> > > 
> > > I can see, for example, why you may want to allow the following in the
> > > pending list: [Add X, Remove X, Add X].  I just want to know if this is
> > > intentional or not. If not, you may consider adding a pending check
> > > during the sanity check phase of `qmp_cxl_process_dynamic_capacity`
> > > 
> > > ~Gregory  
> > 
> > First, for remove request, pending list is not involved. See cxl r3.1,
> > 9.13.3.3. Pending basically means "pending to add". 
> > So for the above example, in the pending list, you can see [Add x, add x] 
> > if the
> > event is not processed in time.
> > Second, from the spec, I cannot find any text saying we cannot issue
> > another add extent X if it is still pending.
> 
> I think there is text saying that the capacity is not released for reuse
> by the device until it receives a response from the host.   Whilst
> it's not explicit on offers to the same host, I'm not sure that matters.
> So I don't think it is suppose to queue multiple extents...

Are you suggesting we add a check here to reject the second add when the
first one is still pending?

Currently, we do not allow releasing an extent when it is still pending,
which aligns with the case you mentioned above "not release for reuse", I
think.
Can the second add mean a retry instead of reuse? 

Fan

> 
> 
> > From the kernel side, if the first one is accepted, the second one will
> > get rejected, and there is no issue there.
> > If the first is reject for some reason, the second one can get
> > accepted or rejected and do not need to worry about the first one.
> > 
> > 
> > Fan
> > 
> 

Re: [PATCH] Add zh_TW Traditional Chinese translation

[Daniel P . Berrangé]

On Wed, Apr 17, 2024 at 12:41:16AM +0800, Zhao Liu wrote:
> Hi Peter,
> 
> On Tue, Apr 16, 2024 at 02:27:45PM +0100, Peter Maydell wrote:
> > Date: Tue, 16 Apr 2024 14:27:45 +0100
> > From: Peter Maydell 
> > Subject: Re: [PATCH] Add zh_TW Traditional Chinese translation
> > 
> > On Tue, 16 Apr 2024 at 14:00, Peter Dave Hello  
> > wrote:
> > >
> > > From: Peter Dave Hello 
> > > Date: Tue, 16 Apr 2024 00:43:29 +0800
> > > Subject: [PATCH] Add a simple zh_TW Traditional Chinese translation
> > >
> > > This patch adds a basic zh_TW translation file for Taiwan Traditional
> > > Chinese users.
> > >
> > > Signed-off-by: Peter Dave Hello 
> > 
> > This name in your Signed-off-by line doesn't match the
> > name you use in the .po file...
> > 
> > > ---
> > >  po/LINGUAS  |  1 +
> > >  po/zh_TW.po | 93 +
> > >  2 files changed, 94 insertions(+)
> > >  create mode 100644 po/zh_TW.po
> > >
> > > diff --git a/po/LINGUAS b/po/LINGUAS
> > > index 9b33a36..08163e8 100644
> > > --- a/po/LINGUAS
> > > +++ b/po/LINGUAS
> > > @@ -7,3 +7,4 @@ sv
> > >  tr
> > >  uk
> > >  zh_CN
> > > +zh_TW
> > > diff --git a/po/zh_TW.po b/po/zh_TW.po
> > > new file mode 100644
> > > index 000..d25557e
> > > --- /dev/null
> > > +++ b/po/zh_TW.po
> > > @@ -0,0 +1,93 @@
> > > +# Chinese translations for PACKAGE package.
> > > +# Copyright (C) 2024 THE PACKAGE'S COPYRIGHT HOLDER
> > > +# This file is distributed under the same license as the PACKAGE package.
> > 
> > Can you replace all these placeholder ALLCAPS items
> > with the right values, please?
> > 
> > > +# Peter Hsu , 2024.
> > > +#
> 
> Open source license is missing here.
> 
> And I checked the other .po files and found that none of them declare
> the open source license, are they missing it? Or does this case default
> to "GPL-2.0-or-later"?

Best practice is for every file to mention its license, ideally
using the "SPDX-Identifier"  tag syntax for new files.

If any file is missing a license header statement, then implicitly it
falls under the LICENSE file rules, which is GPL-2.0-or-later. 

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 v6 08/12] hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release dynamic capacity response

[fan]

On Tue, Apr 16, 2024 at 10:02:53AM +, Jørgen Hansen wrote:
> On 4/15/24 19:56, fan wrote:
> >  From 4b9695299d3d4b22f83666f8ab79099ec9f9817f Mon Sep 17 00:00:00 2001
> > From: Fan Ni 
> > Date: Tue, 20 Feb 2024 09:48:30 -0800
> > Subject: [PATCH 08/13] hw/cxl/cxl-mailbox-utils: Add mailbox commands to
> >   support add/release dynamic capacity response
> > 
> > Per CXL spec 3.1, two mailbox commands are implemented:
> > Add Dynamic Capacity Response (Opcode 4802h) 8.2.9.9.9.3, and
> > Release Dynamic Capacity (Opcode 4803h) 8.2.9.9.9.4.
> > 
> > For the process of the above two commands, we use two-pass approach.
> > Pass 1: Check whether the input payload is valid or not; if not, skip
> >  Pass 2 and return mailbox process error.
> > Pass 2: Do the real work--add or release extents, respectively.
> > 
> > Signed-off-by: Fan Ni 
> > ---
> >   hw/cxl/cxl-mailbox-utils.c  | 396 
> >   hw/mem/cxl_type3.c  |  11 +
> >   include/hw/cxl/cxl_device.h |   4 +
> >   3 files changed, 411 insertions(+)
> > 
> > diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
> > index 1915959015..cd9092b6bf 100644
> > --- a/hw/cxl/cxl-mailbox-utils.c
> > +++ b/hw/cxl/cxl-mailbox-utils.c
> 
> snip
> 
> > +/*
> > + * Copy extent list from src to dst
> > + * Return value: number of extents copied
> > + */
> > +static uint32_t copy_extent_list(CXLDCExtentList *dst,
> > + const CXLDCExtentList *src)
> > +{
> > +uint32_t cnt = 0;
> > +CXLDCExtent *ent;
> > +
> > +if (!dst || !src) {
> > +return 0;
> > +}
> > +
> > +QTAILQ_FOREACH(ent, src, node) {
> > +cxl_insert_extent_to_extent_list(dst, ent->start_dpa, ent->len,
> > + ent->tag, ent->shared_seq);
> > +cnt++;
> > +}
> > +return cnt;
> > +}
> > +
> > +static CXLRetCode cxl_dc_extent_release_dry_run(CXLType3Dev *ct3d,
> > +const CXLUpdateDCExtentListInPl *in, CXLDCExtentList *updated_list,
> > +uint32_t *updated_list_size)
> > +{
> > +CXLDCExtent *ent, *ent_next;
> > +uint64_t dpa, len;
> > +uint32_t i;
> > +int cnt_delta = 0;
> > +CXLRetCode ret = CXL_MBOX_SUCCESS;
> > +
> > +QTAILQ_INIT(updated_list);
> > +copy_extent_list(updated_list, >dc.extents);
> > +
> > +for (i = 0; i < in->num_entries_updated; i++) {
> > +Range range;
> > +
> > +dpa = in->updated_entries[i].start_dpa;
> > +len = in->updated_entries[i].len;
> > +
> > +while (len > 0) {
> > +QTAILQ_FOREACH(ent, updated_list, node) {
> > +range_init_nofail(, ent->start_dpa, ent->len);
> > +
> > +if (range_contains(, dpa)) {
> > +uint64_t len1, len2 = 0, len_done = 0;
> > +uint64_t ent_start_dpa = ent->start_dpa;
> > +uint64_t ent_len = ent->len;
> > +
> > +len1 = dpa - ent->start_dpa;
> > +/* Found the extent or the subset of an existing 
> > extent */
> > +if (range_contains(, dpa + len - 1)) {
> > +len2 = ent_start_dpa + ent_len - dpa - len;
> > +} else {
> > +/*
> > + * TODO: we reject the attempt to remove an extent
> > + * that overlaps with multiple extents in the 
> > device
> > + * for now. We will allow it once superset release
> > + * support is added.
> > + */
> > +ret = CXL_MBOX_INVALID_PA;
> > +goto free_and_exit;
> > +}
> > +len_done = ent_len - len1 - len2;
> > +
> > +cxl_remove_extent_from_extent_list(updated_list, ent);
> > +cnt_delta--;
> > +
> > +if (len1) {
> > +cxl_insert_extent_to_extent_list(updated_list,
> > + ent_start_dpa,
> > + len1, NULL, 0);
> > +cnt_delta++;
> > +}
> > +if (len2) {
> > +cxl_insert_extent_to_extent_list(updated_list,
> > + dpa + len,
> > + len2, NULL, 0);
> > +cnt_delta++;
> > +}
> > +
> > +if (cnt_delta + ct3d->dc.total_extent_count >
> > +CXL_NUM_EXTENTS_SUPPORTED) {
> > +ret = CXL_MBOX_RESOURCES_EXHAUSTED;
> > +goto free_and_exit;
> > +}
> > +
> > +len -= len_done;
> > +/* len == 0 here until 

Re: [PATCH] Add zh_TW Traditional Chinese translation

[Zhao Liu]

Hi Peter,

On Tue, Apr 16, 2024 at 02:27:45PM +0100, Peter Maydell wrote:
> Date: Tue, 16 Apr 2024 14:27:45 +0100
> From: Peter Maydell 
> Subject: Re: [PATCH] Add zh_TW Traditional Chinese translation
> 
> On Tue, 16 Apr 2024 at 14:00, Peter Dave Hello  
> wrote:
> >
> > From: Peter Dave Hello 
> > Date: Tue, 16 Apr 2024 00:43:29 +0800
> > Subject: [PATCH] Add a simple zh_TW Traditional Chinese translation
> >
> > This patch adds a basic zh_TW translation file for Taiwan Traditional
> > Chinese users.
> >
> > Signed-off-by: Peter Dave Hello 
> 
> This name in your Signed-off-by line doesn't match the
> name you use in the .po file...
> 
> > ---
> >  po/LINGUAS  |  1 +
> >  po/zh_TW.po | 93 +
> >  2 files changed, 94 insertions(+)
> >  create mode 100644 po/zh_TW.po
> >
> > diff --git a/po/LINGUAS b/po/LINGUAS
> > index 9b33a36..08163e8 100644
> > --- a/po/LINGUAS
> > +++ b/po/LINGUAS
> > @@ -7,3 +7,4 @@ sv
> >  tr
> >  uk
> >  zh_CN
> > +zh_TW
> > diff --git a/po/zh_TW.po b/po/zh_TW.po
> > new file mode 100644
> > index 000..d25557e
> > --- /dev/null
> > +++ b/po/zh_TW.po
> > @@ -0,0 +1,93 @@
> > +# Chinese translations for PACKAGE package.
> > +# Copyright (C) 2024 THE PACKAGE'S COPYRIGHT HOLDER
> > +# This file is distributed under the same license as the PACKAGE package.
> 
> Can you replace all these placeholder ALLCAPS items
> with the right values, please?
> 
> > +# Peter Hsu , 2024.
> > +#

Open source license is missing here.

And I checked the other .po files and found that none of them declare
the open source license, are they missing it? Or does this case default
to "GPL-2.0-or-later"?

Thanks,
Zhao

Re: [PATCH] Add zh_TW Traditional Chinese translation

[Zhao Liu]

On Tue, Apr 16, 2024 at 11:31:24AM +, Peter Dave Hello wrote:
> Date: Tue, 16 Apr 2024 11:31:24 +
> From: Peter Dave Hello 
> Subject: [PATCH] Add zh_TW Traditional Chinese translation
> 
> From: Peter Dave Hello 
> Date: Tue, 16 Apr 2024 00:43:29 +0800
> Subject: [PATCH] Add a simple zh_TW Traditional Chinese translation
> 
> This patch adds a basic zh_TW translation file for Taiwan Traditional
> Chinese users.
> 
> Signed-off-by: Peter Dave Hello 
> ---
>  po/LINGUAS  |  1 +
>  po/zh_TW.po | 93 +
>  2 files changed, 94 insertions(+)
>  create mode 100644 po/zh_TW.po
> 
> diff --git a/po/LINGUAS b/po/LINGUAS
> index 9b33a36..08163e8 100644
> --- a/po/LINGUAS
> +++ b/po/LINGUAS
> @@ -7,3 +7,4 @@ sv
>  tr
>  uk
>  zh_CN
> +zh_TW
> diff --git a/po/zh_TW.po b/po/zh_TW.po
> new file mode 100644
> index 000..d25557e
> --- /dev/null
> +++ b/po/zh_TW.po
> @@ -0,0 +1,93 @@
> +# Chinese translations for PACKAGE package.
> +# Copyright (C) 2024 THE PACKAGE'S COPYRIGHT HOLDER
> +# This file is distributed under the same license as the PACKAGE package.
> +# Peter Hsu , 2024.
> +#
> +msgid ""
> +msgstr ""
> +"Project-Id-Version: PACKAGE VERSION\n"

"Project-Id-Version: QEMU 9.1 \n"

(Now the target version should be v9.1.)

> +"Report-Msgid-Bugs-To: \n"

"Report-Msgid-Bugs-To: qemu-devel@nongnu.org\n"

> +"POT-Creation-Date: 2024-04-16 17:52+0800\n"
> +"PO-Revision-Date: 2024-04-16 17:52+0800\n"
> +"Last-Translator: Peter Hsu \n"
> +"Language-Team: Chinese (traditional)\n"
> +"Language: zh_TW\n"
> +"MIME-Version: 1.0\n"
> +"Content-Type: text/plain; charset=ASCII\n"
> +"Content-Transfer-Encoding: 8bit\n"
> +
> +#: ui/gtk.c:231

Referring to the support of other languages, the comment here can be
deleted. The lineno related comments in the following text can be
similarly deleted.

Regards,
Zhao

Re: [QEMU][PATCH v3 5/7] memory: add MemoryRegion map and unmap callbacks

[Peter Xu]

On Tue, Apr 16, 2024 at 03:28:41PM +0200, Jürgen Groß wrote:
> On 16.04.24 13:32, Edgar E. Iglesias wrote:
> > On Wed, Apr 10, 2024 at 8:56 PM Peter Xu  wrote:
> > > 
> > > On Wed, Apr 10, 2024 at 06:44:38PM +0200, Edgar E. Iglesias wrote:
> > > > On Tue, Feb 27, 2024 at 11:37 PM Vikram Garhwal 
> > > > wrote:
> > > > 
> > > > > From: Juergen Gross 
> > > > > 
> > > > > In order to support mapping and unmapping guest memory dynamically to
> > > > > and from qemu during address_space_[un]map() operations add the map()
> > > > > and unmap() callbacks to MemoryRegionOps.
> > > > > 
> > > > > Those will be used e.g. for Xen grant mappings when performing guest
> > > > > I/Os.
> > > > > 
> > > > > Signed-off-by: Juergen Gross 
> > > > > Signed-off-by: Vikram Garhwal 
> > > > > 
> > > > 
> > > > 
> > > > Paolo, Peter, David, Phiippe, do you guys have any concerns with this 
> > > > patch?
> > > 
> > 
> > Thanks for your comments Peter,
> > 
> > 
> > > This introduces a 3rd memory type afaict, neither direct nor !direct.
> > > 
> > > What happens if someone does address_space_write() to it?  I didn't see it
> > > covered here..
> > 
> > You're right, that won't work, the memory needs to be mapped before it
> > can be used.
> > At minimum there should be some graceful failure, right now this will crash.
> > 
> > > 
> > > OTOH, the cover letter didn't mention too much either on the big picture:
> > > 
> > > https://lore.kernel.org/all/20240227223501.28475-1-vikram.garh...@amd.com/
> > > 
> > > I want to have a quick grasp on whether it's justified worthwhile we 
> > > should
> > > introduce this complexity to qemu memory core.
> > > 
> > > Could I request a better cover letter when repost?  It'll be great to
> > > mention things like:
> > 
> > I'll do that, but also answer inline in the meantime since we should
> > perhaps change the approach.
> > 
> > > 
> > >- what is grant mapping, why it needs to be used, when it can be used 
> > > (is
> > >  it only relevant to vIOMMU=on)?  Some more information on the high
> > >  level design using this type or MR would be great.
> > 
> > https://github.com/xen-project/xen/blob/master/docs/misc/grant-tables.txt
> > 
> > Xen VM's that use QEMU's VirtIO have a QEMU instance running in a separate 
> > VM.
> > 
> > There's basically two mechanisms for QEMU's Virtio backends to access
> > the guest's RAM.
> > 1. Foreign mappings. This gives the VM running QEMU access to the
> > entire RAM of the guest VM.
> 
> Additionally it requires qemu to run in dom0, while in general Xen allows
> to run backends in less privileged "driver domains", which are usually not
> allowed to perform foreign mappings.
> 
> > 2. Grant mappings. This allows the guest to dynamically grant and
> > remove access to pages as needed.
> > So the VM running QEMU, cannot map guest RAM unless it's been
> > instructed to do so by the guest.
> > 
> > #2 is desirable because if QEMU gets compromised it has a smaller
> > attack surface onto the guest.
> 
> And it allows to run the virtio backend in a less privileged VM.
> 
> > 
> > > 
> > >- why a 3rd memory type is required?  Do we have other alternatives?
> > 
> > Yes, there are alternatives.
> > 
> > 1. It was suggested by Stefano to try to handle this in existing 
> > qemu/hw/xen/*.
> > This would be less intrusive but perhaps also less explicit.
> > Concerns about touching the Memory API have been raised before, so
> > perhaps we should try this.
> > I'm a little unsure how we would deal with unmapping when the guest
> > removes our grants and we're using models that don't map but use
> > address_space_read/write().
> 
> Those would either need to use grant-copy hypercalls, or they'd need to map,
> read/write, unmap.
> 
> > 
> > 2. Another approach could be to change the Xen grant-iommu in the
> > Linux kernel to work with a grant vIOMMU in QEMU.
> > Linux could explicitly ask QEMU's grant vIOMMU to map/unmap granted regions.
> > This would have the benefit that we wouldn't need to allocate
> > address-bit 63 for grants.
> > A drawback is that it may be slower since we're going to need to
> > bounce between guest/qemu a bit more.
> 
> It would be a _lot_ slower, unless virtio-iommu and grants are both modified
> to match. I have looked into that, but the needed effort is rather large. At
> the last Xen summit I have suggested to introduce a new grant format which
> would work more like a normal page table structure. Using the same format
> for virtio-iommu would allow to avoid the additional bounces between qemu and
> the guest (and in fact that was one of the motivations to suggest the new
> grant format).

I have a better picture now, thanks both.

It really looks like an vIOMMU already to me, perhaps with a special refID
mapping playing similar roles as IOVAs in the rest IOMMU worlds.

I can't yet tell what's the best way for Xen - as of now QEMU's memory API
does provide such translations via IOMMUMemoryRegionClass.translate(), but
only from 

Re: [PATCH v3 16/16] docs:aspeed: Add AST2700 Evaluation board

[Cédric Le Goater]

On 4/16/24 11:19, Jamin Lin wrote:

Add AST2700 Evaluation board and its boot command.

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  docs/system/arm/aspeed.rst | 39 ++
  1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst
index b2dea54eed..320ff2a4cd 100644
--- a/docs/system/arm/aspeed.rst
+++ b/docs/system/arm/aspeed.rst
@@ -1,11 +1,12 @@
-Aspeed family boards (``*-bmc``, ``ast2500-evb``, ``ast2600-evb``)
-==
+Aspeed family boards (``*-bmc``, ``ast2500-evb``, ``ast2600-evb``, 
``ast2700-evb``)
+===
  
  The QEMU Aspeed machines model BMCs of various OpenPOWER systems and

  Aspeed evaluation boards. They are based on different releases of the
  Aspeed SoC : the AST2400 integrating an ARM926EJ-S CPU (400MHz), the
-AST2500 with an ARM1176JZS CPU (800MHz) and more recently the AST2600
-with dual cores ARM Cortex-A7 CPUs (1.2GHz).
+AST2500 with an ARM1176JZS CPU (800MHz), the AST2600
+with dual cores ARM Cortex-A7 CPUs (1.2GHz) and more recently the AST2700
+with quad cores ARM Cortex-A35 64 bits CPUs (1.6GHz)
  
  The SoC comes with RAM, Gigabit ethernet, USB, SD/MMC, USB, SPI, I2C,

  etc.
@@ -38,6 +39,10 @@ AST2600 SoC based machines :
  - ``qcom-dc-scm-v1-bmc``   Qualcomm DC-SCM V1 BMC
  - ``qcom-firework-bmc``Qualcomm Firework BMC
  
+AST2700 SoC based machines :

+
+- ``ast2700-evb``  Aspeed AST2700 Evaluation board (Cortex-A35)
+
  Supported devices
  -
  
@@ -66,6 +71,7 @@ Supported devices

   * eMMC Boot Controller (dummy)
   * PECI Controller (minimal)
   * I3C Controller
+ * Internal Bridge Controller (SLI dummy)
  
  
  Missing devices

@@ -95,6 +101,10 @@ or directly from the OpenBMC GitHub release repository :
  
 https://github.com/openbmc/openbmc/releases
  
+or directly from the ASPEED Forked OpenBMC GitHub release repository :

+
+   https://github.com/AspeedTech-BMC/openbmc/releases
+
  To boot a kernel directly from a Linux build tree:
  
  .. code-block:: bash

@@ -164,6 +174,27 @@ under Linux), use :
  
-M ast2500-evb,bmc-console=uart3
  
+

+Boot the AST2700 machine from the flash image, use an MTD drive :
+
+.. code-block:: bash
+
+  IMGDIR=ast2700-default
+  UBOOT_SIZE=$(stat --format=%s -L ${IMGDIR}/u-boot-nodtb.bin)
+
+  $ qemu-system-aarch64 -M ast2700-evb \
+   -device 
loader,force-raw=on,addr=0x4,file=${IMGDIR}/u-boot-nodtb.bin \
+   -device loader,force-raw=on,addr=$((0x4 + 
${UBOOT_SIZE})),file=u-boot.dtb \
+   -device loader,force-raw=on,addr=0x43000,file=${IMGDIR}/bl31.bin \
+   -device 
loader,force-raw=on,addr=0x43008,file=${IMGDIR}/optee/tee-raw.bin \
+   -device loader,cpu-num=0,addr=0x43000 \
+   -device loader,cpu-num=1,addr=0x43000 \
+   -device loader,cpu-num=2,addr=0x43000 \
+   -device loader,cpu-num=3,addr=0x43000 \
+   -smp 4 \
+   -drive file=${IMGDIR}/image-bmc,format=raw,if=mtd \
+   -nographic
+
  Aspeed minibmc family boards (``ast1030-evb``)
  ==
  

Re: [PATCH v3 01/22] hw/i386/pc: Deprecate 2.4 to 2.7 pc-i440fx machines

[Thomas Huth]

On 16/04/2024 16.49, Philippe Mathieu-Daudé wrote:

On 16/4/24 16:23, Thomas Huth wrote:

On 16/04/2024 15.52, Philippe Mathieu-Daudé wrote:

Similarly to the commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated",
deprecate the 2.4 to 2.7 machines.

Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
  docs/about/deprecated.rst | 4 ++--
  hw/i386/pc_piix.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..967ee34267 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,8 +219,8 @@ deprecated; use the new name ``dtb-randomness`` 
instead. The new name

  better reflects the way this property affects all random data within
  the device tree blob, not just the ``kaslr-seed`` node.
-``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
-'
+``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2) and 
``pc-i440fx-2.4`` up to ``pc-i440fx-2.7`` (since 9.1)

+'''


Didn't we want to mark everything up to 2.12 as deprecated?


I took your suggestion:
https://lore.kernel.org/qemu-devel/2a01baa6-b6a3-4572-94cd-63b2eaab7...@redhat.com/
I am happy to go up to 2.12 :)


I thought we discussed deprecating all machine types up to 2.12 on all 
targets when we discussed the ppc spapr machine type deprecation later ... 
but I cannot find that discussion anymore, maybe it was just on IRC ...


Anyway, let's go with up to 2.12 if nobody complains!

 Thomas

Re: [RFC QEMU PATCH v9 2/2] virtio-pci: implement No_Soft_Reset bit

[Igor Mammedov]

On Tue, 16 Apr 2024 15:01:27 +0800
Jiqian Chen  wrote:

> In current code, when guest does S3, virtio-gpu are reset due to the
> bit No_Soft_Reset is not set. After resetting, the display resources
> of virtio-gpu are destroyed, then the display can't come back and only
> show blank after resuming.

Just a high level question.
Typically when system goes into S3 all devices (modulo RAM) loose context
(aka powered off), and then it's upto device driver to recover whatever
was lost.
So why should we implement hw(qemu) workaround for a driver problem?

> 
> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> this bit, if this bit is set, the devices resetting will not be done, and
> then the display can work after resuming.
> 
> No_Soft_Reset bit is implemented for all virtio devices, and was tested
> only on virtio-gpu device. Set it false by default for safety.
> 
> Signed-off-by: Jiqian Chen 
> ---
>  hw/virtio/virtio-pci.c | 37 ++
>  include/hw/virtio/virtio-pci.h |  5 +
>  2 files changed, 42 insertions(+)
> 
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index a1b61308e7a0..82fa4defe5cd 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -2230,6 +2230,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> Error **errp)
>  pcie_cap_lnkctl_init(pci_dev);
>  }
>  
> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> + PCI_PM_CTRL_NO_SOFT_RESET);
> +}
> +
>  if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
>  /* Init Power Management Control Register */
>  pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
> @@ -2292,11 +2297,37 @@ static void virtio_pci_reset(DeviceState *qdev)
>  }
>  }
>  
> +static bool virtio_pci_no_soft_reset(PCIDevice *dev)
> +{
> +uint16_t pmcsr;
> +
> +if (!pci_is_express(dev) || !dev->exp.pm_cap) {
> +return false;
> +}
> +
> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> +
> +/*
> + * When No_Soft_Reset bit is set and the device
> + * is in D3hot state, don't reset device
> + */
> +return (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> +   (pmcsr & PCI_PM_CTRL_STATE_MASK) == 3;
> +}
> +
>  static void virtio_pci_bus_reset_hold(Object *obj)
>  {
>  PCIDevice *dev = PCI_DEVICE(obj);
>  DeviceState *qdev = DEVICE(obj);
>  
> +/*
> + * Note that: a proposal to add SUSPEND bit is being discussed,
> + * may need to consider the state of SUSPEND bit in future
> + */
> +if (virtio_pci_no_soft_reset(dev)) {
> +return;
> +}
> +
>  virtio_pci_reset(qdev);
>  
>  if (pci_is_express(dev)) {
> @@ -2336,6 +2367,12 @@ static Property virtio_pci_properties[] = {
>  VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
>  DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
>  VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> +/*
> + * for safety, set this false by default, if change it to true,
> + * need to consider compatible for old machine
> + */
> +DEFINE_PROP_BIT("pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
>  DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
>  VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
>  DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
> index 59d88018c16a..9e67ba38c748 100644
> --- a/include/hw/virtio/virtio-pci.h
> +++ b/include/hw/virtio/virtio-pci.h
> @@ -43,6 +43,7 @@ enum {
>  VIRTIO_PCI_FLAG_INIT_FLR_BIT,
>  VIRTIO_PCI_FLAG_AER_BIT,
>  VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
> +VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT,
>  };
>  
>  /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -79,6 +80,10 @@ enum {
>  /* Init Power Management */
>  #define VIRTIO_PCI_FLAG_INIT_PM (1 << VIRTIO_PCI_FLAG_INIT_PM_BIT)
>  
> +/* Init The No_Soft_Reset bit of Power Management */
> +#define VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET \
> +  (1 << VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT)
> +
>  /* Init Function Level Reset capability */
>  #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
>  

Re: [PATCH v3 06/16] aspeed/smc: correct device description

[Cédric Le Goater]

On 4/16/24 11:18, Jamin Lin wrote:

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  hw/ssi/aspeed_smc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
index 6e1a84c197..8a8d77b480 100644
--- a/hw/ssi/aspeed_smc.c
+++ b/hw/ssi/aspeed_smc.c
@@ -1448,7 +1448,7 @@ static void aspeed_2500_fmc_class_init(ObjectClass 
*klass, void *data)
  DeviceClass *dc = DEVICE_CLASS(klass);
  AspeedSMCClass *asc = ASPEED_SMC_CLASS(klass);
  
-dc->desc   = "Aspeed 2600 FMC Controller";

+dc->desc   = "Aspeed 2500 FMC Controller";
  asc->r_conf= R_CONF;
  asc->r_ce_ctrl = R_CE_CTRL;
  asc->r_ctrl0   = R_CTRL0;
@@ -1486,7 +1486,7 @@ static void aspeed_2500_spi1_class_init(ObjectClass 
*klass, void *data)
  DeviceClass *dc = DEVICE_CLASS(klass);
  AspeedSMCClass *asc = ASPEED_SMC_CLASS(klass);
  
-dc->desc   = "Aspeed 2600 SPI1 Controller";

+dc->desc   = "Aspeed 2500 SPI1 Controller";
  asc->r_conf= R_CONF;
  asc->r_ce_ctrl = R_CE_CTRL;
  asc->r_ctrl0   = R_CTRL0;
@@ -1521,7 +1521,7 @@ static void aspeed_2500_spi2_class_init(ObjectClass 
*klass, void *data)
  DeviceClass *dc = DEVICE_CLASS(klass);
  AspeedSMCClass *asc = ASPEED_SMC_CLASS(klass);
  
-dc->desc   = "Aspeed 2600 SPI2 Controller";

+dc->desc   = "Aspeed 2500 SPI2 Controller";
  asc->r_conf= R_CONF;
  asc->r_ce_ctrl = R_CE_CTRL;
  asc->r_ctrl0   = R_CTRL0;

Re: [PATCH v3 05/16] aspeed/sdmc: Add AST2700 support

[Cédric Le Goater]

On 4/16/24 11:18, Jamin Lin wrote:

The SDRAM memory controller(DRAMC) controls the access to external
DDR4 and DDR5 SDRAM and power up to DDR4 and DDR5 PHY.

The DRAM memory controller of AST2700 is not backward compatible
to previous chips such AST2600, AST2500 and AST2400.

Max memory is now 8GiB on the AST2700. Introduce new
aspeed_2700_sdmc and class with read/write operation and
reset handlers.

Define DRAMC necessary protected registers and
unprotected registers for AST2700 and increase
the register set to 0x1000.

Add unlocked property to change controller protected status.

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  hw/misc/aspeed_sdmc.c | 190 +-
  include/hw/misc/aspeed_sdmc.h |   5 +-
  2 files changed, 193 insertions(+), 2 deletions(-)

diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c
index 873d67c592..69a34903db 100644
--- a/hw/misc/aspeed_sdmc.c
+++ b/hw/misc/aspeed_sdmc.c
@@ -27,6 +27,7 @@
  #define   PROT_SOFTLOCKED0x00
  
  #define   PROT_KEY_UNLOCK 0xFC600309

+#define   PROT_2700_KEY_UNLOCK  0x1688A8A8
  #define   PROT_KEY_HARDLOCK   0xDEADDEAD /* AST2600 */
  
  /* Configuration Register */

@@ -54,6 +55,46 @@
  #define R_DRAM_TIME   (0x8c / 4)
  #define R_ECC_ERR_INJECT  (0xb4 / 4)
  
+/* AST2700 Register */

+#define R_2700_PROT (0x00 / 4)
+#define R_INT_STATUS(0x04 / 4)
+#define R_INT_CLEAR (0x08 / 4)
+#define R_INT_MASK  (0x0c / 4)
+#define R_MAIN_CONF (0x10 / 4)
+#define R_MAIN_CONTROL  (0x14 / 4)
+#define R_MAIN_STATUS   (0x18 / 4)
+#define R_ERR_STATUS(0x1c / 4)
+#define R_ECC_FAIL_STATUS   (0x78 / 4)
+#define R_ECC_FAIL_ADDR (0x7c / 4)
+#define R_ECC_TESTING_CONTROL   (0x80 / 4)
+#define R_PROT_REGION_LOCK_STATUS   (0x94 / 4)
+#define R_TEST_FAIL_ADDR(0xd4 / 4)
+#define R_TEST_FAIL_D0  (0xd8 / 4)
+#define R_TEST_FAIL_D1  (0xdc / 4)
+#define R_TEST_FAIL_D2  (0xe0 / 4)
+#define R_TEST_FAIL_D3  (0xe4 / 4)
+#define R_DBG_STATUS(0xf4 / 4)
+#define R_PHY_INTERFACE_STATUS  (0xf8 / 4)
+#define R_GRAPHIC_MEM_BASE_ADDR (0x10c / 4)
+#define R_PORT0_INTERFACE_MONITOR0  (0x240 / 4)
+#define R_PORT0_INTERFACE_MONITOR1  (0x244 / 4)
+#define R_PORT0_INTERFACE_MONITOR2  (0x248 / 4)
+#define R_PORT1_INTERFACE_MONITOR0  (0x2c0 / 4)
+#define R_PORT1_INTERFACE_MONITOR1  (0x2c4 / 4)
+#define R_PORT1_INTERFACE_MONITOR2  (0x2c8 / 4)
+#define R_PORT2_INTERFACE_MONITOR0  (0x340 / 4)
+#define R_PORT2_INTERFACE_MONITOR1  (0x344 / 4)
+#define R_PORT2_INTERFACE_MONITOR2  (0x348 / 4)
+#define R_PORT3_INTERFACE_MONITOR0  (0x3c0 / 4)
+#define R_PORT3_INTERFACE_MONITOR1  (0x3c4 / 4)
+#define R_PORT3_INTERFACE_MONITOR2  (0x3c8 / 4)
+#define R_PORT4_INTERFACE_MONITOR0  (0x440 / 4)
+#define R_PORT4_INTERFACE_MONITOR1  (0x444 / 4)
+#define R_PORT4_INTERFACE_MONITOR2  (0x448 / 4)
+#define R_PORT5_INTERFACE_MONITOR0  (0x4c0 / 4)
+#define R_PORT5_INTERFACE_MONITOR1  (0x4c4 / 4)
+#define R_PORT5_INTERFACE_MONITOR2  (0x4c8 / 4)
+
  /*
   * Configuration register Ox4 (for Aspeed AST2400 SOC)
   *
@@ -101,6 +142,19 @@
   ASPEED_SDMC_AST2500_RESERVED | ASPEED_SDMC_VGA_COMPAT |\
   ASPEED_SDMC_VGA_APERTURE(ASPEED_SDMC_VGA_64MB))
  
+/*

+ * Main Configuration register Ox10 (for Aspeed AST2700 SOC and higher)
+ *
+ */
+#define ASPEED_SDMC_AST2700_RESERVED0x2082 /* 31:16, 13, 7, 1 */
+#define ASPEED_SDMC_AST2700_DATA_SCRAMBLE   (1 << 8)
+#define ASPEED_SDMC_AST2700_ECC_ENABLE  (1 << 6)
+#define ASPEED_SDMC_AST2700_PAGE_MATCHING_ENABLE(1 << 5)
+#define ASPEED_SDMC_AST2700_DRAM_SIZE(x)((x & 0x7) << 2)
+
+#define ASPEED_SDMC_AST2700_READONLY_MASK   \
+ (ASPEED_SDMC_AST2700_RESERVED)
+
  static uint64_t aspeed_sdmc_read(void *opaque, hwaddr addr, unsigned size)
  {
  AspeedSDMCState *s = ASPEED_SDMC(opaque);
@@ -216,7 +270,7 @@ static void aspeed_sdmc_realize(DeviceState *dev, Error 
**errp)
  AspeedSDMCState *s = ASPEED_SDMC(dev);
  AspeedSDMCClass *asc = ASPEED_SDMC_GET_CLASS(s);
  
-assert(asc->max_ram_size < 4 * GiB); /* 32-bit address bus */

+assert(asc->max_ram_size < 4 * GiB || asc->is_bus64bit);
  s->max_ram_size = asc->max_ram_size;
  
  memory_region_init_io(>iomem, OBJECT(s), _sdmc_ops, s,

@@ -236,6 +290,7 @@ static const VMStateDescription vmstate_aspeed_sdmc = {
  
  static Property aspeed_sdmc_properties[] = {

  DEFINE_PROP_UINT64("max-ram-size", AspeedSDMCState, max_ram_size, 0),
+DEFINE_PROP_BOOL("unlocked", AspeedSDMCState, unlocked, false),
  DEFINE_PROP_END_OF_LIST(),
  };
  
@@ -500,12 +555,145 @@ static const TypeInfo aspeed_2600_sdmc_info = {

  .class_init = aspeed_2600_sdmc_class_init,
  };
  
+static void aspeed_2700_sdmc_reset(DeviceState 

Re: [PATCH v3 27/27] target/i386/kvm: Improve KVM_EXIT_NOTIFY warnings

[Peter Maydell]

On Fri, 12 Apr 2024 at 08:37, Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 
> ---
>  target/i386/kvm/kvm.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index e68cbe9293..1fc809b2f9 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -5275,7 +5275,6 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run 
> *run)
>  uint64_t code;
>  int ret;
>  bool ctx_invalid;
> -char str[256];
>  KVMState *state;
>
>  switch (run->exit_reason) {
> @@ -5335,15 +5334,16 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run 
> *run)
>  case KVM_EXIT_NOTIFY:
>  ctx_invalid = !!(run->notify.flags & KVM_NOTIFY_CONTEXT_INVALID);
>  state = KVM_STATE(current_accel());
> -sprintf(str, "Encounter a notify exit with %svalid context in"
> - " guest. There can be possible misbehaves in guest."
> - " Please have a look.", ctx_invalid ? "in" : "");
>  if (ctx_invalid ||
>  state->notify_vmexit == NOTIFY_VMEXIT_OPTION_INTERNAL_ERROR) {
> -warn_report("KVM internal error: %s", str);
> +warn_report("KVM internal error: Encountered a notify exit "
> +"with invalid context in guest.");
>  ret = -1;
>  } else {
> -warn_report_once("KVM: %s", str);
> +warn_report_once("KVM: Encounterd a notify exit with valid "

"Encountered"

> + "context in guest. "
> + "The guest could be misbehaving. "
> + "Please have a look.");

"Please have a look" is a bit more chatty than we usually are
in warning messages...

thanks
-- PMM

Re: [PATCH v3 02/16] aspeed/sli: Add AST2700 support

[Cédric Le Goater]

Hello Jamin,

On 4/16/24 11:18, Jamin Lin wrote:

AST2700 SLI engine is designed to accelerate the
throughput between cross-die connections.
It have CPU_SLI at CPU die and IO_SLI at IO die.

Introduce dummy AST2700 SLI and SLIIO models.

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 
---
  hw/misc/aspeed_sli.c | 178 +++
  hw/misc/meson.build  |   3 +-
  hw/misc/trace-events |   7 ++
  include/hw/misc/aspeed_sli.h |  31 ++
  4 files changed, 218 insertions(+), 1 deletion(-)
  create mode 100644 hw/misc/aspeed_sli.c
  create mode 100644 include/hw/misc/aspeed_sli.h

diff --git a/hw/misc/aspeed_sli.c b/hw/misc/aspeed_sli.c
new file mode 100644
index 00..e84fd6a4ca
--- /dev/null
+++ b/hw/misc/aspeed_sli.c
@@ -0,0 +1,178 @@
+/*
+ * ASPEED SLI Controller
+ *
+ * Copyright (C) 2024 ASPEED Technology Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "hw/qdev-properties.h"
+#include "hw/misc/aspeed_sli.h"
+#include "qapi/error.h"
+#include "migration/vmstate.h"
+#include "trace.h"
+
+#define SLI_REGION_SIZE 0x500
+#define TO_REG(addr) ((addr) >> 2)
+
+static uint64_t aspeed_sli_read(void *opaque, hwaddr addr, unsigned int size)
+{
+AspeedSLIState *s = ASPEED_SLI(opaque);
+int reg = TO_REG(addr);
+
+if (reg >= ARRAY_SIZE(s->regs)) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Out-of-bounds read at offset 0x%" HWADDR_PRIx "\n",
+  __func__, addr);
+return 0;
+}
+
+trace_aspeed_sli_read(addr, size, s->regs[reg]);
+return s->regs[reg];
+}
+
+static void aspeed_sli_write(void *opaque, hwaddr addr, uint64_t data,
+  unsigned int size)
+{
+AspeedSLIState *s = ASPEED_SLI(opaque);
+int reg = TO_REG(addr);
+
+if (reg >= ARRAY_SIZE(s->regs)) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Out-of-bounds write at offset 0x%" HWADDR_PRIx "\n",
+  __func__, addr);
+return;
+}
+
+trace_aspeed_sli_write(addr, size, data);
+s->regs[reg] = data;
+}
+
+static uint64_t aspeed_sliio_read(void *opaque, hwaddr addr, unsigned int size)
+{
+AspeedSLIState *s = ASPEED_SLI(opaque);
+int reg = TO_REG(addr);
+
+if (reg >= ARRAY_SIZE(s->regs)) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Out-of-bounds read at offset 0x%" HWADDR_PRIx "\n",
+  __func__, addr);
+return 0;
+}
+
+trace_aspeed_sliio_read(addr, size, s->regs[reg]);
+return s->regs[reg];
+}
+
+static void aspeed_sliio_write(void *opaque, hwaddr addr, uint64_t data,
+  unsigned int size)
+{
+AspeedSLIState *s = ASPEED_SLI(opaque);
+int reg = TO_REG(addr);
+
+if (reg >= ARRAY_SIZE(s->regs)) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: Out-of-bounds write at offset 0x%" HWADDR_PRIx "\n",
+  __func__, addr);
+return;
+}
+
+trace_aspeed_sliio_write(addr, size, data);
+s->regs[reg] = data;
+}
+
+static const MemoryRegionOps aspeed_sli_ops = {
+.read = aspeed_sli_read,
+.write = aspeed_sli_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.valid = {
+.min_access_size = 1,
+.max_access_size = 4,
+},
+};
+
+static const MemoryRegionOps aspeed_sliio_ops = {
+.read = aspeed_sliio_read,
+.write = aspeed_sliio_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+.valid = {
+.min_access_size = 1,
+.max_access_size = 4,
+},
+};
+
+static void aspeed_sli_realize(DeviceState *dev, Error **errp)
+{
+AspeedSLIState *s = ASPEED_SLI(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+memory_region_init_io(>iomem, OBJECT(s), _sli_ops, s,
+  TYPE_ASPEED_SLI, SLI_REGION_SIZE);
+sysbus_init_mmio(sbd, >iomem);
+}
+
+static void aspeed_sliio_realize(DeviceState *dev, Error **errp)
+{
+AspeedSLIState *s = ASPEED_SLI(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+memory_region_init_io(>iomem, OBJECT(s), _sliio_ops, s,
+  TYPE_ASPEED_SLI, SLI_REGION_SIZE);
+sysbus_init_mmio(sbd, >iomem);
+}
+
+static void aspeed_sli_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->desc = "Aspeed SLI Controller";
+dc->realize = aspeed_sli_realize;
+}
+
+static const TypeInfo aspeed_sli_info = {
+.name  = TYPE_ASPEED_SLI,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(AspeedSLIState),
+.class_init= aspeed_sli_class_init,
+.class_size= sizeof(AspeedSLIClass),
+.abstract  = true,
+};
+
+static void aspeed_2700_sli_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->desc = "AST2700 SLI Controller";
+}
+

Re: [PATCH v3 04/16] aspeed/sdmc: fix coding style

[Cédric Le Goater]

On 4/16/24 11:18, Jamin Lin wrote:

Fix coding style issues from checkpatch.pl

Test command:
scripts/checkpatch.pl --no-tree -f hw/misc/aspeed_sdmc.c

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  hw/misc/aspeed_sdmc.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c
index 74279bbe8e..873d67c592 100644
--- a/hw/misc/aspeed_sdmc.c
+++ b/hw/misc/aspeed_sdmc.c
@@ -296,7 +296,8 @@ static void aspeed_2400_sdmc_write(AspeedSDMCState *s, 
uint32_t reg,
 uint32_t data)
  {
  if (reg == R_PROT) {
-s->regs[reg] = (data == PROT_KEY_UNLOCK) ? PROT_UNLOCKED : 
PROT_SOFTLOCKED;
+s->regs[reg] =
+(data == PROT_KEY_UNLOCK) ? PROT_UNLOCKED : PROT_SOFTLOCKED;
  return;
  }
  
@@ -354,7 +355,8 @@ static void aspeed_2500_sdmc_write(AspeedSDMCState *s, uint32_t reg,

 uint32_t data)
  {
  if (reg == R_PROT) {
-s->regs[reg] = (data == PROT_KEY_UNLOCK) ? PROT_UNLOCKED : 
PROT_SOFTLOCKED;
+s->regs[reg] =
+(data == PROT_KEY_UNLOCK) ? PROT_UNLOCKED : PROT_SOFTLOCKED;
  return;
  }
  
@@ -434,8 +436,9 @@ static void aspeed_2600_sdmc_write(AspeedSDMCState *s, uint32_t reg,

  }
  
  if (s->regs[R_PROT] == PROT_HARDLOCKED) {

-qemu_log_mask(LOG_GUEST_ERROR, "%s: SDMC is locked until system 
reset!\n",
-__func__);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: SDMC is locked until system reset!\n",
+  __func__);
  return;
  }
  

Re: [PATCH v3 03/16] aspeed/sdmc: remove redundant macros

[Cédric Le Goater]

On 4/16/24 11:18, Jamin Lin wrote:

These macros are no longer used for ASPEED SOCs, so removes them.

Signed-off-by: Troy Lee 
Signed-off-by: Jamin Lin 



Reviewed-by: Cédric Le Goater 

Thanks,

C.



---
  hw/misc/aspeed_sdmc.c | 15 ---
  1 file changed, 15 deletions(-)

diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c
index 64cd1a81dc..74279bbe8e 100644
--- a/hw/misc/aspeed_sdmc.c
+++ b/hw/misc/aspeed_sdmc.c
@@ -76,10 +76,6 @@
  #define ASPEED_SDMC_VGA_32MB0x2
  #define ASPEED_SDMC_VGA_64MB0x3
  #define ASPEED_SDMC_DRAM_SIZE(x)(x & 0x3)
-#define ASPEED_SDMC_DRAM_64MB   0x0
-#define ASPEED_SDMC_DRAM_128MB  0x1
-#define ASPEED_SDMC_DRAM_256MB  0x2
-#define ASPEED_SDMC_DRAM_512MB  0x3
  
  #define ASPEED_SDMC_READONLY_MASK   \

  (ASPEED_SDMC_RESERVED | ASPEED_SDMC_VGA_COMPAT |\
@@ -100,17 +96,6 @@
  #define ASPEED_SDMC_CACHE_ENABLE(1 << 10) /* differs from AST2400 */
  #define ASPEED_SDMC_DRAM_TYPE   (1 << 4)  /* differs from AST2400 */
  
-/* DRAM size definitions differs */

-#define ASPEED_SDMC_AST2500_128MB   0x0
-#define ASPEED_SDMC_AST2500_256MB   0x1
-#define ASPEED_SDMC_AST2500_512MB   0x2
-#define ASPEED_SDMC_AST2500_1024MB  0x3
-
-#define ASPEED_SDMC_AST2600_256MB   0x0
-#define ASPEED_SDMC_AST2600_512MB   0x1
-#define ASPEED_SDMC_AST2600_1024MB  0x2
-#define ASPEED_SDMC_AST2600_2048MB  0x3
-
  #define ASPEED_SDMC_AST2500_READONLY_MASK   \
  (ASPEED_SDMC_HW_VERSION(0xf) | ASPEED_SDMC_CACHE_INITIAL_DONE | \
   ASPEED_SDMC_AST2500_RESERVED | ASPEED_SDMC_VGA_COMPAT |\

Re: [PATCH v3 27/27] target/i386/kvm: Improve KVM_EXIT_NOTIFY warnings

[Zhao Liu]

On Fri, Apr 12, 2024 at 12:33:46AM -0700, Richard Henderson wrote:
> Date: Fri, 12 Apr 2024 00:33:46 -0700
> From: Richard Henderson 
> Subject: [PATCH v3 27/27] target/i386/kvm: Improve KVM_EXIT_NOTIFY warnings
> X-Mailer: git-send-email 2.34.1
> 
> Signed-off-by: Richard Henderson 
> ---
>  target/i386/kvm/kvm.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Reviewed-by: Zhao Liu 

Re: [PATCH v9] arm/kvm: Enable support for KVM_ARM_VCPU_PMU_V3_FILTER

[Cornelia Huck]

On Wed, Apr 10 2024, Thomas Huth  wrote:

> On 09/04/2024 09.47, Shaoqin Huang wrote:
>> Hi Thmoas,
>> 
>> On 4/9/24 13:33, Thomas Huth wrote:
 +    assert_has_feature(qts, "host", "kvm-pmu-filter");
>>>
>>> So you assert here that the feature is available ...
>>>
   assert_has_feature(qts, "host", "kvm-steal-time");
   assert_has_feature(qts, "host", "sve");
   resp = do_query_no_props(qts, "host");
 +    kvm_supports_pmu_filter = resp_get_feature_str(resp, 
 "kvm-pmu-filter");
   kvm_supports_steal_time = resp_get_feature(resp, 
 "kvm-steal-time");
   kvm_supports_sve = resp_get_feature(resp, "sve");
   vls = resp_get_sve_vls(resp);
   qobject_unref(resp);
 +    if (kvm_supports_pmu_filter) { >
>>> ... why do you then need to check for its availability here again?
>>> I either don't understand this part of the code, or you could drop the 
>>> kvm_supports_pmu_filter variable and simply always execute the code below.
>> 
>> Thanks for your reviewing. I did so because all other feature like 
>> "kvm-steal-time" check its availability again. I don't know the original 
>> reason why they did that. I just followed it.
>> 
>> Do you think we should delete all the checking?
>
> resp_get_feature() seems to return a boolean value, so though these feature 
> could be there, they still could be disabled, I assume? Thus we likely need 
> to keep the check for those.

This had confused me as well when I looked at it the last time -- one
thing is to check whether we have a certain prop in the cpu model, the
other one whether we actually support it. Maybe this needs some
comments?

Re: [PATCH v3 20/22] hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine

[Zhao Liu]

On Tue, Apr 16, 2024 at 03:52:49PM +0200, Philippe Mathieu-Daudé wrote:
> Date: Tue, 16 Apr 2024 15:52:49 +0200
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH v3 20/22] hw/i386/pc: Remove deprecated pc-i440fx-2.3
>  machine
> X-Mailer: git-send-email 2.41.0
> 
> The pc-i440fx-2.3 machine was deprecated for the 8.2
> release (see commit c7437f0ddb "docs/about: Mark the
> old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
> time to remove it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  docs/about/deprecated.rst   |  4 ++--
>  docs/about/removed-features.rst |  2 +-
>  hw/i386/pc.c| 25 -
>  hw/i386/pc_piix.c   | 19 ---
>  4 files changed, 3 insertions(+), 47 deletions(-)

Reviewed-by: Zhao Liu 

Re: [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

[Jonathan Cameron via]

On Fri,  1 Mar 2024 10:41:09 -1000
Richard Henderson  wrote:

> If translation is disabled, the default memory type is Device, which
> requires alignment checking.  This is more optimally done early via
> the MemOp given to the TCG memory operation.
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reported-by: Idan Horowitz 
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204
> Signed-off-by: Richard Henderson 

Hi Richard.

I noticed some tests I was running stopped booting with master.
(it's a fun and complex stack of QEMU + kvm on QEMU for vCPU Hotplug kernel 
work,
but this is the host booting)

EDK2 build from upstream as of somepoint last week.

Bisects to this patch.

 qemu-system-aarch64 -M virt,gic-version=3,virtualization=true -m 
4g,maxmem=8G,slots=8 -cpu cortex-a76 -smp cpus=4,threads=2,clusters=2,sockets=1 
\
 -kernel Image \
 -drive if=none,file=full.qcow2,format=qcow2,id=hd \
 -device ioh3420,id=root_port1 -device virtio-blk-pci,drive=hd \
 -netdev user,id=mynet,hostfwd=tcp::-:22 -device 
virtio-net-pci,netdev=mynet,id=bob \
 -nographic -no-reboot -append 'earlycon root=/dev/vda2 fsck.mode=skip 
tp_printk' \
 -monitor telnet:127.0.0.1:1235,server,nowait -bios QEMU_EFI.fd \
 -object memory-backend-ram,size=4G,id=mem0 \
 -numa node,nodeid=0,cpus=0-3,memdev=mem0

Symptoms: Nothing on console from edk2 which is built in debug mode so is 
normally very noisy.
  No sign of anything much happening at all :(

Jonathan



> ---
>  target/arm/tcg/hflags.c | 34 --
>  1 file changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/target/arm/tcg/hflags.c b/target/arm/tcg/hflags.c
> index 8e5d35d922..5da1b0fc1d 100644
> --- a/target/arm/tcg/hflags.c
> +++ b/target/arm/tcg/hflags.c
> @@ -26,6 +26,35 @@ static inline bool fgt_svc(CPUARMState *env, int el)
>  FIELD_EX64(env->cp15.fgt_exec[FGTREG_HFGITR], HFGITR_EL2, SVC_EL1);
>  }
>  
> +/* Return true if memory alignment should be enforced. */
> +static bool aprofile_require_alignment(CPUARMState *env, int el, uint64_t 
> sctlr)
> +{
> +#ifdef CONFIG_USER_ONLY
> +return false;
> +#else
> +/* Check the alignment enable bit. */
> +if (sctlr & SCTLR_A) {
> +return true;
> +}
> +
> +/*
> + * If translation is disabled, then the default memory type is
> + * Device(-nGnRnE) instead of Normal, which requires that alignment
> + * be enforced.  Since this affects all ram, it is most efficient
> + * to handle this during translation.
> + */
> +if (sctlr & SCTLR_M) {
> +/* Translation enabled: memory type in PTE via MAIR_ELx. */
> +return false;
> +}
> +if (el < 2 && (arm_hcr_el2_eff(env) & (HCR_DC | HCR_VM))) {
> +/* Stage 2 translation enabled: memory type in PTE. */
> +return false;
> +}
> +return true;
> +#endif
> +}
> +
>  static CPUARMTBFlags rebuild_hflags_common(CPUARMState *env, int fp_el,
> ARMMMUIdx mmu_idx,
> CPUARMTBFlags flags)
> @@ -121,8 +150,9 @@ static CPUARMTBFlags rebuild_hflags_a32(CPUARMState *env, 
> int fp_el,
>  {
>  CPUARMTBFlags flags = {};
>  int el = arm_current_el(env);
> +uint64_t sctlr = arm_sctlr(env, el);
>  
> -if (arm_sctlr(env, el) & SCTLR_A) {
> +if (aprofile_require_alignment(env, el, sctlr)) {
>  DP_TBFLAG_ANY(flags, ALIGN_MEM, 1);
>  }
>  
> @@ -223,7 +253,7 @@ static CPUARMTBFlags rebuild_hflags_a64(CPUARMState *env, 
> int el, int fp_el,
>  
>  sctlr = regime_sctlr(env, stage1);
>  
> -if (sctlr & SCTLR_A) {
> +if (aprofile_require_alignment(env, el, sctlr)) {
>  DP_TBFLAG_ANY(flags, ALIGN_MEM, 1);
>  }
>