safe.
> >
> >
> > On Mon, Jul 14, 2025 at 05:41:22PM +0100, David Woodhouse wrote:
> > > On 14 July 2025 15:28:09 GMT+01:00, Yi Liu
> > > wrote:
> > > > Hi David,
> > > >
> > > > On 2025/7/14 16:00, David Woodhouse wro
On 14 July 2025 15:28:09 GMT+01:00, Yi Liu wrote:
>Hi David,
>
>On 2025/7/14 16:00, David Woodhouse wrote:
>> From: David Woodhouse
>>
>> FreeBSD does both, and this appears to be perfectly valid. The VT-d
>> spec even talks about the ordering (the sta
On Sun, 2025-07-13 at 17:29 -0400, Michael S. Tsirkin wrote:
>
> > + if (inv_desc->lo & VTD_INV_DESC_WAIT_IF)
> > + vtd_generate_completion_event(s);
> >
> > /* FIXME: need to be masked with HAW? */
> > dma_addr_t status_addr = inv_desc->hi;
>
> Follow QEM
From: David Woodhouse
FreeBSD does both, and this appears to be perfectly valid. The VT-d
spec even talks about the ordering (the status write should be done
first, unsurprisingly).
We certainly shouldn't assert() and abort QEMU if the guest asks for
both.
Fixes: ed7b8fbcfb88 ("i
From: David Woodhouse
FreeBSD does both, and this appears to be perfectly valid. The VT-d
spec even talks about the ordering (the status write should be done
first, unsurprisingly).
We certainly shouldn't assert() and abort QEMU if the guest asks for
both.
Fixes: ed7b8fbcfb88 ("i
_chk (__pri, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack
> ());
> |
> ^~
>
> Add a check that 'value' is not null before passing it to
> trace_xs_node_read().
>
> Fixes: e6cdeee95990 ("hw/xen: Add xs
; file impl should get discarded by the linker automatically, avoiding
> a duplicate symbols problem.
Thanks.
In that case,
Acked-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On Thu, 2025-05-08 at 17:01 +0200, Philippe Mathieu-Daudé wrote:
> Cc'ing Zhao
>
> On 8/5/25 15:58, Daniel P. Berrangé wrote:
Hm, what mailer does that? Does it mean August 5th or May 8th? Even in
the original definition of RFC821 they knew not to use dates in those
forms :)
> > This removes the
On Fri, 2025-02-07 at 14:37 +, David Woodhouse wrote:
> From: David Woodhouse
>
> At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so
> the correct MSR index to use for the hypercall page isn't known.
>
> Rather than setting it to the
On Tue, 2025-04-01 at 13:58 +0200, Philippe Mathieu-Daudé wrote:
> On 1/4/25 13:43, David Woodhouse wrote:
> > On Tue, 2025-04-01 at 13:30 +0200, Philippe Mathieu-Daudé wrote:
> > > On 1/4/25 13:18, Philippe Mathieu-Daudé wrote:
> > > > Hi David,
> > > >
On Tue, 2025-04-01 at 13:30 +0200, Philippe Mathieu-Daudé wrote:
> On 1/4/25 13:18, Philippe Mathieu-Daudé wrote:
> > Hi David,
> >
> > On 8/1/25 14:51, David Woodhouse wrote:
> > > On Tue, 2024-12-31 at 21:22 +0100, Philippe Mathieu-Daudé wrote:
> > > >
On Fri, 2025-02-07 at 14:34 +, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock device only has a reset method in order to plug its memory
> region into the system memory. It was originally done this way in order
> to defer the memory_region_add_subregion
On 7 February 2025 15:37:40 GMT, Sean Christopherson wrote:
>On Fri, Feb 07, 2025, David Woodhouse wrote:
>> From: David Woodhouse
>>
>> At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so
>> the correct MSR index to use for the hypercall
From: David Woodhouse
Block devices don't work in PV Grub (0.9x) if there is no mode specified. It
complains: "Error ENOENT when reading the mode"
Signed-off-by: David Woodhouse
---
hw/block/xen-block.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/block/xen-block.c
From: David Woodhouse
At the time kvm_xen_init() is called, hyperv_enabled() doesn't yet work, so
the correct MSR index to use for the hypercall page isn't known.
Rather than setting it to the default and then shifting it later for the
Hyper-V case with a confusing second call to kv
From: David Woodhouse
The vmclock device only has a reset method in order to plug its memory
region into the system memory. It was originally done this way in order
to defer the memory_region_add_subregion_overlap() from vmclock_realize(),
but that doesn't seem to be necessary (any l
On Tue, 2025-02-04 at 14:52 +, Peter Maydell wrote:
> On Tue, 4 Feb 2025 at 14:17, David Woodhouse wrote:
> >
> > On Tue, 2025-02-04 at 13:49 +, Peter Maydell wrote:
> > > On Thu, 16 Jan 2025 at 14:05, David Woodhouse
> > > wrote:
> > > >
On Tue, 2025-02-04 at 13:49 +, Peter Maydell wrote:
> On Thu, 16 Jan 2025 at 14:05, David Woodhouse
> wrote:
> >
> > From: David Woodhouse
> >
> > The vmclock device addresses the problem of live migration with
> > precision clocks. The tolerances of a
On Fri, 2025-01-17 at 11:49 +0100, Phil Dennis-Jordan wrote:
>
> This note made me realise that my feature addition (macOS PV graphics
> device) that caused the regression requiring my patch in this series
> hasn't made it into the changelog. I'd be happy to add it myself, but
> I don't have a wik
On Thu, 2025-01-16 at 16:57 +0100, Philippe Mathieu-Daudé wrote:
> On 16/1/25 16:32, David Woodhouse wrote:
> > On Thu, 2025-01-16 at 16:15 +0100, Philippe Mathieu-Daudé wrote:
> > >
> > > > --- a/hw/acpi/Kconfig
> > > > +++ b/hw/acpi/Kconfig
>
On Thu, 2025-01-16 at 09:44 -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 16, 2025 at 01:59:40PM +0000, David Woodhouse wrote:
> > (Posting one last time with the header commits split out).
> >
> > The vmclock device addresses the problem of live migration with
>
On Thu, 2025-01-16 at 16:57 +0100, Philippe Mathieu-Daudé wrote:
>
> > > I'm only seeing e820_add_entry (I386) and ACPI API called. So:
> > >
> > > depends on I386 && ACPI
>
> Actually the Kconfig should be:
>
> select ACPI
> depends on I386
Ack.
smime.p7s
Description: S/MIM
On Thu, 2025-01-16 at 16:15 +0100, Philippe Mathieu-Daudé wrote:
>
> > --- a/hw/acpi/Kconfig
> > +++ b/hw/acpi/Kconfig
> > @@ -60,6 +60,11 @@ config ACPI_VMGENID
> > default y
> > depends on PC
> >
> > +config ACPI_VMCLOCK
> > + bool
> > + default y
> > + depends on PC
>
On Thu, 2025-01-16 at 09:44 -0500, Michael S. Tsirkin wrote:
>
> Reviewed-by: Michael S. Tsirkin
>
> feel free to merge.
Thanks. I've added your R-b to all three (replacing your previous
Acked-by), and will post the PR tomorrow to give others a chance to
comment on the header bits.
smime.p7s
On Thu, 2025-01-16 at 15:07 +0100, Paul Durrant wrote:
> On 16/01/2025 14:59, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Signed-off-by: David Woodhouse
> > ---
> > include/standard-headers/linux/vmclock-abi.h | 182 +++
&g
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
On Thu, 2025-01-16 at 02:05 -0500, Michael S. Tsirkin wrote:
>
> Yes pls do. You can add:
>
> Acked-by: Michael S. Tsirkin
>
> but, I noticed checkpatch warnings:
>
> 3634039b93cc51816263e0cb5ba32e1b61142d5d:89: WARNING: added, moved or
> deleted file(s), does MAINTAINERS need updating?
> 3634
omment improvements.
v3:
• Add comment that vmclock-abi.h will come from the Linux kernel
headers once it gets merged there.
v2:
• Change esterror/maxerror fields to nanoseconds.
• Change to officially assigned AMZNC10C ACPI HID.
• Fix little-endian handling of fields in update.
David Woodhous
From: David Woodhouse
Signed-off-by: David Woodhouse
---
include/standard-headers/linux/vmclock-abi.h | 182 +++
linux-headers/linux/iommufd.h| 31 ++--
linux-headers/linux/stddef.h | 13 +-
3 files changed, 212 insertions(+), 14 deletions
From: David Woodhouse
This isn't a Linux-specific ABI but Linux does export the header file
with its definition, so import it from there instead of creating our own.
Signed-off-by: David Woodhouse
Acked-by: Michael S. Tsirkin
---
scripts/update-linux-headers.sh | 1 +
1 file chang
On Thu, 2024-07-18 at 09:20 +0200, Stefano Garzarella wrote:
> If a file imported from Linux is touched, emit a warning and suggest
> using scripts/update-linux-headers.sh.
>
> Also check that updating imported files from Linux are not mixed with
> other changes, in which case emit an error.
>
>
}_exit_notifier() declarations.
Fixes: f5ab12caba4f ("ui & main loop: Redesign of system-specific main
thread event handling")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2771
Reported-by: David Woodhouse
Signed-off-by: Phil Dennis-Jordan
Tested-by: David Woodhouse
Signed
From: David Woodhouse
The following changes since commit 7433709a147706ad7d1956b15669279933d0f82b:
Merge tag 'hw-misc-20250113' of https://github.com/philmd/qemu into staging
(2025-01-14 12:46:56 -0500)
are available in the Git repository at:
git://git.infradead.org/users/dwmw
From: David Woodhouse
This returns the full contents of the node, having created the node path
from the printf-style format string provided in its arguments.
This will save various callers from having to do so for themselves (and
from using xs_node_scanf() with the non-portable %ms format
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/xen/xen_pvdev.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..c9143ba259 100644
--- a/hw/xen
From: David Woodhouse
Reduce some duplication.
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/xen/trace-events | 1 -
hw/xen/xen-bus-helper.c | 15 ++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/hw/xen/trace
From: David Woodhouse
When attempting to read the 'output' node, interpret any error *other*
than ENOENT as a fatal error. For ENOENT, fall back to serial_hd() to
find a character device, or create a null device.
Do not attempt to prepend to errp when serial_hd() fails; the error
isn&
From: David Woodhouse
Now that xs_node_read() can construct a node path, no need to open-code it.
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/char/xen_console.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff
le allocation of the same string. Instead use
xs_node_read() to read the whole xenstore node.
Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create
XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau Mo
From: David Woodhouse
Now that xs_node_read() can construct a node path, no need to open-code it.
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/net/xen_nic.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw
On Wed, 2025-01-15 at 20:17 +0100, Phil Dennis-Jordan wrote:
>
> BQL_LOCK_GUARD expands to a call to bql_auto_lock(), which in turn
> defends against recursive locking by checking bql_locked().
>
> https://gitlab.com/qemu-project/qemu/-/blob/master/include/qemu/main-loop.h#L377
>
> I think that
On 15 January 2025 23:42:41 CET, "Michael S. Tsirkin" wrote:
>On Wed, Jan 15, 2025 at 07:15:18PM +0100, David Woodhouse wrote:
>> On Wed, 2025-01-15 at 13:08 -0500, Michael S. Tsirkin wrote:
>> > The following changes since commit
>> > 7433709a147706ad7d1956b
On Wed, 2025-01-15 at 13:08 -0500, Michael S. Tsirkin wrote:
> The following changes since commit 7433709a147706ad7d1956b15669279933d0f82b:
>
> Merge tag 'hw-misc-20250113' of https://github.com/philmd/qemu into staging
> (2025-01-14 12:46:56 -0500)
>
> are available in the Git repository at:
ers.
>
> Additionally, the BQL promise is now documented at the
> qemu_{add,remove}_exit_notifier() declarations.
>
> Fixes: f5ab12caba4f ("ui & main loop: Redesign of system-specific main
> thread event handling")
> Resolves: https://gitlab.com/qemu-project/qemu
h now looks like
this:
From 8b44a3e39f36540818d99ef8cf79e64bba1ed9c3 Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Wed, 15 Jan 2025 15:46:06 +
Subject: [PATCH] hw/xen: Fix errp handling in xen_console
When attempting to read the 'output' node, interpret any error *other*
th
From: David Woodhouse
Reduce some duplication.
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/xen/trace-events | 1 -
hw/xen/xen-bus-helper.c | 15 ++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/hw/xen/trace
_read().
• Clean up errp handling for xen-console 'output' node.
• Improve comment for xs_node_read().
v2:
• Add xs_node_read() helper.
• Also fix usage of %ms in xen-block.c
David Woodhouse (6):
hw/xen: Add xs_node_read() helper function
hw/xen: Use xs_node_read() from
From: David Woodhouse
This returns the full contents of the node, having created the node path
from the printf-style format string provided in its arguments.
This will save various callers from having to do so for themselves (and
from using xs_node_scanf() with the non-portable %ms format
From: David Woodhouse
When attempting to read the 'output' node, interpret any error *other*
than ENOENT as a fatal error. For ENOENT, fall back to serial_hd() to
find a character device, or create a null device.
Do not attempt to prepend to errp when serial_hd() fails; the error
isn&
From: David Woodhouse
Now that xs_node_read() can construct a node path, no need to open-code it.
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/char/xen_console.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff
le allocation of the same string. Instead use
xs_node_read() to read the whole xenstore node.
Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create
XenDevice-s...')
Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
Signed-off-by: Roger Pau M
From: David Woodhouse
Now that xs_node_read() can construct a node path, no need to open-code it.
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/net/xen_nic.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Acked-by: Roger Pau Monné
---
hw/xen/xen_pvdev.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..c9143ba259 100644
--- a/hw/xen
ore path
> as error_setg() will not set `errp` again.
>
> Could you keep ignoring errors from xs_node_read() like it was done with
> xs_node_scanf() (I mean pass `NULL` instead of `errp`)? And we will need
> another patch to fix the wrong use of `error_prepend()` and use
> `error_setg` i
On Wed, 2025-01-15 at 15:34 +0100, Roger Pau Monné wrote:
> On Fri, Jan 10, 2025 at 10:02:53AM +0000, David Woodhouse wrote:
> > On Fri, 2025-01-10 at 10:35 +0100, Roger Pau Monne wrote:
> > > Hello,
> > >
> > > First patch from David introduces a new helper
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/xen/xen_pvdev.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..c9143ba259 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -22,6 +22,7
From: David Woodhouse
Now that xs_node_read() can construct a node path, no need to open-code it.
Signed-off-by: David Woodhouse
---
hw/char/xen_console.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index
From: David Woodhouse
Now that xs_node_read() can construct a node path, no need to open-code it.
Signed-off-by: David Woodhouse
---
hw/net/xen_nic.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 97ebd9fa30
From: David Woodhouse
Reduce some duplication.
Signed-off-by: David Woodhouse
---
hw/xen/trace-events | 1 -
hw/xen/xen-bus-helper.c | 15 ++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 461dee7b23
rted by the FreeBSD scanf libc
> implementation.
>
> Thanks, Roger.
Thanks. I've got a handful of non-bugfix cleanups to use the new
xs_node_read in my tree at
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xs_node_read
David Woodhouse (4):
hw/xen: Use xs_node_re
('hw/xen: update Xen console to XenDevice model')
> Signed-off-by: Roger Pau Monné
Reviewed-by: David Woodhouse
Thanks.
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2025-01-10 at 09:16 +0100, Philippe Mathieu-Daudé wrote:
> On 10/1/25 09:08, David Woodhouse wrote:
> > On Thu, 2025-01-09 at 17:55 +0100, Roger Pau Monné wrote:
> > > On Thu, Jan 09, 2025 at 11:25:13AM +0000, David Woodhouse wrote:
> > > > On Thu, 2025-01-09
On Thu, 2025-01-09 at 17:55 +0100, Roger Pau Monné wrote:
> On Thu, Jan 09, 2025 at 11:25:13AM +0000, David Woodhouse wrote:
> > On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
> > >
> > > > char label[32];
> > > > XenDevice *xe
On Thu, 2025-01-09 at 11:03 -0500, Stefan Hajnoczi wrote:
> On Thu, 9 Jan 2025 at 09:14, David Woodhouse wrote:
> >
> > On Thu, 2025-01-09 at 09:01 -0500, Stefan Hajnoczi wrote:
> > > On Thu, 9 Jan 2025 at 08:18, David Woodhouse wrote:
> > > >
> > >
On Thu, 2025-01-09 at 09:01 -0500, Stefan Hajnoczi wrote:
> On Thu, 9 Jan 2025 at 08:18, David Woodhouse wrote:
> >
> > On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote:
> > > On Wed, 8 Jan 2025 at 06:11, David Woodhouse
> > > wrote:
> > >
&
On Thu, 2025-01-09 at 10:48 +, David Woodhouse wrote:
> From: David Woodhouse
>
> The following changes since commit 3f8bcbba3b320c610689576fc47595f1076198dd:
>
> Merge tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu into
> staging (2025-01
On Thu, 2025-01-09 at 07:52 -0500, Stefan Hajnoczi wrote:
> On Wed, 8 Jan 2025 at 06:11, David Woodhouse
> wrote:
> >
> > From: David Woodhouse
> >
> > The following changes since commit
> > 6528013b5f5ba6bb3934b7f5fe57a3110680530f:
> >
> >
On Thu, 2025-01-09 at 08:00 -0500, Michael S. Tsirkin wrote:
>
> It's tagged, will be in the next pull. Thanks!
Thank you.
smime.p7s
Description: S/MIME cryptographic signature
On Wed, 2025-01-08 at 14:26 +, Bernhard Beschow wrote:
>
>
> Am 8. Januar 2025 09:25:28 UTC schrieb Bernhard Beschow :
> > Signed-off-by: Bernhard Beschow
> > ---
> > include/hw/core/shared-irq.h | 39
> > hw/core/shared-irq.c | 88
On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
>
> > char label[32];
> > XenDevice *xendev = NULL;
> > XenConsole *con;
> > @@ -550,7 +551,10 @@ static void
> > xen_console_device_create(XenBackendInstance *backend,
> > goto fail;
> > }
> >
> > -
From: David Woodhouse
The following changes since commit 3f8bcbba3b320c610689576fc47595f1076198dd:
Merge tag 'pull-request-2025-01-08' of https://gitlab.com/thuth/qemu into
staging (2025-01-08 11:38:21 -0500)
are available in the Git repository at:
git://git.infradead.org/u
From: David Woodhouse
The system GSIs are not designed for sharing. One device might assert a
shared interrupt with qemu_set_irq() and another might deassert it, and
the level from the first device is lost.
This could be solved by refactoring the x86 GSI code to use an OrIrq
device, but that
-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index 5969105667..17802aa33d 100644
--- a/hw/i386/kvm/xen_xenstore.c
+++ b/hw/i386/kvm/xen_xenstore.c
@@ -532,6 +532,10 @@ static v
On Tue, 2024-12-31 at 21:22 +0100, Philippe Mathieu-Daudé wrote:
>
> This change tidies up main thread management to be more flexible.
>
> * The qemu_main global function pointer is a custom function for the
> main thread, and it may now be NULL. When it is, the main thread
> runs the main
From: David Woodhouse
The system GSIs are not designed for sharing. One device might assert a
shared interrupt with qemu_set_irq() and another might deassert it, and
the level from the first device is lost.
This could be solved by refactoring the x86 GSI code to use an OrIrq
device, but that
off-by: Akihiko Odaki
Reviewed-by: David Woodhouse
Thanks.
> ---
> hw/i386/kvm/xen_xenstore.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
> index 59691056670e..17802aa33d20 100644
> --- a/hw/i386/kvm/xen_xen
On Wed, 2025-01-08 at 09:45 +, Bernhard Beschow wrote:
>
>
> Am 7. Januar 2025 16:20:28 UTC schrieb David Woodhouse
> :
> > On Tue, 2025-01-07 at 11:07 -0500, Michael S. Tsirkin wrote:
> > > On Thu, Dec 19, 2024 at 05:24:11PM +0100, David Woodhouse wrote:
&g
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The following changes since commit 6528013b5f5ba6bb3934b7f5fe57a3110680530f:
Merge tag 'qga-pull-2025-01-06' of https://github.com/kostyanf14/qemu into
staging (2025-01-06 09:39:02 -0500)
are available in the Git repository at:
git://git.infradead.org/u
On Tue, 2025-01-07 at 16:38 +, Paul Durrant wrote:
>
> > +#ifdef CONFIG_XEN_EMU
> > + /*
> > + * Xen delivers the GSI to the Legacy PIC (not that Legacy PIC
> > + * routing actually works properly under Xen). And then to
> > + * *either* the PIRQ handling or the
From: David Woodhouse
The system GSIs are not designed for sharing. One device might assert a
shared interrupt with qemu_set_irq() and another might deassert it, and
the level from the first device is lost.
This could be solved by using a multiplexer which functions as an OR
gate, much like the
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
On Tue, 2025-01-07 at 11:07 -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 19, 2024 at 05:24:11PM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The system GSIs are not designed for sharing. One device might assert a
> > shared interrupt with qemu_
On Thu, 2024-12-19 at 17:24 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The system GSIs are not designed for sharing. One device might assert a
> shared interrupt with qemu_set_irq() and another might deassert it, and
> the level from the first device is lost.
>
On Thu, 2024-12-19 at 18:24 +0100, David Woodhouse wrote:
> On Tue, 2024-12-03 at 17:33 +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The vmclock device addresses the problem of live migration with
> > precision clocks. The tolerances of a hard
On Thu, 2024-12-19 at 10:05 -0800, Richard Henderson wrote:
> On 12/19/24 04:56, David Woodhouse wrote:
> > On Thu, 2024-12-19 at 13:24 +0100, Thomas Huth wrote:
> >
> > > Anyway, to properly track this, I've now created a ticket with the full
> > > log:
&
On Tue, 2024-12-03 at 17:33 +, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock device addresses the problem of live migration with
> precision clocks. The tolerances of a hardware counter (e.g. TSC) are
> typically around ±50PPM. A guest will use NTP/PTP/PPS to
From: David Woodhouse
The system GSIs are not designed for sharing. One device might assert a
shared interrupt with qemu_set_irq() and another might deassert it, and
the level from the first device is lost.
This could be solved by using a multiplexer which functions as an OR
gate, much like the
On Thu, 2024-12-19 at 13:24 +0100, Thomas Huth wrote:
> On 19/12/2024 09.49, David Woodhouse wrote:
> > On 19 December 2024 09:35:13 CET, Thomas Huth wrote:
> > > On 18/12/2024 23.14, David Woodhouse wrote:
> > > > On Wed, 2024-12-18 at 16:54 +0100, Thomas Huth
On 19 December 2024 09:35:13 CET, Thomas Huth wrote:
>On 18/12/2024 23.14, David Woodhouse wrote:
>> On Wed, 2024-12-18 at 16:54 +0100, Thomas Huth wrote:
>>> On 18/12/2024 12.48, David Woodhouse wrote:
>>>> On 18 December 2024 12:32:49 CET, Thomas Huth wrote:
&
On Wed, 2024-12-18 at 16:54 +0100, Thomas Huth wrote:
> On 18/12/2024 12.48, David Woodhouse wrote:
> > On 18 December 2024 12:32:49 CET, Thomas Huth wrote:
> > > Use the serial console to execute the commands in the guest instead
> > > of using ssh since we do
On Wed, 2024-12-18 at 22:42 +0100, David Woodhouse wrote:
>
> It seems like it's because of the way QEMU handles shared level-
> triggered interrupts.
Yeah, this hack seems to confirm it. As I said, PCI INTx manages to
demux correctly, but any time you have non-PCI interrupt shari
On Wed, 2024-12-18 at 17:19 +0100, Thomas Huth wrote:
> On 18/12/2024 15.11, David Woodhouse wrote:
> > On Wed, 2024-12-18 at 14:38 +0100, Thomas Huth wrote:
> ...
> > > But FWIW, there seems to be another issue with this test. While running it
> > > m
On 18 December 2024 18:16:13 CET, Thomas Huth wrote:
>On 18/12/2024 17.19, Thomas Huth wrote:
>> On 18/12/2024 15.11, David Woodhouse wrote:
>>> On Wed, 2024-12-18 at 14:38 +0100, Thomas Huth wrote:
>> ...
>>>> But FWIW, there seems to be another is
On Wed, 2024-12-18 at 14:38 +0100, Thomas Huth wrote:
> On 18/12/2024 13.40, Thomas Huth wrote:
> > On 18/12/2024 12.48, David Woodhouse wrote:
> > > On 18 December 2024 12:32:49 CET, Thomas Huth wrote:
> > > > Use the serial console to execute the commands in the
On 18 December 2024 12:32:49 CET, Thomas Huth wrote:
>Use the serial console to execute the commands in the guest instead
>of using ssh since we don't have ssh support in the functional
>framework yet.
>
>Signed-off-by: Thomas Huth
Hm, but serial is lossy and experience shows that it leads to fl
From: David Woodhouse
The vmclock device addresses the problem of live migration with
precision clocks. The tolerances of a hardware counter (e.g. TSC) are
typically around ±50PPM. A guest will use NTP/PTP/PPS to discipline that
counter against an external source of 'real' time, and
From: David Woodhouse
The VMCLOCK device gives support for accurate timekeeping even across
live migration, unlike the KVM PTP clock. To help ensure that users can
always use ptp_vmclock where it's available in preference to ptp_kvm,
set it to 'default PTP_1588_CLOCK_VMCLOCK&#
On 28 October 2024 17:12:56 CET, Jakub Kicinski wrote:
>On Sat, 19 Oct 2024 18:49:24 +0100 David Woodhouse wrote:
>> > Yes please and thank you! We gotta straighten it out before
>> > the merge window.
>>
>> Hm, as I (finally) come to do that, I realise that
On Mon, 2024-10-14 at 13:12 -0700, Jakub Kicinski wrote:
> On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote:
> > On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> > > On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:
> > > >
1 - 100 of 1240 matches
Mail list logo
