Re: [PATCH 3/3] target/i386/kvm: get and put AMD pmu registers

A little bit more information from kernel perspective. https://lkml.org/lkml/2022/10/31/476 I was kindly thinking of the same idea, but not sure if it is expected  from a bare-metal perspective, since the four legacy MSRs are always there. Also not sure if they are used by other

Re: [PATCH 2/3] i386: kvm: disable KVM_CAP_PMU_CAPABILITY if "pmu" is disabled

On 11/21/22 06:03, Greg Kurz wrote: On Sat, 19 Nov 2022 04:29:00 -0800 Dongli Zhang wrote: The "perf stat" at the VM side still works even we set "-cpu host,-pmu" in the QEMU command line. That is, neither "-cpu host,-pmu" nor "-cpu EPYC" could disable the pmu virtualization in an AMD

Re: [PATCH] target/i386/cpu: disable PERFCORE for AMD when cpu.pmu is off

Hey Vitaly, On 10/31/22 6:07 AM, Vitaly Kuznetsov wrote: Liang Yan writes: With cpu.pmu=off, perfctr_core could still be seen in an AMD guest cpuid. By further digging, I found cpu.perfctr_core did the trick. However, considering the 'enable_pmu' in KVM could work on both Intel and AMD, we

[PATCH] target/i386/cpu: disable PERFCORE for AMD when cpu.pmu is off

the property 'perfctr_ctr' and change the AMD PMU to off by default. Signed-off-by: Liang Yan --- target/i386/cpu.c | 4 1 file changed, 4 insertions(+) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 22b681ca37..edf5413c90 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c

Re: Deadlock between bdrv_drain_all_begin and prepare_mmio_access

On 8/2/22 08:35, Kevin Wolf wrote: Am 24.07.2022 um 23:41 hat Liang Yan geschrieben: Hello All, I am facing a lock situation between main-loop thread 1 and vcpu thread 4 when doing a qmp snapshot. QEMU is running on 6.0.x, checked the upstream code and did not see any big change since between

Deadlock between bdrv_drain_all_begin and prepare_mmio_access

Hello All, I am facing a lock situation between main-loop thread 1 and vcpu thread 4 when doing a qmp snapshot. QEMU is running on 6.0.x, checked the upstream code and did not see any big change since between. Guest is a Windows 10 VM. Unfortunately, I could not get into the windows vm or

Re: [PATCH v16 00/99] arm tcg/kvm refactor and split with kvm only support

Hi Alex, I am wondering the current status on this patch series. I have been working on it recently, I am wondering f you have a wip-git-repo,  I can send my patches there if not duplicated, otherwise I can resend the series here with a  new rebase and some fixes based on the comments. Let

Re: [PATCH v1 1/1] vfio: Make migration support non experimental by default.

On 7/14/21 6:19 AM, Kirti Wankhede wrote: > > > On 7/10/2021 1:14 PM, Claudio Fontana wrote: >> On 3/8/21 5:09 PM, Tarun Gupta wrote: >>> VFIO migration support in QEMU is experimental as of now, which was >>> done to >>> provide soak time and resolve concerns regarding bit-stream. >>> But, with

Re: [RFC][PATCH v2 1/3] hw/misc: Add implementation of ivshmem revision 2 device

A quick check by checkpatch.pl, pretty straightforward to fix. ERROR: return is not a function, parentheses are not required #211: FILE: hw/misc/ivshmem2.c:138: +return (ivs->features & (1 << feature)); ERROR: memory barrier without comment #255: FILE: hw/misc/ivshmem2.c:182: +smp_mb();

Re: [RFC][PATCH v2 3/3] contrib: Add server for ivshmem revision 2

A quick check by checkpatch.pl, pretty straightforward to fix. ERROR: memory barrier without comment #205: FILE: contrib/ivshmem2-server/ivshmem2-server.c:106: +smp_mb(); ERROR: spaces required around that '*' (ctx:VxV) #753: FILE: contrib/ivshmem2-server/main.c:22: +#define

Re: [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU

84301] virtio-ivshmem :00:04.0: backend failed! Tested-by: Liang Yan On 1/7/20 9:36 AM, Jan Kiszka wrote: > Overdue update of the ivshmem 2.0 device model as presented at [1]. > > Changes in v2: > - changed PCI device ID to Siemens-granted one, >adjusted PCI device revisi

Re: [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU

On 4/9/20 10:11 AM, Jan Kiszka wrote: > On 09.04.20 15:52, Liang Yan wrote: >> >> >> On 1/7/20 9:36 AM, Jan Kiszka wrote: >>> Overdue update of the ivshmem 2.0 device model as presented at [1]. >>> >>> Changes in v2: >>>   - changed P

Re: [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU

On 1/7/20 9:36 AM, Jan Kiszka wrote: > Overdue update of the ivshmem 2.0 device model as presented at [1]. > > Changes in v2: > - changed PCI device ID to Siemens-granted one, >adjusted PCI device revision to 0 > - removed unused feature register from device > - addressed feedback on

[Bug 1865626] Re: qemu hang when ipl boot from a mdev dasd

s390zp12:~ # cat test.sh /root/qemu/s390x-softmmu/qemu-system-s390x \ -machine s390-ccw-virtio,accel=kvm \ -nographic \ -bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \ -device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,devno=fe.0.1234,bootindex=1 \

[Bug 1865626] [NEW] qemu hang when ipl boot from a mdev dasd

Public bug reported: qemu latest kernel 5.3.18 I am using a passthrough dasd as boot device, the installment looks fine and gets into reboot process. However VM could not boot and just hang as below after that. I have been checking on "s390: vfio-ccw dasd ipl support" series right now but no

Re: [PATCH v4] target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none

On 2/3/20 8:54 AM, Peter Maydell wrote: > On Mon, 3 Feb 2020 at 13:44, Liang Yan wrote: >> >> Commit e19afd566781 mentioned that target-arm only supports queryable >> cpu models 'max', 'host', and the current type when KVM is in use. >> The logic works well un

[PATCH v4] target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none

) will terminate process. So We add a check above it. This won't affect i386 and s390x since they do not use current_cpu. Signed-off-by: Liang Yan --- v4: change code style based on the review from Andrew Jones v3: change git commit message v2: fix code style issue --- target/arm/monitor.c | 15

Re: [PATCH v3] target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none

On 2/3/20 8:08 AM, Andrew Jones wrote: > On Fri, Jan 31, 2020 at 10:46:49PM -0500, Liang Yan wrote: >> Commit e19afd56 mentioned that target-arm only supports queryable > > Please use more hexdigits. I'm not sure QEMU has a policy for that, > but I'd go with 12. > >&

[PATCH v3] target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none

) will terminate process. So We add a check above it. This won't affect i386 and s390x since they do not use current_cpu. Signed-off-by: Liang Yan --- v3: change git commit message v2: fix code style issue --- target/arm/monitor.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions

[PATCH v2] target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none

add a check above it. This won't affect i386 and s390x, because they are not invovled current_cpu. Signed-off-by: Liang Yan --- v2: fix code style issue --- target/arm/monitor.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/target/arm/monitor.c b/target/

[PATCH] target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine type none

add a check above it. This won't affect i386 and s390x, because they are not invovled current_cpu. Signed-off-by: Liang Yan --- target/arm/monitor.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/target/arm/monitor.c b/target/arm/monitor.c index 9725dff

Re: [PATCH v2 0/2] Add support for 2nd generation AMD EPYC processors

Kindly Ping. Just wondering if there are any plans for it. Best, Liang On 11/7/19 1:00 PM, Moger, Babu wrote: > The following series adds the support for 2nd generation AMD EPYC Processors > on qemu guests. The model display name for 2nd generation will be EPYC-Rome. > > Also fixes few missed

Re: [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU

On 11/11/19 7:57 AM, Jan Kiszka wrote: > To get the ball rolling after my presentation of the topic at KVM Forum > [1] and many fruitful discussions around it, this is a first concrete > code series. As discussed, I'm starting with the IVSHMEM implementation > of a QEMU device and server. It's

[Qemu-devel] [Bug 1815143] Re: qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4 not implemented

Confirmed the fix, thanks for the help. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815143 Title: qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4

[Qemu-devel] [Bug 1815143] Re: qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4 not implemented

A little bit confused here, I tired to bisect it from 2.10, but it was always good from this branch. then I went back to 2.9.1, it was always crashed. Machine type related? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1815143] Re: qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4 not implemented

Hi, Thomas, you are right, I am using 2.9.1, and it does look OK in 2.10. do you mind to point me which part of code fixed it? Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815143 Title:

[Qemu-devel] [Bug 1815143] [NEW] qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4 not implemented

Public bug reported: just wondering if TCG implements instruction prefix 0x7f4 server3:~ # zcat /boot/vmlinux-4.4.162-94.72-default.gz > /tmp/kernel --> starting qemu with kvm enabled works fine server3:~ # qemu-system-s390x -nographic -kernel /tmp/kernel -initrd /boot/initrd -enable-kvm

Re: [Qemu-devel] [Qemu-block] [PATCH] iotests: update qemu-iotests/082.out after 9cbef9d68ee

On 10/18/18 4:46 PM, Eric Blake wrote: > On 10/18/18 3:22 PM, Liang Yan wrote: >> qemu-img help output is changed after commit 9cbef9d68ee, this is a >> update for iotests. >> >> Signed-off-by: Liang Yan >> --- >>   tests/qemu-iotests/082.out | 956 +

[Qemu-devel] [PATCH] iotests: update qemu-iotests/082.out after 9cbef9d68ee

qemu-img help output is changed after commit 9cbef9d68ee, this is a update for iotests. Signed-off-by: Liang Yan --- tests/qemu-iotests/082.out | 956 ++--- 1 file changed, 478 insertions(+), 478 deletions(-) diff --git a/tests/qemu-iotests/082.out b/tests/qemu

[Qemu-devel] [Bug 1441443] Re: Is there a way to create a 10G network interface for VMs in KVM2.0?

Unless you are using SRIOV or DPDK which both need hardware support. If could support SRIOV, then using IOMMU+VFIO, and pass-through to VM, this will get a close number. Or DPDK, using a user-space driver + vhost-net, will also get a pretty good value. -- You received this bug notification

[Qemu-devel] [Bug 1736042] Re: qemu-system-x86_64 does not boot image reliably

This looks not a QEMU bug to me. You may drop "-curses" first, and run again. Once get inside, change grub file(/etc/default/grub) by uncomment GRUB_TERMINAL=console. It should work then. If still not, then blacklist vga16fb and add "fbcon=map:99 text" in grub command line. Remember to run

Re: [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events

This patch doesn't work here, my test environment actually broke, I am so sorry for the mess! Please just ignore it. On 11/2/17 1:40 PM, Daniel P. Berrange wrote: > On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote: >> On 2 November 2017 at 17:18, Liang Yan <l...@sus

Re: [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events

On 11/2/17 1:40 PM, Daniel P. Berrange wrote: > On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote: >> On 2 November 2017 at 17:18, Liang Yan <l...@suse.com> wrote: >>> New tigervnc changes the way to send long pressed key, >>> from "down up down

Re: [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events

Thanks for the reply. On 11/2/17 1:26 PM, Peter Maydell wrote: > On 2 November 2017 at 17:18, Liang Yan <l...@suse.com> wrote: >> New tigervnc changes the way to send long pressed key, >> from "down up down up ..." to "down down ... up", it only >&

[Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events

. This patch inserts an up event after each regular key down event to simulate an auto-repeat key event for xen keyboard frontend driver. Signed-off-by: Liang Yan <l...@suse.com> --- v2: - exclude extended key - change log comment hw/display/xenfb.c | 5 + 1 file changed, 5 insertions(+

[Qemu-devel] [PATCH] hw/display/xenfb: Simulate auto-repeat key events

New tigervnc server changes the way to send long pressed key, from "down up down up ..." to "down down ... up". So we insert an up event after each key down event to simulate auto-repeat key events for xen keyboard frontend driver. Signed-off-by: Liang Yan <l...@suse.com&g

Re: [Qemu-devel] [Bug 1721788] Re: Failed to get shared "write" lock with 'qemu-img info'

This does  not only affect qemu-img only, it could not make libvirt "" work either when two vms were running with share disk image.  Is there a workaround for this situation? Best, Liang On 10/6/17 10:30 AM, Daniel Berrange wrote: > I've just noticed, however, that '--force-share' appears

[Qemu-devel] [PATCH] chardev/baum: fix baum that releases brlapi twice

Error process of baum_chr_open needs to set brlapi null, so it won't get released twice in char_braille_finalize, which will cause "/usr/bin/qemu-system-x86_64: double free or corruption (!prev)" Signed-off-by: Liang Yan <l...@suse.com> --- chardev/baum.c | 1 + 1 file chan

[Qemu-devel] [PATCH v2] hw/display/xenfb.c: Add trace_xenfb_key_event

It may be better to add a trace event to monitor the last moment of a key event from QEMU to guest VM Signed-off-by: Liang Yan <l...@suse.com> --- hw/display/trace-events | 1 + hw/display/xenfb.c | 1 + 2 files changed, 2 insertions(+) diff --git a/hw/display/trace-events b/hw/d

[Qemu-devel] [PATCH] hw/display/xenfb.c: Add trace_xenfb_key_event

It may be better to add a trace event to monitor the last moment of a key event from QEMU to guest VM Signed-off-by: Liang Yan <l...@suse.com> --- hw/display/trace-events | 1 + hw/display/xenfb.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/hw/display/trace-events b/hw/d

Re: [Qemu-devel] [Bug 1686390] [NEW] vnc server closed socket after arrow "down" keyevent

On 4/26/17 9:12 AM, leon wrote: > Public bug reported: > > This is a rewrite for https://bugs.launchpad.net/qemu/+bug/1670377 > > QEMU 2.6 or later > tigervncviwer 1.6 > > Once get into grub boot interface(choose boot os, or recovery mode), > keep pressing arrow down button for couple times,

Re: [Qemu-devel] some error when compile qemu

On 03/15/2016 10:46 AM, Alex Bennée wrote: 高强 writes: Hi,alls I compile qemu on ubuntu 12.04,when "make",some error appears.the error: Start by ensuring you have all your build dependencies installed. On Ubuntu: apt-get build-dep qemu Yes, according to

Re: [Qemu-devel] [edk2] Could not add PCI device with big memory to aarch64 VMs

Hi, Laszlo, On 11/30/2015 06:45 PM, Laszlo Ersek wrote: On 12/01/15 01:46, liang yan wrote: Hello, Laszlo, On 11/30/2015 03:05 PM, Laszlo Ersek wrote: [snip] If you need more room (with large alignments), then there's no way around supporting QEMU's 64 bit aperture, VIRT_PCIE_MMIO_HIGH

Re: [Qemu-devel] Could not add PCI device with big memory to aarch64 VMs

On 11/04/2015 05:53 PM, Laszlo Ersek wrote: On 11/04/15 23:22, liang yan wrote: Hello, Laszlo, (2)It also has a problem that once I use a memory bigger than 256M for ivshmem, it could not get through UEFI, the error message is PciBus: Discovered PCI @ [00|01|00] BAR[0]: Type = Mem32

Re: [Qemu-devel] [edk2] Could not add PCI device with big memory to aarch64 VMs

Hello, Laszlo, On 11/30/2015 03:05 PM, Laszlo Ersek wrote: On 11/30/15 19:45, liang yan wrote: On 11/04/2015 05:53 PM, Laszlo Ersek wrote: On 11/04/15 23:22, liang yan wrote: Hello, Laszlo, (2)It also has a problem that once I use a memory bigger than 256M for ivshmem, it could not get

[Qemu-devel] Could not add PCI device with big memory to aarch64 VMs

Hello, Laszlo, (1)I am trying to add ivshmem device(PCI device with big memory) to my aarch64 vm. So far, I could find device information from vm. But it seems vm did not create correct resource file for this device. Do you have any idea that this happens? I used the upstream EDK2 to build

Re: [Qemu-devel] [PATCH v9 00/24] Generate ACPI v5.1 tables and expose them to guest over fw_cfg on ARM

Hello, Laszlo, On 10/10/15 00:34, liang yan wrote: >/Hello, Shannon,/ >/> From: Shannon Zhao <address@hidden>/ >/>/ >/> This patch series generate seven ACPI tables for machine virt on ARM./ >/> The set of generated tables are:/ >/> - RSDP/ >/&g

Re: [Qemu-devel] [PATCH v9 00/24] Generate ACPI v5.1 tables and expose them to guest over fw_cfg on ARM

Hello, Shannon, From: Shannon Zhao This patch series generate seven ACPI tables for machine virt on ARM. The set of generated tables are: - RSDP - RSDT - MADT - GTDT - FADT - DSDT - MCFG (For PCIe host bridge) These tables are created dynamically using the function of

Re: [Qemu-devel] Could not boot a guest vm from kvm mode based on APM X-Gene Host and latest qemu

On 09/16/2015 08:34 AM, Alex Bennée wrote: liang yan <lia...@hpe.com> writes: Hello, All, I am trying to enable kvm for a guest vm on an APM X-Gene Host with latest qemu, but could not make it work. The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1-arm64, Guest kernel is

Re: [Qemu-devel] Could not boot a guest vm from kvm mode based on APM X-Gene Host and latest qemu

On 09/16/2015 03:24 AM, Tushar Jagad wrote: Hi, On Mon, Sep 14, 2015 at 06:03:48PM -0600, liang yan wrote: Hello, All, I am trying to enable kvm for a guest vm on an APM X-Gene Host with latest qemu, but could not make it work. The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1

[Qemu-devel] Could not boot a guest vm from kvm mode based on APM X-Gene Host and latest qemu

Hello, All, I am trying to enable kvm for a guest vm on an APM X-Gene Host with latest qemu, but could not make it work. The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1-arm64, Guest kernel is linux-3.16rc3 QEMU is latest version Host has these dmesg info [2.708259] kvm [1]: