Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 5 -
hw/display/ramfb-stubs.c | 2 +-
hw/display/ramfb.c| 6 --
hw/vfio/display.c | 4 ++--
hw/vfio/pci.c | 2 ++
hw/vfio/pci.h | 1 +
include/hw/display/ramfb.h
el.org/all/20250617030521.2109305-1-shahu...@redhat.com/
v3: https://lore.kernel.org/all/20250609073408.2083831-1-shahu...@redhat.com/
v2: https://lore.kernel.org/all/20250606070234.2063451-1-shahu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Shaoqin
Move the TYPE_* to a new file hw/vfio/types.h because the
TYPE_VFIO_PCI will be used in later patch, but directly include the
hw/vfio/pci.h can cause some compilation error when cross build the
windows version.
The hw/vfio/types.h can be included to mitigate that problem.
Signed-off-by: Shaoqin
Auger
Signed-off-by: Shaoqin Huang
---
hw/core/machine.c | 2 ++
hw/display/ramfb-standalone.c | 2 +-
hw/i386/microvm.c | 3 +++
hw/i386/pc_piix.c | 10 ++
hw/i386/pc_q35.c | 3 +++
hw/vfio/pci.c | 2 +-
6 file
Auger
Signed-off-by: Shaoqin Huang
---
hw/core/machine.c | 2 ++
hw/display/ramfb-standalone.c | 2 +-
hw/i386/microvm.c | 3 +++
hw/i386/pc_piix.c | 10 ++
hw/i386/pc_q35.c | 3 +++
hw/vfio/pci.c | 2 +-
6 file
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 5 -
hw/display/ramfb-stubs.c | 2 +-
hw/display/ramfb.c| 6 --
hw/vfio/display.c | 4 ++--
hw/vfio/pci.c | 2 ++
hw/vfio/pci.h | 1 +
include/hw/display/ramfb.h
//lore.kernel.org/all/20250609073408.2083831-1-shahu...@redhat.com/
v2: https://lore.kernel.org/all/20250606070234.2063451-1-shahu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Shaoqin Huang (2):
ramfb: Add property to control if load the romfile
hw
Hi maintainers,
This is a kindly ping, could you help to review this patch series?
Thanks,
Shaoqin
On 7/4/25 11:03 AM, Shaoqin Huang wrote:
Currently the ramfb device loads the vgabios-ramfb.bin unconditionally, but only
the x86 need the vgabios-ramfb.bin, this can cause that when use the
<= 10.0 (handling the case of arm virt,
for compat reasons).
At the same time, set the "use-legacy-x86-rom" property to true on those
historical versioned machine types in order to avoid the memory layout
being changed.
Reviewed-by: Eric Auger
Signed-off-by: Shaoqin Huang
---
hw/c
hu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Shaoqin Huang (2):
ramfb: Add property to control if load the romfile
hw/i386: Add the ramfb romfile compatibility
hw/core/machine.c | 2 ++
hw/display/ramfb-standalone.c | 4 +++-
hw/display/ramfb-stubs.c
s property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
For now the default value is true but it will be turned off by default
in subsequent patch when compats get properly handled.
Reviewed-by: Eric Auger
Signed-off-by: Shaoqin
Hi Eric,
Thanks for your review.
On 7/3/25 12:54 PM, Eric Auger wrote:
Hi Shaoqin,
On 7/3/25 3:28 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need it.
At the same time, set the "use
Hi Gerd,
On 7/2/25 5:52 PM, Gerd Hoffmann wrote:
On Wed, Jul 02, 2025 at 05:28:01PM +0800, Shaoqin Huang wrote:
Hi Eric,
On 7/2/25 5:08 PM, Eric Auger wrote:
On 7/2/25 10:56 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to t
Hi Eric,
On 7/2/25 5:08 PM, Eric Auger wrote:
On 7/2/25 10:56 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need it.
At the same time, set the "use-legacy-x86-rom" property to true
nged.
Signed-off-by: Shaoqin Huang
---
hw/core/machine.c | 2 ++
hw/display/ramfb-standalone.c | 2 +-
hw/i386/pc_piix.c | 10 ++
hw/i386/pc_q35.c | 3 +++
hw/vfio/pci.c | 2 +-
5 files changed, 17 insertions(+), 2 deletions(-)
s property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
For now the default value is true but it will be turned off by default
in subsequent patch when compats get properly handled.
Signed-off-by: Shaoqin Huang
---
hw/display/ram
609073408.2083831-1-shahu...@redhat.com/
v2: https://lore.kernel.org/all/20250606070234.2063451-1-shahu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Shaoqin Huang (2):
ramfb: Add property to control if load the romfile
hw/i386: Add the ramf
Hi Zhao,
On 7/2/25 2:09 PM, Zhao Liu wrote:
One more question, now the qemu doesn't have the hw_compat_10_1, should I
first add another patch to add it just like the commit:
0a7c438a42 hw: add compat machines for 10.0
Hi Shaoqin, I think you can add compat option in hw_compat_10_0. Then
the co
Hi Eric,
On 7/2/25 10:24 AM, Shaoqin Huang wrote:
Hi Eric,
Thanks for your review.
On 7/1/25 1:17 PM, Eric Auger wrote:
Hi,
On 7/1/25 5:05 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need i
Hi Eric,
Thanks for your review.
On 7/1/25 1:17 PM, Eric Auger wrote:
Hi,
On 7/1/25 5:05 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need it.
At the same time, set the "use-legacy-x86-r
0605030351.2056571-1-shahu...@redhat.com/
Shaoqin Huang (2):
ramfb: Add property to control if load the romfile
hw/i386: Add the ramfb romfile compatibility
hw/core/machine.c | 2 ++
hw/display/ramfb-standalone.c | 4 +++-
hw/display/ramfb-stubs.c | 2 +-
hw/display/ramfb.c
nged.
Signed-off-by: Shaoqin Huang
---
hw/core/machine.c | 2 ++
hw/display/ramfb-standalone.c | 2 +-
hw/i386/pc_piix.c | 10 ++
hw/i386/pc_q35.c | 3 +++
hw/vfio/pci.c | 2 +-
5 files changed, 17 insertions(+), 2 deletions(-)
s property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
For now the default value is true but it will be turned off by default
in subsequent patch when compats get properly handled.
Signed-off-by: Shaoqin Huang
---
hw/display/ram
Hi Daniel,
On 6/27/25 3:15 PM, Daniel P. Berrangé wrote:
On Fri, Jun 27, 2025 at 01:37:55PM +0800, Shaoqin Huang wrote:
Hi Eric,
On 6/26/25 4:01 PM, Eric Auger wrote:
On 6/26/25 4:05 AM, Shaoqin Huang wrote:
Hi Eric,
On 6/23/25 5:20 PM, Eric Auger wrote:
On 6/17/25 5:05 AM, Shaoqin
Hi Eric,
On 6/26/25 4:01 PM, Eric Auger wrote:
On 6/26/25 4:05 AM, Shaoqin Huang wrote:
Hi Eric,
On 6/23/25 5:20 PM, Eric Auger wrote:
On 6/17/25 5:05 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since onl
https://lore.kernel.org/all/20250617030521.2109305-1-shahu...@redhat.com/
v3: https://lore.kernel.org/all/20250609073408.2083831-1-shahu...@redhat.com/
v2: https://lore.kernel.org/all/20250606070234.2063451-1-shahu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need it.
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 2 +-
hw/i386/pc_piix.c | 10 ++
hw/i386/pc_q35.c | 3 +++
hw/
s property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
For now the default value is true but it will be turned off by default
in subsequent patch when compats get properly handled.
Signed-off-by: Shaoqin Huang
---
hw/display/ram
Hi Eric,
On 6/23/25 5:20 PM, Eric Auger wrote:
On 6/17/25 5:05 AM, Shaoqin Huang wrote:
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need it.
s/compatatibility/compatibility in the title
Ok. Will fix it.
Sig
Hi Eric,
On 6/23/25 5:20 PM, Eric Auger wrote:
Hi Shaoqin,
On 6/17/25 5:05 AM, Shaoqin Huang wrote:
Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
Currently the ramfb device loads ...
Ok, will change it.
the x86 need the vgabios-ramfb.bin, this can cause that when
Hi guys,
Kindly ping for this series.
Thanks,
Shaoqin
On 6/17/25 11:05 AM, Shaoqin Huang wrote:
Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
the x86 need the vgabios-ramfb.bin, this can cause that when use the
release package on arm64 it can't find the vg
Set the "use-legacy-x86-rom" property to false by default, and only set
it to true on x86 since only x86 will need it.
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 2 +-
hw/i386/pc_q35.c | 3 +++
hw/vfio/pci.c | 2 +-
3 files
perty, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 4 +++-
hw/display/ramfb-stubs.c | 2 +-
hw/display/ramfb.c| 6 --
hw/vfio/display.c
ps://lore.kernel.org/all/20250606070234.2063451-1-shahu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Shaoqin Huang (2):
ramfb: Add property to control if load the romfile
hw/i386: Add the ramfb romfile compatatibility
hw/display/ramfb-standalone.c | 4 +++-
On 6/9/25 5:10 PM, Daniel P. Berrangé wrote:
On Mon, Jun 09, 2025 at 09:48:36AM +0100, Peter Maydell wrote:
On Mon, 9 Jun 2025 at 08:34, Shaoqin Huang wrote:
On arm64, it doesn't use the vgabios-ramfb.bin, so set the property
"use-legacy-x86-rom" to false, thus the ramfb
Hi Gerd, Daniel,
Sorry for the late reply.
On 6/10/25 2:47 PM, Gerd Hoffmann wrote:
Hi,
$ qemu-system-aarch64 -machine virt -cpu max -device ati-vga
qemu-system-aarch64: -device ati-vga: failed to find romfile "vgabios-ati.bin"
$ qemu-system-aarch64 -machine virt -cpu max -device cirrus-
ange the property name.
v2: https://lore.kernel.org/all/20250606070234.2063451-1-shahu...@redhat.com/
v1: https://lore.kernel.org/all/20250605030351.2056571-1-shahu...@redhat.com/
Shaoqin Huang (2):
ramfb: Add property to control if load the romfile
hw/arm: Add the romfile compatatibility
On arm64, it doesn't use the vgabios-ramfb.bin, so set the property
"use-legacy-x86-rom" to false, thus the ramfb won't load the
vgabios-ramfb.bin.
This can mitigate the problem that on release version the qemu can't
find the vgabios-ramfb.bin if it use the ramfb.
Sig
perty, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 4 +++-
hw/display/ramfb-stubs.c | 2 +-
hw/display/ramfb.c| 6 --
hw/vfio/display.c
On 6/6/25 4:07 PM, Cédric Le Goater wrote:
On 6/6/25 10:06, Cédric Le Goater wrote:
On 6/6/25 09:52, Daniel P. Berrangé wrote:
On Fri, Jun 06, 2025 at 03:02:34AM -0400, Shaoqin Huang wrote:
Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
the x86 need the vgabios
Hi Daniel,
On 6/6/25 3:52 PM, Daniel P. Berrangé wrote:
On Fri, Jun 06, 2025 at 03:02:34AM -0400, Shaoqin Huang wrote:
Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
the x86 need the vgabios-ramfb.bin, this can cause that when use the
release package on arm64 it can&#
perty, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 4 +++-
hw/display/ramfb-stubs.c | 2 +-
hw/display/ramfb.c| 6 --
hw/vfio/display.c
Hi Daniel,
On 6/5/25 10:40 PM, Daniel P. Berrangé wrote:
On Thu, Jun 05, 2025 at 04:24:07PM +0200, Cédric Le Goater wrote:
On 6/5/25 14:21, Gerd Hoffmann wrote:
Hi,
Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
the x86 need the vgabios-ramfb.bin, this can cause
Hi, guys
Thanks for all of your suggestions.
On 6/5/25 11:11 PM, Philippe Mathieu-Daudé wrote:
On 5/6/25 14:21, Gerd Hoffmann wrote:
Hi,
Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
the x86 need the vgabios-ramfb.bin, this can cause that when use the
release pac
vfio display also use the ramfb_setup() to load the
vgabios-ramfb.bin file.
After have this property, the machine type can set the compatibility to
not load the vgabios-ramfb.bin if the arch doesn't need it.
Signed-off-by: Shaoqin Huang
---
hw/display/ramfb-standalone.c | 4 +++-
hw/display/ram
Hi Zhao,
I've added some code and test it on ARM64, it works very well.
And after reviewing the code, it looks good to me.
Reviewed-by: Shaoqin Huang
On 4/9/25 4:26 PM, Zhao Liu wrote:
Hi all,
Now I've converted the previous RFC (v2) to PATCH.
Compared with RFC v2 [1], this vers
Hi Zhao,
On 3/21/25 11:43 AM, Zhao Liu wrote:
Hi Shaoqin,
Thank you very much for testing!
I tried your series on ARM64, but it reports error at compile time, here is
the error output:
qapi/kvm.json:59:Unexpected indentation.
I guess this is caused by my invalid format and sphinx complains
Hi Zhao,
Thanks for your effort to respin the PMU Filter series.
I tried your series on ARM64, but it reports error at compile time, here
is the error output:
qapi/kvm.json:59:Unexpected indentation.
While I compiled it on x86, everything is ok. Could you please check why
it failed on ARM64
Hi Zhao,
On 8/2/24 17:37, Zhao Liu wrote:
Hello Shaoqin,
On Fri, Aug 02, 2024 at 05:01:47PM +0800, Shaoqin Huang wrote:
Date: Fri, 2 Aug 2024 17:01:47 +0800
From: Shaoqin Huang
Subject: Re: [RFC 0/5] accel/kvm: Support KVM PMU filter
Hi Zhao,
On 7/10/24 12:51, Zhao Liu wrote:
Hi QEMU
Hi Zhao,
On 7/10/24 12:51, Zhao Liu wrote:
Hi QEMU maintainers, arm and PMU folks,
I picked up Shaoqing's previous work [1] on the KVM PMU filter for arm,
and now is trying to support this feature for x86 with a JSON-compatible
API.
While arm and x86 use different KVM ioctls to configure the P
Hi Zhao,
Thanks for your proposed idea. If you are willing to take the PMU Filter
Enabling work, you can do it. I won't update this series anymore due to
the QAPI restriction. I really appreciate if you can implement that.
Thanks,
Shaoqin
On 5/13/24 14:52, Zhao Liu wrote:
Hi Daniel,
Pleas
Hi Daniel,
On 4/16/24 01:29, Daniel P. Berrangé wrote:
On Mon, Apr 08, 2024 at 10:49:40PM -0400, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`kvm-pmu-filter` as -cpu sub-option to
Hi Thmoas,
On 4/9/24 13:33, Thomas Huth wrote:
+ assert_has_feature(qts, "host", "kvm-pmu-filter");
So you assert here that the feature is available ...
assert_has_feature(qts, "host", "kvm-steal-time");
assert_has_feature(qts, "host", "sve");
resp = do_q
s sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events do still work.
Signed-off-by: Shaoqin Huang
---
v8->v9:
- Replace the warn_report to error_setg in some places.
- Merge the check condition to make code more clean.
- Try to use the QAPI format for
Hi Eric,
On 3/19/24 23:23, Eric Auger wrote:
+if (kvm_supports_pmu_filter) {
+assert_set_feature_str(qts, "host", "kvm-pmu-filter", "");
+assert_set_feature_str(qts, "host", "kvm-pmu-filter",
+ "A:0x11-0x11");
+assert_
Hi Kevin,
On 4/2/24 21:01, Kevin Wolf wrote:
Maybe I'm wrong. So I want to double check with if the -cpu option
support json format nowadays?
As far as I can see, -cpu doesn't support JSON yet. But even if it did,
your command line would be invalid because the 'host,' part isn't JSON.
Thanks
Hi Daniel,
On 3/25/24 16:55, Daniel P. Berrangé wrote:
On Mon, Mar 25, 2024 at 01:35:58PM +0800, Shaoqin Huang wrote:
Hi Daniel,
Thanks for your reviewing. I see your comments in the v7.
I have some doubts about what you said about the QAPI. Do you want me to
convert the current design into
?
Thanks,
Shaoqin
On 3/22/24 22:53, Daniel P. Berrangé wrote:
On Tue, Mar 12, 2024 at 03:48:49AM -0400, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`kvm-pmu-filter` as -cpu sub-option to
s sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events do still work.
Signed-off-by: Shaoqin Huang
---
v7->v8:
- Add qtest for kvm-pmu-filter.
- Do the kvm-pmu-filter syntax checking up-front in the kvm_pmu_filter_set()
function. And store the filter inf
Hi Peter,
On 2/22/24 22:28, Peter Maydell wrote:
On Wed, 21 Feb 2024 at 06:34, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`kvm-pmu-filter` as -cpu sub-option to set the PMU Event
s sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events do still work.
Reviewed-by: Sebastian Ott
Signed-off-by: Shaoqin Huang
---
v6->v7:
- Check return value of sscanf.
- Improve the check condition.
v5->v6:
- Commit message improvement.
Hi Eric,
On 2/15/24 17:13, Eric Auger wrote:
Hi Shaoqin,
On 2/1/24 09:51, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`kvm-pmu-filter` as -cpu sub-option to set the PMU Event
s sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events do still work.
Reviewed-by: Sebastian Ott
Signed-off-by: Shaoqin Huang
---
v5->v6:
- Commit message improvement.
- Remove some unused code.
- Collect Reviewed-by, thanks Sebastian.
- Use g_aut
Hi Eric,
On 1/17/24 20:59, Eric Auger wrote:
Hi Shaoqin,
On 1/15/24 09:01, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`kvm-pmu-filter` as -cpu sub-option to set the PMU Event
Hi Eric,
On 1/17/24 20:59, Eric Auger wrote:
Hi Shaoqin,
On 1/15/24 09:01, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`kvm-pmu-filter` as -cpu sub-option to set the PMU Event
0 seconds sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events are still work.
Signed-off-by: Shaoqin Huang
---
v4->v5:
- Change the kvm-pmu-filter as a -cpu sub-option. [Eric]
- Comment tweak. [Gavin]
- Rebase to
s
As we can see, the cycle counter has been disabled in the guest, but
other pmu events are still work.
Signed-off-by: Shaoqin Huang
---
v3->v4:
- Fix the wrong check for pmu_filter_init.[Sebastian]
- Fix multiple alignment issue. [Gavin]
- Report error by
Hi Gavin,
On 12/1/23 13:37, Gavin Shan wrote:
Hi Shaoqin,
On 11/29/23 14:08, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provide the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`pmu-filter` as -accel sub-option to set the PMU Event
On 12/1/23 00:55, Sebastian Ott wrote:
On Tue, 28 Nov 2023, Shaoqin Huang wrote:
+static void kvm_arm_pmu_filter_init(CPUState *cs)
+{
+ static bool pmu_filter_init = false;
+ struct kvm_pmu_event_filter filter;
+ struct kvm_device_attr attr = {
+ .group
s
As we can see, the cycle counter has been disabled in the guest, but
other pmu events are still work.
Signed-off-by: Shaoqin Huang
---
v2->v3:
- Improve commits message, use kernel doc wording, add more explaination on
filter example, fix some typo error.[Eric]
- Add g_fr
Hi Eric,
On 11/25/23 02:24, Eric Auger wrote:
Hi,
On 11/17/23 07:08, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provide the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`pmu-filter` as -accel sub-option to set the PMU Event Filtering
Hi Eric,
On 11/24/23 18:40, Eric Auger wrote:
Hi Shaoqin,
On 11/17/23 07:08, Shaoqin Huang wrote:
The KVM_ARM_VCPU_PMU_V3_FILTER provide the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`pmu-filter` as -accel sub-option to set the PMU Event
event.
Signed-off-by: Salil Mehta
Reviewed-by: Shaoqin Huang
---
docs/specs/acpi_hw_reduced_hotplug.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/specs/acpi_hw_reduced_hotplug.rst
b/docs/specs/acpi_hw_reduced_hotplug.rst
index 0bd3f9399f..3acd6fcd8b 100644
2492480 seconds time elapsed
0.001752000 seconds user
0.0 seconds sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events are still work.
Signed-off-by: Shaoqin Huang
---
v1->v2:
- Add more description for allow and deny meanin
Hi Sebastian,
On 11/15/23 20:17, Sebastian Ott wrote:
Hi,
On Mon, 13 Nov 2023, Shaoqin Huang wrote:
+ ``pmu-filter={A,D}:start-end[;...]``
+ KVM implements pmu event filtering to prevent a guest from
being able to
+ sample certain events. It has the following format:
+
+ pmu
3% of all
branches
1.002492480 seconds time elapsed
0.001752000 seconds user
0.0 seconds sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events are still work.
Signed-off-by: Shaoqin Huang
---
include/sysemu/kvm_int.h | 1 +
q
On 10/19/23 17:34, Salil Mehta wrote:
Hi Shaoqin,
From: Shaoqin Huang
Sent: Thursday, October 19, 2023 10:05 AM
To: Salil Mehta ; qemu-devel@nongnu.org; qemu-
a...@nongnu.org
Cc: m...@kernel.org; jean-phili...@linaro.org; Jonathan Cameron
; lpieral...@kernel.org;
peter.mayd...@linaro.org
cpi/generic_event_device.h | 5 ++
include/hw/core/cpu.h | 1 +
include/sysemu/kvm.h | 16 +++
system/physmem.c | 29
15 files changed, 184 insertions(+), 27 deletions(-)
Hi salil,
All patches looks good to me. Thanks for y
of CPU hotplug event initialization in the
existing GED framework.
Co-developed-by: Keqian Zhu
Signed-off-by: Keqian Zhu
Signed-off-by: Salil Mehta
Reviewed-by: Jonathan Cameron
Reviewed-by: Gavin Shan
Reviewed-by: David Hildenbrand
Tested-by: Vishnu Pajjuri
Reviewed-by: Shaoqin Huang
Host KVM is not destroyed and its
representative KVM vCPU object/context in Qemu is parked.
Refactor common logic so that some APIs could be reused by vCPU Hotplug code.
Signed-off-by: Salil Mehta
Reviewed-by: Gavin Shan
Tested-by: Vishnu Pajjuri
Reviewed-by: Shaoqin Huang
---
accel/kvm
Host KVM is not destroyed and its
representative KVM vCPU object/context in Qemu is parked.
Refactor common logic so that some APIs could be reused by vCPU Hotplug code.
Signed-off-by: Salil Mehta
Reviewed-by: Gavin Shan
Tested-by: Vishnu Pajjuri
Reviewed-by: Shaoqin Huang
---
accel/kvm
: Keqian Zhu
Signed-off-by: Salil Mehta
Reviewed-by: Jonathan Cameron
Reviewed-by: Gavin Shan
Reviewed-by: Shaoqin Huang
---
hw/acpi/generic_event_device.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index
Reviewed-by: Gavin Shan
Reviewed-by: Shaoqin Huang
---
hw/acpi/acpi-cpu-hotplug-stub.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/acpi/acpi-cpu-hotplug-stub.c b/hw/acpi/acpi-cpu-hotplug-stub.c
index 3fc4b14c26..c6c61bb9cd 100644
--- a/hw/acpi/acpi-cpu-hotplug-stub.c
+++ b
: Jonathan Cameron
Reviewed-by: Gavin Shan
Reviewed-by: David Hildenbrand
Reviewed-by: Shaoqin Huang
---
hw/acpi/cpu.c | 2 +-
include/hw/acpi/cpu_hotplug.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index 19c154d78f
On 9/26/23 18:04, Salil Mehta via wrote:
Factor out CPU properties code common for {hot,cold}-plugged CPUs. This allows
code reuse.
Signed-off-by: Salil Mehta
---
hw/arm/virt.c | 220 ++
include/hw/arm/virt.h | 4 +
2 files changed, 140 i
Hi Salil,
On 6/26/23 21:42, Salil Mehta wrote:
From: Shaoqin Huang
Sent: Monday, June 26, 2023 7:49 AM
To: qemu-devel@nongnu.org; qemu-...@nongnu.org
Cc: oliver.up...@linux.dev; Salil Mehta ;
james.mo...@arm.com; gs...@redhat.com; Shaoqin Huang ;
Cornelia Huck ; k...@vger.kernel.org; Michael S
when reset vcpu, we need to mark it as dirty to force the vcpu to
sync its register to kvm, and when reset gicv3, we need to pause all
vcpus to grab the all vcpu locks, thus when handling the psci CPU_ON
call, the vcpu can be successfuly boot up.
Signed-off-by: Shaoqin Huang
---
hw/intc
Now the psci call can only be used when tcg_enabled, we want to reuse it
when kvm_enabled, which will be used in subsequent patch which enable
the psci handling in userspace.
Signed-off-by: Shaoqin Huang
---
target/arm/helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Copy in the SMCCC definitions from the kernel, which will be used to
implement SMCCC handling in userspace.
Signed-off-by: Shaoqin Huang
---
linux-headers/linux/arm-smccc.h | 240
1 file changed, 240 insertions(+)
create mode 100644 linux-headers/linux/arm
Update to commit 45a3e24f65e9 ("Linux 6.4-rc7").
Signed-off-by: Shaoqin Huang
---
include/standard-headers/linux/const.h| 2 +-
include/standard-headers/linux/virtio_blk.h | 18 +++
.../standard-headers/linux/virtio_config.h| 6 +++
include/standard-hea
-by: Shaoqin Huang
---
docs/system/arm/virt.rst | 4 +++
hw/arm/virt.c| 21
include/hw/arm/virt.h| 1 +
target/arm/kvm.c | 54
4 files changed, 80 insertions(+)
diff --git a/docs/system/arm/virt.rst b/docs/system
nux.dev
[2] lore.kernel.org/20230203135043.409192-1-james.mo...@arm.com
Shaoqin Huang (5):
linux-headers: Update to v6.4-rc7
linux-headers: Import arm-smccc.h from Linux v6.4-rc7
target/arm: make psci call can be used by kvm
arm/kvm: add skeleton implementation for userspace SMCCC call handling
ar
Simply fix the #vcpus_count to @vcpus_count in CPUArchId comments. Whlie
at it, reorder the parameters in comments to match the sequence of
parameters which defined in the CPUArchId.
Reviewed-by: Igor Mammedov
Signed-off-by: Shaoqin Huang
---
include/hw/boards.h | 4 ++--
1 file changed, 2
duplicate property 'pc.ram' to object (type
'container')
Aborted (core dumped)
Instead of abort, check for the conflicting 'id' and exit with
an error, suggesting how to remedy the issue.
Signed-off-by: Igor Mammedov
CC: th...@redhat.com
Reviewed-by: Shaoqin Huan
Simply fix the #vcpus_count to @vcpus_count in CPUArchId comments. Since
we are at here, resort the parameters in comments to match the sequence
of parameters which defined in the CPUArchId.
CC: Igor Mammedov
Signed-off-by: Shaoqin Huang
---
include/hw/boards.h | 4 ++--
1 file changed, 2
Simply fix the #vcpus_count to @vcpus_count in CPUArchId comments. Since
we are at here, resort the parameters in comments to match the sequence
of parameters which defined in the CPUArchId.
Signed-off-by: Shaoqin Huang
---
include/hw/boards.h | 4 ++--
1 file changed, 2 insertions(+), 2
96 matches
Mail list logo
