On 3/8/24 09:08, Philippe Mathieu-Daudé wrote:
> On 7/3/24 20:43, Thomas Huth wrote:
>> On 28/02/2024 17.43, Zhao Liu wrote:
>>> Hi Philippe,
>>>
+/*
+ * Real ICH9 contains a single SMI output line and doesn't
broadcast CPUs.
+ * Virtualized ICH9 allows broadcasting upon
Hi Phil,
On 2/26/24 17:49, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This is an experimental series to reduce calls to the
> cpu_interrupt() API from generic HW/. I'm trying to use
> the ICH9 chipset from a non-x86 machine. Without this
> experiment, we can not because cpu_interrupt() is target
>
On 2/22/24 16:49, Andrea Bolognani wrote:
> On Thu, Feb 22, 2024 at 04:10:20PM +0100, Philippe Mathieu-Daudé wrote:
>> On 19/2/24 11:34, Xianglai Li wrote:
>>> The UEFI loading mode in loongarch is very different
>>> from that in other architectures:loongarch's UEFI code
>>> is in rom, while other
On 2/20/24 08:58, Philippe Mathieu-Daudé wrote:
> Hi Laszlo, Igor, Gerd,
>
> (old patch, now commit 5ce45c7a2b)
>
> On 26/1/17 02:44, Laszlo Ersek wrote:
>> The generic edk2 SMM infrastructure prefers
>> EFI_SMM_CONTROL2_PROTOCOL.Trigger() to inject an SMI on each
and
>>> extracting the address width and using it to override the
>>> phys_bits value as shown in this patch.
>>>
>>> Previous attempt at solving this issue in OVMF:
>>> https://edk2.groups.io/g/devel/topic/102359124
>>>
>>> Cc: Gerd
fmann
> Cc: Philippe Mathieu-Daudé
> Cc: Alex Williamson
> Cc: Cédric Le Goater
> Cc: Laszlo Ersek
> Cc: Dongwon Kim
> Acked-by: Gerd Hoffmann
> Tested-by: Yanghang Liu
> Signed-off-by: Vivek Kasireddy
>
> ---
> v2:
> - Replace the term passthrough with
On 1/19/24 15:29, Peter Maydell wrote:
> On Mon, 15 Jan 2024 at 04:35, Bin Meng wrote:
>>
>> The Arm dtb changes caused an address change:
>>
>> DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x0001)
>> {
>> [ ... ]
>> -Name (MEMA, 0x43C8)
>> +Name (MEMA, 0x43D8)
On 1/15/24 15:46, Bin Meng wrote:
> On Mon, Jan 15, 2024 at 7:40 PM Alex Bennée wrote:
>>
>> Bin Meng writes:
>>
>>> The Arm dtb changes caused an address change:
>>>
>>> DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x0001)
>>> {
>>> [ ... ]
>>> -Name (MEMA, 0x43C8)
>>>
On 11/22/23 17:30, Gerd Hoffmann wrote:
> Hi,
>
>> - in general, we should filter out surrogate code points, for any use.
>> any UCS2 string from the guest that contains a surrogate code point
>> should be considered invalid, and the request should be rejected based
>> just on that.
>
>
On 11/15/23 16:12, Gerd Hoffmann wrote:
> This is the core code for guest <-> host communication. This accepts
> request messages from the guest, dispatches them to the service called,
> and sends back the response message.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/uefi/var-service-core.c |
On 11/20/23 17:50, Gerd Hoffmann wrote:
> On Mon, Nov 20, 2023 at 12:53:45PM +0100, Alexander Graf wrote:
>> Hey Gerd!
>>
>> On 15.11.23 16:12, Gerd Hoffmann wrote:
>>> This patch adds a virtual device to qemu which the uefi firmware can use
>>> to store variables. This moves the UEFI variable
On 11/15/23 16:12, Gerd Hoffmann wrote:
> Add variables for a bunch of GUIDs we will need.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/uefi/var-service-guid.c | 61 ++
> 1 file changed, 61 insertions(+)
> create mode 100644 hw/uefi/var-service-guid.c
>
>
I guess I'll have to see these in use to think anything of them.
(I prefer a more "functional" structuring for a series, where the thing
sort of builds & works from patch#1 onwards, it's only the actual
functionality that is introduced layer by layer. But, that's not an
objection; this patch certainly works as the collection of APIs the rest
is going to implement and call later.)
Again we'll have to keep an eye on the integer types.
with some comments inserted:
Reviewed-by: Laszlo Ersek
Laszlo
On 11/15/23 16:12, Gerd Hoffmann wrote:
> A bunch of #defines and structs copied over from edk2,
> mostly needed to decode and encode the messages in the
> communication buffer.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/hw/uefi/var-service-edk2.h | 184 +
> 1
0x10
> +#define UEFI_VARS_STS_ERR_NOT_SUPPORTED 0x11
> +#define UEFI_VARS_STS_ERR_BAD_BUFFER_SIZE0x12
> +
> +
> +#endif /* QEMU_UEFI_VAR_SERVICE_API_H */
Reviewed-by: Laszlo Ersek
ress width and using it to override the
>>> phys_bits value as shown in this patch.
>>>
>>> Previous attempt at solving this issue in OVMF:
>>> https://edk2.groups.io/g/devel/topic/102359124
>>>
>>> Cc: Gerd Hoffmann
>>> Cc: Philippe Mat
can be done by parsing the IOMMU caps value from sysfs and
> extracting the address width and using it to override the
> phys_bits value as shown in this patch.
>
> Previous attempt at solving this issue in OVMF:
> https://edk2.groups.io/g/devel/topic/102359124
>
> Cc: Gerd Hoffmann
&g
On 11/6/23 11:44, Marc-André Lureau wrote:
> Hi
>
> On Tue, Sep 19, 2023 at 7:09 PM Peter Xu wrote:
>>
>> On Tue, Sep 19, 2023 at 04:51:21PM +0400, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Thu, Sep 7, 2023 at 5:15 PM wrote:
From: Marc-André Lureau
Hi,
This is a
ream.
The patches should hopefully land in edk2-stable202311 (i.e., in the
November release).
The new ArmVirtQemu behavior is as follows:
- just one UART: same as before
- two UARTs: the UEFI console is on the "chosen" UART, and the edk2
DEBUG log is on the "first non-chosen" UART (i.e.
p them.
> v3 will be there.
(Alt. link:
<https://lists.gnu.org/archive/html/qemu-devel/2023-10/msg01164.html>.)
That was on 04 Oct 2023 -- exactly two weeks ago :(
Stefan, can you perhaps apply this v3 series directly from the list?
Thanks,
Laszlo
On 10/2/23 22:32, Laszlo Ersek wrote:
> v2
On 10/9/23 08:32, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Add a "VFIODisplay" subsection whenever "x-ramfb-migrate" is turned on.
>
> Turn it off by default on machines <= 8.1 for compatibility reasons.
>
> Signed-off-by: Ma
On 10/5/23 18:34, Cédric Le Goater wrote:
> On 10/5/23 13:30, marcandre.lur...@redhat.com wrote:
>> From: Marc-André Lureau
>>
>> Add a "VFIODisplay" subsection whenever "x-ramfb-migrate" is turned on.
>>
>> Turn it off by default on machines <= 8.1 for compatibility reasons.
>>
>> Signed-off-by:
; +}
> +
> if (!pdev->failover_pair_id) {
> if (!vfio_migration_realize(vbasedev, errp)) {
> goto out_deregister;
> @@ -3484,6 +3527,7 @@ static const TypeInfo vfio_pci_dev_info = {
>
> static Property vfio_pci_dev_nohotplug_properties[] = {
> DEFINE_PROP_BOOL("ramfb", VFIOPCIDevice, enable_ramfb, false),
> +DEFINE_PROP_ON_OFF_AUTO("x-ramfb-migrate", VFIOPCIDevice, ramfb_migrate,
> ON_OFF_AUTO_AUTO),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/stubs/ramfb.c b/stubs/ramfb.c
> index 48143f3354..cf64733b10 100644
> --- a/stubs/ramfb.c
> +++ b/stubs/ramfb.c
> @@ -2,6 +2,8 @@
> #include "qapi/error.h"
> #include "hw/display/ramfb.h"
>
> +const VMStateDescription ramfb_vmstate = {};
> +
> void ramfb_display_update(QemuConsole *con, RAMFBState *s)
> {
> }
Reviewed-by: Laszlo Ersek
"ramfb",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.post_load = ramfb_post_load,
> +.fields = (VMStateField[]) {
> +VMSTATE_BUFFER_UNSAFE(cfg, RAMFBState, 0, sizeof(RAMFBCfg)),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> RAMFBState *ramfb_setup(Error **errp)
> {
> FWCfgState *fw_cfg = fw_cfg_find();
Identical to v3, which I reviewed, so:
Reviewed-by: Laszlo Ersek
a)
> {
> DeviceClass *dc = DEVICE_CLASS(klass);
>
> set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
> +dc->vmsd = _dev_vmstate;
> dc->realize = ramfb_realizefn;
> dc->desc = "ram framebuffer standalone device";
> dc->user_creatable = true;
> +device_class_set_props(dc, ramfb_properties);
> }
>
> static const TypeInfo ramfb_info = {
Identical to v3, which I reviewed, so:
Reviewed-by: Laszlo Ersek
On 10/5/23 16:16, Laszlo Ersek wrote:
> On 10/5/23 14:01, Cédric Le Goater wrote:
>> On 10/5/23 13:30, marcandre.lur...@redhat.com wrote:
>>> From: Marc-André Lureau
>>>
>>> Hi,
>>>
>>> Implement RAMFB migration, and add properties to
On 10/5/23 14:01, Cédric Le Goater wrote:
> On 10/5/23 13:30, marcandre.lur...@redhat.com wrote:
>> From: Marc-André Lureau
>>
>> Hi,
>>
>> Implement RAMFB migration, and add properties to enable it only on >= 8.2
>> machines, + a few related cleanups.
>>
>> Cedric, did you get the chance to test
On 10/4/23 14:54, Michael S. Tsirkin wrote:
> On Wed, Oct 04, 2023 at 12:08:52PM +0200, Laszlo Ersek wrote:
>> On 10/4/23 11:06, Michael S. Tsirkin wrote:
>>> On Mon, Oct 02, 2023 at 10:32:15PM +0200, Laszlo Ersek wrote:
>>>> Cc: "Michael S. Tsir
On 10/4/23 14:53, Michael S. Tsirkin wrote:
> On Wed, Oct 04, 2023 at 12:11:44PM +0200, Laszlo Ersek wrote:
>> On 10/4/23 10:44, Michael S. Tsirkin wrote:
>>> From: Laszlo Ersek
>>>
>>> (1) The virtio-1.2 specification
>>> <http://docs.oasis-open
On 10/3/23 17:55, Stefan Hajnoczi wrote:
> On Tue, 3 Oct 2023 at 10:41, Michael S. Tsirkin wrote:
>>
>> On Sun, Aug 27, 2023 at 08:29:37PM +0200, Laszlo Ersek wrote:
>>> (1) The virtio-1.0 specification
>>> <http://docs.oasis-open.org/virtio/virtio/v1.0/
On 10/3/23 17:55, Stefan Hajnoczi wrote:
> On Tue, 3 Oct 2023 at 10:41, Michael S. Tsirkin wrote:
>>
>> On Sun, Aug 27, 2023 at 08:29:37PM +0200, Laszlo Ersek wrote:
>>> (1) The virtio-1.0 specification
>>> <http://docs.oasis-open.org/virtio/virtio/v1.0/
On 10/4/23 10:44, Michael S. Tsirkin wrote:
> From: Laszlo Ersek
>
> (1) The virtio-1.2 specification
> <http://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html> writes:
>
>> 3 General Initialization And Device Operation
>> 3.1 Device Initializa
On 10/4/23 11:06, Michael S. Tsirkin wrote:
> On Mon, Oct 02, 2023 at 10:32:15PM +0200, Laszlo Ersek wrote:
>> Cc: "Michael S. Tsirkin" (supporter:vhost)
>
> why the (supporter:vhost) part? not all scripts will cope
> well with text after the mail. If you really want
On 10/3/23 16:25, Michael S. Tsirkin wrote:
> On Tue, Oct 03, 2023 at 03:23:24PM +0200, Laszlo Ersek wrote:
>> On 10/3/23 15:08, Stefan Hajnoczi wrote:
>>> On Tue, 3 Oct 2023 at 08:27, Michael S. Tsirkin wrote:
>>>>
>>>> On Mon, Oct 02, 2023 at 05:13:26
On 10/3/23 15:08, Stefan Hajnoczi wrote:
> On Tue, 3 Oct 2023 at 08:27, Michael S. Tsirkin wrote:
>>
>> On Mon, Oct 02, 2023 at 05:13:26PM -0400, Stefan Hajnoczi wrote:
>>> One more question:
>>>
>>> Why is the disabled state not needed by regular (non-vhost) virtio-net
>>> devices?
>>
>> Tap
On 10/3/23 12:47, Marc-André Lureau wrote:
> Hi
>
> On Tue, Oct 3, 2023 at 2:17 PM Cédric Le Goater wrote:
>>
>> On 10/3/23 10:56, marcandre.lur...@redhat.com wrote:
>>> From: Marc-André Lureau
>>>
>>> Add a "VFIODisplay" subsection whenever "x-ramfb-migrate" is turned on.
>>>
>>> Turn it off
On 10/3/23 10:56, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Add a "VFIODisplay" subsection whenever "x-ramfb-migrate" is turned on.
>
> Turn it off by default on machines <= 8.1 for compatibility reasons.
>
> Signed-off-by: Marc-André Lureau
> ---
> hw/vfio/pci.h | 3
_POINTER + VMSTATE_BUFFER_UNSAFE chain.
That's not to say I could have *completed* the patch myself, of course.
:) (From the many things, I didn't know that it was
VMSTATE_BUFFER_UNSAFE that we'd need -- but I certainly thought of
VMSTATE_STRUCT_POINTER for the higher-level devices.)
It's interesting that we don't have to do this in a "subsection" here --
this device used to have no VMStateDescription at all!
FWIW (patches #3 and #4):
Reviewed-by: Laszlo Ersek
Laszlo
On 10/2/23 22:38, Alex Williamson wrote:
> On Mon, 2 Oct 2023 21:41:55 +0200
> Laszlo Ersek wrote:
>
>> On 10/2/23 21:26, Alex Williamson wrote:
>>> On Mon, 2 Oct 2023 20:24:11 +0200
>>> Laszlo Ersek wrote:
>>>
>>>> On 10/2/23 16:41, Alex
l S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Garzarella
Tested-by: Albert Esteve
Reviewed-by: Eugenio Pérez
--
comments.
Retested.
Laszlo Ersek (7):
vhost-user: strip superfluous whitespace
vhost-user: tighten "reply_supported" scope in "set_vring_addr"
vhost-user: factor out "vhost_user_write_sync"
vhost-user: flatten "enforce_reply" into "vhost_use
uot;.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Garzarella
Tested-by: Albert Esteve
parate VHOST_USER_GET_FEATURES *exchange*, which requires
a backend response regardless of VHOST_USER_PROTOCOL_F_REPLY_ACK.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Sig
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Stefano Garzarella
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Albert Esteve
ange.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Stefano Garzarella
Tested-by: Albert Esteve
Reviewed-by: Philippe Mathieu-Daudé
Review
gio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Garzarella
Tested-by: Albert Esteve
Reviewed-by: Eugenio Pérez
---
Notes:
v3:
- pick up R-b from Eugenio, T-b from Albert
v2:
- pick
vement -- no observable change.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Stefano Garzarella
Tested-by: Albert Esteve
Reviewed-by: Phil
On 9/6/23 09:12, Albert Esteve wrote:
>
>
> On Thu, Aug 31, 2023 at 9:14 AM Laszlo Ersek <mailto:ler...@redhat.com>> wrote:
>
> On 8/30/23 15:40, Laszlo Ersek wrote:
> > Cc: "Michael S. Tsirkin" mailto:m...@redhat.com>>
> (
On 10/2/23 21:26, Alex Williamson wrote:
> On Mon, 2 Oct 2023 20:24:11 +0200
> Laszlo Ersek wrote:
>
>> On 10/2/23 16:41, Alex Williamson wrote:
>>> On Mon, 2 Oct 2023 15:38:10 +0200
>>> Cédric Le Goater wrote:
>>>
>>>> On 10/2/23 13:11,
On 10/2/23 16:41, Alex Williamson wrote:
> On Mon, 2 Oct 2023 15:38:10 +0200
> Cédric Le Goater wrote:
>
>> On 10/2/23 13:11, marcandre.lur...@redhat.com wrote:
>>> From: Marc-André Lureau
>>>
>>> RAMFB migration was unsupported until now, let's make it conditional.
>>> The following patch will
On 10/1/23 00:14, Laszlo Ersek wrote:
> On 9/29/23 13:17, Marc-André Lureau wrote:
>> Hi
>>
>> On Wed, Sep 27, 2023 at 7:46 PM Laszlo Ersek wrote:
>>>
>>> On 9/19/23 15:19, Laszlo Ersek wrote:
>>>> The fw_cfg DMA write callback in ramfb pr
e.h"
> -#include "sysemu/numa.h"
> #include "sysemu/xen.h"
> -#include "qemu/error-report.h"
> #include "sysemu/qtest.h"
> -#include "hw/pci/pci.h"
> #include "hw/mem/nvdimm.h"
> #include "migration/global_state.h"
> -#include "migration/vmstate.h"
> #include "exec/confidential-guest-support.h"
> -#include "hw/virtio/virtio.h"
> #include "hw/virtio/virtio-pci.h"
> #include "hw/virtio/virtio-net.h"
>
Acked-by: Laszlo Ersek
;
> -#include "hw/mem/pc-dimm.h"
> #include "hw/mem/nvdimm.h"
> -#include "hw/cxl/cxl.h"
> #include "hw/cxl/cxl_host.h"
> -#include "qapi/error.h"
> -#include "qapi/qapi-visit-common.h"
> -#include "qapi/qapi-visit-machine.h"
> -#include "qapi/visitor.h"
> -#include "hw/core/cpu.h"
> #include "hw/usb.h"
> #include "hw/i386/intel_iommu.h"
> #include "hw/net/ne2000-isa.h"
> -#include "standard-headers/asm-x86/bootparam.h"
> #include "hw/virtio/virtio-iommu.h"
> #include "hw/virtio/virtio-md-pci.h"
> #include "hw/i386/kvm/xen_overlay.h"
> #include "hw/i386/kvm/xen_evtchn.h"
> #include "hw/i386/kvm/xen_gnttab.h"
> #include "hw/i386/kvm/xen_xenstore.h"
> -#include "sysemu/replay.h"
> -#include "target/i386/cpu.h"
> #include "e820_memory_layout.h"
> -#include "fw_cfg.h"
> #include "trace.h"
> #include CONFIG_DEVICES
>
Acked-by: Laszlo Ersek
On 10/2/23 13:11, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> For compatibility reasons.
>
> Signed-off-by: Marc-André Lureau
> ---
> hw/core/machine.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
>
On 10/2/23 13:11, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> RAMFB migration was unsupported until now, let's make it conditional.
> The following patch will prevent machines <= 8.1 to migrate it.
>
> Signed-off-by: Marc-André Lureau
> ---
> hw/vfio/pci.h
On 10/2/23 13:11, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Implementing RAMFB migration is quite straightforward. One caveat is to
> treat the whole RAMFBCfg as a blob, since that's what is exposed to the
> guest directly. This avoid having to fiddle with endianness
On 10/2/23 14:01, Marc-André Lureau wrote:
> Hi
>
> On Mon, Oct 2, 2023 at 3:12 PM wrote:
>>
>> From: Marc-André Lureau
>>
>> Implementing RAMFB migration is quite straightforward. One caveat is to
>> treat the whole RAMFBCfg as a blob, since that's what is exposed to the
>> guest directly.
On 10/2/23 08:57, Michael S. Tsirkin wrote:
> On Mon, Oct 02, 2023 at 03:56:03AM +0200, Laszlo Ersek wrote:
>> On 10/1/23 21:25, Michael S. Tsirkin wrote:
>>> Not this actually - v2 of this.
>>
>> Thank you, but:
>>
>> - Stefan's question should be answ
On 10/1/23 18:07, Marc-André Lureau wrote:
> Hi Laszlo
>
> On Sun, Oct 1, 2023 at 4:20 AM Laszlo Ersek wrote:
>>
>> On 10/1/23 00:14, Laszlo Ersek wrote:
>>> On 9/29/23 13:17, Marc-André Lureau wrote:
> [..]
>>>> fwiw, my migration support patch is st
On 10/1/23 21:25, Michael S. Tsirkin wrote:
> Not this actually - v2 of this.
Thank you, but:
- Stefan's question should be answered still IMO (although if you pick
up this series, then that could be interpreted as "QEMU bug, not spec bug")
- I was supposed to update the commit message on 7/7
On 10/1/23 08:15, Mark Cave-Ayland wrote:
> On 30/09/2023 22:28, Laszlo Ersek wrote:
>
>> On 9/29/23 09:57, Mark Cave-Ayland wrote:
>>> On 26/09/2023 09:00, Marc-André Lureau wrote:
>>>
>>>> Hi Laszlo
>>>>
>>>> On Mon, Sep 2
On 10/1/23 00:14, Laszlo Ersek wrote:
> On 9/29/23 13:17, Marc-André Lureau wrote:
>> Hi
>>
>> On Wed, Sep 27, 2023 at 7:46 PM Laszlo Ersek wrote:
>>>
>>> On 9/19/23 15:19, Laszlo Ersek wrote:
>>>> The fw_cfg DMA write callback in ramfb pr
On 9/29/23 13:17, Marc-André Lureau wrote:
> Hi
>
> On Wed, Sep 27, 2023 at 7:46 PM Laszlo Ersek wrote:
>>
>> On 9/19/23 15:19, Laszlo Ersek wrote:
>>> The fw_cfg DMA write callback in ramfb prepares a new display surface in
>>> QEMU; this new surface is
On 9/29/23 09:57, Mark Cave-Ayland wrote:
> On 26/09/2023 09:00, Marc-André Lureau wrote:
>
>> Hi Laszlo
>>
>> On Mon, Sep 25, 2023 at 7:36 PM Laszlo Ersek wrote:
>>> Has this been queued by someone? Both Gerd and Marc-André are "odd
>>> fixe
On 9/19/23 15:19, Laszlo Ersek wrote:
> The fw_cfg DMA write callback in ramfb prepares a new display surface in
> QEMU; this new surface is put to use ("swapped in") upon the next display
> update. At that time, the old surface (if any) is released.
>
> If the guest trig
On 9/15/23 13:50, Marc-André Lureau wrote:
> Hi Laszlo
>
> On Wed, Sep 13, 2023 at 6:50 PM Laszlo Ersek wrote:
>>
>> Fix a recent regression (crash) in the multihead check; clean up the
>> code some more.
>>
>> Cc: "Marc-André Lureau"
Ping -- Michael, any comments please? This set (now at v2) has been
waiting on your answer since Aug 30th.
Laszlo
On 9/5/23 08:30, Laszlo Ersek wrote:
> Michael,
>
> On 8/30/23 17:37, Stefan Hajnoczi wrote:
>> On Wed, 30 Aug 2023 at 09:30, Laszlo Ersek wrote:
>>>
>
On 9/20/23 19:35, Stephen Brennan wrote:
> Hi Jon,
>
> Jon Doron writes:
>> Hi Stephen,
>> Like you have said the reason is as I wrote in the commit message,
>> without "fixing" the vaddr GDB is messing up mapping and working with
>> the generated core file.
>
> For the record I totally love
appears to date back to the introducion of ramfb (995b30179bdc,
"hw/display: add ramfb, a simple boot framebuffer living in guest ram",
2018-06-18).
Cc: Gerd Hoffmann (maintainer:ramfb)
Cc: qemu-sta...@nongnu.org
Fixes: 995b30179bdc
Signed-off-by: Laszlo Ersek
---
hw/display/ramfb.c
qemu_console_is_multihead() is only called from within "ui/console.c";
make it static.
Cc: "Marc-André Lureau" (odd fixer:Graphics)
Cc: Gerd Hoffmann (odd fixer:Graphics)
Signed-off-by: Laszlo Ersek
---
include/ui/console.h | 1 -
ui/console.c | 2 +-
2 files
of "c" to
qemu_graphic_console_is_multihead().
Thus, look for the *first* (and possibly *only*) graphical console, if
any, that refers to the same "device" as "c", but by a different "head"
number.
Cc: "Marc-André Lureau" (odd fixer:Graphics)
Cc:
qemu_console_is_multihead().
Rework qemu_console_is_multihead() with plain old C language field
accesses.
Cc: "Marc-André Lureau" (odd fixer:Graphics)
Cc: Gerd Hoffmann (odd fixer:Graphics)
Signed-off-by: Laszlo Ersek
---
ui/console.c | 16
1 file changed, 8 insertions(+), 8 deletion
operty_find_err() at qom/object.c:1314:
> qemu: Property 'qemu-fixed-text-console.device' not found
> Aborted (core dumped)
This is effectively an unchecked downcast. Make it checked: only consider
such console candidates that are themselves QemuGraphicConsole instances.
Cc: "Marc-André L
Fix a recent regression (crash) in the multihead check; clean up the
code some more.
Cc: "Marc-André Lureau" (odd fixer:Graphics)
Cc: Gerd Hoffmann (odd fixer:Graphics)
Thanks,
Laszlo
Laszlo Ersek (4):
ui/console: make qemu_console_is_multihead() static
ui/console:
On 9/12/23 18:40, Philippe Mathieu-Daudé wrote:
> On 12/9/23 17:55, Laszlo Ersek wrote:
>> - The comment is incorrectly indented / formatted.
>>
>> - The comment states a 8MB limit, even though the code enforces a 16MB
>> limit.
>>
>> Both of these warts
TCG CPUs)
Cc: Eduardo Habkost (maintainer:X86 TCG CPUs)
Cc: qemu-triv...@nongnu.org
Fixes: 0657c657eb37
Signed-off-by: Laszlo Ersek
---
Notes:
v2:
- use the binary units MiB, KiB, GiB comprehensively in the comment
hw/i386/pc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-
(maintainer:X86 TCG CPUs)
Cc: qemu-triv...@nongnu.org
Fixes: 0657c657eb37
Signed-off-by: Laszlo Ersek
---
hw/i386/pc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 54838c0c411d..d06b8da49cae 100644
--- a/hw/i386/pc.c
+++ b/hw/
On 9/11/23 15:12, Laszlo Ersek wrote:
> On 9/11/23 10:53, Gerd Hoffmann wrote:
>> On Mon, Sep 11, 2023 at 12:12:43PM +0400, Marc-André Lureau wrote:
>>>> Gerd, here's the question for you: why are "device" and "head" QOM
>>>>
On 9/11/23 10:53, Gerd Hoffmann wrote:
> On Mon, Sep 11, 2023 at 12:12:43PM +0400, Marc-André Lureau wrote:
>>> Gerd, here's the question for you: why are "device" and "head" QOM
>>> properties in the first place? What are they needed for?
>>>
>>
>> You get QOM tree introspection (ex: (qemu)
On 9/8/23 01:47, Laszlo Ersek wrote:
> I don't know why qemu_console_is_multihead() used a lot of QOM
> trickery for this in the first place, but here's what I'd propose as
> fix -- simply try to locate a QemuGraphicConsole in "consoles" that
> refer
Question for Gerd below:
On 9/7/23 14:29, Philippe Mathieu-Daudé wrote:
> On 7/9/23 13:25, Laszlo Ersek wrote:
>> This is with QEMU v8.1.0-391-gc152379422a2.
>>
>> I use the command line from (scroll to the bottom):
>>
>> https://github.com/tianocore/edk2/commi
On 9/7/23 17:59, Eugenio Perez Martin wrote:
> On Wed, Aug 30, 2023 at 3:41 PM Laszlo Ersek wrote:
>>
>> (1) The virtio-1.2 specification
>> <http://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html> writes:
>>
>>> 3 General Initializa
This is with QEMU v8.1.0-391-gc152379422a2.
I use the command line from (scroll to the bottom):
https://github.com/tianocore/edk2/commit/49f06b664018
(with "-full-screen" removed).
The crash is as follows:
Unexpected error in object_property_find_err() at
On 9/6/23 09:12, Albert Esteve wrote:
>
>
> On Thu, Aug 31, 2023 at 9:14 AM Laszlo Ersek <mailto:ler...@redhat.com>> wrote:
>
> On 8/30/23 15:40, Laszlo Ersek wrote:
> > Cc: "Michael S. Tsirkin" mailto:m...@redhat.com>>
> (
Michael,
On 8/30/23 17:37, Stefan Hajnoczi wrote:
> On Wed, 30 Aug 2023 at 09:30, Laszlo Ersek wrote:
>>
>> On 8/30/23 14:10, Stefan Hajnoczi wrote:
>>> On Sun, 27 Aug 2023 at 14:31, Laszlo Ersek wrote:
>>>>
>>>> (1) The virtio-1.0 specificatio
On 8/30/23 15:40, Laszlo Ersek wrote:
> In order to avoid a forward-declaration for "vhost_user_write_sync" in a
> subsequent patch, hoist "vhost_user_write_sync" ->
> "vhost_user_get_features" -> "vhost_user_get_u64" just above
On 8/30/23 15:40, Laszlo Ersek wrote:
> In the vhost_user_set_vring_addr() function, we calculate
> "reply_supported" unconditionally, even though we'll only need it if
> "wait_for_reply" is also true.
>
> Restrict the scope of "reply_supported" to
On 8/30/23 15:40, Laszlo Ersek wrote:
> Cc: "Michael S. Tsirkin" (supporter:vhost)
> Cc: Eugenio Perez Martin
> Cc: German Maglione
> Cc: Liu Jiang
> Cc: Sergio Lopez Pascual
> Cc: Stefano Garzarella
> Signed-off-by: Laszlo Ersek
> Reviewed-by: Stefano Garz
l S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Garzarella
---
Notes:
v2:
- pick up R-b's
vement -- no observable change.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Stefano Garzarella
---
Notes:
v2:
_ENABLE, and waiting
for the reply, if the VHOST_USER_PROTOCOL_F_REPLY_ACK vhost-user feature
has been negotiated, or
- performing a separate VHOST_USER_GET_FEATURES *exchange*, which requires
a backend response regardless of VHOST_USER_PROTOCOL_F_REPLY_ACK.
Cc: "Michael S. Tsirkin" (su
uot;.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Garzarella
---
Notes:
v2:
-
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Stefano Garzarella
---
Notes:
v2:
- pick up Stefano's R-b
hw/virtio/vh
o Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Thanks,
Laszlo
Laszlo Ersek (7):
vhost-user: strip superfluous whitespace
vhost-user: tighten "reply_supported" scope in "set_vring_addr"
vhost-user: factor out "v
ange.
Cc: "Michael S. Tsirkin" (supporter:vhost)
Cc: Eugenio Perez Martin
Cc: German Maglione
Cc: Liu Jiang
Cc: Sergio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Stefano Garzarella
---
Notes:
v2:
- pick up Stefano's R-b
hw/virtio/vhost
gio Lopez Pascual
Cc: Stefano Garzarella
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Stefano Garzarella
---
Notes:
v2:
- pick up R-b's from Phil and Stefano
- rename "vhost_user_write_msg" to "vhost_user_write_sync" (
On 8/30/23 14:10, Stefan Hajnoczi wrote:
> On Sun, 27 Aug 2023 at 14:31, Laszlo Ersek wrote:
>>
>> (1) The virtio-1.0 specification
>> <http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html> writes:
>>
>>> 3 General Initialization And Device
On 8/30/23 11:14, Laszlo Ersek wrote:
> On 8/30/23 10:31, Stefano Garzarella wrote:
>> On Sun, Aug 27, 2023 at 08:29:33PM +0200, Laszlo Ersek wrote:
>>> The tails of the "vhost_user_set_vring_addr" and "vhost_user_set_u64"
>>> functions are now byte
On 8/30/23 10:48, Stefano Garzarella wrote:
> On Sun, Aug 27, 2023 at 08:29:30PM +0200, Laszlo Ersek wrote:
>> The last patch in the series states and fixes the problem; prior patches
>> only refactor the code.
>
> Thanks for the fix and great cleanup!
>
> I fully r
On 8/30/23 10:39, Stefano Garzarella wrote:
> On Sun, Aug 27, 2023 at 08:29:37PM +0200, Laszlo Ersek wrote:
>> (1) The virtio-1.0 specification
>> <http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html> writes:
>
> What about referring the latest spec availabl
1 - 100 of 4203 matches
Mail list logo
