On 14/3/24 22:37, Claudio Fontana wrote:
some users were confused by this message showing under TCG:
Selected CPU generation is too new. Maximum supported model
in the configuration: 'xyz'
(Note for the maintainer queuing this patch, consider adding
few extra spaces to indent the previously
On 14/3/24 18:22, Claudio Fontana wrote:
At least for now cpu-topology is implemented only for KVM.
We already say this, but this tries to be more explicit,
and also show it in the examples.
This adds a new reference in the introduction that we can point to,
whenever we need to reference
On 14/3/24 12:52, Gerd Hoffmann wrote:
Needed to avoid stale toolchain configurations breaking firmware builds.
Signed-off-by: Gerd Hoffmann
---
roms/Makefile | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Philippe Mathieu-Daudé
On 14/3/24 12:53, Gerd Hoffmann wrote:
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4641
Signed-off-by: Gerd Hoffmann
---
roms/edk2-build.config | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Philippe Mathieu-Daudé
On Fri, Mar 15, 2024 at 5:39 AM Si-Wei Liu wrote:
>
> On setups with one or more virtio-net devices with vhost on,
> dirty tracking iteration increases cost the bigger the number
> amount of queues are set up e.g. on idle guests migration the
> following is observed with virtio-net with vhost=on:
Currently there is no way to distinguish the case that rombar is
explicitly specified as 1 and the case that rombar is not specified.
Set rombar UINT32_MAX by default to distinguish these cases just as it
is done for addr and romsize. It was confirmed that changing the default
value to UINT32_MAX
romsize is an uint32_t variable. Specifying -1 as an uint32_t value is
obscure way to denote UINT32_MAX.
Worse, if int is wider than 32-bit, it will change the behavior of a
construct like the following:
romsize = -1;
if (romsize != -1) {
...
}
When -1 is assigned to romsize, -1 will be
vfio determines if rombar is explicitly enabled by inspecting QDict.
Inspecting QDict is not nice because QDict is untyped and depends on the
details on the external interface. Add an infrastructure to determine if
rombar is explicitly enabled to hw/pci.
This changes the semantics of UINT32_MAX,
A device gets automatically unrealized when being unparented.
Signed-off-by: Akihiko Odaki
---
hw/pci/pcie_sriov.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
index e9b23221d713..499becd5273f 100644
--- a/hw/pci/pcie_sriov.c
+++
The renamed state will not only represent powering state of PFs, but
also represent SR-IOV VF enablement in the future.
Signed-off-by: Akihiko Odaki
---
include/hw/pci/pci.h| 7 ++-
include/hw/pci/pci_device.h | 2 +-
hw/pci/pci.c| 14 +++---
pci_new() aborts when creating a VF with a function number equals to or
is greater than PCI_DEVFN_MAX.
Signed-off-by: Akihiko Odaki
---
docs/pcie_sriov.txt | 8 +---
include/hw/pci/pcie_sriov.h | 5 +++--
hw/net/igb.c| 13 ++---
hw/nvme/ctrl.c
It is no longer used.
Signed-off-by: Akihiko Odaki
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
---
include/hw/qdev-core.h | 4
hw/core/qdev.c | 1 -
system/qdev-monitor.c | 12 +++-
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git
num_vfs is not migrated so use PCI_SRIOV_CTRL_VFE and PCI_SRIOV_NUM_VF
instead.
Signed-off-by: Akihiko Odaki
---
include/hw/pci/pcie_sriov.h | 1 -
hw/pci/pcie_sriov.c | 28
hw/pci/trace-events | 2 +-
3 files changed, 21 insertions(+), 10
pcie_sriov doesn't have code to restore its state after migration, but
igb, which uses pcie_sriov, naively claimed its migration capability.
Add code to register VFs after migration and fix igb migration.
Fixes: 3a977deebe6b ("Intrdocue igb device emulation")
Signed-off-by: Akihiko Odaki
---
Disable SR-IOV VF devices by reusing code to power down PCI devices
instead of removing them when the guest requests to disable VFs. This
allows to realize devices and report VF realization errors at PF
realization time.
Signed-off-by: Akihiko Odaki
---
include/hw/pci/pci.h| 5 ---
Release VFs failed to realize just as we do in unregister_vfs().
Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization
(SR/IOV)")
Signed-off-by: Akihiko Odaki
---
hw/pci/pcie_sriov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/pci/pcie_sriov.c
I submitted a RFC series[1] to add support for SR-IOV emulation to
virtio-net-pci. During the development of the series, I fixed some
trivial bugs and made improvements that I think are independently
useful. This series extracts those fixes and improvements from the RFC
series.
[1]:
On Fri, Mar 15, 2024 at 5:39 AM Si-Wei Liu wrote:
>
> There could be a mix of both vhost-user and vhost-kernel clients
> in the same QEMU process, where separate vhost loggers for the
> specific vhost type have to be used. Make the vhost logger per
> backend type, and have them properly reference
The fd: URI has supported migration to a file or socket since before
QEMU 8.2. In 8.2 we added the file: URI that supported migration to a
file. So now we have two ways (three if you count exec:>cat) to
migrate to a file. Fine.
However,
In 8.2 we also added the new qmp_migrate API that uses a
We currently store the file descriptor used during the main outgoing
channel creation to use it again when creating the multifd
channels.
Since this fd is used for the first iochannel, there's risk that the
QIOChannel gets freed and the fd closed while outgoing_args.fd still
has it available.
When doing migration using the fd: URI, QEMU will fetch the file
descriptor passed in via the monitor at
fd_start_outgoing|incoming_migration(), which means the checks at
migration_channels_and_transport_compatible() happen too soon and we
don't know at that point whether the FD refers to a plain
Hi,
In this v3:
patch 1 - The fd_is_socket() verification and an update to the comment
in the code;
patch 2 - The fix for the fd-reuse bug in outgoing_args;
patch 3 - A proposal on how to fix the fd-socket vs. fd-file
issue. I'm basically moving the fd_is_socket() call
Just a ping to make sure this patch hasn't been lost in the noise.
Any chance to get this merged? Should I send a v2 with a revised commit message?
Regards,
Justinien
在 2024/2/14 0:51, Jonathan Cameron 写道:
+
+void cxl_event_handle_record(struct cxl_memdev *cxlmd,
+enum cxl_event_log_type type,
+enum cxl_event_type event_type,
+const uuid_t *uuid, union cxl_event *evt)
+{
Hello, Jonathan
When during the test of qmps of CXL events like
"cxl-inject-general-media-event",
I am confuesd about the argument "flags". According to "qapi/cxl.json" in qemu,
this argument represents "Event Record Flags" in Common Event Record Format.
However, it seems like the specific
Hi Salil,
[...]
+void cpu_address_space_destroy(CPUState *cpu, int asidx) {
+CPUAddressSpace *cpuas;
+
+assert(cpu->cpu_ases);
+assert(asidx >= 0 && asidx < cpu->num_ases);
+/* KVM cannot currently support multiple address spaces. */
+assert(asidx == 0 || !kvm_enabled());
+
+
On Fri, 8 Mar 2024 15:22:50 -0800, Sean Christopherson wrote:
> On Fri, Mar 08, 2024, James Gowans wrote:
> > We are also aware of ongoing work on guest_memfd. The current
> > implementation unmaps guest memory from VMM address space, but leaves it
> > in the kernel’s direct map. We’re not looking
On setups with one or more virtio-net devices with vhost on,
dirty tracking iteration increases cost the bigger the number
amount of queues are set up e.g. on idle guests migration the
following is observed with virtio-net with vhost=on:
48 queues -> 78.11% [.] vhost_dev_sync_region.isra.13
8
There could be a mix of both vhost-user and vhost-kernel clients
in the same QEMU process, where separate vhost loggers for the
specific vhost type have to be used. Make the vhost logger per
backend type, and have them properly reference counted.
Suggested-by: Michael S. Tsirkin
Signed-off-by:
some users were confused by this message showing under TCG:
Selected CPU generation is too new. Maximum supported model
in the configuration: 'xyz'
Clarify that the maximum can depend on the accel, and add a
hint to try a different one.
Also add a hint for features mismatch to suggest trying
ui-dbus.so is a shared library. But it is apparently handled differently
than all the other shared libraries: it is not compiled with -fPIC.
As a result it fails to link. Not sure why this happens only here.
Everything up to v7.2.9 was fine.
Looking at some random other library like
On Wed, Mar 06, 2024 at 04:28:16PM +, Jonathan Cameron wrote:
> On Mon, 4 Mar 2024 11:34:01 -0800
> nifan@gmail.com wrote:
>
> > From: Fan Ni
> >
> > Add (file/memory backed) host backend, all the dynamic capacity regions
> > will share a single, large enough host backend. Set up
On 3/14/24 21:10, Claudio Fontana wrote:
> On 3/14/24 20:44, Nina Schoetterl-Glausch wrote:
>> On Thu, 2024-03-14 at 20:00 +0100, Claudio Fontana wrote:
>>> some users were confused by this message showing under TCG:
>>>
>>> Selected CPU generation is too new. Maximum supported model
>>> in the
On 3/14/24 3:05 PM, Eugenio Perez Martin wrote:
On Thu, Mar 14, 2024 at 5:06 PM Jonah Palmer wrote:
On 3/14/24 10:55 AM, Eugenio Perez Martin wrote:
On Thu, Mar 14, 2024 at 1:16 PM Jonah Palmer wrote:
On 3/13/24 11:01 PM, Jason Wang wrote:
On Wed, Mar 13, 2024 at 7:55 PM Jonah
On 3/14/24 20:44, Nina Schoetterl-Glausch wrote:
> On Thu, 2024-03-14 at 20:00 +0100, Claudio Fontana wrote:
>> some users were confused by this message showing under TCG:
>>
>> Selected CPU generation is too new. Maximum supported model
>> in the configuration: 'xyz'
>>
>> Try to clarify that the
On Thu, 2024-03-14 at 20:00 +0100, Claudio Fontana wrote:
> some users were confused by this message showing under TCG:
>
> Selected CPU generation is too new. Maximum supported model
> in the configuration: 'xyz'
>
> Try to clarify that the maximum can depend on the accel by
> adding also the
On Fri, Mar 15, 2024 at 12:29:57AM +0530, Himanshu Chauhan wrote:
> Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable
> the sdtrig extension and disable the debug property for these CPUs.
You still have the 'and disable the debug property' here...
>
> Signed-off-by:
On Fri, Mar 15, 2024 at 12:29:56AM +0530, Himanshu Chauhan wrote:
> This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
>-cpu rv64,sdtrig=
> option can be used to dynamically turn
On Fri, Mar 15, 2024 at 12:29:55AM +0530, Himanshu Chauhan wrote:
> The mcontrol6 triggers are not defined in debug specification v0.13
> These triggers are defined in sdtrig ISA extension.
>
> This patch:
>* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
>* Keeps
On Thu, Mar 14, 2024 at 7:35 PM Si-Wei Liu wrote:
>
>
>
> On 3/14/2024 8:34 AM, Eugenio Perez Martin wrote:
> > On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote:
> >> On setups with one or more virtio-net devices with vhost on,
> >> dirty tracking iteration increases cost the bigger the number
>
On Thu, Mar 14, 2024 at 5:06 PM Jonah Palmer wrote:
>
>
>
> On 3/14/24 10:55 AM, Eugenio Perez Martin wrote:
> > On Thu, Mar 14, 2024 at 1:16 PM Jonah Palmer
> > wrote:
> >>
> >>
> >>
> >> On 3/13/24 11:01 PM, Jason Wang wrote:
> >>> On Wed, Mar 13, 2024 at 7:55 PM Jonah Palmer
> >>> wrote:
>
On Thu, 2024-03-14 at 18:22 +0100, Claudio Fontana wrote:
> At least for now cpu-topology is implemented only for KVM.
>
> We already say this, but this tries to be more explicit,
> and also show it in the examples.
>
> This adds a new reference in the introduction that we can point to,
>
This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
The sdtrig extension may or may not be implemented in a system. Therefore, the
-cpu rv64,sdtrig=
option can be used to dynamically turn sdtrig extension on or off.
By default, the sdtrig extension is disabled
The mcontrol6 triggers are not defined in debug specification v0.13
These triggers are defined in sdtrig ISA extension.
This patch:
* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
* Keeps the debug property. All triggers that are defined in v0.13 are
exposed.
Check if each element of array of pointers for itimer contains a non-null
pointer before freeing.
Signed-off-by: Himanshu Chauhan
---
target/riscv/debug.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/riscv/debug.c b/target/riscv/debug.c
index
Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable
the sdtrig extension and disable the debug property for these CPUs.
Signed-off-by: Himanshu Chauhan
---
target/riscv/cpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index
some users were confused by this message showing under TCG:
Selected CPU generation is too new. Maximum supported model
in the configuration: 'xyz'
Try to clarify that the maximum can depend on the accel by
adding also the current accelerator to the message as such:
Selected CPU generation is
All the CPUs may or may not implement the debug triggers. Some CPUs
may implement only debug specification v0.13 and not sdtrig ISA
extension.
This patchset, adds sdtrig ISA as an extension which can be turned on or off by
sdtrig= option. It is turned off by default.
When debug is true and
On 3/14/2024 8:25 AM, Eugenio Perez Martin wrote:
On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote:
There could be a mix of both vhost-user and vhost-kernel clients
in the same QEMU process, where separate vhost loggers for the
specific vhost type have to be used. Make the vhost logger per
On 3/14/2024 8:34 AM, Eugenio Perez Martin wrote:
On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote:
On setups with one or more virtio-net devices with vhost on,
dirty tracking iteration increases cost the bigger the number
amount of queues are set up e.g. on idle guests migration the
On Wed, Mar 13, 2024 at 06:28:22PM -0300, Fabiano Rosas wrote:
> Hi,
>
> In this v2:
>
> patch 1 - The fix for the ioc leaks, now including the main channel
>
> patch 2 - A fix for an fd: migration case I thought I had written code
> for, but obviously didn't.
The two issues are
We're going to make changes that will required each helper to be
responsible for the 'vstart' management, i.e. we will relieve the
'vstart < vl' assumption that helpers have today.
Helpers are usually able to deal with vstart >= vl, i.e. doing nothing
aside from setting vstart = 0 at the end, but
From: Ivan Klokov
The vstart_eq_zero flag is updated at the beginning of the translation
phase from the env->vstart variable. During the execution phase all
functions will set env->vstart = 0 after a successful execution, but the
vstart_eq_zero flag remains the same as at the start of the block.
trans_vmv_v_i , trans_vfmv_v_f and the trans_##NAME macro from
GEN_VMV_WHOLE_TRANS() are calling mark_vs_dirty() in both branches of
their 'ifs'. conditionals.
Call it just once in the end like other functions are doing.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
On Thu, Mar 14, 2024 at 01:50:07PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Thu, Mar 14, 2024 at 11:10:12AM -0400, Peter Xu wrote:
> >> On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
> >> > When doing migration using the fd: URI, the incoming migration starts
> >>
trans_vmv_x_s, trans_vmv_s_x, trans_vfmv_f_s and trans_vfmv_s_f aren't
setting vstart = 0 after execution. This is usually done by a helper in
vector_helper.c but these functions don't use helpers.
We'll set vstart after any potential 'over' brconds, and that will also
mandate a mark_vs_dirty()
All helpers that rely on vstart >= vl are now doing early exits using
the VSTART_CHECK_EARLY_EXIT() macro. This macro will not only exit the
helper but also clear vstart.
We're still left with brconds that are skipping the helper, which is the
only place where we're clearing vstart. The pattern
Hi,
The series was renamed to reflect that at this point we're fixing more
things than just vstart management.
In this new version a couple fixes were added:
- patch 3 (new) fixes the memcpy endianess in 'vmvr_v', as suggested by
Richard;
- patch 5 (new) fixes ldst_whole insns to now clear
Change the for loops in ldst helpers to do a single increment in the
counter, and assign it env->vstart, to avoid re-reading from vstart
every time.
Suggested-by: Richard Henderson
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: Richard Henderson
---
Commit 8ff8ac6329 added a conditional to guard the vext_ldst_whole()
helper if vstart >= evl. But by skipping the helper we're also not
setting vstart = 0 at the end of the insns, which is incorrect.
We'll move the conditional to vext_ldst_whole(), following in line with
the removal of all
The helper isn't setting env->vstart = 0 after its execution, as it is
expected from every vector instruction that completes successfully.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
target/riscv/vector_helper.c | 1 +
1 file
vmvr_v isn't handling the case where the host might be big endian and
the bytes to be copied aren't sequential.
Suggested-by: Richard Henderson
Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR")
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/vector_helper.c | 10
These insns have 2 paths: we'll either have vstart already cleared if
vstart_eq_zero or we'll do a brcond to check if vstart >= maxsz to call
the 'vmvr_v' helper. The helper will clear vstart if it executes until
the end, or if vstart >= vl.
For starters, the check itself is wrong: we're checking
On Thu, Mar 14, 2024 at 01:44:13PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
> >> When doing migration using the fd: URI, the incoming migration starts
> >> before the user has passed the file descriptor to QEMU. This
On Thu, Mar 14, 2024 at 01:55:31PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Wed, Mar 13, 2024 at 06:28:22PM -0300, Fabiano Rosas wrote:
> >> Hi,
> >>
> >> In this v2:
> >>
> >> patch 1 - The fix for the ioc leaks, now including the main channel
> >>
> >> patch 2 - A fix for an
On Thu, Mar 14, 2024 at 06:25:00PM +0100, Alexander Ivanov wrote:
>
>
> On 3/14/24 13:44, Daniel P. Berrangé wrote:
> > On Wed, Mar 13, 2024 at 11:43:27AM +0100, Alexander Ivanov wrote:
> > > If a block device is an LVM logical volume we can resize it using
> > > standard LVM tools.
> > >
> > >
On 3/14/24 13:44, Daniel P. Berrangé wrote:
On Wed, Mar 13, 2024 at 11:43:27AM +0100, Alexander Ivanov wrote:
If a block device is an LVM logical volume we can resize it using
standard LVM tools.
Add a helper to detect if a device is a DM device. In raw_co_truncate()
check if the block
On 3/14/24 17:44, Nina Schoetterl-Glausch wrote:
> On Thu, 2024-03-14 at 16:54 +0100, Thomas Huth wrote:
>> On 14/03/2024 16.49, Claudio Fontana wrote:
>>> Hello Pierre, Ilya,
>>>
>>> I have a question on the s390x "topology" feature and examples.
>>>
>>> Mainly, is this feature supposed to be KVM
At least for now cpu-topology is implemented only for KVM.
We already say this, but this tries to be more explicit,
and also show it in the examples.
This adds a new reference in the introduction that we can point to,
whenever we need to reference accelerators and how to select them.
On Thu, Mar 14, 2024 at 05:05:10PM +0530, Himanshu Chauhan wrote:
> Ventana's Veyron CPUs support sdtrig ISA extension. By default, enable
> the sdtrig extension and disable the debug property for these CPUs.
The commit message needs to be updated to remove the 'and disable the
debug property'.
On Thu, Mar 14, 2024 at 05:05:09PM +0530, Himanshu Chauhan wrote:
> This patch adds "sdtrig" in the ISA string when sdtrig extension is enabled.
> The sdtrig extension may or may not be implemented in a system. Therefore, the
>-cpu rv64,sdtrig=
> option can be used to dynamically turn
On Thu, Mar 14, 2024 at 05:05:08PM +0530, Himanshu Chauhan wrote:
> The mcontrol6 triggers are not defined in debug specification v0.13
> These triggers are defined in sdtrig ISA extension.
>
> This patch:
>* Adds ext_sdtrig capability which is used to select mcontrol6 triggers
>* Keeps
This replicates the scenario in which the bug was reported.
Unfortunately this relies on actually executing a guest (so that the
firmware initialises the virtio-blk device and moves it to its
configured iothread), so this can't make use of the qtest accelerator
like most other test cases. I tried
Kevin Wolf (2):
nbd/server: Fix race in draining the export
iotests: Add test for reset/AioContext switches with NBD exports
nbd/server.c | 15 ++---
tests/qemu-iotests/tests/iothreads-nbd-export | 66 +++
.../tests/iothreads-nbd-export.out
When draining an NBD export, nbd_drained_begin() first sets
client->quiescing so that nbd_client_receive_next_request() won't start
any new request coroutines. Then nbd_drained_poll() tries to makes sure
that we wait for any existing request coroutines by checking that
client->nb_requests has
Peter Xu writes:
> On Wed, Mar 13, 2024 at 06:28:22PM -0300, Fabiano Rosas wrote:
>> Hi,
>>
>> In this v2:
>>
>> patch 1 - The fix for the ioc leaks, now including the main channel
>>
>> patch 2 - A fix for an fd: migration case I thought I had written code
>> for, but obviously
Peter Xu writes:
> On Thu, Mar 14, 2024 at 11:10:12AM -0400, Peter Xu wrote:
>> On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
>> > When doing migration using the fd: URI, the incoming migration starts
>> > before the user has passed the file descriptor to QEMU. This means
>> >
On Thu, 2024-03-14 at 16:54 +0100, Thomas Huth wrote:
> On 14/03/2024 16.49, Claudio Fontana wrote:
> > Hello Pierre, Ilya,
> >
> > I have a question on the s390x "topology" feature and examples.
> >
> > Mainly, is this feature supposed to be KVM accelerator-only, or also
> > available when
Peter Xu writes:
> On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
>> When doing migration using the fd: URI, the incoming migration starts
>> before the user has passed the file descriptor to QEMU. This means
>> that the checks at migration_channels_and_transport_compatible()
>>
On 3/13/24 15:33, Xianglai Li wrote:
+if (unlikely((level == 0) || (level > 4))) {
+return base;
+}
+
+if (FIELD_EX64(base, TLBENTRY, HUGE)) {
+if (FIELD_EX64(base, TLBENTRY, LEVEL)) {
+return base;
+} else {
+return FIELD_DP64(base,
On 3/14/24 10:55 AM, Eugenio Perez Martin wrote:
On Thu, Mar 14, 2024 at 1:16 PM Jonah Palmer wrote:
On 3/13/24 11:01 PM, Jason Wang wrote:
On Wed, Mar 13, 2024 at 7:55 PM Jonah Palmer wrote:
Add support to virtio-pci devices for handling the extra data sent
from the driver to the
On 14/03/2024 16.49, Claudio Fontana wrote:
Hello Pierre, Ilya,
I have a question on the s390x "topology" feature and examples.
Mainly, is this feature supposed to be KVM accelerator-only, or also available
when using the TCG accelerator?
Hi Claudio!
Pierre left IBM, please CC: Nina with
Hello Pierre, Ilya,
I have a question on the s390x "topology" feature and examples.
Mainly, is this feature supposed to be KVM accelerator-only, or also available
when using the TCG accelerator?
(docs/devel/s390-cpu-topology.rst vs
W dniu 14.03.2024 o 15:56, Alex Bennée pisze:
If we are not going to delete the entries then at least use a @skip
instead of commenting. Maybe:
@skip("Potential un-diagnosed upstream bug?")
Daniel or Peter suggested to open a GitLab issue and use
On Thu, Mar 14, 2024 at 11:10:12AM -0400, Peter Xu wrote:
> On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
> > When doing migration using the fd: URI, the incoming migration starts
> > before the user has passed the file descriptor to QEMU. This means
> > that the checks at
On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote:
>
> On setups with one or more virtio-net devices with vhost on,
> dirty tracking iteration increases cost the bigger the number
> amount of queues are set up e.g. on idle guests migration the
> following is observed with virtio-net with vhost=on:
On Thu, Mar 14, 2024 at 04:22:41PM +0100, Igor Mammedov wrote:
> Changelog:
> v4:
>* rebase on top of current master due to conflict with
> new SMBIOS table 9 commits
>* add extra patch with comments about obscure legacy entries counting
Thanks a lot for the quick turnaround Igor!
On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote:
>
> There could be a mix of both vhost-user and vhost-kernel clients
> in the same QEMU process, where separate vhost loggers for the
> specific vhost type have to be used. Make the vhost logger per
> backend type, and have them properly reference
Use smbios-entry-point-type='auto' for newer machine types as a workaround
for Windows not detecting SMBIOS tables. Which makes QEMU pick SMBIOS tables
based on configuration (with 2.x preferred and fallback to 3.x if the former
isn't compatible with configuration)
Default compat setting of
Unfortunately having 2.0 machine type deprecated is not enough
to get rid of legacy SMBIOS handling since 'isapc' also uses
that and it's staying around.
Hence add test for CLI options handling to be sure that it
ain't broken during SMBIOS code refactoring.
Signed-off-by: Igor Mammedov
If SMBIOS v2 version is requested but number of cores/threads
are more than it's possible to describe with v2, error out
instead of silently ignoring the fact and filling core/thread
count with bogus values.
This will help caller to decide if it should fallback to
SMBIOSv3 when
smbios_get_tables() bails out right away if leagacy mode is enabled
and won't generate any SMBIOS tables. At the same time x86 specific
fw_cfg_build_smbios() will genarate legacy tables and then proceed
to preparing temporary mem_array for useless call to
smbios_get_tables() and then discard it.
Cureently it not possible to run SMBIOS test without ACPI one,
which gets into the way when testing ACPI-less configs.
Extract SMBIOS testing into separate routines that could also
be run without ACPI dependency and use that for testing SMBIOS.
As the 1st user add "acpi/piix4/smbios-options"
As a preparation to move legacy handling into a separate file,
add prefix 'smbios_' to type0/type1/have_binfile_bitmap/have_fields_bitmap
and expose them in smbios.h so that they can be reused in
legacy and modern code.
Doing it as a separate patch to avoid rename cluttering follow-up
patch which
legacy mode doesn't support structures of type 2 and more,
and CLI has a check for '-smbios type' option, however it's
still possible to sneak in type4 as a blob with '-smbios file'
option. However doing the later makes SMBIOS tables broken
since SeaBIOS doesn't expect that.
Rather than trying to
clean up smbios_set_defaults() which is reused by legacy
and non legacy machines from being aware of 'legacy' notion
and need to turn it off. And push legacy handling up to
PC machine code where it's relevant.
Signed-off-by: Igor Mammedov
Reviewed-by: Ani Sinha
Acked-by: Daniel Henrique Barboza
address shift is caused by switch to 32-bit SMBIOS entry point
which has slightly different size from 64-bit one and happens
to trigger a bit different memory layout.
Expected diff:
-Name (MEMA, 0x07FFE000)
+Name (MEMA, 0x07FFF000)
Signed-off-by: Igor Mammedov
Acked-by: Ani Sinha
---
在 2024/2/10 14:46, Dan Williams 写道:
Shiyang Ruan wrote:
If poison is detected(reported from cxl memdev), OS should be notified to
handle it. Introduce this function:
1. translate DPA to HPA;
2. construct a MCE instance; (TODO: more details need to be filled)
3. log it into MCE
Signed-off-by: Igor Mammedov
---
hw/smbios/smbios_legacy.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/smbios/smbios_legacy.c b/hw/smbios/smbios_legacy.c
index 06907cd16c..c37a8ee821 100644
--- a/hw/smbios/smbios_legacy.c
+++ b/hw/smbios/smbios_legacy.c
@@ -151,6 +151,9 @@
Current code uses mix of error_report()+exit(1)
and error_setg() to handle errors.
Use newer error_setg() everywhere, beside consistency
it will allow to detect error condition without killing
QEMU and attempt switch-over to SMBIOS3.x tables/entrypoint
in follow up patch.
while at it, clear
1 - 100 of 182 matches
Mail list logo
