[PATCH v3 7/7] hw/xen: Fix errp handling in xen_console

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&

[PATCH v3 4/7] hw/xen: Use xs_node_read() from xen_console_get_name()

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

[PATCH v3 1/7] hw/xen: Add xs_node_read() helper function

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

[PATCH v3 5/7] hw/xen: Use xs_node_read() from xen_netdev_get_name()

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

Re: [PATCH v2 2/2] xen: do not use '%ms' scanf specifier

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

Re: [PATCH v3 7/7] hw/xen: Fix errp handling in xen_console

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

Re: [PATCH v2 00/38] x86: Try to wrangle PV clocks vs. TSC

On Wed, 2025-02-26 at 18:18 -0800, Sean Christopherson wrote: > This... snowballed a bit. > > The bulk of the changes are in kvmclock and TSC, but pretty much every > hypervisor's guest-side code gets touched at some point.  I am reaonsably > confident in the correctness of the KVM changes.  For a

Using Restricted DMA for virtio-pci

On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote: > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage o

Re: Using Restricted DMA for virtio-pci

On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote: > On Fri, Mar 21, 2025 at 03:38:10PM +0000, David Woodhouse wrote: > > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote: > > > This series implements mitigations for lack of DMA access control on > > &g

Re: [PATCH 1/2] i386/xen: Move KVM_XEN_HVM_CONFIG ioctl to kvm_xen_init_vcpu()

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

Re: Using Restricted DMA for virtio-pci

On Fri, 2025-03-21 at 18:42 +, David Woodhouse wrote: > On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote: > > On Fri, Mar 21, 2025 at 03:38:10PM +0000, David Woodhouse wrote: > > > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote: > > > > This ser

Re: Using Restricted DMA for virtio-pci

On Sun, 2025-03-30 at 09:42 -0400, Michael S. Tsirkin wrote: > On Fri, Mar 28, 2025 at 05:40:41PM +0000, David Woodhouse wrote: > > On Fri, 2025-03-21 at 18:42 +0000, David Woodhouse wrote: > > > > > > > > I don't mind as such (though I don't unders

<    5   6   7   8   9   10