[Bug 1502613] Re: [Feature Request] Battery Status / Virtual Battery
I just wanted to add that this would (probably) help solve the error 43 on mobile Nvidia GPU passthrough scenarios. While facing this myself I was able to get it working by simulating a battery and attaching it via an ACPI table. Your work is greatly appreciated Sergey. Thank you very much! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1502613 Title: [Feature Request] Battery Status / Virtual Battery Status in QEMU: In Progress Bug description: When using virtualization on notebooks heavily then virtual machines do not realize that they're running on a notebook device causing high power consumption because they're not switching into a optimized "laptop mode". This leads to the circumstance that they are trying to do things like defragmentation / virtus scan / etc. while the host is still running on batteries. So it would be great if QEMU / KVM would have support for emulating "Virtual Batteries" to guests causing them to enable power-saving options like disabling specific services / devices / file operations automatically by OS. Optionally a great feature would be to set virtual battery's status manually. For example: Current charge rate / charging / discharging / ... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1502613/+subscriptions
Re: [PATCH 11/11] dockerfiles/debian-win64-cross: Download WHPX MinGW headers
On 04/08/2020 20.32, Stefan Weil wrote: > Am 04.08.20 um 19:00 schrieb Thomas Huth: > >> To compile-test the WHPX accelerator, we need to download these system >> headers first (they are unfortunately not part of any released and >> packaged MinGW toolchain yet). >> >> Idea taken from another patch by Stefan Weil. >> >> Signed-off-by: Thomas Huth >> --- >> tests/docker/dockerfiles/debian-win64-cross.docker | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/tests/docker/dockerfiles/debian-win64-cross.docker >> b/tests/docker/dockerfiles/debian-win64-cross.docker >> index 2fc9cfcbc6..4cc4a3f365 100644 >> --- a/tests/docker/dockerfiles/debian-win64-cross.docker >> +++ b/tests/docker/dockerfiles/debian-win64-cross.docker >> @@ -32,7 +32,14 @@ RUN apt-get update && \ >> mxe-$TARGET-w64-mingw32.shared-sdl2 \ >> mxe-$TARGET-w64-mingw32.shared-sdl2-mixer \ >> mxe-$TARGET-w64-mingw32.shared-sdl2-gfx \ >> -mxe-$TARGET-w64-mingw32.shared-zlib >> +mxe-$TARGET-w64-mingw32.shared-zlib \ >> +curl && \ >> +curl -s -S -o >> /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvEmulation.h \ >> + >> "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvemulation.h?format=raw"; >> && \ >> +curl -s -S -o >> /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvPlatform.h \ >> + >> "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatform.h?format=raw"; >> && \ >> +curl -s -S -o >> /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/winhvplatformdefs.h \ >> + >> "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatformdefs.h?format=raw"; >> >> # Specify the cross prefix for this image (see tests/docker/common.rc) >> ENV QEMU_CONFIGURE_OPTS --cross-prefix=x86_64-w64-mingw32.shared- > > > I expect a build failure: Mingw-w64 decided to use lower case filenames, > and those header files include each other. The first two headers include the third header, that's why I've used lowercase for the third header (which is apparently not included by QEMU directly). But yes, all that CamelCase vs. lower-case stuff is very annoying. I think once there is a new MinGW release available in the major Linux distros that ships with these headers, we should change the QEMU source code to always use the lowercase headers, too. Thomas
Re: [PATCH-for-5.0 1/2] hw/acpi/piix4: Add 'system-hotplug-support' property
On 8/5/20 7:56 AM, Philippe Mathieu-Daudé wrote:
> On 3/19/20 11:02 AM, Paolo Bonzini wrote:
>> On 19/03/20 10:42, Philippe Mathieu-Daudé wrote:
>>> On 3/19/20 10:36 AM, Paolo Bonzini wrote:
On 18/03/20 23:15, Philippe Mathieu-Daudé wrote:
> The I/O ranges registered by the piix4_acpi_system_hot_add_init()
> function are not documented in the PIIX4 datasheet.
> This appears to be a PC-only feature added in commit 5e3cb5347e
> ("initialize hot add system / acpi gpe") which was then moved
> to the PIIX4 device model in commit 9d5e77a22f ("make
> qemu_system_device_hot_add piix independent")
> Add a property (default enabled, to not modify the current
> behavior) to allow machines wanting to model a simple PIIX4
> to disable this feature.
Yes, all hotplug stuff (PCI/memory/CPU) are custom additions by QEMU.
> + DEFINE_PROP_BOOL("system-hotplug-support", PIIX4PMState,
> + use_acpi_system_hotplug, true),
Why not cpu-hotplug-support?
>>>
>>> Because I have no idea what this code is about, and it seems more than
>>> cpu (pci, memory):
>>
>> Right, I should have been more verbose. You mentioned I/O port 0xaf00
>> which is CPU hotplug. Perhaps unless you can also crash with PCI
>> hotplug (0xae00-0xae0f) it's worth removing only CPU hotplug from MIPS
>> machines, and keep PCI hotplug.
>
> I am sorry I don't understand what PCI hotplug has to do with PIIX which
> is a PCI-slave southbridge... If MIPS or other arch is interested in PCI
> hotplug feature, that would be managed by the northbridge or another PCI
> bridge.
Ah, writing that comment made me realize the problem might be these
'virtualization' features have been implemented in the wrong place.
Maybe the less disruptive path is to move them to the i440fx
northbridge. That way we shouldn't need to maintain a piix_hw.c and
piix_virt_twisted.c (child of piix_hw overloaded with hotplug features).
I haven't looked at the history yet, maybe the problem happened when
i440fx/piix was split.
>
>>
>> Paolo
>>
>>> static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
>>> PCIBus *bus, PIIX4PMState *s)
>>> {
>>> memory_region_init_io(&s->io_gpe, OBJECT(s), &piix4_gpe_ops, s,
>>> "acpi-gpe0", GPE_LEN);
>>> memory_region_add_subregion(parent, GPE_BASE, &s->io_gpe);
>>>
>>> acpi_pcihp_init(OBJECT(s), &s->acpi_pci_hotplug, bus, parent,
>>> s->use_acpi_pci_hotplug);
>>>
>>> s->cpu_hotplug_legacy = true;
>>> object_property_add_bool(OBJECT(s), "cpu-hotplug-legacy",
>>> piix4_get_cpu_hotplug_legacy,
>>> piix4_set_cpu_hotplug_legacy,
>>> NULL);
>>> legacy_acpi_cpu_hotplug_init(parent, OBJECT(s), &s->gpe_cpu,
>>> PIIX4_CPU_HOTPLUG_IO_BASE);
>>>
>>> if (s->acpi_memory_hotplug.is_enabled) {
>>> acpi_memory_hotplug_init(parent, OBJECT(s),
>>> &s->acpi_memory_hotplug,
>>> ACPI_MEMORY_HOTPLUG_BASE);
>>> }
>>> }
>>>
>>
>
Re: [PATCH-for-5.0 1/2] hw/acpi/piix4: Add 'system-hotplug-support' property
On 3/19/20 11:02 AM, Paolo Bonzini wrote:
> On 19/03/20 10:42, Philippe Mathieu-Daudé wrote:
>> On 3/19/20 10:36 AM, Paolo Bonzini wrote:
>>> On 18/03/20 23:15, Philippe Mathieu-Daudé wrote:
The I/O ranges registered by the piix4_acpi_system_hot_add_init()
function are not documented in the PIIX4 datasheet.
This appears to be a PC-only feature added in commit 5e3cb5347e
("initialize hot add system / acpi gpe") which was then moved
to the PIIX4 device model in commit 9d5e77a22f ("make
qemu_system_device_hot_add piix independent")
Add a property (default enabled, to not modify the current
behavior) to allow machines wanting to model a simple PIIX4
to disable this feature.
>>>
>>> Yes, all hotplug stuff (PCI/memory/CPU) are custom additions by QEMU.
>>>
+ DEFINE_PROP_BOOL("system-hotplug-support", PIIX4PMState,
+ use_acpi_system_hotplug, true),
>>>
>>> Why not cpu-hotplug-support?
>>
>> Because I have no idea what this code is about, and it seems more than
>> cpu (pci, memory):
>
> Right, I should have been more verbose. You mentioned I/O port 0xaf00
> which is CPU hotplug. Perhaps unless you can also crash with PCI
> hotplug (0xae00-0xae0f) it's worth removing only CPU hotplug from MIPS
> machines, and keep PCI hotplug.
I am sorry I don't understand what PCI hotplug has to do with PIIX which
is a PCI-slave southbridge... If MIPS or other arch is interested in PCI
hotplug feature, that would be managed by the northbridge or another PCI
bridge.
>
> Paolo
>
>> static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
>> PCIBus *bus, PIIX4PMState *s)
>> {
>> memory_region_init_io(&s->io_gpe, OBJECT(s), &piix4_gpe_ops, s,
>> "acpi-gpe0", GPE_LEN);
>> memory_region_add_subregion(parent, GPE_BASE, &s->io_gpe);
>>
>> acpi_pcihp_init(OBJECT(s), &s->acpi_pci_hotplug, bus, parent,
>> s->use_acpi_pci_hotplug);
>>
>> s->cpu_hotplug_legacy = true;
>> object_property_add_bool(OBJECT(s), "cpu-hotplug-legacy",
>> piix4_get_cpu_hotplug_legacy,
>> piix4_set_cpu_hotplug_legacy,
>> NULL);
>> legacy_acpi_cpu_hotplug_init(parent, OBJECT(s), &s->gpe_cpu,
>> PIIX4_CPU_HOTPLUG_IO_BASE);
>>
>> if (s->acpi_memory_hotplug.is_enabled) {
>> acpi_memory_hotplug_init(parent, OBJECT(s),
>> &s->acpi_memory_hotplug,
>> ACPI_MEMORY_HOTPLUG_BASE);
>> }
>> }
>>
>
Re: [PATCH] docs: Update POWER9 XIVE support for nested guests
On Tue, Aug 04, 2020 at 03:16:39PM +0200, Cédric Le Goater wrote: > It is not yet supported. > > Signed-off-by: Cédric Le Goater Applied to ppc-for-5.2. > --- > docs/specs/ppc-spapr-xive.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/docs/specs/ppc-spapr-xive.rst b/docs/specs/ppc-spapr-xive.rst > index 6159bc6eed62..7199db730b82 100644 > --- a/docs/specs/ppc-spapr-xive.rst > +++ b/docs/specs/ppc-spapr-xive.rst > @@ -61,6 +61,11 @@ depend on the XIVE KVM capability of the host. On older > kernels > without XIVE KVM support, QEMU will use the emulated XIVE device as a > fallback and on newer kernels (>=5.2), the KVM XIVE device. > > +XIVE native exploitation mode is not supported for KVM nested guests, > +VMs running under a L1 hypervisor (KVM on pSeries). In that case, the > +hypervisor will not advertise the KVM capability and QEMU will use the > +emulated XIVE device, same as for older versions of KVM. > + > As a final refinement, the user can also switch the use of the KVM > device with the machine option ``kernel_irqchip``. > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [RFC v2 1/1] memory: Delete assertion in memory_region_unregister_iommu_notifier
On 2020/8/5 上午4:30, Peter Xu wrote:
On Mon, Aug 03, 2020 at 06:00:34PM +0200, Eugenio Pérez wrote:
On Fri, 2020-07-03 at 15:24 +0800, Jason Wang wrote:
On 2020/7/2 下午11:45, Peter Xu wrote:
On Thu, Jul 02, 2020 at 11:01:54AM +0800, Jason Wang wrote:
So I think we agree that a new notifier is needed?
Good to me, or a new flag should be easier (IOMMU_NOTIFIER_DEV_IOTLB)?
That should work but I wonder something as following is better.
Instead of introducing new flags, how about carry the type of event in
the notifier then the device (vhost) can choose the message it want to
process like:
static vhost_iommu_event(IOMMUNotifier *n, IOMMUTLBEvent *event)
{
switch (event->type) {
case IOMMU_MAP:
case IOMMU_UNMAP:
case IOMMU_DEV_IOTLB_UNMAP:
...
}
Thanks
Hi!
Sorry, I thought I had this clear but now it seems not so clear to me. Do you
mean to add that switch to the current
vhost_iommu_unmap_notify, and then the "type" field to the IOMMUTLBEntry? Is
that the scope of the changes, or there is
something I'm missing?
If that is correct, what is the advantage for vhost or other notifiers? I
understand that move the IOMMUTLBEntry (addr,
len) -> (iova, mask) split/transformation to the different notifiers
implementation could pollute them, but this is even a deeper change and vhost is
not insterested in other events but IOMMU_UNMAP, isn't?
On the other hand, who decide what type of event is? If I follow the backtrace
of the assert in
https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01015.html, it seems
to me that it should be
vtd_process_device_iotlb_desc. How do I know if it should be IOMMU_UNMAP or
IOMMU_DEV_IOTLB_UNMAP? If I set it in some
function of memory.c, I should decide the type looking the actual notifier,
isn't?
(Since Jason didn't reply yesterday, I'll try to; Jason, feel free to correct
me...)
IMHO whether to put the type into the IOMMUTLBEntry is not important. The
important change should be that we introduce IOMMU_DEV_IOTLB_UNMAP (or I'd
rather call it IOMMU_DEV_IOTLB directly which is shorter and cleaner). With
that information we can make the failing assertion conditional for MAP/UNMAP
only.
Or having another dedicated device IOTLB notifier.
We can also allow dev-iotlb messages to take arbitrary addr_mask (so it
becomes a length of address range; imho we can keep using addr_mask for
simplicity, but we can comment for addr_mask that for dev-iotlb it can be not a
real mask).
Yes.
Thanks
Thanks,
[Bug 1890290] Re: PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual, kernel-irqchip=on - `KVM is too old to support ic-mode=dual, kernel-irqchip=on`
this section of table in particular,
https://www.qemu.org/docs/master/specs/ppc-spapr-xive.html#no-xive-
support-in-kvm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890290
Title:
PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual
,kernel-irqchip=on - `KVM is too old to support ic-mode=dual,kernel-
irqchip=on`
Status in QEMU:
New
Bug description:
Env:
HW: Power 9 DD2.3
Host L0: 5.8.0-rc5-g8ba4ffcd8
Qemu: 5.0.50 (v5.0.0-533-gdebe78ce14)
Libvirt: 6.4.0
L1: 5.8.0-rc5-ge9919e11e
qemu_version': '5.0.50 (v5.1.0-rc2-dirty)
libvirt_version': '6.4.0'
L2: 5.8.0-rc7-g6ba1b005f
1. boot a L2 KVM guest with `ic-mode=dual,kernel-irqchip=on`
/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name
'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=2,t
hreads=4 --import --nographics --serial pty --memballoon model=virtio --disk
path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=virtio,size=10,format=qcow2
--network
=bridge=virbr0,model=virtio,mac=52:54:00:e6:fe:f6 --mac=52:54:00:e6:fe:f6
--boot
emulator=/usr/share/avocado-plugins-vt/bin/qemu,kernel=/tmp/linux/vmlinux,kernel_args="root=/de
v/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug
selinux=0" --noautoconsole --qemu-commandline=" -M
pseries,ic-mode=dual,kernel-irqchip=on"
ERRORinternal error: process exited while connecting to monitor:
2020-08-04T11:12:53.304482Z qemu: KVM is too old to support
ic-mode=dual,kernel-irqchip=on
Qemu Log:
```
/usr/share/avocado-plugins-vt/bin/qemu \
-name guest=vm1,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-vm1/master-key.aes
\
-machine pseries-5.1,accel=kvm,usb=off,dump-guest-core=off \
-cpu POWER9 \
-m 8192 \
-overcommit mem-lock=off \
-smp 8,sockets=1,dies=1,cores=2,threads=4 \
-uuid 20a3351b-2776-4e75-9059-c070fe3dd44b \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=34,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-kernel /tmp/linux/vmlinux \
-append 'root=/dev/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init
initcall_debug selinux=0' \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
-blockdev
'{"driver":"file","filename":"/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
\
-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1
\
-netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:fe:f6,bus=pci.0,addr=0x1
\
-chardev pty,id=charserial0 \
-device spapr-vty,chardev=charserial0,id=serial0,reg=0x3000 \
-chardev socket,id=charchannel0,fd=39,server,nowait \
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
\
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-M pseries,ic-mode=dual,kernel-irqchip=on \
-msg timestamp=on
2020-08-04 11:12:53.169+: Domain id=5 is tainted: custom-argv
2020-08-04 11:12:53.179+: 11120: info : libvirt version: 6.4.0, package:
1.fc31 (Unknown, 2020-06-02-05:09:40, ltc-wspoon4.aus.stglabs.ibm.com)
2020-08-04 11:12:53.179+: 11120: info : hostname: atest-guest
2020-08-04 11:12:53.179+: 11120: info : virObjectUnref:347 :
OBJECT_UNREF: obj=0x7fff0c117c40
char device redirected to /dev/pts/0 (label charserial0)
2020-08-04T11:12:53.304482Z qemu: KVM is too old to support
ic-mode=dual,kernel-irqchip=on
2020-08-04 11:12:53.694+: shutting down, reason=failed
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890290/+subscriptions
[Bug 1890290] Re: PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual, kernel-irqchip=on - `KVM is too old to support ic-mode=dual, kernel-irqchip=on`
As per this the table https://www.qemu.org/docs/master/specs/ppc-spapr-
xive.html#kvm-negotiation
reported qemu error msg "KVM is too old to support
ic-mode=dual,kernel-irqchip=on" indicates the
guest os is legacy, but that's not the case here, whereas kernel levels are
near upstream which has support for xive.
My understanding of the env I used as below
Level | XIVE KVM support | XIVE support(in kernel or emulation)
--
L0 | Yes | Yes
L1 | No | Yes(booted with irqchip: in-kernel)
L2 | No | Yes
So, ideally when a L2 guest is started with ic-mode=dual,kernel-irqchip=on, we
should have seen below error
(2) QEMU fails with ``kernel_irqchip requested but unavailable:
IRQ_XIVE capability must be present for KVM``
but we actually saw the reported one, which is misleading.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890290
Title:
PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual
,kernel-irqchip=on - `KVM is too old to support ic-mode=dual,kernel-
irqchip=on`
Status in QEMU:
New
Bug description:
Env:
HW: Power 9 DD2.3
Host L0: 5.8.0-rc5-g8ba4ffcd8
Qemu: 5.0.50 (v5.0.0-533-gdebe78ce14)
Libvirt: 6.4.0
L1: 5.8.0-rc5-ge9919e11e
qemu_version': '5.0.50 (v5.1.0-rc2-dirty)
libvirt_version': '6.4.0'
L2: 5.8.0-rc7-g6ba1b005f
1. boot a L2 KVM guest with `ic-mode=dual,kernel-irqchip=on`
/usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name
'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=2,t
hreads=4 --import --nographics --serial pty --memballoon model=virtio --disk
path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=virtio,size=10,format=qcow2
--network
=bridge=virbr0,model=virtio,mac=52:54:00:e6:fe:f6 --mac=52:54:00:e6:fe:f6
--boot
emulator=/usr/share/avocado-plugins-vt/bin/qemu,kernel=/tmp/linux/vmlinux,kernel_args="root=/de
v/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug
selinux=0" --noautoconsole --qemu-commandline=" -M
pseries,ic-mode=dual,kernel-irqchip=on"
ERRORinternal error: process exited while connecting to monitor:
2020-08-04T11:12:53.304482Z qemu: KVM is too old to support
ic-mode=dual,kernel-irqchip=on
Qemu Log:
```
/usr/share/avocado-plugins-vt/bin/qemu \
-name guest=vm1,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-vm1/master-key.aes
\
-machine pseries-5.1,accel=kvm,usb=off,dump-guest-core=off \
-cpu POWER9 \
-m 8192 \
-overcommit mem-lock=off \
-smp 8,sockets=1,dies=1,cores=2,threads=4 \
-uuid 20a3351b-2776-4e75-9059-c070fe3dd44b \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=34,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-kernel /tmp/linux/vmlinux \
-append 'root=/dev/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init
initcall_debug selinux=0' \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
-blockdev
'{"driver":"file","filename":"/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
\
-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1
\
-netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:fe:f6,bus=pci.0,addr=0x1
\
-chardev pty,id=charserial0 \
-device spapr-vty,chardev=charserial0,id=serial0,reg=0x3000 \
-chardev socket,id=charchannel0,fd=39,server,nowait \
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
\
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-M pseries,ic-mode=dual,kernel-irqchip=on \
-msg timestamp=on
2020-08-04 11:12:53.169+: Domain id=5 is tainted: custom-argv
2020-08-04 11:12:53.179+: 11120: info : libvirt version: 6.4.0, package:
1.fc31 (Unknown, 2020-06-02-05:09:40, ltc-wspoon4.aus.stglabs.ibm.com)
2020-08-04 11:12:53.179+: 11120: info : hostname: atest-guest
2020-08-04 11:12:53.179+: 11120: info : virObjectUnref:347 :
OBJECT_UNREF: obj=0x7fff0c117c40
char device redirected to /dev/pts/0 (label charserial0)
2020-08-04T11:12:53.304482Z qemu: KVM is too old to support
ic-mode=dual,kernel-irqchip=on
2020-08-04 11:12:53.694+: shutting down, reason=failed
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890290/+subscriptions
Re: [PATCH v6 02/12] monitor: Use getter/setter functions for cur_mon
Markus Armbruster writes:
> Kevin Wolf writes:
>
>> cur_mon really needs to be coroutine-local as soon as we move monitor
>> command handlers to coroutines and let them yield. As a first step, just
>> remove all direct accesses to cur_mon so that we can implement this in
>> the getter function later.
>>
>> Signed-off-by: Kevin Wolf
[...]
>> diff --git a/tests/test-util-sockets.c b/tests/test-util-sockets.c
>> index 2ca1e99f17..36fabb5e46 100644
>> --- a/tests/test-util-sockets.c
>> +++ b/tests/test-util-sockets.c
>> @@ -53,27 +53,27 @@ static void test_fd_is_socket_good(void)
>> static int mon_fd = -1;
>> static const char *mon_fdname;
>>
>> -int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
>> -{
>> -g_assert(cur_mon);
>> -g_assert(mon == cur_mon);
>> -if (mon_fd == -1 || !g_str_equal(mon_fdname, fdname)) {
>> -error_setg(errp, "No fd named %s", fdname);
>> -return -1;
>> -}
>> -return dup(mon_fd);
>> -}
>> -
>> /* Syms in libqemustub.a are discarded at .o file granularity.
>> * To replace monitor_get_fd() we must ensure everything in
>> * stubs/monitor.c is defined, to make sure monitor.o is discarded
>> * otherwise we get duplicate syms at link time.
>> */
>> __thread Monitor *cur_mon;
>
> Hmm. Since monitor.o's @cur_mon now has internal linkage, the comment
> doesn't apply to @cur_mon anymore. Easy to fix: move the variable
> before the comment. Bonus: you don't have to move monitor_get_fd()
> then.
>
> Hmm^2, the comment is stale:
>
> * "libqemustub.a"
>
> Gone since Commit ebedb37c8d "Makefile: Remove libqemustub.a". Almost
> three years. git-grep finds three more occurences, all bogus.
Thomas posted a patch:
Subject: [PATCH 07/11] Get rid of the libqemustub.a remainders
Message-Id: <20200804170055.2851-8-th...@redhat.com>
>
> * "stubs/monitor.c"
>
> Commit 6ede81d576 "stubs: Update monitor stubs for
> qemu-storage-daemon" moved stuff from stubs/monitor.c to
> monitor-core.c.
>
> * "we must ensure everything in stubs/monitor.c is defined"
>
> We don't.
These two remain.
> Mind to clean that up beforehand?
[...]
Re: [PATCH] trace/simple: Allow enabling simple traces from command line
Josh DuBois writes: > On Aug 3, 2020, at 4:08 AM, Markus Armbruster wrote: >> >>> >>> - prior to db25d56c014aa1a96319c663e0a60346a223b31e, just like today, >>> QEMU built with simple tracing will always produce a trace- file, >>> regardless of whether the user asks for traces at runtime. >> >> When you send a patch with a Fixes: tag, consider cc'ing people involved >> in the commit being fixed. I might have spotted the regression. > > Sure, this makes sense. > >> I missed the CLI issue. I just wanted my directories not littered with >> trace files ;) >> >> Stefan, what shall we do for 5.1? >> >> If we keep littering, the annoyance will make me drop the trace backend >> "simple" from my build tests. I might even remember to put it back when >> the fix arrives. > > I haven't seen another response, but I just noticed a 'last call' for 5.1. > If this means something is going to get excluded from regular build tests, > that seems important - I for one have no objection to simply reverting this - > 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4 <-- my "fix." These are just my local build test. Our CI is not affected. Reverting is up to Stefan. > I will try to send a better fix along sometime soonish, but I probably won't > get to that before 5.1. If the nuisance of the trace- files is causing > real-world problems for someone actually doing regular development, that > seems more important than the command line issue, to me. Just my $0.02. > > Cheers, and sorry if your build dirs do end up littered again. Sorry for breaking your use case, and looking forward to your fix for your fix!
[Bug 1890370] Re: Segfault in artist vram_bit_write
** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890370 Title: Segfault in artist vram_bit_write Status in QEMU: Invalid Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf810049f 0x writew 0xf8118001 0xff7c writew 0xf8118000 0x8300 writeq 0xf81005fb 0x5c18006400189e EOF SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /hw/display/artist.c:402:17 in AddressSanitizer:DEADLYSIGNAL = ==23157==ERROR: AddressSanitizer: SEGV on unknown address 0x7f17563f (pc 0x560ce3ad742c bp 0x7ffe310c62e0 sp 0x7ffe310c5a60 T0) ==23157==The signal is caused by a WRITE memory access. #0 0x560ce3ad742c in vram_bit_write /hw/display/artist.c:402:43 #1 0x560ce3acf2ab in artist_reg_write /hw/display/artist.c:892:9 #2 0x560ce31c37a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x560ce31c2adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x560ce31c0873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x560ce286e056 in flatview_write_continue /exec.c:3176:23 #6 0x560ce2856866 in flatview_write /exec.c:3216:14 #7 0x560ce2856387 in address_space_write /exec.c:3308:18 #8 0x560ce326a604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x560ce3261c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x560ce3260895 in qtest_read /softmmu/qtest.c:722:5 #11 0x560ce571d343 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x560ce571d4c7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x560ce57317b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x560ce5885b74 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f1665259897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x560ce5c7da7b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x560ce5c7b1ab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x560ce5c7ab44 in main_loop_wait /util/main-loop.c:516:11 #19 0x560ce3282d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x560ce58bd961 in main /softmmu/main.c:49:5 #21 0x7f1663ddfe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x560ce2761729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) With -trace artist\* [I 1596601002.853158] OPENED [R +0.047035] writeq 0xf810049f 0x 24590@1596601002.900238:artist_reg_write 1 0x10049f <- 0xff 24590@1596601002.900258:artist_reg_write 4 0x1004a0 VRAM_IDX <- 0x 24590@1596601002.900269:artist_reg_write 2 0x1004a4 <- 0x 24590@1596601002.900280:artist_reg_write 1 0x1004a6 <- 0xff OK [S +0.047130] OK [R +0.047159] writew 0xf8118001 0xff7c 24590@1596601002.900331:artist_reg_write 1 0x118001 CMAP_BM_ACCESS <- 0xff 24590@1596601002.900344:artist_reg_write 1 0x118002 CMAP_BM_ACCESS <- 0x7c OK [S +0.047194] OK [R +0.047213] writew 0xf8118000 0x8300 24590@1596601002.900383:artist_reg_write 2 0x118000 CMAP_BM_ACCESS <- 0x8300 OK [S +0.047231] OK [R +0.047243] writeq 0xf81005fb 0x5c18006400189e 24590@1596601002.900410:artist_reg_write 1 0x1005fb <- 0x0 24590@1596601002.900418:artist_reg_write 4 0x1005fc <- 0x5c180064 24590@1596601002.900424:artist_reg_write 2 0x100600 VRAM_WRITE_INCR_X <- 0x18 /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17: runtime error: store to misaligned address 0x7fd01d3f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment 0x7fd01d3f: note: pointer points here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17 in AddressSanitizer:DEADLYSIGNAL -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890370/+subscriptions
[Bug 1890312] Re: Segfault in artist_vram_read
There's one more slightly further in the same function - line 1231 https://github.com/hdeller/qemu- hppa/blob/1e5391948f977932d17526c491d262a3cd99a690/hw/display/artist.c#L1231 cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf8118005 0x1e7c50ff016d65ff readl 0xf9080100 EOF [I 1596601465.827371] OPENED [R +0.043473] writeq 0xf8118005 0x1e7c50ff016d65ff 18615@1596601465.870899:artist_reg_write 1 0x118005 DST_BM_ACCESS <- 0x1e 18615@1596601465.870911:artist_reg_write 2 0x118006 DST_BM_ACCESS <- 0x7c50 18615@1596601465.870918:artist_reg_write 4 0x118008 SRC_BM_ACCESS <- 0xff016d65 18615@1596601465.870924:artist_reg_write 1 0x11800c CONTROL_PLANE <- 0xff OK [S +0.043557] OK [R +0.043574] readl 0xf9080100 AddressSanitizer:DEADLYSIGNAL = ==18615==ERROR: AddressSanitizer: SEGV on unknown address 0x7f12d2a01040 (pc 0x560323116048 bp 0x7fffa8723bf0 sp 0x7fffa8723990 T0) ==18615==The signal is caused by a READ memory access. #0 0x560323116048 in artist_vram_read /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:1231:23 #1 0x560322868582 in memory_region_read_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:434:11 ... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890312 Title: Segfault in artist_vram_read Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writew 0xf8118001 0x105a readq 0xf900f8ff EOF = ==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90d0 T0) ==20118==The signal is caused by a READ memory access. #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #16 0x7fc7261ad897 in g_main_context_dispatch () #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 #21 0x55ec9decb911 in main /softmmu/main.c:49:5 The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890312/+subscriptions
Re: [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
On 200804 1801, Alexander Bulekov wrote:
> On 200804 2320, Helge Deller wrote:
> > Hi Alexander,
> >
> > * Alexander Bulekov :
> > > I applied this series and it fixes most of the problems I saw before.
> > > I still see a few crashes - I made issues for them on launchpad:
> > > https://bugs.launchpad.net/qemu/+bug/1890310
> > > https://bugs.launchpad.net/qemu/+bug/1890311
>
> > > https://bugs.launchpad.net/qemu/+bug/1890312
> Hi Helge, I can still reproduce this one ^^^
> I'll fuzz it some more, but so far I am not finding anything else.
> Thanks!
> -Alex
Found one more. It doesn't occur without these patches, but I forgot to
check and submitted a bug:
https://bugs.launchpad.net/qemu/+bug/1890370
Oops.. Closed the report, but the details about the segfault are there.
I think I hit the limits of how much code I will be able to cover, so
I'll probably stop testing now.
Thanks
-Alex
> >
> > Thanks for testing!
> > Below is the updated patch which fixes all of the issues you reported so
> > far. Can you please test again?
> > If you like you can pull all changes from
> > https://github.com/hdeller/qemu-hppa/commits/target-hppa
> >
> > Thanks!
> > Helge
> >
> > ---
> >
> > From ee31d3aa9dd91cde3a4df8fce97239a0ff26f7cc Mon Sep 17 00:00:00 2001
> > From: Helge Deller
> > Date: Tue, 4 Aug 2020 15:35:38 +0200
> > Subject: [PATCH] hw/display/artist: Prevent out of VRAM buffer accesses
> >
> > Simplify bounds checks by changing some parameters like row or column
> > numbers to become unsigned instead of signed.
> > With that we can check if the calculated offset is bigger than the size
> > of the VRAM region and bail out if not.
> >
> > Reported-by: LLVM libFuzzer
> > Reported-by: Alexander Bulekov
> > Buglink: https://bugs.launchpad.net/qemu/+bug/1880326
> > Buglink: https://bugs.launchpad.net/qemu/+bug/1890310
> > Buglink: https://bugs.launchpad.net/qemu/+bug/1890311
> > Buglink: https://bugs.launchpad.net/qemu/+bug/1890312
> > Signed-off-by: Helge Deller
> >
> > diff --git a/hw/display/artist.c b/hw/display/artist.c
> > index 47de17b9e9..66a230bbd5 100644
> > --- a/hw/display/artist.c
> > +++ b/hw/display/artist.c
> > @@ -35,9 +35,9 @@
> > struct vram_buffer {
> > MemoryRegion mr;
> > uint8_t *data;
> > -int size;
> > -int width;
> > -int height;
> > +unsigned int size;
> > +unsigned int width;
> > +unsigned int height;
> > };
> >
> > typedef struct ARTISTState {
> > @@ -203,14 +203,18 @@ static int16_t artist_get_y(uint32_t reg)
> > }
> >
> > static void artist_invalidate_lines(struct vram_buffer *buf,
> > -int starty, int height)
> > +unsigned int starty, unsigned int
> > height)
> > {
> > -int start = starty * buf->width;
> > -int size = height * buf->width;
> > +unsigned int start, size;
> >
> > -if (start + size <= buf->size) {
> > -memory_region_set_dirty(&buf->mr, start, size);
> > +if (starty >= buf->height) {
> > +return;
> > }
> > +
> > +start = starty * buf->width;
> > +size = MIN(height * buf->width, buf->size - start);
> > +
> > +memory_region_set_dirty(&buf->mr, start, size);
> > }
> >
> > static int vram_write_pix_per_transfer(ARTISTState *s)
> > @@ -274,15 +278,15 @@ static artist_rop_t artist_get_op(ARTISTState *s)
> > }
> >
> > static void artist_rop8(ARTISTState *s, struct vram_buffer *buf,
> > -int offset, uint8_t val)
> > +unsigned int offset, uint8_t val)
> > {
> > const artist_rop_t op = artist_get_op(s);
> > uint8_t plane_mask;
> > uint8_t *dst;
> >
> > -if (offset < 0 || offset >= buf->size) {
> > +if (offset >= buf->size) {
> > qemu_log_mask(LOG_GUEST_ERROR,
> > - "rop8 offset:%d bufsize:%u\n", offset, buf->size);
> > + "rop8 offset:%u bufsize:%u\n", offset, buf->size);
> > return;
> > }
> > dst = buf->data + offset;
> > @@ -294,8 +298,7 @@ static void artist_rop8(ARTISTState *s, struct
> > vram_buffer *buf,
> > break;
> >
> > case ARTIST_ROP_COPY:
> > -*dst &= ~plane_mask;
> > -*dst |= val & plane_mask;
> > +*dst = (*dst & ~plane_mask) | (val & plane_mask);
> > break;
> >
> > case ARTIST_ROP_XOR:
> > @@ -349,7 +352,8 @@ static void vram_bit_write(ARTISTState *s, int posx,
> > int posy, bool incr_x,
> > {
> > struct vram_buffer *buf;
> > uint32_t vram_bitmask = s->vram_bitmask;
> > -int mask, i, pix_count, pix_length, offset, width;
> > +int mask, i, pix_count, pix_length;
> > +unsigned int offset, width;
> > uint8_t *data8, *p;
> >
> > pix_count = vram_write_pix_per_transfer(s);
> > @@ -394,7 +398,9 @@ static void vram_bit_write(ARTISTState *s, int posx,
> > int posy, bool incr_x,
> >
> > case 3:
> > if (s->cmap_bm_access) {
> > -
[Bug 1890370] [NEW] Segfault in artist vram_bit_write
Public bug reported: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf810049f 0x writew 0xf8118001 0xff7c writew 0xf8118000 0x8300 writeq 0xf81005fb 0x5c18006400189e EOF SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /hw/display/artist.c:402:17 in AddressSanitizer:DEADLYSIGNAL = ==23157==ERROR: AddressSanitizer: SEGV on unknown address 0x7f17563f (pc 0x560ce3ad742c bp 0x7ffe310c62e0 sp 0x7ffe310c5a60 T0) ==23157==The signal is caused by a WRITE memory access. #0 0x560ce3ad742c in vram_bit_write /hw/display/artist.c:402:43 #1 0x560ce3acf2ab in artist_reg_write /hw/display/artist.c:892:9 #2 0x560ce31c37a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x560ce31c2adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x560ce31c0873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x560ce286e056 in flatview_write_continue /exec.c:3176:23 #6 0x560ce2856866 in flatview_write /exec.c:3216:14 #7 0x560ce2856387 in address_space_write /exec.c:3308:18 #8 0x560ce326a604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x560ce3261c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x560ce3260895 in qtest_read /softmmu/qtest.c:722:5 #11 0x560ce571d343 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x560ce571d4c7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x560ce57317b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x560ce5885b74 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f1665259897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x560ce5c7da7b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x560ce5c7b1ab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x560ce5c7ab44 in main_loop_wait /util/main-loop.c:516:11 #19 0x560ce3282d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x560ce58bd961 in main /softmmu/main.c:49:5 #21 0x7f1663ddfe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x560ce2761729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) With -trace artist\* [I 1596601002.853158] OPENED [R +0.047035] writeq 0xf810049f 0x 24590@1596601002.900238:artist_reg_write 1 0x10049f <- 0xff 24590@1596601002.900258:artist_reg_write 4 0x1004a0 VRAM_IDX <- 0x 24590@1596601002.900269:artist_reg_write 2 0x1004a4 <- 0x 24590@1596601002.900280:artist_reg_write 1 0x1004a6 <- 0xff OK [S +0.047130] OK [R +0.047159] writew 0xf8118001 0xff7c 24590@1596601002.900331:artist_reg_write 1 0x118001 CMAP_BM_ACCESS <- 0xff 24590@1596601002.900344:artist_reg_write 1 0x118002 CMAP_BM_ACCESS <- 0x7c OK [S +0.047194] OK [R +0.047213] writew 0xf8118000 0x8300 24590@1596601002.900383:artist_reg_write 2 0x118000 CMAP_BM_ACCESS <- 0x8300 OK [S +0.047231] OK [R +0.047243] writeq 0xf81005fb 0x5c18006400189e 24590@1596601002.900410:artist_reg_write 1 0x1005fb <- 0x0 24590@1596601002.900418:artist_reg_write 4 0x1005fc <- 0x5c180064 24590@1596601002.900424:artist_reg_write 2 0x100600 VRAM_WRITE_INCR_X <- 0x18 /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17: runtime error: store to misaligned address 0x7fd01d3f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment 0x7fd01d3f: note: pointer points here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17 in AddressSanitizer:DEADLYSIGNAL -Alex ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890370 Title: Segfault in artist vram_bit_write Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf810049f 0x writew 0xf8118001 0xff7c writew 0xf8118000 0x8300 writeq 0xf81005fb 0x5c18006400189e EOF SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /hw/display/artist.c:402:17 in AddressSanitizer:DEADLYSIGNAL = ==23157==ERROR: AddressSanitizer: SEGV on unknown address 0x7f17563f (pc 0x560ce3ad742c bp 0x7ffe310c62e0 sp 0x7ffe310c5a60 T0) ==23157==The signal is caused by a WRITE memory access. #0 0x560ce3ad742c in vram_bit_write /hw/display/artist.c:402:43 #1 0x560ce3acf2ab in artist_reg_write /hw/display/artist.c:892:9 #2 0x560ce31c37a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x560ce31c2adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x560ce31c0873 in memo
Re: [PATCH 7/7] target/arm: Remove ARCH macro
On 8/3/20 4:18 AM, Peter Maydell wrote: > The ARCH() macro was used a lot in the legacy decoder, but > there are now just two uses of it left. Since a macro which > expands out to a goto is liable to be confusing when reading > code, replace the last two uses with a simple open-coded > qeuivalent. ^^^ typo > > Signed-off-by: Peter Maydell > --- > target/arm/translate.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH 6/7] target/arm: Convert T32 coprocessor insns to decodetree
On 8/3/20 4:18 AM, Peter Maydell wrote: > Convert the T32 coprocessor instructions to decodetree. > As with the A32 conversion, this corrects an underdecoding > where we did not check that MRRC/MCRR [24:21] were 0b0010 > and so treated some kinds of LDC/STC and MRRC/MCRR rather > than UNDEFing them. > > Signed-off-by: Peter Maydell > --- > target/arm/t32.decode | 19 + > target/arm/translate.c | 64 ++ > 2 files changed, 21 insertions(+), 62 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH 5/7] target/arm: Do M-profile NOCP checks early and via decodetree
On 8/3/20 4:18 AM, Peter Maydell wrote: > For M-profile CPUs, the architecture specifies that the NOCP > exception when a coprocessor is not present or disabled should cover > the entire wide range of coprocessor-space encodings, and should take > precedence over UNDEF exceptions. (This is the opposite of > A-profile, where checking for a disabled FPU has to happen last.) > > Implement this with decodetree patterns that cover the specified > ranges of the encoding space. There are a few instructions (VLLDM, > VLSTM, and in v8.1 also VSCCLRM) which are in copro-space but must > not be NOCP'd: these must be handled also in the new m-nocp.decode so > they take precedence. > > This is a minor behaviour change: for unallocated insn patterns in > the VFP area (cp=10,11) we will now NOCP rather than UNDEF when the > FPU is disabled. > > As well as giving us the correct architectural behaviour for v8.1M > and the recommended behaviour for v8.0M, this refactoring also > removes the old NOCP handling from the remains of the 'legacy > decoder' in disas_thumb2_insn(), paving the way for cleaning that up. > > Since we don't currently have a v8.1M feature bit or any v8.1M CPUs, > the minor changes to this logic that we'll need for v8.1M are marked > up with TODO comments. > > Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson > +/* M-profile handled this earlier, in disas_m_profile_nocp() */ That's not the function name you settled upon. r~
Re: [PATCH 4/7] target/arm: Tidy up disas_arm_insn()
On 8/3/20 4:18 AM, Peter Maydell wrote: > The only thing left in the "legacy decoder" is the handling > of disas_xscale_insn(), and we can simplify the code. > > Signed-off-by: Peter Maydell > --- > target/arm/translate.c | 26 +- > 1 file changed, 9 insertions(+), 17 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PATCH 3/7] target/arm: Convert A32 coprocessor insns to decodetree
On 8/3/20 4:18 AM, Peter Maydell wrote: > Convert the A32 coprocessor instructions to decodetree. > > Note that this corrects an underdecoding: for the 64-bit access case > (MRRC/MCRR) we did not check that bits [24:21] were 0b0010, so we > would incorrectly treat LDC/STC as MRRC/MCRR rather than UNDEFing > them. > > The decodetree versions of these insns assume the coprocessor > is in the range 0..7 or 14..15. This is architecturally sensible > (as per the comments) and OK in practice for QEMU because the only > uses of the ARMCPRegInfo infrastructure we have that aren't > for coprocessors 14 or 15 are the pxa2xx use of coprocessor 6. > We add an assertion to the define_one_arm_cp_reg_with_opaque() > function to catch any accidental future attempts to use it to > define coprocessor registers for invalid coprocessors. > > Signed-off-by: Peter Maydell > --- > target/arm/a32.decode | 19 +++ > target/arm/helper.c| 29 + > target/arm/translate.c | 74 +++--- > 3 files changed, 111 insertions(+), 11 deletions(-) Reviewed-by: Richard Henderson r~
Re: [PULL 0/2] Net patches
On 2020/8/4 下午6:53, Peter Maydell wrote: On Tue, 4 Aug 2020 at 07:41, Jason Wang wrote: The following changes since commit 5c1c3e4f02e458cf280c677c817ae4fd1ed9bf10: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200803' into staging (2020-08-03 20:34:26 +0100) are available in the git repository at: https://github.com/jasowang/qemu.git tags/net-pull-request for you to fetch changes up to 035e69b063835a5fd23cacabd63690a3d84532a8: hw/net/net_tx_pkt: fix assertion failure in net_tx_pkt_add_raw_fragment() (2020-08-04 14:14:48 +0800) Lukas Straub (1): colo-compare: Remove superfluous NULL-pointer checks for s->iothread Mauro Matteo Cascella (1): hw/net/net_tx_pkt: fix assertion failure in net_tx_pkt_add_raw_fragment() Hi; this pullreq includes a patch where there's mangled UTF-8 in one of the commit messages: the "colo-compare: Remove superfluous NULL-pointer checks for s->iothread" patch has a mangled version of the e-with-acute-accent character in Philippe's surname in his Reviewed-by: tag. Since this is the day of rc3 and I think you're at a timezone offset that would make rerolling the series in time tricky, I'm going to let this through. But please can you fix your patch-handling workflow to ensure it doesn't corrupt UTF-8 ? My bad, it's time for me to use patchwork probably (or is there a better tools)? Thanks Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1 for any user-visible changes. -- PMM
Re: [PATCH v6 4/4] target/riscv: Change the TLB page size depends on PMP entries.
On Tue, Jul 28, 2020 at 4:26 PM Zong Li wrote:
>
> The minimum granularity of PMP is 4 bytes, it is small than 4KB page
> size, therefore, the pmp checking would be ignored if its range doesn't
> start from the alignment of one page. This patch detects the pmp entries
> and sets the small page size to TLB if there is a PMP entry which cover
> the page size.
>
> Signed-off-by: Zong Li
> ---
> target/riscv/cpu_helper.c | 10 ++--
> target/riscv/pmp.c| 52 +++
> target/riscv/pmp.h| 2 ++
> 3 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index 2f337e418c..fd1d373b6f 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -693,6 +693,7 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int
> size,
> bool first_stage_error = true;
> int ret = TRANSLATE_FAIL;
> int mode = mmu_idx;
> +target_ulong tlb_size = 0;
>
> env->guest_phys_fault_addr = 0;
>
> @@ -784,8 +785,13 @@ bool riscv_cpu_tlb_fill(CPUState *cs, vaddr address, int
> size,
> }
>
> if (ret == TRANSLATE_SUCCESS) {
> -tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK,
> - prot, mmu_idx, TARGET_PAGE_SIZE);
> +if (pmp_is_range_in_tlb(env, pa & TARGET_PAGE_MASK, &tlb_size)) {
> +tlb_set_page(cs, address & ~(tlb_size - 1), pa & ~(tlb_size - 1),
> + prot, mmu_idx, tlb_size);
> +} else {
> +tlb_set_page(cs, address & TARGET_PAGE_MASK, pa &
> TARGET_PAGE_MASK,
> + prot, mmu_idx, TARGET_PAGE_SIZE);
> +}
> return true;
> } else if (probe) {
> return false;
> diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
> index aeba796484..adadf6e9ba 100644
> --- a/target/riscv/pmp.c
> +++ b/target/riscv/pmp.c
> @@ -393,3 +393,55 @@ target_ulong pmpaddr_csr_read(CPURISCVState *env,
> uint32_t addr_index)
>
> return val;
> }
> +
> +/*
> + * Calculate the TLB size if the start address or the end address of
> + * PMP entry is presented in thie TLB page.
> + */
> +static target_ulong pmp_get_tlb_size(CPURISCVState *env, int pmp_index,
> +target_ulong tlb_sa, target_ulong tlb_ea)
> +{
> +target_ulong pmp_sa = env->pmp_state.addr[pmp_index].sa;
> +target_ulong pmp_ea = env->pmp_state.addr[pmp_index].ea;
> +
> +if (pmp_sa >= tlb_sa && pmp_ea <= tlb_ea) {
> +return pmp_ea - pmp_sa + 1;
> +}
> +
> +if (pmp_sa >= tlb_sa && pmp_sa <= tlb_ea && pmp_ea >= tlb_ea) {
> +return tlb_ea - pmp_sa + 1;
> +}
> +
> +if (pmp_ea <= tlb_ea && pmp_ea >= tlb_sa && pmp_sa <= tlb_sa) {
> +return pmp_ea - tlb_sa + 1;
> +}
> +
> +return 0;
> +}
> +
> +/*
> + * Check is there a PMP entry whcih range covers this page. If so,
> + * try to find the minimum granularity for the TLB size.
> + */
> +bool pmp_is_range_in_tlb(CPURISCVState *env, hwaddr tlb_sa,
> +target_ulong *tlb_size)
> +{
> +int i;
> +target_ulong val;
> +target_ulong tlb_ea = (tlb_sa + TARGET_PAGE_SIZE - 1);
> +
> +for (i = 0; i < MAX_RISCV_PMPS; i++) {
> +val = pmp_get_tlb_size(env, i, tlb_sa, tlb_ea);
> +if (val) {
> +if (*tlb_size == 0 || *tlb_size > val) {
> +*tlb_size = val;
> +}
> +}
> +}
> +
> +if (*tlb_size != 0) {
> +return true;
> +}
> +
> +return false;
> +}
> diff --git a/target/riscv/pmp.h b/target/riscv/pmp.h
> index 8e19793132..c70f2ea4c4 100644
> --- a/target/riscv/pmp.h
> +++ b/target/riscv/pmp.h
> @@ -60,5 +60,7 @@ void pmpaddr_csr_write(CPURISCVState *env, uint32_t
> addr_index,
> target_ulong pmpaddr_csr_read(CPURISCVState *env, uint32_t addr_index);
> bool pmp_hart_has_privs(CPURISCVState *env, target_ulong addr,
> target_ulong size, pmp_priv_t priv, target_ulong mode);
> +bool pmp_is_range_in_tlb(CPURISCVState *env, hwaddr tlb_sa,
> +target_ulong *tlb_size);
>
> #endif
> --
> 2.27.0
>
ping
Re: [PATCH] qcow2: flush qcow2 l2 meta for new allocated clusters
Patchew URL: https://patchew.org/QEMU/20200805023826.184-1-fangyi...@huawei.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. The full log is available at http://patchew.org/logs/20200805023826.184-1-fangyi...@huawei.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: device compatibility interface for live migration with assigned devices
On 2020/8/5 上午10:16, Yan Zhao wrote: On Wed, Aug 05, 2020 at 10:22:15AM +0800, Jason Wang wrote: On 2020/8/5 上午12:35, Cornelia Huck wrote: [sorry about not chiming in earlier] On Wed, 29 Jul 2020 16:05:03 +0800 Yan Zhao wrote: On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote: (...) Based on the feedback we've received, the previously proposed interface is not viable. I think there's agreement that the user needs to be able to parse and interpret the version information. Using json seems viable, but I don't know if it's the best option. Is there any precedent of markup strings returned via sysfs we could follow? I don't think encoding complex information in a sysfs file is a viable approach. Quoting Documentation/filesystems/sysfs.rst: "Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type. Mixing types, expressing multiple lines of data, and doing fancy formatting of data is heavily frowned upon." Even though this is an older file, I think these restrictions still apply. +1, that's another reason why devlink(netlink) is better. hi Jason, do you have any materials or sample code about devlink, so we can have a good study of it? I found some kernel docs about it but my preliminary study didn't show me the advantage of devlink. CC Jiri and Parav for a better answer for this. My understanding is that the following advantages are obvious (as I replied in another thread): - existing users (NIC, crypto, SCSI, ib), mature and stable - much better error reporting (ext_ack other than string or errno) - namespace aware - do not couple with kobject Thanks Thanks Yan
[PATCH] qcow2: flush qcow2 l2 meta for new allocated clusters
From: fangying
When qemu or qemu-nbd process uses a qcow2 image and configured with
'cache = none', it will write to the qcow2 image with a cache to cache
L2 tables, however the process will not use L2 tables without explicitly
calling the flush command or closing the mirror flash into the disk.
Which may cause the disk data inconsistent with the written data for
a long time. If an abnormal process exit occurs here, the issued written
data will be lost.
Therefore, in order to keep data consistency we need to flush the changes
to the L2 entry to the disk in time for the newly allocated cluster.
Signed-off-by: Ying Fang
diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
index 7444b9c..ab6e812 100644
--- a/block/qcow2-cache.c
+++ b/block/qcow2-cache.c
@@ -266,6 +266,22 @@ int qcow2_cache_flush(BlockDriverState *bs, Qcow2Cache *c)
return result;
}
+#define L2_ENTRIES_PER_SECTOR 64
+int qcow2_cache_l2_write_entry(BlockDriverState *bs, Qcow2Cache *c,
+ void *table, int index, int num)
+{
+int ret;
+int i = qcow2_cache_get_table_idx(c, table);
+int start_sector = index / L2_ENTRIES_PER_SECTOR;
+int end_sector = (index + num - 1) / L2_ENTRIES_PER_SECTOR;
+int nr_sectors = end_sector - start_sector + 1;
+ret = bdrv_pwrite(bs->file,
+ c->entries[i].offset + start_sector * BDRV_SECTOR_SIZE,
+ table + start_sector * BDRV_SECTOR_SIZE,
+ nr_sectors * BDRV_SECTOR_SIZE);
+return ret;
+}
+
int qcow2_cache_set_dependency(BlockDriverState *bs, Qcow2Cache *c,
Qcow2Cache *dependency)
{
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index a677ba9..ae49a83 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -998,6 +998,9 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs,
QCowL2Meta *m)
}
+ret = qcow2_cache_l2_write_entry(bs, s->l2_table_cache, l2_slice,
+ l2_index, m->nb_clusters);
+
qcow2_cache_put(s->l2_table_cache, (void **) &l2_slice);
/*
diff --git a/block/qcow2.h b/block/qcow2.h
index 7ce2c23..168ab59 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -748,6 +748,8 @@ int qcow2_cache_destroy(Qcow2Cache *c);
void qcow2_cache_entry_mark_dirty(Qcow2Cache *c, void *table);
int qcow2_cache_flush(BlockDriverState *bs, Qcow2Cache *c);
int qcow2_cache_write(BlockDriverState *bs, Qcow2Cache *c);
+int qcow2_cache_l2_write_entry(BlockDriverState *bs, Qcow2Cache *c,
+ void *table, int index, int num);
int qcow2_cache_set_dependency(BlockDriverState *bs, Qcow2Cache *c,
Qcow2Cache *dependency);
void qcow2_cache_depends_on_flush(Qcow2Cache *c);
--
1.8.3.1
Re: device compatibility interface for live migration with assigned devices
On Wed, Aug 05, 2020 at 10:22:15AM +0800, Jason Wang wrote: > > On 2020/8/5 上午12:35, Cornelia Huck wrote: > > [sorry about not chiming in earlier] > > > > On Wed, 29 Jul 2020 16:05:03 +0800 > > Yan Zhao wrote: > > > > > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote: > > (...) > > > > > > Based on the feedback we've received, the previously proposed interface > > > > is not viable. I think there's agreement that the user needs to be > > > > able to parse and interpret the version information. Using json seems > > > > viable, but I don't know if it's the best option. Is there any > > > > precedent of markup strings returned via sysfs we could follow? > > I don't think encoding complex information in a sysfs file is a viable > > approach. Quoting Documentation/filesystems/sysfs.rst: > > > > "Attributes should be ASCII text files, preferably with only one value > > per file. It is noted that it may not be efficient to contain only one > > value per file, so it is socially acceptable to express an array of > > values of the same type. > > Mixing types, expressing multiple lines of data, and doing fancy > > formatting of data is heavily frowned upon." > > > > Even though this is an older file, I think these restrictions still > > apply. > > > +1, that's another reason why devlink(netlink) is better. > hi Jason, do you have any materials or sample code about devlink, so we can have a good study of it? I found some kernel docs about it but my preliminary study didn't show me the advantage of devlink. Thanks Yan
Re: device compatibility interface for live migration with assigned devices
On 2020/8/5 上午12:35, Cornelia Huck wrote: [sorry about not chiming in earlier] On Wed, 29 Jul 2020 16:05:03 +0800 Yan Zhao wrote: On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote: (...) Based on the feedback we've received, the previously proposed interface is not viable. I think there's agreement that the user needs to be able to parse and interpret the version information. Using json seems viable, but I don't know if it's the best option. Is there any precedent of markup strings returned via sysfs we could follow? I don't think encoding complex information in a sysfs file is a viable approach. Quoting Documentation/filesystems/sysfs.rst: "Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type. Mixing types, expressing multiple lines of data, and doing fancy formatting of data is heavily frowned upon." Even though this is an older file, I think these restrictions still apply. +1, that's another reason why devlink(netlink) is better. Thanks
Re: [Bug 1890360] [NEW] Assertion failure in address_space_unmap through virtio-blk
Hi Stefan, This looks an awful lot like the one you looked at here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg705719.html though this one is for virtio-pci, while that one was for virtio-mmio: They are probably the same issue, but the original reproducer no longer causes an asserion failure for me, so maybe there was already a fix.. -Alex On 200805 0116, Alexander Bulekov wrote: > Public bug reported: > > Hello, > Reproducer: > cat << EOF | ./i386-softmmu/qemu-system-i386 \ > -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ > -device virtio-blk,drive=mydrive \ > -nodefaults -nographic -qtest stdio > outl 0xcf8 0x80001010 > outl 0xcfc 0xc001 > outl 0xcf8 0x80001014 > outl 0xcf8 0x80001004 > outw 0xcfc 0x7 > outl 0xc006 0x3aff9090 > outl 0xcf8 0x8000100e > outl 0xcfc 0x41005e1e > write 0x3b2 0x1 0x5e > write 0x3b4 0x1 0x5e > write 0x3aff5e6 0x1 0x11 > write 0x3aff5eb 0x1 0xc6 > write 0x3aff5ec 0x1 0xc6 > write 0x7 0x1 0xff > write 0x8 0x1 0xfb > write 0xc 0x1 0x11 > write 0xe 0x1 0x5e > write 0x5e8 0x1 0x11 > write 0x5ec 0x1 0xc6 > outl 0x410e 0x10e > EOF > > > qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void > *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. > ==789== ERROR: libFuzzer: deadly signal > #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 > #9 in address_space_unmap /exec.c:3623:9 > #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 > #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 > #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 > #13 in virtqueue_push /hw/virtio/virtio.c:917:5 > #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 > #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 > #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 > #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 > #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 > #19 in aio_dispatch_handler /util/aio-posix.c:328:9 > #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 > #21 in aio_dispatch /util/aio-posix.c:381:5 > #22 in aio_ctx_dispatch /util/async.c:306:5 > #23 in g_main_context_dispatch > > > With -trace virtio\* > > ... > [S +0.099667] OK > [R +0.099681] write 0x5ec 0x1 0xc6 > OK > [S +0.099690] OK > [R +0.099700] outl 0x410e 0x10e > 29575@1596590112.074339:virtio_queue_notify vdev 0x62d30590 n 0 vq > 0x7f9b93fc9800 > 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x6060f260 > OK > [S +0.099833] OK > 29575@1596590112.076459:virtio_queue_notify vdev 0x62d30590 n 0 vq > 0x7f9b93fc9800 > 29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d30590 req > 0x61143e80 sector 0 nsectors 0 > 29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d30590 req > 0x61143e80 status 1 > qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: > void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): > Assertion `mr != NULL' failed. > > > -Alex > > ** Affects: qemu > Importance: Undecided > Status: New > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/1890360 > > Title: > Assertion failure in address_space_unmap through virtio-blk > > Status in QEMU: > New > > Bug description: > Hello, > Reproducer: > cat << EOF | ./i386-softmmu/qemu-system-i386 \ > -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ > -device virtio-blk,drive=mydrive \ > -nodefaults -nographic -qtest stdio > outl 0xcf8 0x80001010 > outl 0xcfc 0xc001 > outl 0xcf8 0x80001014 > outl 0xcf8 0x80001004 > outw 0xcfc 0x7 > outl 0xc006 0x3aff9090 > outl 0xcf8 0x8000100e > outl 0xcfc 0x41005e1e > write 0x3b2 0x1 0x5e > write 0x3b4 0x1 0x5e > write 0x3aff5e6 0x1 0x11 > write 0x3aff5eb 0x1 0xc6 > write 0x3aff5ec 0x1 0xc6 > write 0x7 0x1 0xff > write 0x8 0x1 0xfb > write 0xc 0x1 0x11 > write 0xe 0x1 0x5e > write 0x5e8 0x1 0x11 > write 0x5ec 0x1 0xc6 > outl 0x410e 0x10e > EOF > > > qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void > *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. > ==789== ERROR: libFuzzer: deadly signal > #8 in __assert_fail > /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 > #9 in address_space_unmap /exec.c:3623:9 > #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 > #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 > #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 > #13 in virtqueue_push /hw/virtio/virtio.c:917:5 > #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 > #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 > #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 > #17 in virtio_queue_notify_aio_v
[Bug 1890360] [NEW] Assertion failure in address_space_unmap through virtio-blk
Public bug reported: Hello, Reproducer: cat << EOF | ./i386-softmmu/qemu-system-i386 \ -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ -device virtio-blk,drive=mydrive \ -nodefaults -nographic -qtest stdio outl 0xcf8 0x80001010 outl 0xcfc 0xc001 outl 0xcf8 0x80001014 outl 0xcf8 0x80001004 outw 0xcfc 0x7 outl 0xc006 0x3aff9090 outl 0xcf8 0x8000100e outl 0xcfc 0x41005e1e write 0x3b2 0x1 0x5e write 0x3b4 0x1 0x5e write 0x3aff5e6 0x1 0x11 write 0x3aff5eb 0x1 0xc6 write 0x3aff5ec 0x1 0xc6 write 0x7 0x1 0xff write 0x8 0x1 0xfb write 0xc 0x1 0x11 write 0xe 0x1 0x5e write 0x5e8 0x1 0x11 write 0x5ec 0x1 0xc6 outl 0x410e 0x10e EOF qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. ==789== ERROR: libFuzzer: deadly signal #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 #9 in address_space_unmap /exec.c:3623:9 #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 #13 in virtqueue_push /hw/virtio/virtio.c:917:5 #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 #19 in aio_dispatch_handler /util/aio-posix.c:328:9 #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 #21 in aio_dispatch /util/aio-posix.c:381:5 #22 in aio_ctx_dispatch /util/async.c:306:5 #23 in g_main_context_dispatch With -trace virtio\* ... [S +0.099667] OK [R +0.099681] write 0x5ec 0x1 0xc6 OK [S +0.099690] OK [R +0.099700] outl 0x410e 0x10e 29575@1596590112.074339:virtio_queue_notify vdev 0x62d30590 n 0 vq 0x7f9b93fc9800 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x6060f260 OK [S +0.099833] OK 29575@1596590112.076459:virtio_queue_notify vdev 0x62d30590 n 0 vq 0x7f9b93fc9800 29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d30590 req 0x61143e80 sector 0 nsectors 0 29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d30590 req 0x61143e80 status 1 qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. -Alex ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890360 Title: Assertion failure in address_space_unmap through virtio-blk Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./i386-softmmu/qemu-system-i386 \ -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ -device virtio-blk,drive=mydrive \ -nodefaults -nographic -qtest stdio outl 0xcf8 0x80001010 outl 0xcfc 0xc001 outl 0xcf8 0x80001014 outl 0xcf8 0x80001004 outw 0xcfc 0x7 outl 0xc006 0x3aff9090 outl 0xcf8 0x8000100e outl 0xcfc 0x41005e1e write 0x3b2 0x1 0x5e write 0x3b4 0x1 0x5e write 0x3aff5e6 0x1 0x11 write 0x3aff5eb 0x1 0xc6 write 0x3aff5ec 0x1 0xc6 write 0x7 0x1 0xff write 0x8 0x1 0xfb write 0xc 0x1 0x11 write 0xe 0x1 0x5e write 0x5e8 0x1 0x11 write 0x5ec 0x1 0xc6 outl 0x410e 0x10e EOF qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed. ==789== ERROR: libFuzzer: deadly signal #8 in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3 #9 in address_space_unmap /exec.c:3623:9 #10 in dma_memory_unmap /include/sysemu/dma.h:145:5 #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9 #12 in virtqueue_fill /hw/virtio/virtio.c:843:5 #13 in virtqueue_push /hw/virtio/virtio.c:917:5 #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5 #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13 #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17 #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15 #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9 #19 in aio_dispatch_handler /util/aio-posix.c:328:9 #20 in aio_dispatch_handlers /util/aio-posix.c:371:20 #21 in aio_dispatch /util/aio-posix.c:381:5 #22 in aio_ctx_dispatch /util/async.c:306:5 #23 in g_main_context_dispatch With -trace virtio\* ... [S +0.099667] OK [R +0.099681] write 0x5ec 0x1 0xc6 OK [S +0.099690] OK [R +0.099700] outl 0x410e 0x10e 29575@1596590112.074339:virtio_queue_notify vdev 0x62d30590 n 0 vq 0x7f9b93fc9800 29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x606
Re: [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
On 200804 2320, Helge Deller wrote:
> Hi Alexander,
>
> * Alexander Bulekov :
> > I applied this series and it fixes most of the problems I saw before.
> > I still see a few crashes - I made issues for them on launchpad:
> > https://bugs.launchpad.net/qemu/+bug/1890310
> > https://bugs.launchpad.net/qemu/+bug/1890311
> > https://bugs.launchpad.net/qemu/+bug/1890312
Hi Helge, I can still reproduce this one ^^^
I'll fuzz it some more, but so far I am not finding anything else.
Thanks!
-Alex
>
> Thanks for testing!
> Below is the updated patch which fixes all of the issues you reported so
> far. Can you please test again?
> If you like you can pull all changes from
> https://github.com/hdeller/qemu-hppa/commits/target-hppa
>
> Thanks!
> Helge
>
> ---
>
> From ee31d3aa9dd91cde3a4df8fce97239a0ff26f7cc Mon Sep 17 00:00:00 2001
> From: Helge Deller
> Date: Tue, 4 Aug 2020 15:35:38 +0200
> Subject: [PATCH] hw/display/artist: Prevent out of VRAM buffer accesses
>
> Simplify bounds checks by changing some parameters like row or column
> numbers to become unsigned instead of signed.
> With that we can check if the calculated offset is bigger than the size
> of the VRAM region and bail out if not.
>
> Reported-by: LLVM libFuzzer
> Reported-by: Alexander Bulekov
> Buglink: https://bugs.launchpad.net/qemu/+bug/1880326
> Buglink: https://bugs.launchpad.net/qemu/+bug/1890310
> Buglink: https://bugs.launchpad.net/qemu/+bug/1890311
> Buglink: https://bugs.launchpad.net/qemu/+bug/1890312
> Signed-off-by: Helge Deller
>
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index 47de17b9e9..66a230bbd5 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -35,9 +35,9 @@
> struct vram_buffer {
> MemoryRegion mr;
> uint8_t *data;
> -int size;
> -int width;
> -int height;
> +unsigned int size;
> +unsigned int width;
> +unsigned int height;
> };
>
> typedef struct ARTISTState {
> @@ -203,14 +203,18 @@ static int16_t artist_get_y(uint32_t reg)
> }
>
> static void artist_invalidate_lines(struct vram_buffer *buf,
> -int starty, int height)
> +unsigned int starty, unsigned int height)
> {
> -int start = starty * buf->width;
> -int size = height * buf->width;
> +unsigned int start, size;
>
> -if (start + size <= buf->size) {
> -memory_region_set_dirty(&buf->mr, start, size);
> +if (starty >= buf->height) {
> +return;
> }
> +
> +start = starty * buf->width;
> +size = MIN(height * buf->width, buf->size - start);
> +
> +memory_region_set_dirty(&buf->mr, start, size);
> }
>
> static int vram_write_pix_per_transfer(ARTISTState *s)
> @@ -274,15 +278,15 @@ static artist_rop_t artist_get_op(ARTISTState *s)
> }
>
> static void artist_rop8(ARTISTState *s, struct vram_buffer *buf,
> -int offset, uint8_t val)
> +unsigned int offset, uint8_t val)
> {
> const artist_rop_t op = artist_get_op(s);
> uint8_t plane_mask;
> uint8_t *dst;
>
> -if (offset < 0 || offset >= buf->size) {
> +if (offset >= buf->size) {
> qemu_log_mask(LOG_GUEST_ERROR,
> - "rop8 offset:%d bufsize:%u\n", offset, buf->size);
> + "rop8 offset:%u bufsize:%u\n", offset, buf->size);
> return;
> }
> dst = buf->data + offset;
> @@ -294,8 +298,7 @@ static void artist_rop8(ARTISTState *s, struct
> vram_buffer *buf,
> break;
>
> case ARTIST_ROP_COPY:
> -*dst &= ~plane_mask;
> -*dst |= val & plane_mask;
> +*dst = (*dst & ~plane_mask) | (val & plane_mask);
> break;
>
> case ARTIST_ROP_XOR:
> @@ -349,7 +352,8 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
> {
> struct vram_buffer *buf;
> uint32_t vram_bitmask = s->vram_bitmask;
> -int mask, i, pix_count, pix_length, offset, width;
> +int mask, i, pix_count, pix_length;
> +unsigned int offset, width;
> uint8_t *data8, *p;
>
> pix_count = vram_write_pix_per_transfer(s);
> @@ -394,7 +398,9 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
>
> case 3:
> if (s->cmap_bm_access) {
> -*(uint32_t *)(p + offset) = data;
> +if (offset + 3 < buf->size) {
> +*(uint32_t *)(p + offset) = data;
> +}
> break;
> }
> data8 = (uint8_t *)&data;
> @@ -464,12 +470,14 @@ static void vram_bit_write(ARTISTState *s, int posx,
> int posy, bool incr_x,
> }
> }
>
> -static void block_move(ARTISTState *s, int source_x, int source_y, int
> dest_x,
> - int dest_y, int width, int height)
> +static void block_move(ARTISTState *s,
> + unsigned int source_x, unsigned int source_y,
> + unsigned int dest
[PATCH v8 0/4] Introduce Xilinx ZynqMP CAN controller
Changelog: v7 -> v8: Change CAN controller to keep one canbus per controller. Add canbus connections at machine level. Remove ctrl_idx from CAN controller. v6 -> v7: Remove '-m 4G' option from xlnx-can-test. This option causes the fail of docker-quick@centos7 build test. v5 -> v6: Add ptimer based counter for time stamping on RX messages. Fix reset issues. Rebase the patches with master latest changes. Added reference clock property for CAN ptimer. v4 -> v5: Add XlnxZynqMPCAN controller id to debug messages. Drop parameter errp of object_property_add(). Add formatting related suggestions. v3 -> v4: Correct formatting issues. v2 -> v3: Rectify the build issue. Rearrange the patch order. v1 -> v2: Rename the CAN device state and address code style issues. Connect the CAN device to Xlnx-ZCU102 board. Add maintainer entry. Add QTEST for the CAN device. Vikram Garhwal (4): hw/net/can: Introduce Xilinx ZynqMP CAN controller xlnx-zynqmp: Connect Xilinx ZynqMP CAN controllers tests/qtest: Introduce tests for Xilinx ZynqMP CAN controller MAINTAINERS: Add maintainer entry for Xilinx ZynqMP CAN controller MAINTAINERS |8 + hw/arm/xlnx-zcu102.c | 20 + hw/arm/xlnx-zynqmp.c | 34 ++ hw/net/can/Makefile.objs |1 + hw/net/can/xlnx-zynqmp-can.c | 1152 ++ include/hw/arm/xlnx-zynqmp.h |8 + include/hw/net/xlnx-zynqmp-can.h | 78 +++ tests/qtest/Makefile.include |2 + tests/qtest/xlnx-can-test.c | 359 9 files changed, 1662 insertions(+) create mode 100644 hw/net/can/xlnx-zynqmp-can.c create mode 100644 include/hw/net/xlnx-zynqmp-can.h create mode 100644 tests/qtest/xlnx-can-test.c -- 2.7.4
Re: [PULL 0/3] virtio,acpi: bugfixes
On Tue, Aug 04, 2020 at 06:20:53PM +0100, Peter Maydell wrote: > On Tue, 4 Aug 2020 at 15:17, Michael S. Tsirkin wrote: > > > > The following changes since commit 5c1c3e4f02e458cf280c677c817ae4fd1ed9bf10: > > > > Merge remote-tracking branch > > 'remotes/pmaydell/tags/pull-target-arm-20200803' into staging (2020-08-03 > > 20:34:26 +0100) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream > > > > for you to fetch changes up to 5957b49b423fe456896e10f7e4a6c69be07f9407: > > > > virtio-mem: Correct format specifier mismatch for RISC-V (2020-08-04 > > 09:13:34 -0400) > > > > > > virtio,acpi: bugfixes > > > > A couple of last minute bugfixes. > > > > Signed-off-by: Michael S. Tsirkin > > > > > > Bruce Rogers (1): > > virtio-mem: Correct format specifier mismatch for RISC-V > > > > Michael S. Tsirkin (2): > > i386/acpi: fix inconsistent QEMU/OVMF device paths > > arm/acpi: fix an out of spec _UID for PCI root > > > I applied your updated pull with just the virtio-mem fix. > > thanks > -- PMM Thanks! OK I think this is a good place to stop. No need to postpone the rc for the rest of them - not regressions, fixes can wait until the next release. -- MST
Re: [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
Hi Alexander,
* Alexander Bulekov :
> I applied this series and it fixes most of the problems I saw before.
> I still see a few crashes - I made issues for them on launchpad:
> https://bugs.launchpad.net/qemu/+bug/1890310
> https://bugs.launchpad.net/qemu/+bug/1890311
> https://bugs.launchpad.net/qemu/+bug/1890312
Thanks for testing!
Below is the updated patch which fixes all of the issues you reported so
far. Can you please test again?
If you like you can pull all changes from
https://github.com/hdeller/qemu-hppa/commits/target-hppa
Thanks!
Helge
---
From ee31d3aa9dd91cde3a4df8fce97239a0ff26f7cc Mon Sep 17 00:00:00 2001
From: Helge Deller
Date: Tue, 4 Aug 2020 15:35:38 +0200
Subject: [PATCH] hw/display/artist: Prevent out of VRAM buffer accesses
Simplify bounds checks by changing some parameters like row or column
numbers to become unsigned instead of signed.
With that we can check if the calculated offset is bigger than the size
of the VRAM region and bail out if not.
Reported-by: LLVM libFuzzer
Reported-by: Alexander Bulekov
Buglink: https://bugs.launchpad.net/qemu/+bug/1880326
Buglink: https://bugs.launchpad.net/qemu/+bug/1890310
Buglink: https://bugs.launchpad.net/qemu/+bug/1890311
Buglink: https://bugs.launchpad.net/qemu/+bug/1890312
Signed-off-by: Helge Deller
diff --git a/hw/display/artist.c b/hw/display/artist.c
index 47de17b9e9..66a230bbd5 100644
--- a/hw/display/artist.c
+++ b/hw/display/artist.c
@@ -35,9 +35,9 @@
struct vram_buffer {
MemoryRegion mr;
uint8_t *data;
-int size;
-int width;
-int height;
+unsigned int size;
+unsigned int width;
+unsigned int height;
};
typedef struct ARTISTState {
@@ -203,14 +203,18 @@ static int16_t artist_get_y(uint32_t reg)
}
static void artist_invalidate_lines(struct vram_buffer *buf,
-int starty, int height)
+unsigned int starty, unsigned int height)
{
-int start = starty * buf->width;
-int size = height * buf->width;
+unsigned int start, size;
-if (start + size <= buf->size) {
-memory_region_set_dirty(&buf->mr, start, size);
+if (starty >= buf->height) {
+return;
}
+
+start = starty * buf->width;
+size = MIN(height * buf->width, buf->size - start);
+
+memory_region_set_dirty(&buf->mr, start, size);
}
static int vram_write_pix_per_transfer(ARTISTState *s)
@@ -274,15 +278,15 @@ static artist_rop_t artist_get_op(ARTISTState *s)
}
static void artist_rop8(ARTISTState *s, struct vram_buffer *buf,
-int offset, uint8_t val)
+unsigned int offset, uint8_t val)
{
const artist_rop_t op = artist_get_op(s);
uint8_t plane_mask;
uint8_t *dst;
-if (offset < 0 || offset >= buf->size) {
+if (offset >= buf->size) {
qemu_log_mask(LOG_GUEST_ERROR,
- "rop8 offset:%d bufsize:%u\n", offset, buf->size);
+ "rop8 offset:%u bufsize:%u\n", offset, buf->size);
return;
}
dst = buf->data + offset;
@@ -294,8 +298,7 @@ static void artist_rop8(ARTISTState *s, struct vram_buffer
*buf,
break;
case ARTIST_ROP_COPY:
-*dst &= ~plane_mask;
-*dst |= val & plane_mask;
+*dst = (*dst & ~plane_mask) | (val & plane_mask);
break;
case ARTIST_ROP_XOR:
@@ -349,7 +352,8 @@ static void vram_bit_write(ARTISTState *s, int posx, int
posy, bool incr_x,
{
struct vram_buffer *buf;
uint32_t vram_bitmask = s->vram_bitmask;
-int mask, i, pix_count, pix_length, offset, width;
+int mask, i, pix_count, pix_length;
+unsigned int offset, width;
uint8_t *data8, *p;
pix_count = vram_write_pix_per_transfer(s);
@@ -394,7 +398,9 @@ static void vram_bit_write(ARTISTState *s, int posx, int
posy, bool incr_x,
case 3:
if (s->cmap_bm_access) {
-*(uint32_t *)(p + offset) = data;
+if (offset + 3 < buf->size) {
+*(uint32_t *)(p + offset) = data;
+}
break;
}
data8 = (uint8_t *)&data;
@@ -464,12 +470,14 @@ static void vram_bit_write(ARTISTState *s, int posx, int
posy, bool incr_x,
}
}
-static void block_move(ARTISTState *s, int source_x, int source_y, int dest_x,
- int dest_y, int width, int height)
+static void block_move(ARTISTState *s,
+ unsigned int source_x, unsigned int source_y,
+ unsigned int dest_x, unsigned int dest_y,
+ unsigned int width,unsigned int height)
{
struct vram_buffer *buf;
int line, endline, lineincr, startcolumn, endcolumn, columnincr, column;
-uint32_t dst, src;
+unsigned int dst, src;
trace_artist_block_move(source_x, source_y, dest_x, dest_y, width, height);
@@ -481,6 +489,12 @@ static void block_move(ARTISTState *s, int source_x, int
source_y, int dest_x,
}
[PATCH v8 1/4] hw/net/can: Introduce Xilinx ZynqMP CAN controller
The Xilinx ZynqMP CAN controller is developed based on SocketCAN, QEMU CAN bus
implementation. Bus connection and socketCAN connection for each CAN module
can be set through command lines.
Example for using single CAN:
-object can-bus,id=canbus0 \
-machine xlnx-zcu102.canbus0=canbus0 \
-object can-host-socketcan,id=socketcan0,if=vcan0,canbus=canbus0
Example for connecting both CAN to same virtual CAN on host machine:
-object can-bus,id=canbus0 -object can-bus,id=canbus1 \
-machine xlnx-zcu102.canbus0=canbus0 \
-machine xlnx-zcu102.canbus1=canbus1 \
-object can-host-socketcan,id=socketcan0,if=vcan0,canbus=canbus0 \
-object can-host-socketcan,id=socketcan1,if=vcan0,canbus=canbus1
To create virtual CAN on the host machine, please check the QEMU CAN docs:
https://github.com/qemu/qemu/blob/master/docs/can.txt
Signed-off-by: Vikram Garhwal
---
hw/net/can/Makefile.objs |1 +
hw/net/can/xlnx-zynqmp-can.c | 1152 ++
include/hw/net/xlnx-zynqmp-can.h | 78 +++
3 files changed, 1231 insertions(+)
create mode 100644 hw/net/can/xlnx-zynqmp-can.c
create mode 100644 include/hw/net/xlnx-zynqmp-can.h
diff --git a/hw/net/can/Makefile.objs b/hw/net/can/Makefile.objs
index 9f0c4ee..0fe87dd 100644
--- a/hw/net/can/Makefile.objs
+++ b/hw/net/can/Makefile.objs
@@ -2,3 +2,4 @@ common-obj-$(CONFIG_CAN_SJA1000) += can_sja1000.o
common-obj-$(CONFIG_CAN_PCI) += can_kvaser_pci.o
common-obj-$(CONFIG_CAN_PCI) += can_pcm3680_pci.o
common-obj-$(CONFIG_CAN_PCI) += can_mioe3680_pci.o
+common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp-can.o
diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
new file mode 100644
index 000..92ef8ea
--- /dev/null
+++ b/hw/net/can/xlnx-zynqmp-can.c
@@ -0,0 +1,1152 @@
+/*
+ * QEMU model of the Xilinx ZynqMP CAN controller.
+ * This implementation is based on the following datasheet:
+ *
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
+ *
+ * Copyright (c) 2020 Xilinx Inc.
+ *
+ * Written-by: Vikram Garhwal
+ *
+ * Based on QEMU CAN Device emulation implemented by Jin Yang, Deniz Eren and
+ * Pavel Pisa
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/register.h"
+#include "hw/irq.h"
+#include "qapi/error.h"
+#include "qemu/bitops.h"
+#include "qemu/log.h"
+#include "qemu/cutils.h"
+#include "sysemu/sysemu.h"
+#include "migration/vmstate.h"
+#include "hw/qdev-properties.h"
+#include "net/can_emu.h"
+#include "net/can_host.h"
+#include "qemu/event_notifier.h"
+#include "qom/object_interfaces.h"
+#include "hw/net/xlnx-zynqmp-can.h"
+
+#ifndef XLNX_ZYNQMP_CAN_ERR_DEBUG
+#define XLNX_ZYNQMP_CAN_ERR_DEBUG 0
+#endif
+
+#define DB_PRINT(...) do { \
+if (XLNX_ZYNQMP_CAN_ERR_DEBUG) { \
+qemu_log(__VA_ARGS__); \
+} \
+} while (0)
+
+#define MAX_DLC8
+#undef ERROR
+
+REG32(SOFTWARE_RESET_REGISTER, 0x0)
+FIELD(SOFTWARE_RESET_REGISTER, CEN, 1, 1)
+FIELD(SOFTWARE_RESET_REGISTER, SRST, 0, 1)
+REG32(MODE_SELECT_REGISTER, 0x4)
+FIELD(MODE_SELECT_REGISTER, SNOOP, 2, 1)
+FIELD(MODE_SELECT_REGISTER, LBACK, 1, 1)
+FIELD(MODE_SELECT_REGISTER, SLEEP, 0, 1)
+REG32(ARBITRATION_PHASE_BAUD_RATE_PRESCALER_REGISTER, 0x8)
+FIELD(ARBITRATION_PHASE_BAUD_RATE_PRESCALER_REGISTER, BRP, 0, 8)
+REG32(ARBITRATION_PHASE_BIT_TIMING_REGISTER, 0xc)
+FIELD(ARBITRATION_PHASE_BIT_TIMING_REGISTER, SJW, 7, 2)
+FIELD(ARBITRATION_PHASE_BIT_TIMING_REGISTER, TS2, 4, 3)
+FIELD(ARBITRATION_PHASE_BIT_TIMING_REGISTER, TS1, 0, 4)
+REG32(ERROR_COUNTER_REGISTER, 0x10)
+FIELD(ERROR_COUNTER_REGISTER, REC, 8, 8)
+FIELD(ERROR_COUNTER_REGISTER, TEC, 0, 8)
+REG32(ERROR_STATUS_REGISTER, 0x14)
+FIELD(ERROR_STATUS_REGISTER, ACKER, 4, 1)
+FIELD(ERROR_STATUS_REGISTER, BERR, 3, 1)
+FIELD(ERROR_STATUS_REGISTER, STER, 2, 1)
+FIELD(ERROR_STATUS_R
[PATCH v8 4/4] MAINTAINERS: Add maintainer entry for Xilinx ZynqMP CAN controller
Reviewed-by: Francisco Iglesias Reviewed-by: Edgar E. Iglesias Signed-off-by: Vikram Garhwal --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0886eb3..14d9b73 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1536,6 +1536,14 @@ F: hw/net/opencores_eth.c Devices --- +Xilinx CAN +M: Vikram Garhwal +M: Francisco Iglesias +S: Maintained +F: hw/net/can/xlnx-* +F: include/hw/net/xlnx-* +F: tests/qtest/xlnx-can-test* + EDU M: Jiri Slaby S: Maintained -- 2.7.4
[PATCH v8 3/4] tests/qtest: Introduce tests for Xilinx ZynqMP CAN controller
The QTests perform five tests on the Xilinx ZynqMP CAN controller:
Tests the CAN controller in loopback, sleep and snoop mode.
Tests filtering of incoming CAN messages.
Signed-off-by: Vikram Garhwal
---
tests/qtest/Makefile.include | 2 +
tests/qtest/xlnx-can-test.c | 359 +++
2 files changed, 361 insertions(+)
create mode 100644 tests/qtest/xlnx-can-test.c
diff --git a/tests/qtest/Makefile.include b/tests/qtest/Makefile.include
index b0204e4..ca0e652 100644
--- a/tests/qtest/Makefile.include
+++ b/tests/qtest/Makefile.include
@@ -138,6 +138,7 @@ check-qtest-aarch64-$(CONFIG_TPM_TIS_SYSBUS) +=
tpm-tis-device-swtpm-test
check-qtest-aarch64-y += numa-test
check-qtest-aarch64-y += boot-serial-test
check-qtest-aarch64-y += migration-test
+check-qtest-aarch64-y += xlnx-can-test
# TODO: once aarch64 TCG is fixed on ARM 32 bit host, make test unconditional
ifneq ($(ARCH),arm)
@@ -268,6 +269,7 @@ tests/qtest/bios-tables-test$(EXESUF):
tests/qtest/bios-tables-test.o \
tests/qtest/boot-sector.o tests/qtest/acpi-utils.o $(libqos-obj-y)
tests/qtest/pxe-test$(EXESUF): tests/qtest/pxe-test.o
tests/qtest/boot-sector.o $(libqos-obj-y)
tests/qtest/microbit-test$(EXESUF): tests/qtest/microbit-test.o
+tests/qtest/xlnx-can-test$(EXESUF): tests/qtest/xlnx-can-test.o
tests/qtest/m25p80-test$(EXESUF): tests/qtest/m25p80-test.o
tests/qtest/i440fx-test$(EXESUF): tests/qtest/i440fx-test.o $(libqos-pc-obj-y)
tests/qtest/q35-test$(EXESUF): tests/qtest/q35-test.o $(libqos-pc-obj-y)
diff --git a/tests/qtest/xlnx-can-test.c b/tests/qtest/xlnx-can-test.c
new file mode 100644
index 000..7a3c5b1
--- /dev/null
+++ b/tests/qtest/xlnx-can-test.c
@@ -0,0 +1,359 @@
+/*
+ * QTests for the Xilinx ZynqMP CAN controller.
+ *
+ * Copyright (c) 2020 Xilinx Inc.
+ *
+ * Written-by: Vikram Garhwal
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "libqtest.h"
+
+/* Base address. */
+#define CAN0_BASE_ADDR 0xFF06
+#define CAN1_BASE_ADDR 0xFF07
+
+/* Register addresses. */
+#define R_SRR_OFFSET0x00
+#define R_MSR_OFFSET0x04
+#define R_SR_OFFSET 0x18
+#define R_ISR_OFFSET0x1C
+#define R_ICR_OFFSET0x24
+#define R_TXID_OFFSET 0x30
+#define R_TXDLC_OFFSET 0x34
+#define R_TXDATA1_OFFSET0x38
+#define R_TXDATA2_OFFSET0x3C
+#define R_RXID_OFFSET 0x50
+#define R_RXDLC_OFFSET 0x54
+#define R_RXDATA1_OFFSET0x58
+#define R_RXDATA2_OFFSET0x5C
+#define R_AFR 0x60
+#define R_AFMR1 0x64
+#define R_AFIR1 0x68
+#define R_AFMR2 0x6C
+#define R_AFIR2 0x70
+#define R_AFMR3 0x74
+#define R_AFIR3 0x78
+#define R_AFMR4 0x7C
+#define R_AFIR4 0x80
+
+/* CAN modes. */
+#define CONFIG_MODE 0x00
+#define NORMAL_MODE 0x00
+#define LOOPBACK_MODE 0x02
+#define SNOOP_MODE 0x04
+#define SLEEP_MODE 0x01
+#define ENABLE_CAN (1 << 1)
+#define STATUS_NORMAL_MODE (1 << 3)
+#define STATUS_LOOPBACK_MODE(1 << 1)
+#define STATUS_SNOOP_MODE (1 << 12)
+#define STATUS_SLEEP_MODE (1 << 2)
+#define ISR_TXOK(1 << 1)
+#define ISR_RXOK(1 << 4)
+
+static void match_rx_tx_data(uint32_t *buf_tx, uint32_t *buf_rx,
+ uint8_t can_timestamp)
+{
+uint16_t size = 0;
+uint8_t len = 4;
+
+while (size < len) {
+if (R_RXID_OFFSET + 4 * size == R_RXDLC_OFFSET) {
+g_assert_cmpint(buf_rx[size], ==, buf_tx[size] + can_timestamp);
+} else {
+g_assert_cmpint(buf_rx[size], ==, buf_tx[size]);
+}
+
+size++;
+}
+}
+
+static void read_data(QTestState *qts, uint6
[PATCH v8 2/4] xlnx-zynqmp: Connect Xilinx ZynqMP CAN controllers
Connect CAN0 and CAN1 on the ZynqMP.
Signed-off-by: Vikram Garhwal
---
hw/arm/xlnx-zcu102.c | 20
hw/arm/xlnx-zynqmp.c | 34 ++
include/hw/arm/xlnx-zynqmp.h | 8
3 files changed, 62 insertions(+)
diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index 5997262..c3e3420 100644
--- a/hw/arm/xlnx-zcu102.c
+++ b/hw/arm/xlnx-zcu102.c
@@ -24,6 +24,7 @@
#include "qemu/log.h"
#include "sysemu/qtest.h"
#include "sysemu/device_tree.h"
+#include "net/can_emu.h"
typedef struct XlnxZCU102 {
MachineState parent_obj;
@@ -33,6 +34,8 @@ typedef struct XlnxZCU102 {
bool secure;
bool virt;
+CanBusState *canbus[XLNX_ZYNQMP_NUM_CAN];
+
struct arm_boot_info binfo;
} XlnxZCU102;
@@ -125,6 +128,14 @@ static void xlnx_zcu102_init(MachineState *machine)
object_property_set_bool(OBJECT(&s->soc), "virtualization", s->virt,
&error_fatal);
+for (i = 0; i < XLNX_ZYNQMP_NUM_CAN; i++) {
+gchar *bus_name = g_strdup_printf("canbus%d", i);
+
+object_property_set_link(OBJECT(&s->soc), bus_name,
+ OBJECT(s->canbus[i]), &error_fatal);
+g_free(bus_name);
+}
+
qdev_realize(DEVICE(&s->soc), NULL, &error_fatal);
/* Create and plug in the SD cards */
@@ -220,6 +231,15 @@ static void xlnx_zcu102_machine_instance_init(Object *obj)
"Set on/off to enable/disable emulating a "
"guest CPU which implements the ARM "
"Virtualization Extensions");
+object_property_add_link(obj, "xlnx-zcu102.canbus0", TYPE_CAN_BUS,
+ (Object **)&s->canbus[0],
+ object_property_allow_set_link,
+ 0);
+
+object_property_add_link(obj, "xlnx-zcu102.canbus1", TYPE_CAN_BUS,
+ (Object **)&s->canbus[1],
+ object_property_allow_set_link,
+ 0);
}
static void xlnx_zcu102_machine_class_init(ObjectClass *oc, void *data)
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index c435b9d..adad3e7 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -81,6 +81,14 @@ static const int uart_intr[XLNX_ZYNQMP_NUM_UARTS] = {
21, 22,
};
+static const uint64_t can_addr[XLNX_ZYNQMP_NUM_CAN] = {
+0xFF06, 0xFF07,
+};
+
+static const int can_intr[XLNX_ZYNQMP_NUM_CAN] = {
+23, 24,
+};
+
static const uint64_t sdhci_addr[XLNX_ZYNQMP_NUM_SDHCI] = {
0xFF16, 0xFF17,
};
@@ -243,6 +251,11 @@ static void xlnx_zynqmp_init(Object *obj)
TYPE_CADENCE_UART);
}
+for (i = 0; i < XLNX_ZYNQMP_NUM_CAN; i++) {
+object_initialize_child(obj, "can[*]", &s->can[i],
+TYPE_XLNX_ZYNQMP_CAN);
+}
+
object_initialize_child(obj, "sata", &s->sata, TYPE_SYSBUS_AHCI);
for (i = 0; i < XLNX_ZYNQMP_NUM_SDHCI; i++) {
@@ -480,6 +493,23 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error
**errp)
gic_spi[uart_intr[i]]);
}
+for (i = 0; i < XLNX_ZYNQMP_NUM_CAN; i++) {
+object_property_set_int(OBJECT(&s->can[i]), "ext_clk_freq",
+XLNX_ZYNQMP_CAN_REF_CLK, &error_abort);
+
+object_property_set_link(OBJECT(&s->can[i]), "canbus",
+ OBJECT(s->canbus[i]), &error_fatal);
+
+sysbus_realize(SYS_BUS_DEVICE(&s->can[i]), &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->can[i]), 0, can_addr[i]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->can[i]), 0,
+ gic_spi[can_intr[i]]);
+}
+
object_property_set_int(OBJECT(&s->sata), "num-ports", SATA_NUM_PORTS,
&error_abort);
if (!sysbus_realize(SYS_BUS_DEVICE(&s->sata), errp)) {
@@ -617,6 +647,10 @@ static Property xlnx_zynqmp_props[] = {
DEFINE_PROP_BOOL("has_rpu", XlnxZynqMPState, has_rpu, false),
DEFINE_PROP_LINK("ddr-ram", XlnxZynqMPState, ddr_ram, TYPE_MEMORY_REGION,
MemoryRegion *),
+DEFINE_PROP_LINK("canbus0", XlnxZynqMPState, canbus[0], TYPE_CAN_BUS,
+ CanBusState *),
+DEFINE_PROP_LINK("canbus1", XlnxZynqMPState, canbus[1], TYPE_CAN_BUS,
+ CanBusState *),
DEFINE_PROP_END_OF_LIST()
};
diff --git a/include/hw/arm/xlnx-zynqmp.h b/include/hw/arm/xlnx-zynqmp.h
index 53076fa..8cada69 100644
--- a/include/hw/arm/xlnx-zynqmp.h
+++ b/include/hw/arm/xlnx-zynqmp.h
@@ -22,6 +22,7 @@
#include "hw/intc/arm_gic.h"
#include "hw/net/cadence_gem.h"
#include "hw/char/cadence_uart.h"
+#include "hw/net/xlnx-zynqmp-can.h"
#include "hw/ide/ahci.h"
#include "hw/sd/sdhci.h"
#includ
Re: [PATCH] target/arm: Fix Rt/Rt2 in ESR_ELx for copro traps from AArch32 to 64
On 8/3/20 9:54 AM, Peter Maydell wrote:
> +case 14:
> +switch (mode) {
> +case ARM_CPU_MODE_USR:
> +case ARM_CPU_MODE_SYS:
> +return 14;
> +case ARM_CPU_MODE_HYP:
> +return 16;
Hyp uses LR_usr...
> +case ARM_CPU_MODE_IRQ:
> +return 18;
> +case ARM_CPU_MODE_SVC:
> +return 20;
> +case ARM_CPU_MODE_ABT:
> +return 22;
> +case ARM_CPU_MODE_UND:
> +return 24;
... making all of these off-by-2.
> +case ARM_CPU_MODE_FIQ:
> +return 30;
> +default:
> +g_assert_not_reached();
> +}
> +case 15:
> +return 31;
I don't see that R15 is mapped at all. Is this really reachable?
Otherwise it looks ok.
r~
Re: [PATCH 1/2] hw/core: Add bql_interrupt flag to CPUClass
On Sun, Aug 02, 2020 at 05:05:04PM +0100, Alex Bennée wrote:
>
> Eduardo Habkost writes:
>
> > On Fri, Jul 31, 2020 at 03:14:02PM -0400, Robert Foley wrote:
> >> On Fri, 31 Jul 2020 at 13:44, Eduardo Habkost wrote:
> >> > >
> >> > > +static inline void cpu_class_disable_bql_interrupt(CPUClass *cc)
> >> > > +{
> >> > > +cc->bql_interrupt = false;
> >> > > +}
> >> >
> >> > Class data is not supposed to change outside class_init. Why do
> >> > you need this function? I don't see it being used anywhere in
> >> > this series.
> >>
> >> This function was to be called from changes in a later patch series
> >> that depend on these changes. BTW, I added a correction above,
> >> it should be disable, not enable. The idea is that it is initialized to
> >> true,
> >> but then the per arch changes would use this call at init time to set
> >> it to false
> >> as needed.
> >
> > If you plan to call it from class_init, I don't think you need a
> > wrapper. You can simply set cc->bql_interrupt=false directly
> > inside arch-specific class_init functions.
>
> We just need to be careful of the ordering so the base class init goes
> first. Is that always the case?
Absolutely. Subclasses overriding class data previously
initialized by the base class is a very common pattern in QOM
code.
--
Eduardo
Re: [PULL 0/3] virtio,acpi: bugfixes
On Tue, Aug 04, 2020 at 10:17:01AM -0400, Michael S. Tsirkin wrote: > The following changes since commit 5c1c3e4f02e458cf280c677c817ae4fd1ed9bf10: > > Merge remote-tracking branch > 'remotes/pmaydell/tags/pull-target-arm-20200803' into staging (2020-08-03 > 20:34:26 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream > > for you to fetch changes up to 5957b49b423fe456896e10f7e4a6c69be07f9407: > > virtio-mem: Correct format specifier mismatch for RISC-V (2020-08-04 > 09:13:34 -0400) I dropped patches 1-2 and pushed a new tag. Pls apply, sorry about the noise! > > virtio,acpi: bugfixes > > A couple of last minute bugfixes. > > Signed-off-by: Michael S. Tsirkin > > > Bruce Rogers (1): > virtio-mem: Correct format specifier mismatch for RISC-V > > Michael S. Tsirkin (2): > i386/acpi: fix inconsistent QEMU/OVMF device paths > arm/acpi: fix an out of spec _UID for PCI root > > hw/arm/virt-acpi-build.c | 2 +- > hw/i386/acpi-build.c | 4 ++-- > hw/virtio/virtio-mem.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) >
Re: [RFC v2 1/1] memory: Delete assertion in memory_region_unregister_iommu_notifier
On Mon, Aug 03, 2020 at 06:00:34PM +0200, Eugenio Pérez wrote:
> On Fri, 2020-07-03 at 15:24 +0800, Jason Wang wrote:
> > On 2020/7/2 下午11:45, Peter Xu wrote:
> > > On Thu, Jul 02, 2020 at 11:01:54AM +0800, Jason Wang wrote:
> > > > So I think we agree that a new notifier is needed?
> > > Good to me, or a new flag should be easier (IOMMU_NOTIFIER_DEV_IOTLB)?
> >
> > That should work but I wonder something as following is better.
> >
> > Instead of introducing new flags, how about carry the type of event in
> > the notifier then the device (vhost) can choose the message it want to
> > process like:
> >
> > static vhost_iommu_event(IOMMUNotifier *n, IOMMUTLBEvent *event)
> >
> > {
> >
> > switch (event->type) {
> >
> > case IOMMU_MAP:
> > case IOMMU_UNMAP:
> > case IOMMU_DEV_IOTLB_UNMAP:
> > ...
> >
> > }
> >
> > Thanks
> >
> >
>
> Hi!
>
> Sorry, I thought I had this clear but now it seems not so clear to me. Do you
> mean to add that switch to the current
> vhost_iommu_unmap_notify, and then the "type" field to the IOMMUTLBEntry? Is
> that the scope of the changes, or there is
> something I'm missing?
>
> If that is correct, what is the advantage for vhost or other notifiers? I
> understand that move the IOMMUTLBEntry (addr,
> len) -> (iova, mask) split/transformation to the different notifiers
> implementation could pollute them, but this is even a deeper change and vhost
> is not insterested in other events but IOMMU_UNMAP, isn't?
>
> On the other hand, who decide what type of event is? If I follow the
> backtrace of the assert in
> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01015.html, it seems
> to me that it should be
> vtd_process_device_iotlb_desc. How do I know if it should be IOMMU_UNMAP or
> IOMMU_DEV_IOTLB_UNMAP? If I set it in some
> function of memory.c, I should decide the type looking the actual notifier,
> isn't?
(Since Jason didn't reply yesterday, I'll try to; Jason, feel free to correct
me...)
IMHO whether to put the type into the IOMMUTLBEntry is not important. The
important change should be that we introduce IOMMU_DEV_IOTLB_UNMAP (or I'd
rather call it IOMMU_DEV_IOTLB directly which is shorter and cleaner). With
that information we can make the failing assertion conditional for MAP/UNMAP
only. We can also allow dev-iotlb messages to take arbitrary addr_mask (so it
becomes a length of address range; imho we can keep using addr_mask for
simplicity, but we can comment for addr_mask that for dev-iotlb it can be not a
real mask).
Thanks,
--
Peter Xu
[Bug 1890310] Re: Segfault in artist.c:block_move
** Changed in: qemu Assignee: (unassigned) => Helge Deller (hdeller) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890310 Title: Segfault in artist.c:block_move Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf8100802 0xff5c651b7c5c writeq 0xf8100afb 0x25e EOF AddressSanitizer:DEADLYSIGNAL = ==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a54 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) ==12686==The signal is caused by a READ memory access. #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 #6 0x55af390ea866 in flatview_write /exec.c:3216:14 #7 0x55af390ea387 in address_space_write /exec.c:3308:18 #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x55af3c151261 in main /softmmu/main.c:49:5 #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move ==12686==ABORTING The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890310/+subscriptions
[Bug 1890312] Re: Segfault in artist_vram_read
** Changed in: qemu Assignee: (unassigned) => Helge Deller (hdeller) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890312 Title: Segfault in artist_vram_read Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writew 0xf8118001 0x105a readq 0xf900f8ff EOF = ==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90d0 T0) ==20118==The signal is caused by a READ memory access. #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #16 0x7fc7261ad897 in g_main_context_dispatch () #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 #21 0x55ec9decb911 in main /softmmu/main.c:49:5 The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890312/+subscriptions
[Bug 1890311] Re: Segfault in cpu_physical_memory_set_dirty_range on hppa + artist
** Changed in: qemu Assignee: (unassigned) => Helge Deller (hdeller) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890311 Title: Segfault in cpu_physical_memory_set_dirty_range on hppa + artist Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf810049f 0x85 writew 0xf8118001 0x14 writeq 0xf81005fb 0x5c6418001832 EOF AddressSanitizer:DEADLYSIGNAL = ==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb4 (pc 0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0) ==10793==The signal is caused by a READ memory access. #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13 #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9 #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x5577f4c04873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23 #6 0x5577f429a866 in flatview_write /exec.c:3216:14 #7 0x5577f429a387 in address_space_write /exec.c:3308:18 #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5 #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x5577f72c9474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f93ea531897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11 #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x5577f7301261 in main /softmmu/main.c:49:5 #21 0x7f93e90b7e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x5577f41a5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move ==10793==ABORTING The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890311/+subscriptions
[PATCH v2 for-5.1?] target/arm: Fix Rt/Rt2 in ESR_ELx for copro traps from AArch32 to 64
When a coprocessor instruction in an AArch32 guest traps to AArch32
Hyp mode, the syndrome register (HSR) includes Rt and Rt2 fields
which are simply copies of the Rt and Rt2 fields from the trapped
instruction. However, if the instruction is trapped from AArch32 to
an AArch64 higher exception level, the Rt and Rt2 fields in the
syndrome register (ESR_ELx) must be the AArch64 view of the register.
This makes a difference if the AArch32 guest was in a mode other than
User or System and it was using r13 or r14, or if it was in FIQ mode
and using r8-r14.
We don't know at translate time which AArch32 CPU mode we are in, so
we leave the values we generate in our prototype syndrome register
value at translate time as the raw Rt/Rt2 from the instruction, and
instead correct them to the AArch64 view when we find we need to take
an exception from AArch32 to AArch64 with one of these syndrome
values.
Fixes: https://bugs.launchpad.net/qemu/+bug/1879587
Reported-by: Julien Freche
Signed-off-by: Peter Maydell
---
Changes v1->v2: fixed the register mapping for LR (thanks to
Julien for testing v1, diagnosing the bug in it, and suggesting
the fix to LR handling)
Marc: Cc'd you just in case you're interested, given that I'd
expect running Linux aarch64 KVM in QEMU emulation with a 32-bit
guest to hit this bug...
---
target/arm/helper.c | 92 -
1 file changed, 91 insertions(+), 1 deletion(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 8ef0fb478f4..455c92b8915 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -9581,6 +9581,66 @@ static void arm_cpu_do_interrupt_aarch32(CPUState *cs)
take_aarch32_exception(env, new_mode, mask, offset, addr);
}
+static int aarch64_regnum(CPUARMState *env, int aarch32_reg)
+{
+/*
+ * Return the register number of the AArch64 view of the AArch32
+ * register @aarch32_reg. The CPUARMState CPSR is assumed to still
+ * be that of the AArch32 mode the exception came from.
+ */
+int mode = env->uncached_cpsr & CPSR_M;
+
+switch (aarch32_reg) {
+case 0 ... 7:
+return aarch32_reg;
+case 8 ... 12:
+return mode == ARM_CPU_MODE_FIQ ? aarch32_reg + 16 : aarch32_reg;
+case 13:
+switch (mode) {
+case ARM_CPU_MODE_USR:
+case ARM_CPU_MODE_SYS:
+return 13;
+case ARM_CPU_MODE_HYP:
+return 15;
+case ARM_CPU_MODE_IRQ:
+return 17;
+case ARM_CPU_MODE_SVC:
+return 19;
+case ARM_CPU_MODE_ABT:
+return 21;
+case ARM_CPU_MODE_UND:
+return 23;
+case ARM_CPU_MODE_FIQ:
+return 29;
+default:
+g_assert_not_reached();
+}
+case 14:
+switch (mode) {
+case ARM_CPU_MODE_USR:
+case ARM_CPU_MODE_SYS:
+case ARM_CPU_MODE_HYP:
+return 14;
+case ARM_CPU_MODE_IRQ:
+return 16;
+case ARM_CPU_MODE_SVC:
+return 18;
+case ARM_CPU_MODE_ABT:
+return 20;
+case ARM_CPU_MODE_UND:
+return 22;
+case ARM_CPU_MODE_FIQ:
+return 30;
+default:
+g_assert_not_reached();
+}
+case 15:
+return 31;
+default:
+g_assert_not_reached();
+}
+}
+
/* Handle exception entry to a target EL which is using AArch64 */
static void arm_cpu_do_interrupt_aarch64(CPUState *cs)
{
@@ -9591,6 +9651,7 @@ static void arm_cpu_do_interrupt_aarch64(CPUState *cs)
unsigned int new_mode = aarch64_pstate_mode(new_el, true);
unsigned int old_mode;
unsigned int cur_el = arm_current_el(env);
+int rt;
/*
* Note that new_el can never be 0. If cur_el is 0, then
@@ -9645,7 +9706,8 @@ static void arm_cpu_do_interrupt_aarch64(CPUState *cs)
case EXCP_HVC:
case EXCP_HYP_TRAP:
case EXCP_SMC:
-if (syn_get_ec(env->exception.syndrome) == EC_ADVSIMDFPACCESSTRAP) {
+switch (syn_get_ec(env->exception.syndrome)) {
+case EC_ADVSIMDFPACCESSTRAP:
/*
* QEMU internal FP/SIMD syndromes from AArch32 include the
* TA and coproc fields which are only exposed if the exception
@@ -9653,6 +9715,34 @@ static void arm_cpu_do_interrupt_aarch64(CPUState *cs)
* AArch64 format syndrome.
*/
env->exception.syndrome &= ~MAKE_64BIT_MASK(0, 20);
+break;
+case EC_CP14RTTRAP:
+case EC_CP15RTTRAP:
+case EC_CP14DTTRAP:
+/*
+ * For a trap on AArch32 MRC/MCR/LDC/STC the Rt field is currently
+ * the raw register field from the insn; when taking this to
+ * AArch64 we must convert it to the AArch64 view of the register
+ * number. Notice that we read a 4-bit AArch32 register number and
+ * write back a 5-bit AArch64 one.
+ */
+rt
[Bug 1718719] Re: qemu can't capture keys properly under wayland
** Changed in: xserver Status: Unknown => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1718719 Title: qemu can't capture keys properly under wayland Status in QEMU: New Status in XServer: New Status in qemu package in Ubuntu: Confirmed Status in xorg-server package in Ubuntu: Incomplete Bug description: This appears to be different than the previous similar bugs; patches do look to be applied to use libinput in the wayland case. Still: unknown keycodes `(unnamed)', please report to qemu-devel@nongnu.org I am using qemu-system-x86 1:2.10+dfsg-0ubuntu1 on artful. Many key inputs work correctly, but at boot the system will not properly catch the arrow keys, the above error shows up immediately after hitting Esc (for instance) to get to the boot menu. Booting from CD onto a daily Ubuntu desktop image, I can't navigate the splash menu. The same works correctly through virt-manager (which uses spice AFAICT, but wayland tends to crash when running virt-manager), and things work if I switch my session to Xorg rather than wayland. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1718719/+subscriptions
[Bug 1879587] Re: Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64
Whoops, yes. I somehow misread that table (I think I failed to spot that
there is no LR_hyp and it just shares r14 with usr/sys, so I did a
cut-n-paste of the SP cases to LR, which isn't right). I think your
adjustment to the patch is correct. I'll do a v2 patch for you to test,
but it will just be those fixes applied to v1.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879587
Title:
Register number in ESR is incorrect for certain banked registers when
switching from AA32 to AA64
Status in QEMU:
In Progress
Bug description:
I am running into a situation where I have:
- A hypervisor running in EL2, AA64
- A guest running in EL1, AA32
We trap certain accesses to special registers such as DACR (via
HCR.TVM). One instruction that is trapped is:
ee03ef10 ->mcr 15, 0, lr, cr3, cr0, {0}
The guest is running in SVC mode. So, LR should refer to LR_svc there.
LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However,
the actual ESR value is: 0xfe00dc0
If we decode the 'rt':
>>> (0xfe00dc0 >> 5) & 0x1f
14
My understanding is that 14 is incorrect in the context of AA64. rt
should be set to 18. The current mode being SVC, LR refers to LR_svc
not LR_usr. In other words, the mapping between registers in AA64 and
AA32 doesn't seem to be accounted for. I've tested this with Qemu
5.0.0
Let me know if that makes sense and if you would like more info. I am also
happy to test patches.
Thanks for all the great work on Qemu!
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879587/+subscriptions
[Bug 1890333] [NEW] Assertion failure in address_space_stw_le_cached through virtio-* devices
Public bug reported: Hello, Reproducer: cat << EOF | ./i386-softmmu/qemu-system-i386 \ -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ -device virtio-blk,drive=mydrive \ -nodefaults -qtest stdio -nographic outl 0xcf8 0x80001001 outl 0xcfc 0x6574c1ff outl 0xcf8 0x8000100e outl 0xcfc 0xefe5e1e outl 0xe86 0x3aff9090 outl 0xe84 0x3aff9090 outl 0xe8e 0xe EOF qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. Aborted I can trigger similar assertions with other VIRTIO devices, as-well. I reported this at some point in Message-ID: <20200511033001.dzvtbdhl3oz5p...@mozz.bu.edu> but never created a Launchpad issue... -Alex ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890333 Title: Assertion failure in address_space_stw_le_cached through virtio-* devices Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./i386-softmmu/qemu-system-i386 \ -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ -device virtio-blk,drive=mydrive \ -nodefaults -qtest stdio -nographic outl 0xcf8 0x80001001 outl 0xcfc 0x6574c1ff outl 0xcf8 0x8000100e outl 0xcfc 0xefe5e1e outl 0xe86 0x3aff9090 outl 0xe84 0x3aff9090 outl 0xe8e 0xe EOF qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. Aborted I can trigger similar assertions with other VIRTIO devices, as-well. I reported this at some point in Message-ID: <20200511033001.dzvtbdhl3oz5p...@mozz.bu.edu> but never created a Launchpad issue... -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890333/+subscriptions
[Bug 1879587] Re: Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64
Unfortunately, I won't be able to send the code or binary for the
hypervisor as of now (it will become available at some point in the
future though). I've done a bit of debugging on the QEMU code and it
seems like the approach you are taking works fine in general but the
register mapping code doesn't seem quite right. Applying this patch (on
top of yours):
>From e2182581dcdeedc2cb88cd21b88b4db744677737 Mon Sep 17 00:00:00 2001
From: Julien Freche
Date: Tue, 4 Aug 2020 11:54:49 -0700
Subject: [PATCH] Possible fix
---
target/arm/helper.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 60b80228fd..455c92b891 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -9619,17 +9619,16 @@ static int aarch64_regnum(CPUARMState *env, int
aarch32_reg)
switch (mode) {
case ARM_CPU_MODE_USR:
case ARM_CPU_MODE_SYS:
-return 14;
case ARM_CPU_MODE_HYP:
-return 16;
+return 14;
case ARM_CPU_MODE_IRQ:
-return 18;
+return 16;
case ARM_CPU_MODE_SVC:
-return 20;
+return 18;
case ARM_CPU_MODE_ABT:
-return 22;
+return 20;
case ARM_CPU_MODE_UND:
-return 24;
+return 22;
case ARM_CPU_MODE_FIQ:
return 30;
default:
--
2.28.0
Based on the ARM documentation, I would think that LR_svc maps to X18,
not X20. I fixed the ones that seemed wrong but I haven't check every
possible case so you may want to double check this. With the patch I was
able to boot Linux correctly.
Let me know if that makes sense
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879587
Title:
Register number in ESR is incorrect for certain banked registers when
switching from AA32 to AA64
Status in QEMU:
In Progress
Bug description:
I am running into a situation where I have:
- A hypervisor running in EL2, AA64
- A guest running in EL1, AA32
We trap certain accesses to special registers such as DACR (via
HCR.TVM). One instruction that is trapped is:
ee03ef10 ->mcr 15, 0, lr, cr3, cr0, {0}
The guest is running in SVC mode. So, LR should refer to LR_svc there.
LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However,
the actual ESR value is: 0xfe00dc0
If we decode the 'rt':
>>> (0xfe00dc0 >> 5) & 0x1f
14
My understanding is that 14 is incorrect in the context of AA64. rt
should be set to 18. The current mode being SVC, LR refers to LR_svc
not LR_usr. In other words, the mapping between registers in AA64 and
AA32 doesn't seem to be accounted for. I've tested this with Qemu
5.0.0
Let me know if that makes sense and if you would like more info. I am also
happy to test patches.
Thanks for all the great work on Qemu!
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879587/+subscriptions
Re: [PATCH-for-5.1] stubs: Fix notify-event stub linkage error on MinGW
On 8/4/20 8:22 PM, Philippe Mathieu-Daudé wrote:
> In commit e4d6d41ce2 we reduced the user-mode object list,
> but forgot to also change the notify.o stub in the next commit
> dc70f80fb2. This triggers a linker error while compiling the
> tests under MinGW:
>
> LINKtests/test-timed-average.exe
> libqemuutil.a(main-loop.o): In function `qemu_notify_event':
> util/main-loop.c:139: multiple definition of `qemu_notify_event'
>
> tests/test-timed-average.o:/builds/huth/qemu/tests/../stubs/notify-event.c:5:
> first defined here
> collect2: error: ld returned 1 exit status
> rules.mak:124: recipe for target 'tests/test-timed-average.exe' failed
>
> Correct by placing the stub object between the system emulation /
> tools guards.
>
> Fixes: dc70f80fb2 ("stubs/Makefile: Reduce the user-mode object list")
> Reported-by: Thomas Huth
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> stubs/Makefile.objs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> index d42046afe4..4e8605a609 100644
> --- a/stubs/Makefile.objs
> +++ b/stubs/Makefile.objs
> @@ -12,7 +12,6 @@ stub-obj-y += isa-bus.o
> stub-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
> stub-obj-$(CONFIG_LINUX_IO_URING) += io_uring.o
> stub-obj-y += monitor-core.o
> -stub-obj-y += notify-event.o
> stub-obj-y += pci-bus.o
> stub-obj-y += qmp_memory_device.o
> stub-obj-y += qtest.o
> @@ -45,6 +44,7 @@ stub-obj-y += iothread.o
> stub-obj-y += machine-init-done.o
> stub-obj-y += migr-blocker.o
> stub-obj-y += monitor.o
> +stub-obj-y += notify-event.o
> stub-obj-y += pci-host-piix.o
> stub-obj-y += ram-block.o
> stub-obj-y += replay-user.o
>
self-NACK, this doesn't work as expected =)
Re: [PULL 0/2] target-arm queue
On Tue, 4 Aug 2020 at 17:08, Peter Maydell wrote: > > Couple of last-minute things for rc3... > > -- PMM > > The following changes since commit d15532d91be177e7528310e0110e39f915779a99: > > Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20200804' into > staging (2020-08-04 11:53:20 +0100) > > are available in the Git repository at: > > https://git.linaro.org/people/pmaydell/qemu-arm.git > tags/pull-target-arm-20200804 > > for you to fetch changes up to d250bb19ced3b702c7c37731855f6876d0cc7995: > > target/arm: Fix decode of LDRA[AB] instructions (2020-08-04 16:40:19 +0100) > > > target-arm queue: > * Fix decode of LDRA[AB] instructions > * docs/devel: Document decodetree no-overlap groups > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1 for any user-visible changes. -- PMM
Re: [PATCH 11/11] dockerfiles/debian-win64-cross: Download WHPX MinGW headers
Am 04.08.20 um 19:00 schrieb Thomas Huth: > To compile-test the WHPX accelerator, we need to download these system > headers first (they are unfortunately not part of any released and > packaged MinGW toolchain yet). > > Idea taken from another patch by Stefan Weil. > > Signed-off-by: Thomas Huth > --- > tests/docker/dockerfiles/debian-win64-cross.docker | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/tests/docker/dockerfiles/debian-win64-cross.docker > b/tests/docker/dockerfiles/debian-win64-cross.docker > index 2fc9cfcbc6..4cc4a3f365 100644 > --- a/tests/docker/dockerfiles/debian-win64-cross.docker > +++ b/tests/docker/dockerfiles/debian-win64-cross.docker > @@ -32,7 +32,14 @@ RUN apt-get update && \ > mxe-$TARGET-w64-mingw32.shared-sdl2 \ > mxe-$TARGET-w64-mingw32.shared-sdl2-mixer \ > mxe-$TARGET-w64-mingw32.shared-sdl2-gfx \ > -mxe-$TARGET-w64-mingw32.shared-zlib > +mxe-$TARGET-w64-mingw32.shared-zlib \ > +curl && \ > +curl -s -S -o > /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvEmulation.h \ > + > "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvemulation.h?format=raw"; > && \ > +curl -s -S -o > /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvPlatform.h \ > + > "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatform.h?format=raw"; > && \ > +curl -s -S -o > /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/winhvplatformdefs.h \ > + > "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatformdefs.h?format=raw"; > > # Specify the cross prefix for this image (see tests/docker/common.rc) > ENV QEMU_CONFIGURE_OPTS --cross-prefix=x86_64-w64-mingw32.shared- I expect a build failure: Mingw-w64 decided to use lower case filenames, and those header files include each other. We need both lower case filenames (for Mingw-w64) and camel case filenames (for QEMU). That's why I used additional symlinks. Regards Stefan
Re: [PATCH-for-5.0 1/2] hw/acpi/piix4: Add 'system-hotplug-support' property
On 8/3/20 7:33 PM, Marcelo Tosatti wrote: > On Mon, Aug 03, 2020 at 07:10:11PM +0200, Philippe Mathieu-Daudé wrote: >> Hi Igor, Paolo. >> >> On 3/23/20 12:04 PM, Marcelo Tosatti wrote: >>> On Mon, Mar 23, 2020 at 09:05:06AM +0100, Paolo Bonzini wrote: On 22/03/20 17:27, Philippe Mathieu-Daudé wrote: >>> >> That 'ugly' is typically used within QEMU to deal with such things >> probably due to its low complexity. > > OK. Can you point me to the documentation for this feature? I can find > reference of GPE in the ICH9, but I can't find where this IO address on > the PIIX4 comes from: > > #define GPE_BASE 0xafe0 It's made up. The implementation is placed in PIIX4_PM because it is referenced by the ACPI tables. Real hardware would probably place this in the ACPI embedded controller or in the BMC. Paolo >>> >>> Yes, there was nothing at 0xafe0 at the time ACPI support was written. >>> >> >> Igor earlier said: >> "it's already pretty twisted code and adding one more knob >> to workaround other compat knobs makes it worse." >> >> Is that OK to rename this file "hw/acpi/piix4_twisted.c" and >> copy/paste the same content to "hw/acpi/piix4.c" but remove the >> non-PIIX4 code (GPE from ICH9)? >> >> This seems counterproductive from a maintenance PoV, but the PIIX4 bug >> (https://bugs.launchpad.net/qemu/+bug/1835865) is more than 1 year old >> now... >> >> If someone has a clever idea, I'm open to listen and implement it, but >> keeping ignoring this issue is not good. >> >> Note there is a similar issue with the LPC bus not existing on the >> PIIX, so maybe renaming this to something like "piix_virt.c" and having >> someone writing the specs (or differences with the physical datasheet) >> is not a such bad idea. >> >> Thanks, >> >> Phil. > > Make the port address architecture specific ? I find it worse than using a property set on the PC machine only (that would make the piix4 compiled for each target instead on only once in common-obj as now). But if Igor is OK with that, I don't mind much, let's move forward. Thanks, Phil.
Re: [PATCH 10/11] configure: Allow automatic WHPX detection
Am 04.08.20 um 19:00 schrieb Thomas Huth: > The whpx variable is currently initialized to "no" which causes the WHPX > check to skip the detection unless the user specified --enable-whpx. > Since the detection code should be able to figure it out correctly, let's > initialized the variable to "" on MinGW-builds for proper auto-detection > instead. > > Signed-off-by: Thomas Huth > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index 2acc4d1465..f44e428c91 100755 > --- a/configure > +++ b/configure > @@ -809,6 +809,7 @@ case $targetos in > MINGW32*) >mingw32="yes" >hax="yes" > + whpx="" >vhost_user="no" >audio_possible_drivers="dsound sdl" >if check_include dsound.h; then Reviewed-by: Stefan Weil
Re: cleanups with long-term benefits (was Re: [PATCH] schemas: Add vim modeline)
On 8/4/20 4:03 AM, Markus Armbruster wrote: The pain of tweaking the parser is likely dwarved several times over by the pain of the flag day. You mention this often; I wonder if I misunderstand the critique, because the pain of a "flag day" for a new file format seems negligible to me. I don't think we edit these .json files very often. Generally, we add a new command when we need one. The edits are usually one or two lines plus docstrings. If anyone has patches in-flight, I genuinely doubt it will take more than a few minutes to rewrite for the new file format. No?
[PATCH-for-5.1] stubs: Fix notify-event stub linkage error on MinGW
In commit e4d6d41ce2 we reduced the user-mode object list,
but forgot to also change the notify.o stub in the next commit
dc70f80fb2. This triggers a linker error while compiling the
tests under MinGW:
LINKtests/test-timed-average.exe
libqemuutil.a(main-loop.o): In function `qemu_notify_event':
util/main-loop.c:139: multiple definition of `qemu_notify_event'
tests/test-timed-average.o:/builds/huth/qemu/tests/../stubs/notify-event.c:5:
first defined here
collect2: error: ld returned 1 exit status
rules.mak:124: recipe for target 'tests/test-timed-average.exe' failed
Correct by placing the stub object between the system emulation /
tools guards.
Fixes: dc70f80fb2 ("stubs/Makefile: Reduce the user-mode object list")
Reported-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
---
stubs/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index d42046afe4..4e8605a609 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -12,7 +12,6 @@ stub-obj-y += isa-bus.o
stub-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
stub-obj-$(CONFIG_LINUX_IO_URING) += io_uring.o
stub-obj-y += monitor-core.o
-stub-obj-y += notify-event.o
stub-obj-y += pci-bus.o
stub-obj-y += qmp_memory_device.o
stub-obj-y += qtest.o
@@ -45,6 +44,7 @@ stub-obj-y += iothread.o
stub-obj-y += machine-init-done.o
stub-obj-y += migr-blocker.o
stub-obj-y += monitor.o
+stub-obj-y += notify-event.o
stub-obj-y += pci-host-piix.o
stub-obj-y += ram-block.o
stub-obj-y += replay-user.o
--
2.21.3
Re: [PATCH 08/11] stubs/notify-event: Mark qemu_notify_event() stub as "weak"
On 04/08/2020 19.50, Richard Henderson wrote: > On 8/4/20 10:00 AM, Thomas Huth wrote: >> Otherwise there is a linker error with MinGW while compiling the tests: >> >> LINKtests/test-timed-average.exe >> libqemuutil.a(main-loop.o): In function `qemu_notify_event': >> /builds/huth/qemu/util/main-loop.c:139: multiple definition of >> `qemu_notify_event' >> >> tests/test-timed-average.o:/builds/huth/qemu/tests/../stubs/notify-event.c:5: >> first defined here >> collect2: error: ld returned 1 exit status >> /builds/huth/qemu/rules.mak:124: recipe for target >> 'tests/test-timed-average.exe' failed >> >> Signed-off-by: Thomas Huth >> --- >> stubs/notify-event.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > That doesn't make sense. Since the symbol is satisfied from main-loop.c, it > should not be pulled in from libqemuutil.a. > > What's really happening here? Honestly, I don't have a clue. But since commit ebedb37c8d2aa4775, both the code from util/ and from stubs/ are put into the same library, libqemuutil.a, which is causing the trouble here, I guess. Maybe the linker pulled in the code from the stub first, then some other part used another function from util/main-loop.c which caused the linker to pull in main-loop.o, too, so that it finally found that there is a clash? ... but that's just a plain guess, of course. Paolo (as author of commit ebedb37c8d2), do you have an idea what might be going on here? Thomas
Re: [PATCH V1 00/32] Live Update
Hi folks, any questions or comments on the vfio and pci changes in patch 30? Or on the means of preserving anonymous memory and re-exec'ing in patches 14 - 21? - Steve On 7/30/2020 11:14 AM, Steve Sistare wrote: > Improve and extend the qemu functions that save and restore VM state so a > guest may be suspended and resumed with minimal pause time. qemu may be > updated to a new version in between. > > The first set of patches adds the cprsave and cprload commands to save and > restore VM state, and allow the host kernel to be updated and rebooted in > between. The VM must create guest RAM in a persistent shared memory file, > such as /dev/dax0.0 or persistant /dev/shm PKRAM as proposed in > https://lore.kernel.org/lkml/1588812129-8596-1-git-send-email-anthony.yzn...@oracle.com/ > > cprsave stops the VCPUs and saves VM device state in a simple file, and > thus supports any type of guest image and block device. The caller must > not modify the VM's block devices between cprsave and cprload. > > cprsave and cprload support guests with vfio devices if the caller first > suspends the guest by issuing guest-suspend-ram to the qemu guest agent. > The guest drivers suspend methods flush outstanding requests and re- > initialize the devices, and thus there is no device state to save and > restore. > >1 savevm: add vmstate handler iterators >2 savevm: VM handlers mode mask >3 savevm: QMP command for cprsave >4 savevm: HMP Command for cprsave >5 savevm: QMP command for cprload >6 savevm: HMP Command for cprload >7 savevm: QMP command for cprinfo >8 savevm: HMP command for cprinfo >9 savevm: prevent cprsave if memory is volatile > 10 kvmclock: restore paused KVM clock > 11 cpu: disable ticks when suspended > 12 vl: pause option > 13 gdbstub: gdb support for suspended state > > The next patches add a restart method that eliminates the persistent memory > constraint, and allows qemu to be updated across the restart, but does not > allow host reboot. Anonymous memory segments used by the guest are > preserved across a re-exec of qemu, mapped at the same VA, via a proposed > madvise(MADV_DOEXEC) option in the Linux kernel. See > https://lore.kernel.org/lkml/1595869887-23307-1-git-send-email-anthony.yzn...@oracle.com/ > > 14 savevm: VMS_RESTART and cprsave restart > 15 vl: QEMU_START_FREEZE env var > 16 oslib: add qemu_clr_cloexec > 17 util: env var helpers > 18 osdep: import MADV_DOEXEC > 19 memory: ram_block_add cosmetic changes > 20 vl: add helper to request re-exec > 21 exec, memory: exec(3) to restart > 22 char: qio_channel_socket_accept reuse fd > 23 char: save/restore chardev socket fds > 24 ui: save/restore vnc socket fds > 25 char: save/restore chardev pty fds > 26 monitor: save/restore QMP negotiation status > 27 vhost: reset vhost devices upon cprsave > 28 char: restore terminal on restart > > The next patches extend the restart method to save and restore vfio-pci > state, eliminating the requirement for a guest agent. The vfio container, > group, and device descriptors are preserved across the qemu re-exec. > > 29 pci: export pci_update_mappings > 30 vfio-pci: save and restore > 31 vfio-pci: trace pci config > 32 vfio-pci: improved tracing > > Here is an example of updating qemu from v4.2.0 to v4.2.1 using > "cprload restart". The software update is performed while the guest is > running to minimize downtime. > > window 1 | window 2 > | > # qemu-system-x86_64 ... | > QEMU 4.2.0 monitor - type 'help' ... | > (qemu) info status| > VM status: running| > | # yum update qemu > (qemu) cprsave /tmp/qemu.sav restart | > QEMU 4.2.1 monitor - type 'help' ... | > (qemu) info status| > VM status: paused (prelaunch) | > (qemu) cprload /tmp/qemu.sav | > (qemu) info status| > VM status: running| > > > Here is an example of updating the host kernel using "cprload reboot" > > window 1 | window 2 > | > # qemu-system-x86_64 ...mem-path=/dev/dax0.0 ...| > QEMU 4.2.1 monitor - type 'help' ... | > (qemu) info status| > VM status: running| > | # yum update kernel-uek > (qemu) cprsave /tmp/qemu.sav restart | > | > # systemctl kexec | > kexec_core: Starting new kernel | > ... | > | > # qemu-system-x86_64 ...mem-path=/dev/dax0.0 ...| > QEMU 4.2.1 monitor - type 'help' ... | > (qemu) info status
Re: qapi-schema esotera
On 8/4/20 1:33 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> On 8/3/20 1:25 PM, Eric Blake wrote:
>>> On 8/3/20 11:49 AM, John Snow wrote:
UNION is split into two primary forms:
1. Simple (No discriminator nor base)
2. Flat (Discriminator and base)
In expr.py, I notice that we modify the perceived type of the
'type' expression based on the two union forms.
1a. Simple unions allow Array[T]
1b. Flat unions disallow Array[T]
>>>
>>> Rather, branches in a simple unions are syntactic sugar for a
>>> wrapper struct that contains a single member 'data'; because of that
>>> extra nesting, the type of that single member is unconstrained. In
>>> flat unionw, the type MUST be a QAPI struct, because its members
>>> will be used inline; as currently coded, this prevents the use of an
>>> intrinsic type ('int', 'str') or an array type.
>>>
>>
>> I meant syntactically here, to be clear. I'm looking at expr.py -- if
>> there are deeper constraints on the semantics of the information
>> provided, that happens later.
>>
>> Specifically, check_union's use of check_type() changes depending on
>> the form of the union. One allows a string, the other allows a List of
>> strings, provided the list is precisely one element long.
>>
>>> If you need to use an array type in a flat union, you can't do:
>>>
>>> { 'union' ...
>>> 'data': { 'foo': [ 'MyBranch' ] } }
>>>
>>> but you can provide a wrapper type yourself:
>>>
>>> { 'struct': 'MyBranch', 'data': { 'array': [ 'MyType' ] } }
>>> { 'union' ...
>>> 'data': { 'foo': 'MyBranch' } }
>>>
From the docs:
Syntax:
UNION = { 'union': STRING,
'data': BRANCHES,
'*if': COND,
'*features': FEATURES }
| { 'union': STRING,
'data': BRANCHES,
'base': ( MEMBERS | STRING ),
'discriminator': STRING,
'*if': COND,
'*features': FEATURES }
BRANCHES = { BRANCH, ... }
BRANCH = STRING : TYPE-REF
| STRING : { 'type': TYPE-REF, '*if': COND }
Both arms use the same "BRANCHES" grammar production, which both
use TYPE-REF.
TYPE-REF = STRING | ARRAY-TYPE
ARRAY-TYPE = [ STRING ]
Implying that List[T] should be allowed for both productions.
Can I ask for a ruling from the judges?
>>>
>>> As you found, the docs are a bit misleading; the semantic constraint
>>> on flat union branches being a struct (because they will be inlined)
>>> prevents the use of type-refs that are valid in simple unions (where
>>> those simple types will be wrapped in an implicit struct). A patch
>>> to improve the docs would be a reasonable idea.
>>>
>>
>> Yes. I was working on a YAML prototype and I am trying to follow the
>> existing parser as closely as possible. In some cases, this highlights
>> differences between the grammar as advertised and what the parser
>> actually does.
>
> Please report all such differences, so we can fix them.
>
You have been the delightful beneficiary of all doubts thus far, I
promise. I am not aware of more discrepancies at the moment, but I
didn't finish my prototype, either.
>> If we are to keep the current state of things, splitting UNION into
>> two separate productions might be nice.
>
> It *is* two productions, joined with |.
>
I ... yes. Technically correct. I had meant separating them out even
further in the docs, which I suppose implies two top-level construct
names with how you have the grammar laid out.
I see you want to get rid of one of these productions, though, so don't
worry about this thought of mine. We can simplify in the other direction.
> The work unions really, really need is:
>
> * Eliminate the simple union sugar.
>
What do you mean by "simple union sugar"? Wait, before you answer, let
me make sure I have the nuances of the forms straight in my head.
The following is my attempt to summarize what I know about these forms.
(Please correct me where I am mistaken.)
ALTERNATE is like an untagged union with no discriminator/tag on the
wire. I think of a pure C union when I think of this form. The forms you
can use are limited, based on our ability to differentiate them upon
parsing.
SIMPLE UNION takes no `discriminator` or `base` parameter in the QAPI
specification. However, the wire format is not an undifferentiated union.
{ 'union': 'foobar',
'data': { 'a': 'TypeA',
'b': 'TypeB' } }
Enjoys life at runtime as:
{ "type": ['a' | 'b'],
"data": ... }
(with TypeA or TypeB's definition filling in for the ellipsis as denoted
by the type field.)
FLAT UNION has a more complex definitional form. It specifies a base
type reference by name *or* defined in-line. It also specifies a
discriminator, which must be an enumerated type in the base.
For data, it no longer allows you to
Re: [PATCH 11/11] dockerfiles/debian-win64-cross: Download WHPX MinGW headers
On 8/4/20 7:00 PM, Thomas Huth wrote: > To compile-test the WHPX accelerator, we need to download these system > headers first (they are unfortunately not part of any released and > packaged MinGW toolchain yet). > > Idea taken from another patch by Stefan Weil. > > Signed-off-by: Thomas Huth > --- > tests/docker/dockerfiles/debian-win64-cross.docker | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/tests/docker/dockerfiles/debian-win64-cross.docker > b/tests/docker/dockerfiles/debian-win64-cross.docker > index 2fc9cfcbc6..4cc4a3f365 100644 > --- a/tests/docker/dockerfiles/debian-win64-cross.docker > +++ b/tests/docker/dockerfiles/debian-win64-cross.docker > @@ -32,7 +32,14 @@ RUN apt-get update && \ > mxe-$TARGET-w64-mingw32.shared-sdl2 \ > mxe-$TARGET-w64-mingw32.shared-sdl2-mixer \ > mxe-$TARGET-w64-mingw32.shared-sdl2-gfx \ > -mxe-$TARGET-w64-mingw32.shared-zlib > +mxe-$TARGET-w64-mingw32.shared-zlib \ > +curl && \ > +curl -s -S -o > /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvEmulation.h \ > + > "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvemulation.h?format=raw"; > && \ > +curl -s -S -o > /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvPlatform.h \ > + > "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatform.h?format=raw"; > && \ > +curl -s -S -o > /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/winhvplatformdefs.h \ > + > "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatformdefs.h?format=raw"; Seems legally safer than my older approach =) https://www.mail-archive.com/qemu-devel@nongnu.org/msg645794.html > > # Specify the cross prefix for this image (see tests/docker/common.rc) > ENV QEMU_CONFIGURE_OPTS --cross-prefix=x86_64-w64-mingw32.shared- >
Re: [RFC PATCH 8/8] migration/dirtyrate: Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function which could be
> called
> by libvirt api.
>
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/Makefile.objs | 1 +
> migration/dirtyrate.c | 45 +
> qapi/migration.json | 24
> qapi/pragma.json| 3 ++-
> 4 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/migration/Makefile.objs b/migration/Makefile.objs
> index 0fc619e..12ae98c 100644
> --- a/migration/Makefile.objs
> +++ b/migration/Makefile.objs
> @@ -6,6 +6,7 @@ common-obj-y += qemu-file.o global_state.o
> common-obj-y += qemu-file-channel.o
> common-obj-y += xbzrle.o postcopy-ram.o
> common-obj-y += qjson.o
> +common-obj-y += dirtyrate.o
> common-obj-y += block-dirty-bitmap.o
> common-obj-y += multifd.o
> common-obj-y += multifd-zlib.o
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index d87e16d..5717521 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -31,6 +31,21 @@ CalculatingDirtyRateStage calculating_dirty_rate_stage =
> CAL_DIRTY_RATE_INIT;
> INTERNAL_RAMBLOCK_FOREACH(block) \
> if (!qemu_ram_is_migratable(block)) {} else
>
> +static int64_t get_dirty_rate_info(void)
> +{
> +int64_t dirty_rate = dirty_stat.dirty_rate;
> +/*
> + *Return dirty_rate only when we get CAL_DIRTY_RATE_END.
> + *And we must initial calculating_dirty_rate_stage.
> + */
> +if (calculating_dirty_rate_stage == CAL_DIRTY_RATE_END) {
> +calculating_dirty_rate_stage = CAL_DIRTY_RATE_INIT;
> +return dirty_rate;
I don't think a 'get' should change state - in particular I think we
should be able to call 'get' multiple times and get the result back.
Also, instead of just returning -1 you should probably give an error;
e.g. 'Still measuring' or 'not yet measured'
> +} else {
> +return -1;
> +}
> +}
> +
> static void reset_dirtyrate_stat(void)
> {
> dirty_stat.total_dirty_samples = 0;
> @@ -377,3 +392,33 @@ void *get_dirtyrate_thread(void *arg)
>
> return NULL;
> }
> +
> +void qmp_cal_dirty_rate(int64_t value, Error **errp)
> +{
> +static struct dirtyrate_config dirtyrate_config;
> +QemuThread thread;
> +
> +/*
> + * We don't begin calculating thread only when it's in calculating
> status.
> + */
> +if (calculating_dirty_rate_stage == CAL_DIRTY_RATE_ING) {
> +return;
> +}
> +
> +/*
> + * If we get CAL_DIRTY_RATE_END here, libvirtd may be restarted at last
> round,
> + * we need to initial it.
> + */
> +if (calculating_dirty_rate_stage == CAL_DIRTY_RATE_END)
> +calculating_dirty_rate_stage = CAL_DIRTY_RATE_INIT;
Note please run the patches through scripts/checkpatch.pl - you need
some {'s here and that script tells you about most of these things.
> +dirtyrate_config.sample_period_seconds = value;
Ah, this is where the config comes from - OK, I think you said there was
a max, so you should probably check that the maximum is sensible here
and give an error if it's not.
Dave
> +dirtyrate_config.sample_pages_per_gigabytes = sample_pages_per_gigabytes;
> +qemu_thread_create(&thread, "get_dirtyrate", get_dirtyrate_thread,
> + (void *)&dirtyrate_config, QEMU_THREAD_DETACHED);
> +}
> +
> +int64_t qmp_get_dirty_rate(Error **errp)
> +{
> +return get_dirty_rate_info();
> +}
> diff --git a/qapi/migration.json b/qapi/migration.json
> index d500055..59f35bb 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -1621,3 +1621,27 @@
> ##
> { 'event': 'UNPLUG_PRIMARY',
>'data': { 'device-id': 'str' } }
> +
> +##
> +# @cal_dirty_rate:
> +#
> +# start calculating dirty rate for vm
> +#
> +# @value: time for sample dirty pages
> +#
> +# Since: 5.1
> +#
> +# Example:
> +# {"command": "cal_dirty_rate", "data": {"value": 1} }
> +#
> +##
> +{ 'command': 'cal_dirty_rate', 'data': {'value': 'int64'} }
I'm OK with abbreviating 'calculate' but prefer calc.
> +##
> +# @get_dirty_rate:
> +#
> +# get dirty rate for vm
> +#
> +# Since: 5.1
> +##
> +{ 'command': 'get_dirty_rate', 'returns': 'int64' }
> diff --git a/qapi/pragma.json b/qapi/pragma.json
> index cffae27..ecd294b 100644
> --- a/qapi/pragma.json
> +++ b/qapi/pragma.json
> @@ -10,7 +10,8 @@
> 'query-migrate-cache-size',
> 'query-tpm-models',
> 'query-tpm-types',
> -'ringbuf-read' ],
> +'ringbuf-read',
> +'get_dirty_rate' ],
> 'name-case-whitelist': [
> 'ACPISlotType', # DIMM, visible through
> query-acpi-ospm-status
> 'CpuInfoMIPS', # PC, visible through query-cpu
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [RFC PATCH 7/8] migration/dirtyrate: Implement calculate_dirtyrate() function
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Implement calculate_dirtyrate() function.
>
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/dirtyrate.c | 53
> +--
> 1 file changed, 47 insertions(+), 6 deletions(-)
>
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 00abfa7..d87e16d 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -161,6 +161,21 @@ alloc_block_dirty_info(int *block_index,
> return block_dinfo;
> }
>
> +static void free_block_dirty_info(struct block_dirty_info *infos, int count)
> +{
> +int i;
> +
> +if (!infos) {
> +return;
> +}
> +
> +for (i = 0; i < count; i++) {
> +g_free(infos[i].sample_page_vfn);
> +g_free(infos[i].hash_result);
> +}
> +g_free(infos);
> +}
> +
> static int ram_block_skip(RAMBlock *block)
> {
> if (!strstr(qemu_ram_get_idstr(block), "ram-node") &&
> @@ -278,12 +293,6 @@ static int compare_block_hash_info(struct
> block_dirty_info *info, int block_inde
> return 0;
> }
>
> -
> -static void calculate_dirtyrate(struct dirtyrate_config config, int64_t time)
> -{
> -/* todo */
> -}
Please move this function in the earlier patches so that it's only added
once rather than moved later.
> /*
> * There are multithread will write/read *calculating_dirty_rate_stage*,
> * we can protect only one thread write/read it by libvirt api.
> @@ -320,6 +329,38 @@ static int64_t get_sample_gap_period(struct
> dirtyrate_config config)
> return msec;
> }
>
> +static void calculate_dirtyrate(struct dirtyrate_config config, int64_t time)
> +{
> +struct block_dirty_info *block_dinfo = NULL;
> +int block_index = 0;
> +int64_t msec = time;
> +int64_t initial_time;
you might like to add some trace_ calls to make this easier to debug.
Dave
> +rcu_register_thread();
> +reset_dirtyrate_stat();
> +initial_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> +rcu_read_lock();
> +if (record_block_hash_info(config, &block_dinfo, &block_index) < 0) {
> +goto out;
> +}
> +rcu_read_unlock();
> +
> +msec = block_sample_gap_period(msec, initial_time);
> +
> +rcu_read_lock();
> +if (compare_block_hash_info(block_dinfo, block_index) < 0) {
> +goto out;
> +}
> +
> +update_dirtyrate(msec);
> +
> +out:
> +rcu_read_unlock();
> +free_block_dirty_info(block_dinfo, block_index + 1);
> +rcu_unregister_thread();
> +}
> +
> +
> void *get_dirtyrate_thread(void *arg)
> {
> struct dirtyrate_config config = *(struct dirtyrate_config *)arg;
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [RFC PATCH 6/8] migration/dirtyrate: Implement get_sample_gap_period() and block_sample_gap_period()
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Implement get_sample_gap_period() and block_sample_gap_period() to
> sleep specific time between sample actions.
>
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/dirtyrate.c | 28
> migration/dirtyrate.h | 6 +-
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 7badc53..00abfa7 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -295,10 +295,38 @@ static void
> set_dirty_rate_stage(CalculatingDirtyRateStage ratestage)
> calculating_dirty_rate_stage = ratestage;
> }
>
> +static int64_t block_sample_gap_period(int64_t msec, int64_t initial_time)
> +{
> +int64_t current_time;
> +
> +current_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> +if ((current_time - initial_time) >= msec) {
> +msec = current_time - initial_time;
> +} else {
> +g_usleep((msec + initial_time - current_time) * 1000);
> +}
OK, so I think this is for sleeping in your own thread?
Since it's bounded at about 60s that's not too bad
> +return msec;
> +}
> +
> +static int64_t get_sample_gap_period(struct dirtyrate_config config)
> +{
> +int64_t msec;
> +
> +msec = config.sample_period_seconds * 1000;
> +if (msec <= MIN_FETCH_DIRTYRATE_TIME_MSEC || msec >
> MAX_FETCH_DIRTYRATE_TIME_MSEC) {
> +msec = DEFAULT_FETCH_DIRTYRATE_TIME_MSEC;
> +}
> +return msec;
> +}
> +
> void *get_dirtyrate_thread(void *arg)
> {
> struct dirtyrate_config config = *(struct dirtyrate_config *)arg;
> int64_t msec = 0;
> +
> +/* max period is 60 seconds */
> +msec = get_sample_gap_period(config);
(I'm not sure I understood where the config was set?)
> set_dirty_rate_stage(CAL_DIRTY_RATE_ING);
>
> diff --git a/migration/dirtyrate.h b/migration/dirtyrate.h
> index 4d9b3b8..5aef2d7 100644
> --- a/migration/dirtyrate.h
> +++ b/migration/dirtyrate.h
> @@ -14,12 +14,16 @@
> #define QEMU_MIGRATION_DIRTYRATE_H
>
> /* take 256 pages per GB for cal dirty rate */
> -#define DIRTYRATE_DEFAULT_SAMPLE_PAGES256
> +#define DIRTYRATE_DEFAULT_SAMPLE_PAGES 256
Not for this patch.
> #define DIRTYRATE_SAMPLE_PAGE_SIZE 4096
> #define DIRTYRATE_PAGE_SIZE_SHIFT 12
> #define BLOCK_INFO_MAX_LEN 256
> #define PAGE_SIZE_SHIFT 20
>
> +#define MIN_FETCH_DIRTYRATE_TIME_MSEC0
> +#define MAX_FETCH_DIRTYRATE_TIME_MSEC6
> +#define DEFAULT_FETCH_DIRTYRATE_TIME_MSEC1000
> +
> struct dirtyrate_config {
> uint64_t sample_pages_per_gigabytes;
> int64_t sample_period_seconds;
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH 06/11] tests/Makefile: Add $(EXESUF) to fp-test target
On 8/4/20 7:00 PM, Thomas Huth wrote: > In case we ever want to compile this for Windows, we need the $(EXESUF) > here. > > Signed-off-by: Thomas Huth > --- > tests/Makefile.include | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/Makefile.include b/tests/Makefile.include > index 2806e062d0..e2532e12e2 100644 > --- a/tests/Makefile.include > +++ b/tests/Makefile.include > @@ -687,7 +687,7 @@ check-report.tap: $(patsubst %,check-report-qtest-%.tap, > $(QTEST_TARGETS)) check > # generic Makefile expansions. Once we are cleanly passing all > # the tests we can simplify the make syntax. > > -FP_TEST_BIN=$(BUILD_DIR)/tests/fp/fp-test > +FP_TEST_BIN=$(BUILD_DIR)/tests/fp/fp-test$(EXESUF) > > # the build dir is created by configure > $(FP_TEST_BIN): config-host.h $(test-util-obj-y) > Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 08/11] stubs/notify-event: Mark qemu_notify_event() stub as "weak"
On 8/4/20 10:00 AM, Thomas Huth wrote: > Otherwise there is a linker error with MinGW while compiling the tests: > > LINKtests/test-timed-average.exe > libqemuutil.a(main-loop.o): In function `qemu_notify_event': > /builds/huth/qemu/util/main-loop.c:139: multiple definition of > `qemu_notify_event' > tests/test-timed-average.o:/builds/huth/qemu/tests/../stubs/notify-event.c:5: > first defined here > collect2: error: ld returned 1 exit status > /builds/huth/qemu/rules.mak:124: recipe for target > 'tests/test-timed-average.exe' failed > > Signed-off-by: Thomas Huth > --- > stubs/notify-event.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) That doesn't make sense. Since the symbol is satisfied from main-loop.c, it should not be pulled in from libqemuutil.a. What's really happening here? r~
Re: [PATCH 10/11] configure: Allow automatic WHPX detection
On 8/4/20 7:00 PM, Thomas Huth wrote: > The whpx variable is currently initialized to "no" which causes the WHPX > check to skip the detection unless the user specified --enable-whpx. > Since the detection code should be able to figure it out correctly, let's > initialized the variable to "" on MinGW-builds for proper auto-detection > instead. > > Signed-off-by: Thomas Huth > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index 2acc4d1465..f44e428c91 100755 > --- a/configure > +++ b/configure > @@ -809,6 +809,7 @@ case $targetos in > MINGW32*) >mingw32="yes" >hax="yes" > + whpx="" >vhost_user="no" >audio_possible_drivers="dsound sdl" >if check_include dsound.h; then > Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 07/11] Get rid of the libqemustub.a remainders
On 8/4/20 10:00 AM, Thomas Huth wrote:
> libqemustub.a has been removed in commit ebedb37c8d ("Makefile: Remove
> libqemustub.a"). Some remainders have been missed. Remove them now.
>
> Signed-off-by: Thomas Huth
> ---
> Makefile| 2 +-
> scripts/coverity-scan/run-coverity-scan | 3 ---
> tests/test-util-sockets.c | 3 ++-
> 3 files changed, 3 insertions(+), 5 deletions(-)
Reviewed-by: Richard Henderson
r~
Re: [PATCH 02/11] target/riscv/vector_helper: Fix build on 32-bit big endian targets
On 8/4/20 7:00 PM, Thomas Huth wrote:
> The code currently fails to compile on 32-bit big endian targets:
s/target/host/ here and in subject?
>
> target/riscv/vector_helper.c: In function 'vext_clear':
> target/riscv/vector_helper.c:154:16: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
> memset((void *)((uintptr_t)tail & ~(7ULL)), 0, part1);
> ^
> target/riscv/vector_helper.c:155:16: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
> memset((void *)(((uintptr_t)tail + 8) & ~(7ULL)), 0, part2);
> ^
> cc1: all warnings being treated as errors
>
> We should not use "long long" (i.e. 64-bit) values here to avoid the
> problem. Switch to our QEMU_ALIGN_PTR_DOWN/UP macros instead.
>
> Fixes: 751538d5da ("add vector stride load and store instructions")
> Suggested-by: Philippe Mathieu-Daudé
> Signed-off-by: Thomas Huth
> ---
> target/riscv/vector_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
> index 39f44d1029..793af99067 100644
> --- a/target/riscv/vector_helper.c
> +++ b/target/riscv/vector_helper.c
> @@ -151,8 +151,8 @@ static void vext_clear(void *tail, uint32_t cnt, uint32_t
> tot)
> if (cnt % 8) {
> part1 = 8 - (cnt % 8);
> part2 = tot - cnt - part1;
> -memset((void *)((uintptr_t)tail & ~(7ULL)), 0, part1);
> -memset((void *)(((uintptr_t)tail + 8) & ~(7ULL)), 0, part2);
> +memset(QEMU_ALIGN_PTR_DOWN(tail, 8), 0, part1);
> +memset(QEMU_ALIGN_PTR_UP(tail, 8), 0, part2);
> } else {
> memset(tail, 0, part2);
> }
>
Re: [PATCH 06/11] tests/Makefile: Add $(EXESUF) to fp-test target
On 8/4/20 10:00 AM, Thomas Huth wrote: > In case we ever want to compile this for Windows, we need the $(EXESUF) > here. > > Signed-off-by: Thomas Huth > --- > tests/Makefile.include | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [PATCH] trace/simple: Allow enabling simple traces from command line
On Aug 3, 2020, at 4:08 AM, Markus Armbruster wrote: > >> >> - prior to db25d56c014aa1a96319c663e0a60346a223b31e, just like today, >> QEMU built with simple tracing will always produce a trace- file, >> regardless of whether the user asks for traces at runtime. > > When you send a patch with a Fixes: tag, consider cc'ing people involved > in the commit being fixed. I might have spotted the regression. Sure, this makes sense. > I missed the CLI issue. I just wanted my directories not littered with > trace files ;) > > Stefan, what shall we do for 5.1? > > If we keep littering, the annoyance will make me drop the trace backend > "simple" from my build tests. I might even remember to put it back when > the fix arrives. I haven't seen another response, but I just noticed a 'last call' for 5.1. If this means something is going to get excluded from regular build tests, that seems important - I for one have no objection to simply reverting this - 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4 <-- my "fix." I will try to send a better fix along sometime soonish, but I probably won't get to that before 5.1. If the nuisance of the trace- files is causing real-world problems for someone actually doing regular development, that seems more important than the command line issue, to me. Just my $0.02. Cheers, and sorry if your build dirs do end up littered again.
Re: [PATCH 02/11] target/riscv/vector_helper: Fix build on 32-bit big endian targets
On 8/4/20 10:00 AM, Thomas Huth wrote:
> The code currently fails to compile on 32-bit big endian targets:
>
> target/riscv/vector_helper.c: In function 'vext_clear':
> target/riscv/vector_helper.c:154:16: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
> memset((void *)((uintptr_t)tail & ~(7ULL)), 0, part1);
> ^
> target/riscv/vector_helper.c:155:16: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
> memset((void *)(((uintptr_t)tail + 8) & ~(7ULL)), 0, part2);
> ^
> cc1: all warnings being treated as errors
>
> We should not use "long long" (i.e. 64-bit) values here to avoid the
> problem. Switch to our QEMU_ALIGN_PTR_DOWN/UP macros instead.
>
> Fixes: 751538d5da ("add vector stride load and store instructions")
> Suggested-by: Philippe Mathieu-Daudé
> Signed-off-by: Thomas Huth
> ---
> target/riscv/vector_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Richard Henderson
r~
Re: [RFC PATCH 5/8] migration/dirtyrate: Compare hash results for recorded ramblock
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Compare hash results for recorded ramblock.
>
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/dirtyrate.c | 77
> +++
> 1 file changed, 77 insertions(+)
>
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 45cfc91..7badc53 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -202,6 +202,83 @@ static int record_block_hash_info(struct
> dirtyrate_config config,
> return 0;
> }
>
> +static int cal_block_dirty_rate(struct block_dirty_info *info)
> +{
> +uint8_t *md = NULL;
> +size_t hash_len;
> +int i;
> +int ret = 0;
> +
> +hash_len = qcrypto_hash_digest_len(QCRYPTO_HASH_ALG_MD5);
> +md = g_new0(uint8_t, hash_len);
Is 'hash_len' actually constant for a given algorithm, like MD5 ?
i.e. can we just have a nice fixed size array?
> +for (i = 0; i < info->sample_pages_count; i++) {
> +ret = get_block_vfn_hash(info, info->sample_page_vfn[i], &md,
> &hash_len);
> +if (ret < 0) {
> +goto out;
> +}
> +
> +if (memcmp(md, info->hash_result + i * hash_len, hash_len) != 0) {
> +info->sample_dirty_count++;
When the page doesn't match, do we have to update info->hash_result with
the new hash? If the page is only modified once, and we catch it on
this cycle, we wouldn't want to catch it next time around.
> +}
> +}
> +
> +out:
> +g_free(md);
> +return ret;
> +}
> +
> +static bool find_block_matched(RAMBlock *block, struct block_dirty_info
> *infos,
> + int count, struct block_dirty_info **matched)
> +{
> +int i;
> +
> +for (i = 0; i < count; i++) {
> +if (!strcmp(infos[i].idstr, qemu_ram_get_idstr(block))) {
> +break;
> +}
> +}
> +
> +if (i == count) {
> +return false;
> +}
> +
> +if (infos[i].block_addr != qemu_ram_get_host_addr(block) ||
> +infos[i].block_pages !=
> +(qemu_ram_get_used_length(block) >> DIRTYRATE_PAGE_SIZE_SHIFT)) {
How does this happen?
> +return false;
> +}
> +
> +*matched = &infos[i];
> +return true;
> +}
> +
> +static int compare_block_hash_info(struct block_dirty_info *info, int
> block_index)
> +{
> +struct block_dirty_info *block_dinfo = NULL;
> +RAMBlock *block = NULL;
> +
> +RAMBLOCK_FOREACH_MIGRATABLE(block) {
> +if (ram_block_skip(block) < 0) {
> +continue;
> +}
> +block_dinfo = NULL;
> +if (!find_block_matched(block, info, block_index + 1, &block_dinfo))
> {
> +continue;
> +}
> +if (cal_block_dirty_rate(block_dinfo) < 0) {
> +return -1;
> +}
> +update_dirtyrate_stat(block_dinfo);
> +}
> +if (!dirty_stat.total_sample_count) {
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +
> static void calculate_dirtyrate(struct dirtyrate_config config, int64_t time)
> {
> /* todo */
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] target/arm: Fix decode of {LD,ST}RA[AB] instructions
On Tue, Aug 4, 2020 at 8:41 AM Richard Henderson wrote: > > On 8/3/20 5:21 PM, Peter Collingbourne wrote: > > On Mon, Aug 3, 2020 at 3:27 PM Peter Collingbourne wrote: > >> > >> These instructions use zero as the discriminator, not SP. > > > > Oh, there is no such thing as STRAA/STRAB. I must have been confused > > by the name of the function, disas_ldst_pac. I will send a v2 with a > > fixed commit message, and another patch to rename the function to > > disas_ld_pac. > > It's called decode_ldst_pac because the Arm ARM section is called "Load/store > register (pac)". Page C4-311 in the F.a revision. > > But yes, there are only loads defined in the section. I see. Arguably the ARM ARM section is misnamed then. There is a sibling section named "Load register (literal)", so there is precedent for naming a section after the types of instructions that are actually supported. I will send mail to err...@arm.com to see if the section can be renamed. Peter
Re: [PULL 0/3] virtio,acpi: bugfixes
On Tue, 4 Aug 2020 at 15:17, Michael S. Tsirkin wrote: > > The following changes since commit 5c1c3e4f02e458cf280c677c817ae4fd1ed9bf10: > > Merge remote-tracking branch > 'remotes/pmaydell/tags/pull-target-arm-20200803' into staging (2020-08-03 > 20:34:26 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream > > for you to fetch changes up to 5957b49b423fe456896e10f7e4a6c69be07f9407: > > virtio-mem: Correct format specifier mismatch for RISC-V (2020-08-04 > 09:13:34 -0400) > > > virtio,acpi: bugfixes > > A couple of last minute bugfixes. > > Signed-off-by: Michael S. Tsirkin > > > Bruce Rogers (1): > virtio-mem: Correct format specifier mismatch for RISC-V > > Michael S. Tsirkin (2): > i386/acpi: fix inconsistent QEMU/OVMF device paths > arm/acpi: fix an out of spec _UID for PCI root I applied your updated pull with just the virtio-mem fix. thanks -- PMM
Re: [PATCH 00/11] Run cross-compilation build tests in the gitlab-CI
On 04/08/2020 19.00, Thomas Huth wrote: > Now that we can use all our QEMU build containers in the gitlab-CI, > we can also run the cross-compilation jobs there. Of course, some > problems have to be fixed first, since apparently nobody was running > "make check-build" for QEMU for 32-bit big endian targets or MinGW > recently... > > As a bonus, the last two patches also enable WHPX builds with our > debian-win64-cross container, so that we can compile-test this accelerator > code now, too. I forgot to mention: A test run can be found here: https://gitlab.com/huth/qemu/-/pipelines/174203171 Thomas
[PATCH 11/11] dockerfiles/debian-win64-cross: Download WHPX MinGW headers
To compile-test the WHPX accelerator, we need to download these system headers first (they are unfortunately not part of any released and packaged MinGW toolchain yet). Idea taken from another patch by Stefan Weil. Signed-off-by: Thomas Huth --- tests/docker/dockerfiles/debian-win64-cross.docker | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/tests/docker/dockerfiles/debian-win64-cross.docker b/tests/docker/dockerfiles/debian-win64-cross.docker index 2fc9cfcbc6..4cc4a3f365 100644 --- a/tests/docker/dockerfiles/debian-win64-cross.docker +++ b/tests/docker/dockerfiles/debian-win64-cross.docker @@ -32,7 +32,14 @@ RUN apt-get update && \ mxe-$TARGET-w64-mingw32.shared-sdl2 \ mxe-$TARGET-w64-mingw32.shared-sdl2-mixer \ mxe-$TARGET-w64-mingw32.shared-sdl2-gfx \ -mxe-$TARGET-w64-mingw32.shared-zlib +mxe-$TARGET-w64-mingw32.shared-zlib \ +curl && \ +curl -s -S -o /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvEmulation.h \ + "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvemulation.h?format=raw"; && \ +curl -s -S -o /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/WinHvPlatform.h \ + "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatform.h?format=raw"; && \ +curl -s -S -o /usr/lib/mxe/usr/x86_64-w64-mingw32.shared/include/winhvplatformdefs.h \ + "https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/winhvplatformdefs.h?format=raw"; # Specify the cross prefix for this image (see tests/docker/common.rc) ENV QEMU_CONFIGURE_OPTS --cross-prefix=x86_64-w64-mingw32.shared- -- 2.18.1
[PATCH 09/11] gitlab-ci: Add cross-compiling build tests
Now that we can use all our QEMU test containers in the gitlab-CI, we can easily add some jobs that test cross-compilation for various architectures. There is just only small ugliness: Since the shared runners on gitlab.com are single-threaded, we have to split each compilation job into two parts (--disable-user and --disable-system), and exclude some additional targets, to avoid that the jobs are running too long and hitting the timeout of 1 h. Signed-off-by: Thomas Huth --- .gitlab-ci.d/crossbuilds.yml | 113 +++ .gitlab-ci.yml | 1 + MAINTAINERS | 1 + 3 files changed, 115 insertions(+) create mode 100644 .gitlab-ci.d/crossbuilds.yml diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml new file mode 100644 index 00..4ec7226b5c --- /dev/null +++ b/.gitlab-ci.d/crossbuilds.yml @@ -0,0 +1,113 @@ + +.cross_system_build_job_template: &cross_system_build_job_definition + stage: build + image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest + script: +- mkdir build +- cd build +- PKG_CONFIG_PATH=$PKG_CONFIG_PATH + ../configure --enable-werror $QEMU_CONFIGURE_OPTS --disable-user +--target-list-exclude="aarch64-softmmu i386-softmmu microblaze-softmmu + mips-softmmu mipsel-softmmu mips64-softmmu ppc64-softmmu sh4-softmmu + xtensa-softmmu" +- make -j$(expr $(nproc) + 1) all check-build + +.cross_user_build_job_template: &cross_user_build_job_definition + stage: build + image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest + script: +- mkdir build +- cd build +- PKG_CONFIG_PATH=$PKG_CONFIG_PATH + ../configure --enable-werror $QEMU_CONFIGURE_OPTS --disable-system +- make -j$(expr $(nproc) + 1) all check-build + +cross-armel-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-armel-cross + +cross-armel-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-armel-cross + +cross-armhf-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-armhf-cross + +cross-armhf-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-armhf-cross + +cross-arm64-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-arm64-cross + +cross-arm64-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-arm64-cross + +cross-mips-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-mips-cross + +cross-mips-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-mips-cross + +cross-mipsel-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-mipsel-cross + +cross-mipsel-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-mipsel-cross + +cross-mips64el-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-mips64el-cross + +cross-mips64el-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-mips64el-cross + +cross-ppc64el-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-ppc64el-cross + +cross-ppc64el-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-ppc64el-cross + +cross-s390x-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-s390x-cross + +cross-s390x-user: + <<: *cross_user_build_job_definition + variables: +IMAGE: debian-s390x-cross + +cross-win32-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-win32-cross + +cross-win64-system: + <<: *cross_system_build_job_definition + variables: +IMAGE: debian-win64-cross diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 362e5ee755..8f748237f8 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -18,6 +18,7 @@ include: - local: '/.gitlab-ci.d/edk2.yml' - local: '/.gitlab-ci.d/opensbi.yml' - local: '/.gitlab-ci.d/containers.yml' + - local: '/.gitlab-ci.d/crossbuilds.yml' .native_build_job_template: &native_build_job_definition stage: build diff --git a/MAINTAINERS b/MAINTAINERS index 0886eb3d2b..2731f7a594 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3067,6 +3067,7 @@ M: Alex Bennée R: Wainer dos Santos Moschetta S: Maintained F: .gitlab-ci.yml +F: .gitlab-ci.d/crossbuilds.yml Guest Test Compilation Support M: Alex Bennée -- 2.18.1
[PATCH 06/11] tests/Makefile: Add $(EXESUF) to fp-test target
In case we ever want to compile this for Windows, we need the $(EXESUF) here. Signed-off-by: Thomas Huth --- tests/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.include b/tests/Makefile.include index 2806e062d0..e2532e12e2 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -687,7 +687,7 @@ check-report.tap: $(patsubst %,check-report-qtest-%.tap, $(QTEST_TARGETS)) check # generic Makefile expansions. Once we are cleanly passing all # the tests we can simplify the make syntax. -FP_TEST_BIN=$(BUILD_DIR)/tests/fp/fp-test +FP_TEST_BIN=$(BUILD_DIR)/tests/fp/fp-test$(EXESUF) # the build dir is created by configure $(FP_TEST_BIN): config-host.h $(test-util-obj-y) -- 2.18.1
[PATCH 10/11] configure: Allow automatic WHPX detection
The whpx variable is currently initialized to "no" which causes the WHPX check to skip the detection unless the user specified --enable-whpx. Since the detection code should be able to figure it out correctly, let's initialized the variable to "" on MinGW-builds for proper auto-detection instead. Signed-off-by: Thomas Huth --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 2acc4d1465..f44e428c91 100755 --- a/configure +++ b/configure @@ -809,6 +809,7 @@ case $targetos in MINGW32*) mingw32="yes" hax="yes" + whpx="" vhost_user="no" audio_possible_drivers="dsound sdl" if check_include dsound.h; then -- 2.18.1
[PATCH 05/11] tests/Makefile: Only build usable targets during 'make check-build'
If the softmmu targets are not enabled, "make check-build" fails to build the qtests (which could not be run anyway without softmmu binary). And the softfloat tests can not be compiled with MinGW yet (the macro LITTLEENDIAN is re-defined in one of the system headers there, so this needs some work first before it can be compiled). Signed-off-by: Thomas Huth --- tests/Makefile.include | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.include b/tests/Makefile.include index 430119db74..2806e062d0 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -965,7 +965,10 @@ check-qtest: $(patsubst %,check-qtest-%, $(QTEST_TARGETS)) ifeq ($(CONFIG_TOOLS),y) check-block: $(patsubst %,check-%, $(check-block-y)) endif -check-build: build-unit build-softfloat build-qtest +check-build-y = build-unit +check-build-$(CONFIG_POSIX) += build-softfloat +check-build-$(CONFIG_SOFTMMU) += build-qtest +check-build: $(check-build-y) check-clean: rm -rf $(check-unit-y) tests/*.o tests/*/*.o $(QEMU_IOTESTS_HELPERS-y) -- 2.18.1
[PATCH 07/11] Get rid of the libqemustub.a remainders
libqemustub.a has been removed in commit ebedb37c8d ("Makefile: Remove
libqemustub.a"). Some remainders have been missed. Remove them now.
Signed-off-by: Thomas Huth
---
Makefile| 2 +-
scripts/coverity-scan/run-coverity-scan | 3 ---
tests/test-util-sockets.c | 3 ++-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index c2120d8d48..13dd708c4a 100644
--- a/Makefile
+++ b/Makefile
@@ -726,7 +726,7 @@ virtiofsd$(EXESUF): $(virtiofsd-obj-y) libvhost-user.a
$(COMMON_LDADDS)
$(call LINK, $^)
endif
-vhost-user-gpu$(EXESUF): $(vhost-user-gpu-obj-y) $(libvhost-user-obj-y)
libqemuutil.a libqemustub.a
+vhost-user-gpu$(EXESUF): $(vhost-user-gpu-obj-y) $(libvhost-user-obj-y)
libqemuutil.a
$(call LINK, $^)
ifdef CONFIG_VHOST_USER_INPUT
diff --git a/scripts/coverity-scan/run-coverity-scan
b/scripts/coverity-scan/run-coverity-scan
index 03a791dec9..6eefb4b558 100755
--- a/scripts/coverity-scan/run-coverity-scan
+++ b/scripts/coverity-scan/run-coverity-scan
@@ -403,9 +403,6 @@ echo "Configuring..."
--enable-mpath --enable-libxml2 --enable-glusterfs \
--enable-virtfs --enable-zstd
-echo "Making libqemustub.a..."
-make libqemustub.a
-
echo "Running cov-build..."
rm -rf cov-int
mkdir cov-int
diff --git a/tests/test-util-sockets.c b/tests/test-util-sockets.c
index 2ca1e99f17..261dc48c03 100644
--- a/tests/test-util-sockets.c
+++ b/tests/test-util-sockets.c
@@ -64,7 +64,8 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error
**errp)
return dup(mon_fd);
}
-/* Syms in libqemustub.a are discarded at .o file granularity.
+/*
+ * Syms of stubs in libqemuutil.a are discarded at .o file granularity.
* To replace monitor_get_fd() we must ensure everything in
* stubs/monitor.c is defined, to make sure monitor.o is discarded
* otherwise we get duplicate syms at link time.
--
2.18.1
[PATCH 03/11] tests/Makefile: test-image-locking needs CONFIG_POSIX
test-image-locking.c uses the qemu_lock_fd_test() function which is only available on POSIX-like systems. Reviewed-by: John Snow Signed-off-by: Thomas Huth --- tests/Makefile.include | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/Makefile.include b/tests/Makefile.include index c7e4646ded..1e5ca3b585 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -87,7 +87,9 @@ check-unit-$(CONFIG_BLOCK) += tests/test-blockjob$(EXESUF) check-unit-$(CONFIG_BLOCK) += tests/test-blockjob-txn$(EXESUF) check-unit-$(CONFIG_BLOCK) += tests/test-block-backend$(EXESUF) check-unit-$(CONFIG_BLOCK) += tests/test-block-iothread$(EXESUF) +ifeq ($(CONFIG_POSIX),y) check-unit-$(CONFIG_BLOCK) += tests/test-image-locking$(EXESUF) +endif check-unit-y += tests/test-x86-cpuid$(EXESUF) # all code tested by test-x86-cpuid is inside topology.h ifeq ($(CONFIG_SOFTMMU),y) -- 2.18.1
[PATCH 08/11] stubs/notify-event: Mark qemu_notify_event() stub as "weak"
Otherwise there is a linker error with MinGW while compiling the tests:
LINKtests/test-timed-average.exe
libqemuutil.a(main-loop.o): In function `qemu_notify_event':
/builds/huth/qemu/util/main-loop.c:139: multiple definition of
`qemu_notify_event'
tests/test-timed-average.o:/builds/huth/qemu/tests/../stubs/notify-event.c:5:
first defined here
collect2: error: ld returned 1 exit status
/builds/huth/qemu/rules.mak:124: recipe for target
'tests/test-timed-average.exe' failed
Signed-off-by: Thomas Huth
---
stubs/notify-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/stubs/notify-event.c b/stubs/notify-event.c
index 827bb52d1a..75d98f4a79 100644
--- a/stubs/notify-event.c
+++ b/stubs/notify-event.c
@@ -1,6 +1,6 @@
#include "qemu/osdep.h"
#include "qemu/main-loop.h"
-void qemu_notify_event(void)
+void __attribute__((weak)) qemu_notify_event(void)
{
}
--
2.18.1
[PATCH 02/11] target/riscv/vector_helper: Fix build on 32-bit big endian targets
The code currently fails to compile on 32-bit big endian targets:
target/riscv/vector_helper.c: In function 'vext_clear':
target/riscv/vector_helper.c:154:16: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
memset((void *)((uintptr_t)tail & ~(7ULL)), 0, part1);
^
target/riscv/vector_helper.c:155:16: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
memset((void *)(((uintptr_t)tail + 8) & ~(7ULL)), 0, part2);
^
cc1: all warnings being treated as errors
We should not use "long long" (i.e. 64-bit) values here to avoid the
problem. Switch to our QEMU_ALIGN_PTR_DOWN/UP macros instead.
Fixes: 751538d5da ("add vector stride load and store instructions")
Suggested-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
---
target/riscv/vector_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index 39f44d1029..793af99067 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -151,8 +151,8 @@ static void vext_clear(void *tail, uint32_t cnt, uint32_t
tot)
if (cnt % 8) {
part1 = 8 - (cnt % 8);
part2 = tot - cnt - part1;
-memset((void *)((uintptr_t)tail & ~(7ULL)), 0, part1);
-memset((void *)(((uintptr_t)tail + 8) & ~(7ULL)), 0, part2);
+memset(QEMU_ALIGN_PTR_DOWN(tail, 8), 0, part1);
+memset(QEMU_ALIGN_PTR_UP(tail, 8), 0, part2);
} else {
memset(tail, 0, part2);
}
--
2.18.1
[PATCH 00/11] Run cross-compilation build tests in the gitlab-CI
Now that we can use all our QEMU build containers in the gitlab-CI, we can also run the cross-compilation jobs there. Of course, some problems have to be fixed first, since apparently nobody was running "make check-build" for QEMU for 32-bit big endian targets or MinGW recently... As a bonus, the last two patches also enable WHPX builds with our debian-win64-cross container, so that we can compile-test this accelerator code now, too. Bruce Rogers (1): virtio-mem: Correct format specifier mismatch for RISC-V Thomas Huth (10): target/riscv/vector_helper: Fix build on 32-bit big endian targets tests/Makefile: test-image-locking needs CONFIG_POSIX tests/Makefile: test-replication needs CONFIG_POSIX tests/Makefile: Only build usable targets during 'make check-build' tests/Makefile: Add $(EXESUF) to fp-test target Get rid of the libqemustub.a remainders stubs/notify-event: Mark qemu_notify_event() stub as "weak" gitlab-ci: Add cross-compiling build tests configure: Allow automatic WHPX detection dockerfiles/debian-win64-cross: Download WHPX MinGW headers .gitlab-ci.d/crossbuilds.yml | 113 ++ .gitlab-ci.yml| 1 + MAINTAINERS | 1 + Makefile | 2 +- configure | 1 + hw/virtio/virtio-mem.c| 2 +- scripts/coverity-scan/run-coverity-scan | 3 - stubs/notify-event.c | 2 +- target/riscv/vector_helper.c | 4 +- tests/Makefile.include| 13 +- .../dockerfiles/debian-win64-cross.docker | 9 +- tests/test-util-sockets.c | 3 +- 12 files changed, 141 insertions(+), 13 deletions(-) create mode 100644 .gitlab-ci.d/crossbuilds.yml -- 2.18.1
[PATCH 01/11] virtio-mem: Correct format specifier mismatch for RISC-V
From: Bruce Rogers This likely affects other, less popular host architectures as well. Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of type uintptr, which isn't compatible with the format specifier used to print a user message. Since this particular usage of the underlying data seems unique to this file, the simple fix is to just cast QEMU_VMALLOC_ALIGN to uint32_t, which corresponds to the format specifier used. Signed-off-by: Bruce Rogers Message-Id: <20200730130519.168475-1-brog...@suse.com> Signed-off-by: Thomas Huth --- hw/virtio/virtio-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c index c12e9f79b0..7740fc613f 100644 --- a/hw/virtio/virtio-mem.c +++ b/hw/virtio/virtio-mem.c @@ -36,7 +36,7 @@ * Use QEMU_VMALLOC_ALIGN, so no THP will have to be split when unplugging * memory (e.g., 2MB on x86_64). */ -#define VIRTIO_MEM_MIN_BLOCK_SIZE QEMU_VMALLOC_ALIGN +#define VIRTIO_MEM_MIN_BLOCK_SIZE ((uint32_t)QEMU_VMALLOC_ALIGN) /* * Size the usable region bigger than the requested size if possible. Esp. * Linux guests will only add (aligned) memory blocks in case they fully -- 2.18.1
[PATCH 04/11] tests/Makefile: test-replication needs CONFIG_POSIX
test-replication uses sigaction() and friends which are only available on POSIX-like systems. Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Thomas Huth --- tests/Makefile.include | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.include b/tests/Makefile.include index 1e5ca3b585..430119db74 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -155,11 +155,13 @@ check-unit-$(CONFIG_BLOCK) += tests/test-crypto-afsplit$(EXESUF) check-unit-$(call land,$(CONFIG_BLOCK),$(CONFIG_QEMU_PRIVATE_XTS)) += tests/test-crypto-xts$(EXESUF) check-unit-$(CONFIG_BLOCK) += tests/test-crypto-block$(EXESUF) check-unit-y += tests/test-logging$(EXESUF) -check-unit-$(call land,$(CONFIG_BLOCK),$(CONFIG_REPLICATION)) += tests/test-replication$(EXESUF) check-unit-$(CONFIG_SOFTMMU) += tests/test-bufferiszero$(EXESUF) check-unit-y += tests/test-uuid$(EXESUF) check-unit-y += tests/ptimer-test$(EXESUF) check-unit-y += tests/test-qapi-util$(EXESUF) +ifeq ($(CONFIG_BLOCK)$(CONFIG_REPLICATION)$(CONFIG_POSIX),yyy) +check-unit-y += tests/test-replication$(EXESUF) +endif check-block-$(call land,$(CONFIG_POSIX),$(CONFIG_SOFTMMU)) += tests/check-block.sh -- 2.18.1
Re: [RFC PATCH 4/8] migration/dirtyrate: Record hash results for each ramblock
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Record hash results for each ramblock.
Please be careful when talking about 'ramblock' since we already use
that for a chunk of memory in QEMU.
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/dirtyrate.c | 157
> ++
> migration/dirtyrate.h | 1 +
> 2 files changed, 158 insertions(+)
>
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 6baf674..45cfc91 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -10,12 +10,27 @@
> * See the COPYING file in the top-level directory.
> */
>
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "crypto/hash.h"
> +#include "crypto/random.h"
> +#include "qemu/config-file.h"
> +#include "exec/memory.h"
> +#include "exec/ramblock.h"
> +#include "exec/target_page.h"
> +#include "qemu/rcu_queue.h"
> +#include "qapi/qapi-commands-migration.h"
> +#include "migration.h"
> #include "dirtyrate.h"
>
> static uint64_t sample_pages_per_gigabytes = DIRTYRATE_DEFAULT_SAMPLE_PAGES;
> static struct dirtyrate_statistics dirty_stat;
> CalculatingDirtyRateStage calculating_dirty_rate_stage = CAL_DIRTY_RATE_INIT;
>
> +#define RAMBLOCK_FOREACH_MIGRATABLE(block) \
> +INTERNAL_RAMBLOCK_FOREACH(block) \
> +if (!qemu_ram_is_migratable(block)) {} else
> +
Instead of redefining this here, please move the existing definition up
into migration/ram.h ?
> static void reset_dirtyrate_stat(void)
> {
> dirty_stat.total_dirty_samples = 0;
> @@ -44,6 +59,148 @@ static void update_dirtyrate(int64_t msec)
> dirty_stat.dirty_rate = dirty_rate;
> }
>
> +static int get_block_vfn_hash(struct block_dirty_info *info, unsigned long
> vfn,
> + uint8_t **md, size_t *hash_len)
> +{
> +struct iovec iov_array;
> +int ret = 0;
> +int nkey = 1;
> +
> +iov_array.iov_base = info->block_addr +
> + vfn * DIRTYRATE_SAMPLE_PAGE_SIZE;
> +iov_array.iov_len = DIRTYRATE_SAMPLE_PAGE_SIZE;
I'm a bit confused by how this is working; is 'vfn' an index
in SAMPLE_PAGE_SIZE's rather than individual pages? So this is
going to hash over something the size of a 'DIRTYRATE_SAMPLE_PAGE_SIZE'?
> +if (qcrypto_hash_bytesv(QCRYPTO_HASH_ALG_MD5,
> +&iov_array, nkey,
> +md, hash_len, NULL) < 0) {
> +ret = -1;
> +}
> +
> +return ret;
> +}
> +
> +static int save_block_hash(struct block_dirty_info *info)
> +{
> +unsigned long *rand_buf = NULL;
> +unsigned int sample_pages_count;
> +uint8_t *md = NULL;
> +size_t hash_len;
> +int i;
> +int ret = -1;
> +
> +sample_pages_count = info->sample_pages_count;
> +/* block size less than one page, return success to skip this block */
> +if (unlikely(info->block_pages == 0 || sample_pages_count == 0)) {
> +ret = 0;
> +goto out;
> +}
> +
> +/* use random bytes to pick sample page vfn */
> +rand_buf = g_malloc0_n(sample_pages_count, sizeof(unsigned long));
> +/* DEFAULT_READ_RANDOM_MAX_LIMIT 32M,
> + * can support 4T vm 1024 sample_pages_per_gigabytes
> + */
> +ret = qcrypto_random_bytes((unsigned char *)rand_buf,
> + sample_pages_count * sizeof(unsigned long),
> + NULL);
I think there may be a different way to do this without having to store
the rand_buf.
We already link to glib, and glib has a PRNG;
https://developer.gnome.org/glib/stable/glib-Random-Numbers.html
If you create a new prng is g_rand_new() at the start of day, and take a
copy with g_rand_copy(), then you can replay the sequence of random
numbers it generates without actually storing the sequence.
So g_rand_new(), g_rand_copy() and then before you traverse the set of
pages you go and take a copy again and use the copy; it'll give the same
sequence every time.
Note also, because you're allocating a potentially large array,
for this and the hash_result please use g_try_malloc0_n (or g_try_new0)
and fail properly if it returns NULL.
Note we have users with more than 4T of RAM in their VMs, although I
doubt in a single RAMBlock
> +if (ret) {
> +ret = -1;
> +goto out;
> +}
> +
> +hash_len = qcrypto_hash_digest_len(QCRYPTO_HASH_ALG_MD5);
> +info->hash_result = g_malloc0_n(sample_pages_count, sizeof(uint8_t) *
> hash_len);
> +info->sample_page_vfn = g_malloc0_n(sample_pages_count, sizeof(unsigned
> long));
> +
> +for (i = 0; i < sample_pages_count; i++) {
> +md = info->hash_result + i * hash_len;
> +info->sample_page_vfn[i] = rand_buf[i] % info->block_pages;
> +ret = get_block_vfn_hash(info, info->sample_page_vfn[i], &md,
> &hash_len);
> +if (ret < 0) {
> +goto out;
> +}
> +}
> +ret = 0;
Re: [PATCH 3/3] aio-posix: keep aio_notify_me disabled during polling
On 04/08/20 12:29, Stefan Hajnoczi wrote:
> On Tue, Aug 04, 2020 at 06:28:04AM +0100, Stefan Hajnoczi wrote:
>> @@ -597,15 +574,38 @@ bool aio_poll(AioContext *ctx, bool blocking)
>> * system call---a single round of run_poll_handlers_once suffices.
>> */
>> if (timeout || ctx->fdmon_ops->need_wait(ctx)) {
>> +/*
>> + * aio_notify can avoid the expensive event_notifier_set if
>> + * everything (file descriptors, bottom halves, timers) will
>> + * be re-evaluated before the next blocking poll(). This is
>> + * already true when aio_poll is called with blocking == false;
>> + * if blocking == true, it is only true after poll() returns,
>> + * so disable the optimization now.
>> + */
>> +if (timeout) {
>> +atomic_set(&ctx->notify_me, atomic_read(&ctx->notify_me) + 2);
>> +/*
>> + * Write ctx->notify_me before computing the timeout
>> + * (reading bottom half flags, etc.). Pairs with
>> + * smp_mb in aio_notify().
>> + */
>> +smp_mb();
>> +
>> +/* Check again in case a shorter timer was added */
>> +timeout = qemu_soonest_timeout(timeout,
>> aio_compute_timeout(ctx));
>> +}
>> +
>> ret = ctx->fdmon_ops->wait(ctx, &ready_list, timeout);
>> -}
>>
>> -if (blocking) {
>> -/* Finish the poll before clearing the flag. */
>> -atomic_store_release(&ctx->notify_me, atomic_read(&ctx->notify_me)
>> - 2);
>> -aio_notify_accept(ctx);
>> +if (timeout) {
>> +/* Finish the poll before clearing the flag. */
>> +atomic_store_release(&ctx->notify_me,
>> + atomic_read(&ctx->notify_me) - 2);
>> +}
>> }
>
> Hi Paolo,
> We can avoid calling aio_compute_timeout() like this, what do you think?
I don't understand :) except I guess you mean we can avoid the second
call. Can you post either a complete patch with this squashed, or a 4th
patch (whatever you think is best)?
Paolo
> bool use_notify_me = timeout != 0;
>
> if (use_notify_me) {
> atomic_set(&ctx->notify_me, atomic_read(&ctx->notify_me) + 2);
> /*
>* Write ctx->notify_me before computing the timeout
>* (reading bottom half flags, etc.). Pairs with
>* smp_mb in aio_notify().
>*/
> smp_mb();
>
> /* Don't block if aio_notify() was called */
> if (atomic_read(ctx->notified)) {
> timeout = 0;
> }
> }
>
> ret = ctx->fdmon_ops->wait(ctx, &ready_list, timeout);
>
> if (use_notify_me) {
> /* Finish the poll before clearing the flag. */
> atomic_store_release(&ctx->notify_me,
>atomic_read(&ctx->notify_me) - 2);
> }
>
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 3/8] migration/dirtyrate: Add dirtyrate statistics series functions
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Add dirtyrate statistics to record/update dirtyrate info.
>
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/dirtyrate.c | 47 ++-
> migration/dirtyrate.h | 11 +++
> 2 files changed, 41 insertions(+), 17 deletions(-)
>
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index fc652fb..6baf674 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -13,19 +13,41 @@
> #include "dirtyrate.h"
>
> static uint64_t sample_pages_per_gigabytes = DIRTYRATE_DEFAULT_SAMPLE_PAGES;
> -static uint64_t dirty_rate; /* MB/s */
> +static struct dirtyrate_statistics dirty_stat;
> CalculatingDirtyRateStage calculating_dirty_rate_stage = CAL_DIRTY_RATE_INIT;
>
> -static bool calculate_dirtyrate(struct dirtyrate_config config,
> -uint64_t *dirty_rate, int64_t time)
> +static void reset_dirtyrate_stat(void)
> {
> -/* todo */
> -return true;
> +dirty_stat.total_dirty_samples = 0;
> +dirty_stat.total_sample_count = 0;
> +dirty_stat.total_block_mem_MB = 0;
> +dirty_stat.dirty_rate = 0;
> +}
> +
> +static void update_dirtyrate_stat(struct block_dirty_info *info)
> +{
> +dirty_stat.total_dirty_samples += info->sample_dirty_count;
> +dirty_stat.total_sample_count += info->sample_pages_count;
> +dirty_stat.total_block_mem_MB += (info->block_pages <<
> DIRTYRATE_PAGE_SIZE_SHIFT) >> PAGE_SIZE_SHIFT;
> }
>
> -static void set_dirty_rate(uint64_t drate)
> +static void update_dirtyrate(int64_t msec)
> {
> -dirty_rate = drate;
> +uint64_t dirty_rate;
> +unsigned int total_dirty_samples = dirty_stat.total_dirty_samples;
> +unsigned int total_sample_count = dirty_stat.total_sample_count;
> +unsigned long total_block_mem_MB = dirty_stat.total_block_mem_MB;
> +
> +dirty_rate = total_dirty_samples * total_block_mem_MB *
> + 1000 / (total_sample_count * msec);
> +
> +dirty_stat.dirty_rate = dirty_rate;
> +}
> +
> +
> +static void calculate_dirtyrate(struct dirtyrate_config config, int64_t time)
> +{
> +/* todo */
> }
>
> /*
> @@ -42,21 +64,12 @@ static void
> set_dirty_rate_stage(CalculatingDirtyRateStage ratestage)
> void *get_dirtyrate_thread(void *arg)
> {
> struct dirtyrate_config config = *(struct dirtyrate_config *)arg;
> -uint64_t dirty_rate;
> -uint64_t hash_dirty_rate;
> -bool query_succ;
> int64_t msec = 0;
>
> set_dirty_rate_stage(CAL_DIRTY_RATE_ING);
>
> -query_succ = calculate_dirtyrate(config, &hash_dirty_rate, msec);
> -if (!query_succ) {
> -dirty_rate = 0;
> -} else {
> -dirty_rate = hash_dirty_rate;
> -}
All this was only just added; it might be easier to create the
update_dirtyrate function first.
> +calculate_dirtyrate(config, msec);
>
> -set_dirty_rate(dirty_rate);
> set_dirty_rate_stage(CAL_DIRTY_RATE_END);
>
> return NULL;
> diff --git a/migration/dirtyrate.h b/migration/dirtyrate.h
> index 342b89f..2994535 100644
> --- a/migration/dirtyrate.h
> +++ b/migration/dirtyrate.h
> @@ -15,6 +15,9 @@
>
> /* take 256 pages per GB for cal dirty rate */
> #define DIRTYRATE_DEFAULT_SAMPLE_PAGES256
> +#define DIRTYRATE_PAGE_SIZE_SHIFT 12
> +#define BLOCK_INFO_MAX_LEN 256
> +#define PAGE_SIZE_SHIFT 20
I think you might also have used one of these #define's in a previous
patch; so make sure the patches each compile in order.
Also, can you please comment each one of these - I was confused by a lot
of the calculations above because I don't quite understand what each of
these is.
I don't thinl 'BLOCK_INFO_MAX_LEN' is needed - becuase it's just a
RAMBlock ID, and you can link to the RAMBlock.
I'm not sure what DIRTYRATE_PAGE_SIZE_SHIFT is, or why it's different
from TARGET_PAGE_BITS.
>
> struct dirtyrate_config {
> uint64_t sample_pages_per_gigabytes;
> @@ -33,6 +36,14 @@ typedef enum {
> CAL_DIRTY_RATE_END = 2,
> } CalculatingDirtyRateStage;
>
> +struct dirtyrate_statistics {
> +unsigned int total_dirty_samples;
> +unsigned int total_sample_count;
> +unsigned long total_block_mem_MB;
'long' is normally a bad idea - we use it in a few places and it
was generally a bad idea; size_t for a size is much better.
> +int64_t dirty_rate;
Is this blocks/sec, MB/s what - please comment it.
Dave
> +};
> +
> +
> /*
> * Store dirtypage info for each block.
> */
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v3 4/8] hw/display/artist.c: fix out of bounds check
Hi Helge, Sven,
I think this patch introduces an issue:
cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \
-qtest stdio -accel qtest
writeq 0xf810049f 0x7ed7087fff0d
writew 0xf8118001 0x30fb
writew 0xf8118000 0x5bfb
writeq 0xf81005fb 0xd8d8d8d83d83d6
EOF
AddressSanitizer:DEADLYSIGNAL
=
==440==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc4f3c87fff (pc
0x55a0e0ef024f bp 0x7ffcf40a8740 sp 0x7ffcf40a7f00 T0)
==440==The signal is caused by a WRITE memory access.
#0 0x55a0e0ef024f in vram_bit_write /hw/display/artist.c:397:39
#1 0x55a0e0ee82ab in artist_reg_write /hw/display/artist.c:886:9
#2 0x55a0e05dc7a3 in memory_region_write_accessor /softmmu/memory.c:483:5
#3 0x55a0e05dbadc in access_with_adjusted_size /softmmu/memory.c:539:18
#4 0x55a0e05d9873 in memory_region_dispatch_write /softmmu/memory.c:1466:16
#5 0x55a0dfc87056 in flatview_write_continue /exec.c:3176:23
#6 0x55a0dfc6f866 in flatview_write /exec.c:3216:14
#7 0x55a0dfc6f387 in address_space_write /exec.c:3308:18
#8 0x55a0e0683604 in qtest_process_command /softmmu/qtest.c:452:13
#9 0x55a0e067ac08 in qtest_process_inbuf /softmmu/qtest.c:710:9
#10 0x55a0e0679895 in qtest_read /softmmu/qtest.c:722:5
#11 0x55a0e2b35c43 in qemu_chr_be_write_impl /chardev/char.c:188:9
#12 0x55a0e2b35dc7 in qemu_chr_be_write /chardev/char.c:200:9
#13 0x55a0e2b4a0b3 in fd_chr_read /chardev/char-fd.c:68:9
#14 0x55a0e2c9e474 in qio_channel_fd_source_dispatch
/io/channel-watch.c:84:12
#15 0x7fc52b5d3897 in g_main_context_dispatch
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
#16 0x55a0e309637b in glib_pollfds_poll /util/main-loop.c:217:9
#17 0x55a0e3093aab in os_host_main_loop_wait /util/main-loop.c:240:5
#18 0x55a0e3093444 in main_loop_wait /util/main-loop.c:516:11
#19 0x55a0e069bd00 in qemu_main_loop /softmmu/vl.c:1676:9
#20 0x55a0e2cd6261 in main /softmmu/main.c:49:5
#21 0x7fc52a159e0a in __libc_start_main
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
#22 0x55a0dfb7a729 in _start
(/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:397:39 in vram_bit_write
==440==ABORTING
I bisected it to this patch.
Thanks
-Alex
On 200804 1600, Helge Deller wrote:
> From: Sven Schnelle
>
> Fix the following runtime warning with artist framebuffer:
> "write outside bounds: wants 1256x1023, max size 1280x1024"
>
> Reviewed-by: Richard Henderson
> Signed-off-by: Sven Schnelle
> Signed-off-by: Helge Deller
> ---
> hw/display/artist.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index 6261bfe65b..de56200dbf 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -340,14 +340,13 @@ static void vram_bit_write(ARTISTState *s, int posx,
> int posy, bool incr_x,
> {
> struct vram_buffer *buf;
> uint32_t vram_bitmask = s->vram_bitmask;
> -int mask, i, pix_count, pix_length, offset, height, width;
> +int mask, i, pix_count, pix_length, offset, width;
> uint8_t *data8, *p;
>
> pix_count = vram_write_pix_per_transfer(s);
> pix_length = vram_pixel_length(s);
>
> buf = vram_write_buffer(s);
> -height = buf->height;
> width = buf->width;
>
> if (s->cmap_bm_access) {
> @@ -367,13 +366,6 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
> pix_count = size * 8;
> }
>
> -if (posy * width + posx + pix_count > buf->size) {
> -qemu_log("write outside bounds: wants %dx%d, max size %dx%d\n",
> - posx, posy, width, height);
> -return;
> -}
> -
> -
> switch (pix_length) {
> case 0:
> if (s->image_bitmap_op & 0x2000) {
> @@ -381,8 +373,11 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
> }
>
> for (i = 0; i < pix_count; i++) {
> -artist_rop8(s, p + offset + pix_count - 1 - i,
> -(data & 1) ? (s->plane_mask >> 24) : 0);
> +uint32_t off = offset + pix_count - 1 - i;
> +if (off < buf->size) {
> +artist_rop8(s, p + off,
> +(data & 1) ? (s->plane_mask >> 24) : 0);
> +}
> data >>= 1;
> }
> memory_region_set_dirty(&buf->mr, offset, pix_count);
> @@ -398,7 +393,10 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
> for (i = 3; i >= 0; i--) {
> if (!(s->image_bitmap_op & 0x2000) ||
> s->vram_bitmask & (1 << (28 + i))) {
> -artist_rop8(s, p + offset + 3 - i, data8[ROP8OFF(i)]);
> +uint32_t off =
Re: [PATCH v3 7/8] hw/display/artist: Refactor artist_rop8() to avoid buffer over-run
Hi Helge,
I applied this series and it fixes most of the problems I saw before.
I still see a few crashes - I made issues for them on launchpad:
https://bugs.launchpad.net/qemu/+bug/1890310
https://bugs.launchpad.net/qemu/+bug/1890311
https://bugs.launchpad.net/qemu/+bug/1890312
Thanks!
-Alex
On 200804 1600, Helge Deller wrote:
> From: Philippe Mathieu-Daudé
>
> Invalid I/O writes can craft an offset out of the vram_buffer range.
> Instead of passing an unsafe pointer to artist_rop8(), pass the vram_buffer
> and
> the offset. We can now check if the offset is in range before accessing it.
>
> We avoid:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> 284 *dst &= ~plane_mask;
> (gdb) bt
> #0 0x56367b2085c0 in artist_rop8 (s=0x56367d38b510, dst=0x7f9f972f
> , val=0 '\000') at
> hw/display/artist.c:284
> #1 0x56367b209325 in draw_line (s=0x56367d38b510, x1=-20480, y1=-1,
> x2=0, y2=17920, update_start=true, skip_pix=-1, max_pix=-1) at
> hw/display/artist.c:646
>
> Reported-by: LLVM libFuzzer
> Buglink: https://bugs.launchpad.net/qemu/+bug/1880326
> Signed-off-by: Philippe Mathieu-Daudé
> Signed-off-by: Helge Deller
> ---
> hw/display/artist.c | 40 +---
> 1 file changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/hw/display/artist.c b/hw/display/artist.c
> index a206afe641..47de17b9e9 100644
> --- a/hw/display/artist.c
> +++ b/hw/display/artist.c
> @@ -273,11 +273,20 @@ static artist_rop_t artist_get_op(ARTISTState *s)
> return (s->image_bitmap_op >> 8) & 0xf;
> }
>
> -static void artist_rop8(ARTISTState *s, uint8_t *dst, uint8_t val)
> +static void artist_rop8(ARTISTState *s, struct vram_buffer *buf,
> +int offset, uint8_t val)
> {
> -
> const artist_rop_t op = artist_get_op(s);
> -uint8_t plane_mask = s->plane_mask & 0xff;
> +uint8_t plane_mask;
> +uint8_t *dst;
> +
> +if (offset < 0 || offset >= buf->size) {
> +qemu_log_mask(LOG_GUEST_ERROR,
> + "rop8 offset:%d bufsize:%u\n", offset, buf->size);
> +return;
> +}
> +dst = buf->data + offset;
> +plane_mask = s->plane_mask & 0xff;
>
> switch (op) {
> case ARTIST_ROP_CLEAR:
> @@ -375,7 +384,7 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
> for (i = 0; i < pix_count; i++) {
> uint32_t off = offset + pix_count - 1 - i;
> if (off < buf->size) {
> -artist_rop8(s, p + off,
> +artist_rop8(s, buf, off,
> (data & 1) ? (s->plane_mask >> 24) : 0);
> }
> data >>= 1;
> @@ -395,7 +404,7 @@ static void vram_bit_write(ARTISTState *s, int posx, int
> posy, bool incr_x,
> s->vram_bitmask & (1 << (28 + i))) {
> uint32_t off = offset + 3 - i;
> if (off < buf->size) {
> -artist_rop8(s, p + off, data8[ROP8OFF(i)]);
> +artist_rop8(s, buf, off, data8[ROP8OFF(i)]);
> }
> }
> }
> @@ -424,10 +433,10 @@ static void vram_bit_write(ARTISTState *s, int posx,
> int posy, bool incr_x,
> if (!(s->image_bitmap_op & 0x2000) ||
> (vram_bitmask & mask)) {
> if (data & mask) {
> -artist_rop8(s, p + offset + i, s->fg_color);
> +artist_rop8(s, buf, offset + i, s->fg_color);
> } else {
> if (!(s->image_bitmap_op & 0x1002)) {
> -artist_rop8(s, p + offset + i, s->bg_color);
> +artist_rop8(s, buf, offset + i, s->bg_color);
> }
> }
> }
> @@ -505,7 +514,7 @@ static void block_move(ARTISTState *s, int source_x, int
> source_y, int dest_x,
> if (dst + column > buf->size || src + column > buf->size) {
> continue;
> }
> -artist_rop8(s, buf->data + dst + column, buf->data[src +
> column]);
> +artist_rop8(s, buf, dst + column, buf->data[src + column]);
> }
> }
>
> @@ -546,7 +555,7 @@ static void fill_window(ARTISTState *s, int startx, int
> starty,
> offset = y * s->width;
>
> for (x = startx; x < startx + width; x++) {
> -artist_rop8(s, buf->data + offset + x, color);
> +artist_rop8(s, buf, offset + x, color);
> }
> }
> artist_invalidate_lines(buf, starty, height);
> @@ -559,7 +568,6 @@ static void draw_line(ARTISTState *s, int x1, int y1, int
> x2, int y2,
> uint8_t color;
> int dx, dy, t, e, x, y, incy, diago, horiz;
> bool c1;
> -uint8_t *p;
>
> trace_artist_draw_line(x1, y1, x2, y2);
>
> @@ -628,16 +636,18 @@ static void draw_line(ARTISTState *s, int x1, int y1,
> int x2, int y2,
> color = artist_
Re: device compatibility interface for live migration with assigned devices
[sorry about not chiming in earlier]
On Wed, 29 Jul 2020 16:05:03 +0800
Yan Zhao wrote:
> On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
(...)
> > Based on the feedback we've received, the previously proposed interface
> > is not viable. I think there's agreement that the user needs to be
> > able to parse and interpret the version information. Using json seems
> > viable, but I don't know if it's the best option. Is there any
> > precedent of markup strings returned via sysfs we could follow?
I don't think encoding complex information in a sysfs file is a viable
approach. Quoting Documentation/filesystems/sysfs.rst:
"Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only one
value per file, so it is socially acceptable to express an array of
values of the same type.
Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon."
Even though this is an older file, I think these restrictions still
apply.
> I found some examples of using formatted string under /sys, mostly under
> tracing. maybe we can do a similar implementation.
>
> #cat /sys/kernel/debug/tracing/events/kvm/kvm_mmio/format
Note that this is *not* sysfs (anything under debug/ follows different
rules anyway!)
>
> name: kvm_mmio
> ID: 32
> format:
> field:unsigned short common_type; offset:0; size:2;
> signed:0;
> field:unsigned char common_flags; offset:2; size:1;
> signed:0;
> field:unsigned char common_preempt_count; offset:3;
> size:1; signed:0;
> field:int common_pid; offset:4; size:4; signed:1;
>
> field:u32 type; offset:8; size:4; signed:0;
> field:u32 len; offset:12; size:4; signed:0;
> field:u64 gpa; offset:16; size:8; signed:0;
> field:u64 val; offset:24; size:8; signed:0;
>
> print fmt: "mmio %s len %u gpa 0x%llx val 0x%llx",
> __print_symbolic(REC->type, { 0, "unsatisfied-read" }, { 1, "read" }, { 2,
> "write" }), REC->len, REC->gpa, REC->val
>
>
> #cat /sys/devices/pci:00/:00:02.0/uevent
'uevent' can probably be considered a special case, I would not really
want to copy it.
> DRIVER=vfio-pci
> PCI_CLASS=3
> PCI_ID=8086:591D
> PCI_SUBSYS_ID=8086:2212
> PCI_SLOT_NAME=:00:02.0
> MODALIAS=pci:v8086d591Dsv8086sd2212bc03sc00i00
>
(...)
> what about a migration_compatible attribute under device node like
> below?
>
> #cat /sys/bus/pci/devices/\:00\:02.0/UUID1/migration_compatible
> SELF:
> device_type=pci
> device_id=8086591d
> mdev_type=i915-GVTg_V5_2
> aggregator=1
> pv_mode="none+ppgtt+context"
> interface_version=3
> COMPATIBLE:
> device_type=pci
> device_id=8086591d
> mdev_type=i915-GVTg_V5_{val1:int:1,2,4,8}
> aggregator={val1}/2
> pv_mode={val2:string:"none+ppgtt","none+context","none+ppgtt+context"}
> interface_version={val3:int:2,3}
> COMPATIBLE:
> device_type=pci
> device_id=8086591d
> mdev_type=i915-GVTg_V5_{val1:int:1,2,4,8}
> aggregator={val1}/2
> pv_mode="" #"" meaning empty, could be absent in a compatible device
> interface_version=1
I'd consider anything of a comparable complexity to be a big no-no. If
anything, this needs to be split into individual files (with many of
them being vendor driver specific anyway.)
I think we can list compatible versions in a range/list format, though.
Something like
cat interface_version
2.1.3
cat interface_version_compatible
2.0.2-2.0.4,2.1.0-
(indicating that versions 2.0.{2,3,4} and all versions after 2.1.0 are
compatible, considering versions <2 and >2 incompatible by default)
Possible compatibility between different mdev types feels a bit odd to
me, and should not be included by default (only if it makes sense for a
particular vendor driver.)
[Bug 1890312] [NEW] Segfault in artist_vram_read
Public bug reported: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writew 0xf8118001 0x105a readq 0xf900f8ff EOF = ==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90d0 T0) ==20118==The signal is caused by a READ memory access. #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #16 0x7fc7261ad897 in g_main_context_dispatch () #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 #21 0x55ec9decb911 in main /softmmu/main.c:49:5 The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890312 Title: Segfault in artist_vram_read Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writew 0xf8118001 0x105a readq 0xf900f8ff EOF = ==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90d0 T0) ==20118==The signal is caused by a READ memory access. #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #16 0x7fc7261ad897 in g_main_context_dispatch () #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 #21 0x55ec9decb911 in main /softmmu/main.c:49:5 The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1890312/+subscriptions
[Bug 1890311] [NEW] Segfault in cpu_physical_memory_set_dirty_range on hppa + artist
Public bug reported: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf810049f 0x85 writew 0xf8118001 0x14 writeq 0xf81005fb 0x5c6418001832 EOF AddressSanitizer:DEADLYSIGNAL = ==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb4 (pc 0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0) ==10793==The signal is caused by a READ memory access. #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13 #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9 #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x5577f4c04873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23 #6 0x5577f429a866 in flatview_write /exec.c:3216:14 #7 0x5577f429a387 in address_space_write /exec.c:3308:18 #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5 #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x5577f72c9474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f93ea531897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11 #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x5577f7301261 in main /softmmu/main.c:49:5 #21 0x7f93e90b7e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x5577f41a5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move ==10793==ABORTING The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890311 Title: Segfault in cpu_physical_memory_set_dirty_range on hppa + artist Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf810049f 0x85 writew 0xf8118001 0x14 writeq 0xf81005fb 0x5c6418001832 EOF AddressSanitizer:DEADLYSIGNAL = ==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb4 (pc 0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0) ==10793==The signal is caused by a READ memory access. #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13 #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9 #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x5577f4c04873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23 #6 0x5577f429a866 in flatview_write /exec.c:3216:14 #7 0x5577f429a387 in address_space_write /exec.c:3308:18 #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5 #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x5577f72c9474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f93ea531897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11 #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x5577f7301261 in main /softmmu/main.c:49:5 #21 0x7f93e90b7e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x5577f41a5729
[Bug 1890310] [NEW] Segfault in artist.c:block_move
Public bug reported: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf8100802 0xff5c651b7c5c writeq 0xf8100afb 0x25e EOF AddressSanitizer:DEADLYSIGNAL = ==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a54 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) ==12686==The signal is caused by a READ memory access. #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 #6 0x55af390ea866 in flatview_write /exec.c:3216:14 #7 0x55af390ea387 in address_space_write /exec.c:3308:18 #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x55af3c151261 in main /softmmu/main.c:49:5 #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move ==12686==ABORTING The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> applied (I collected the above trace with the patch-set applied) Thanks -Alex ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1890310 Title: Segfault in artist.c:block_move Status in QEMU: New Bug description: Hello, Reproducer: cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ -qtest stdio -accel qtest writeq 0xf8100802 0xff5c651b7c5c writeq 0xf8100afb 0x25e EOF AddressSanitizer:DEADLYSIGNAL = ==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a54 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) ==12686==The signal is caused by a READ memory access. #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 #6 0x55af390ea866 in flatview_write /exec.c:3216:14 #7 0x55af390ea387 in address_space_write /exec.c:3308:18 #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 #20 0x55af3c151261 in main /softmmu/main.c:49:5 #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-sys
Re: [RFC PATCH 8/8] migration/dirtyrate: Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function
On 7/24/20 10:11 PM, Chuan Zheng wrote:
From: Zheng Chuan
Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function which could be
called
by libvirt api.
Signed-off-by: Zheng Chuan
Signed-off-by: YanYing Zhang
+##
+{ 'command': 'get_dirty_rate', 'returns': 'int64' }
diff --git a/qapi/pragma.json b/qapi/pragma.json
index cffae27..ecd294b 100644
--- a/qapi/pragma.json
+++ b/qapi/pragma.json
@@ -10,7 +10,8 @@
'query-migrate-cache-size',
'query-tpm-models',
'query-tpm-types',
-'ringbuf-read' ],
+'ringbuf-read',
+'get_dirty_rate' ],
Nack. You should not have to change the whitelist; this is evidence
that your command is returning the wrong type. Instead, you should be
using:
{ 'command': 'get-dirty-rate', 'returns': { 'rate': 'int64' } }
and populating a struct, so that if we ever want to return more than
just a single rate, we can extend the command in-place by adding to the
struct.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: [PATCH v2 4/4] gitlab-ci: Fix Avocado cache usage
On 04/08/2020 18.24, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> In commit 6957fd98dc ("gitlab: add avocado asset caching") we
>> tried to save the Avocado cache (as in commit c1073e44b4 with
>> Travis-CI) however it doesn't work as expected. For some reason
>> Avocado uses /root/avocado_cache/ which we can not select later.
>>
>> Manually generate a Avocado config to force the use of the
>> current job's directory.
>>
>> This patch is based on an earlier version from Philippe Mathieu-Daudé.
>
> Maybe add a Based-on: ?
Isn't that tag rather used for expressing dependencies between patch
series? See
https://wiki.qemu.org/Contribute/SubmitAPatch#Base_patches_against_current_git_master
?
>>
>> Signed-off-by: Thomas Huth
>> ---
>> .gitlab-ci.yml | 25 +++--
>> 1 file changed, 19 insertions(+), 6 deletions(-)
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index e96bcd50f8..9820066379 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -47,11 +47,24 @@ include:
>> - find . -type f -exec touch {} +
>> - make $MAKE_CHECK_ARGS
>>
>> -.post_acceptance_template: &post_acceptance
>> +.acceptance_template: &acceptance_definition
>> + cache:
>> +key: "${CI_JOB_NAME}-cache"
>> +paths:
>> + - ${CI_PROJECT_DIR}/avocado-cache
>> +policy: pull-push
>> + before_script:
>> +- mkdir -p ~/.config/avocado
>> +- echo "[datadir.paths]" > ~/.config/avocado/avocado.conf
>> +- echo "cache_dirs = ['${CI_PROJECT_DIR}/avocado-cache']"
>> + >> ~/.config/avocado/avocado.conf
>
> I was hoping there was a neater way to do this with the multiline
> commands but whatever:
I'm still fighting YAML syntax when it comes to such cases ... so I'm
open to suggestions!
> Reviewed-by: Alex Bennée
Thanks a lot!
Thomas
Re: [RFC PATCH 8/8] migration/dirtyrate: Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function
On 7/24/20 10:11 PM, Chuan Zheng wrote:
From: Zheng Chuan
Implement qmp_cal_dirty_rate()/qmp_get_dirty_rate() function which could be
called
by libvirt api.
Signed-off-by: Zheng Chuan
Signed-off-by: YanYing Zhang
---
+++ b/qapi/migration.json
@@ -1621,3 +1621,27 @@
##
{ 'event': 'UNPLUG_PRIMARY',
'data': { 'device-id': 'str' } }
+
+##
+# @cal_dirty_rate:
New QMP commands should be named favoring '-' over '_'; also, it doesn't
hurt to spell it out:
calculate-dirty-rate
+#
+# start calculating dirty rate for vm
+#
+# @value: time for sample dirty pages
In what unit?
+#
+# Since: 5.1
We've missed 5.1; this will need to be updated to 5.2.
+#
+# Example:
+# {"command": "cal_dirty_rate", "data": {"value": 1} }
+#
+##
+{ 'command': 'cal_dirty_rate', 'data': {'value': 'int64'} }
+
+##
+# @get_dirty_rate:
get-dirty-rate, except that we tend to use 'query-' as the prefix for
commands that read values.
+#
+# get dirty rate for vm
+#
+# Since: 5.1
5.2
What units is the rate expressed in?
+##
+{ 'command': 'get_dirty_rate', 'returns': 'int64' }
diff --git a/qapi/pragma.json b/qapi/pragma.json
index cffae27..ecd294b 100644
--- a/qapi/pragma.json
+++ b/qapi/pragma.json
@@ -10,7 +10,8 @@
'query-migrate-cache-size',
'query-tpm-models',
'query-tpm-types',
-'ringbuf-read' ],
+'ringbuf-read',
+'get_dirty_rate' ],
'name-case-whitelist': [
'ACPISlotType', # DIMM, visible through
query-acpi-ospm-status
'CpuInfoMIPS', # PC, visible through query-cpu
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Re: [RFC PATCH 2/8] migration/dirtyrate: Add block_dirty_info to store dirtypage info
* Chuan Zheng (zhengch...@huawei.com) wrote:
> From: Zheng Chuan
>
> Add block_dirty_info to store dirtypage info for each ramblock
>
> Signed-off-by: Zheng Chuan
> Signed-off-by: YanYing Zhang
> ---
> migration/dirtyrate.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/migration/dirtyrate.h b/migration/dirtyrate.h
> index 9a5c228..342b89f 100644
> --- a/migration/dirtyrate.h
> +++ b/migration/dirtyrate.h
> @@ -33,6 +33,19 @@ typedef enum {
> CAL_DIRTY_RATE_END = 2,
> } CalculatingDirtyRateStage;
>
> +/*
> + * Store dirtypage info for each block.
> + */
> +struct block_dirty_info {
Please call this ramblock_dirty_info; we use 'block' a lot to mean
disk block and it gets confusing.
> +char idstr[BLOCK_INFO_MAX_LEN];
Is there a reason you don't just use a RAMBlock * here?
> +uint8_t *block_addr;
> +unsigned long block_pages;
> +unsigned long *sample_page_vfn;
Please comment these; if I understand correctly, that's an array
of page indexes into the block generated from the random numbers
> +unsigned int sample_pages_count;
> +unsigned int sample_dirty_count;
> +uint8_t *hash_result;
If I understand, this is an array of hashes end-to-end for
all the pages in this RAMBlock?
Dave
> +};
> +
> void *get_dirtyrate_thread(void *arg);
> #endif
>
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2 4/4] gitlab-ci: Fix Avocado cache usage
Thomas Huth writes:
> In commit 6957fd98dc ("gitlab: add avocado asset caching") we
> tried to save the Avocado cache (as in commit c1073e44b4 with
> Travis-CI) however it doesn't work as expected. For some reason
> Avocado uses /root/avocado_cache/ which we can not select later.
>
> Manually generate a Avocado config to force the use of the
> current job's directory.
>
> This patch is based on an earlier version from Philippe Mathieu-Daudé.
Maybe add a Based-on: ?
>
> Signed-off-by: Thomas Huth
> ---
> .gitlab-ci.yml | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index e96bcd50f8..9820066379 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -47,11 +47,24 @@ include:
> - find . -type f -exec touch {} +
> - make $MAKE_CHECK_ARGS
>
> -.post_acceptance_template: &post_acceptance
> +.acceptance_template: &acceptance_definition
> + cache:
> +key: "${CI_JOB_NAME}-cache"
> +paths:
> + - ${CI_PROJECT_DIR}/avocado-cache
> +policy: pull-push
> + before_script:
> +- mkdir -p ~/.config/avocado
> +- echo "[datadir.paths]" > ~/.config/avocado/avocado.conf
> +- echo "cache_dirs = ['${CI_PROJECT_DIR}/avocado-cache']"
> + >> ~/.config/avocado/avocado.conf
I was hoping there was a neater way to do this with the multiline
commands but whatever:
Reviewed-by: Alex Bennée
--
Alex Bennée
