From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/arm/mps2-tz.c | 8 ++--
hw/arm/msf2-soc.c| 6 +-
hw/arm/musicpal.c| 3 +--
hw/arm/xilinx_zynq.c | 11 ---
hw/arm/xlnx-versal.c | 7 +--
hw/arm/xlnx-zynqmp.c | 8 +---
6 files changed, 10
From: David Woodhouse
Previously, the first PCI NIC would be assigned to slot 2 even if the
user override the model and made it something other than an rtl8139
which is the default. Everything else would be dynamically assigned.
Now, the first rtl8139 gets slot 2 and everything else is dynamic
From: David Woodhouse
By noting the models for which a configuration was requested, we can give
the user an accurate list of which NIC models were actually available on
the platform/configuration that was otherwise chosen.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
net
From: David Woodhouse
When converting to the shiny build-system-du-jour, a typo prevented the
last_i82596 driver from being built. Correct the config option name to
re-enable the build. And include "sysemu/sysemu.h" so it actually builds.
Fixes: b1419fa66558 ("meson: convert hw/n
From: David Woodhouse
Most code which directly accesses nd_table[] and nb_nics uses them for
one of two things. Either "I have created a NIC device and I'd like a
configuration for it", or "I will create a NIC device *if* there is a
configuration for it". With some var
From: David Woodhouse
Some callers instantiate the device unconditionally, others will do so only
if there is a NICInfo to go with it. This appears to be fairly random, but
preseve the existing behaviour for now.
Signed-off-by: David Woodhouse
---
hw/arm/kzm.c | 4 ++--
hw/arm
From: David Woodhouse
The previous behaviour was: *if* the first NIC specified on the command
line was an RTL8139 (or unspecified model) then it gets assigned to PCI
slot 7, which is where the Fuloong board had an RTL8139. All other
devices (including the first, if it was specified as anything
From: David Woodhouse
Obtain the MAC address from the NIC configuration if there is one, or
generate one explicitly so that it can be placed in the PROM.
Signed-off-by: David Woodhouse
---
hw/sparc/sun4m.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
Xen and ISA NICs first and then calling pci_init_nic_devices() for the
rest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/pc.c| 31
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/mips/loongson3_virt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
index 33eae01eca..caedde2df0 100644
--- a/hw/mips
From: David Woodhouse
Previously, the first PCI NIC would be placed in PCI slot 3 and the rest
would be dynamically assigned. Even if the user overrode the default NIC
type and made it something other than PCNet.
Now, the first PCNet NIC (that is, anything not explicitly specified
to be
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/riscv/microchip_pfsoc.c | 14 ++
hw/riscv/sifive_u.c| 7 +--
2 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/xtensa/xtfpga.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw/xtensa/xtfpga.c b/hw/xtensa/xtfpga.c
index fbad1c83a3..f49e6591dc 100644
--- a/hw/xtensa/xtfpga.c
+++ b/hw
From: David Woodhouse
The Malta board setup code would previously place the first NIC into PCI
slot 11 if was a PCNet card, and the rest (including the first if it was
anything other than a PCNet card) would be dynamically assigned.
Now it will place any PCNet NIC into slot 11, and then
From: David Woodhouse
When instantiating XenBus itself, for each NIC which is configured with
either the model unspecified, or set to to "xen" or "xen-net-device",
create a corresponding xen-net-device for it.
Now we can revert the previous more hackish version which relied
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/arm/highbank.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
index c21e18d08f..6a0e20e58d 100644
--- a/hw/arm/highbank.c
+++ b/hw/arm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/microblaze/petalogix_ml605_mmu.c | 3 +--
hw/microblaze/petalogix_s3adsp1800_mmu.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/microblaze/petalogix_ml605_mmu.c
b/hw
From: David Woodhouse
Some callers instantiate the device unconditionally, others will do so only
if there is a NICInfo to go with it. This appears to be fairly random, but
preserve the existing behaviour of each caller for now.
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw
From: David Woodhouse
Signed-off-by: David Woodhouse
Acked-by: Thomas Huth
---
hw/s390x/s390-virtio-ccw.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index c99682b07d..62804cc228 100644
--- a/hw/s390x
From: David Woodhouse
These old functions can be removed now too. Let net_param_nic() print
the full set of network devices directly, and also make it note that a
list more specific to this platform/config will be available by using
'-nic model=help' instead.
Signed-off-by: David
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/mips/jazz.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/hw/mips/jazz.c b/hw/mips/jazz.c
index 0d2348aa5a..5bf3e328db 100644
--- a/hw/mips/jazz.c
+++ b/hw/mips/jazz.c
@@ -119,15 +119,19 @@ static
From: David Woodhouse
The MIPS SIM platform instantiates its NIC only if a corresponding
configuration exists for it. Use qemu_create_nic_device() function for
that.
Signed-off-by: David Woodhouse
---
hw/mips/mipssim.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
error handling in hw/i386/pc.c.
Document new functions better in include/net/net.h.
v3: Rebase to 8.2
v2: Some build fixes after better coverage testing, revert the Xen fix
in this series because I'm putting the less invasive hack into 8.2
(hopefully).
David W
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Thomas Huth
---
hw/m68k/mcf5208.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index d22d8536db..0cfb806c20 100644
--- a/hw/m68k/mcf5208.c
+++ b
On Fri, 2024-01-26 at 23:03 +0100, Philippe Mathieu-Daudé wrote:
> Mechanical patch produced running the command documented
> in scripts/coccinelle/cpu_env.cocci_template header.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
For the KVM/Xen parts
Acked-by: David Woodhou
(Thanks Andy for the explicit cc)
On Thu, 2024-02-01 at 00:05 +, John L. Poole wrote:
>
> cause Gentoo's build to error out. See line 24790:
>
> 5 | #error In Xen native files, include xen_native.h before other Xen
> headers
>
> at
> https://salemdata.us/xen/xen_tools_20240128_Sun_174
On Thu, 2024-02-01 at 18:39 +, John L. Poole wrote:
>
> While the Xen Project "make" works, the Gentoo emerge
> of app-emulation/xen-tools does not unless the three lines are
> removed to simulate prior 4.17.3 and earlier code.
>
> I suspect the Gentoo approach
> of building tools first co
From: David Woodhouse
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, in the xs_reset_watches() call
called from xs_init().
This mostly doesn't matter much in pra
On Fri, 2020-12-18 at 17:20 -0500, boris.ostrov...@oracle.com wrote:
> Are there other cases where this would be useful? If it's just to
> test a hypervisor under development I would think that people who are
> doing that kind of work are capable of building their own kernel. My
> concern is mostly
On Sun, 2020-12-20 at 13:01 -0500, boris.ostrov...@oracle.com wrote:
> On 12/19/20 3:05 AM, David Woodhouse wrote:
> > On Fri, 2020-12-18 at 17:20 -0500, boris.ostrov...@oracle.com wrote:
> > > Are there other cases where this would be useful? If it's just to
> &
From: David Woodhouse
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in a
From: David Woodhouse
When xen_have_vector_callback is false, we still register the PV spinlock
kicker IPI on the secondary CPUs. Stop doing that.
Signed-off-by: David Woodhouse
---
arch/x86/xen/spinlock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen
From: David Woodhouse
With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
If the interrupt gets handled by Linux on a different CPU, then no events
are seen as pending. Rather than introducing locking to allow other CPUs
to process CPU0's events, just ensure that th
From: David Woodhouse
In the case where xen_have_vector_callback is false, we still register
the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
though they aren't going to be used. Stop doing that.
Signed-off-by: David Woodhouse
---
arch/x86/xen/enlighten_hvm.c | 4 ++
From: David Woodhouse
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions
t properly, and makes it
easier to test. cf. https://lkml.org/lkml/2017/4/10/266
David Woodhouse (5):
xen: Fix event channel callback via INTX/GSI
xen: Set platform PCI device INTX affinity to CPU0
x86/xen: Add a no_vector_callback option to test PCI INTX delivery
x86/
On Mon, 2021-01-04 at 11:50 -0500, boris.ostrov...@oracle.com wrote:
> > diff --git a/arch/x86/xen/enlighten_hvm.c
> > b/arch/x86/xen/enlighten_hvm.c
> > index a1c07e0c888e..7a6ef517e81a 100644
> > --- a/arch/x86/xen/enlighten_hvm.c
> > +++ b/arch/x86/xen/enlighten_hvm.c
> > @@ -164,10 +164,10 @@ s
On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote:
> > @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
> > void __init xen_init_spinlocks(void)
> > {
> >/* Don't need to use pvqspinlock code if there is only 1 vCPU. */
> > - if (num_possible_cpus()
On Mon, 2021-01-04 at 14:06 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 12:32 PM, David Woodhouse wrote:
> > On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote
> > :
> > > > @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stol
ed. And if they call something that *is* related then those
> specific routines should decide what to do based on
> xen_have_vector_callback.
Right.
My current patch (that I'm about to test) now looks like this:
commit 8126bf76319257fca0cf0b87fdfaaa42d2c658b6
Author: David Woodhouse
On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 5:37 PM, David Woodhouse wrote:
> >
> > @@ -33,9 +33,11 @@ static void __init
> > xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
> > int cpu;
> >
> > native_smp_
On Mon, 2021-01-04 at 18:44 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 6:19 PM, David Woodhouse wrote:
> > On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com
> > wrote:
> > > Why not xen_hvm_cpu_die too? common_cpu_die() sounds like something
> >
-ops. But to guard against future regressions
it's useful to call it anyway, and for it to explicitly check for
xen_have_vector_callback before calling those additional functions.
Signed-off-by: David Woodhouse
---
arch/x86/xen/smp_hvm.c | 27 +--
1 file change
From: David Woodhouse
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in a
From: David Woodhouse
In the case where xen_have_vector_callback is false, we still register
the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
though they aren't going to be used. Stop doing that.
Signed-off-by: David Woodhouse
---
arch/x86/xen/enlighten_hvm.c | 4 ++
From: David Woodhouse
Only the IPI-related functions in the smp_ops should be conditional
on the vector callback being available. The rest should still happen:
• xen_hvm_smp_prepare_boot_cpu()
This function does two things, both of which should still happen if
there is no vector
From: David Woodhouse
With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
If the interrupt gets handled by Linux on a different CPU, then no events
are seen as pending. Rather than introducing locking to allow other CPUs
to process CPU0's events, just ensure that th
t properly, and makes it
easier to test. cf. https://lkml.org/lkml/2017/4/10/266
v2:
• Add no_vector_callback to Documentation/admin-guide/kernel-parameters.txt
• Further fixes to conditional smp_ops initialisation in xen_hvm_smp_init()
David Woodhouse (5):
xen: Fix event channel callbac
From: David Woodhouse
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions
t properly, and makes it
easier to test. cf. https://lkml.org/lkml/2017/4/10/266
v2:
• Add no_vector_callback to Documentation/admin-guide/kernel-parameters.txt
• Further fixes to conditional smp_ops initialisation in xen_hvm_smp_init()
v3:
• Rename test option to xen_no_vector_callback
David
From: David Woodhouse
With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
If the interrupt gets handled by Linux on a different CPU, then no events
are seen as pending. Rather than introducing locking to allow other CPUs
to process CPU0's events, just ensure that th
From: David Woodhouse
Only the IPI-related functions in the smp_ops should be conditional
on the vector callback being available. The rest should still happen:
• xen_hvm_smp_prepare_boot_cpu()
This function does two things, both of which should still happen if
there is no vector
From: David Woodhouse
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions
From: David Woodhouse
In the case where xen_have_vector_callback is false, we still register
the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
though they aren't going to be used. Stop doing that.
Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
---
arch/x8
From: David Woodhouse
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in a
On Wed, 2021-01-06 at 09:46 -0500, boris.ostrov...@oracle.com wrote:
> Sorry, I should have noticed this before --- I think this needs to be
> prefixed with "xen_". I know it's pretty long but otherwise this will
> be the first Xen-only option without such prefix (or without "xen."
> module). We al
On Wed, 2021-01-13 at 12:20 +0100, Jürgen Groß wrote:
>
> /home/gross/korg/src/drivers/xen/xenbus/xenbus_probe.c: In function
> 'xenbus_probe_initcall':
> /home/gross/korg/src/drivers/xen/xenbus/xenbus_probe.c:711:41:
> error:
> 'xen_have_vector_callback' undeclared (first use in this function);
From: David Woodhouse
Only the IPI-related functions in the smp_ops should be conditional
on the vector callback being available. The rest should still happen:
• xen_hvm_smp_prepare_boot_cpu()
This function does two things, both of which should still happen if
there is no vector
From: David Woodhouse
In the case where xen_have_vector_callback is false, we still register
the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
though they aren't going to be used. Stop doing that.
Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
---
arch/x8
From: David Woodhouse
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors,
because there are guest kernels still in a
From: David Woodhouse
With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
If the interrupt gets handled by Linux on a different CPU, then no events
are seen as pending. Rather than introducing locking to allow other CPUs
to process CPU0's events, just ensure that th
From: David Woodhouse
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in xs_init().
We tend to get away with this on Xen versions
v4:
• Fix unconditional references to xen_have_vector_callback in Arm build
David Woodhouse (5):
xen: Fix event channel callback via INTX/GSI
xen: Set platform PCI device INTX affinity to CPU0
x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery
x86/xen: Don'
On Mon, 2021-09-13 at 13:44 +0100, Alex Bennée wrote:
> Hi,
>
> As we consider the next cycle for Project Stratos I would like to make
> some more progress on hypervisor agnosticism for our virtio backends.
> While we have implemented a number of virtio vhost-user backends using C
> we've rapidly
On Tue, 2023-06-20 at 13:24 -0400, Joel Upham wrote:
> The primary difference in PCI device IRQ management between Xen HVM and
> QEMU is that Xen PCI IRQs are "device-centric" while QEMU PCI IRQs are
> "chipset-centric". Namely, Xen uses PCI device BDF and INTx as coordinates
> to assert IRQ while
On Tue, 2023-06-20 at 13:24 -0400, Joel Upham wrote:
> The primary difference in PCI device IRQ management between Xen HVM and
> QEMU is that Xen PCI IRQs are "device-centric" while QEMU PCI IRQs are
> "chipset-centric". Namely, Xen uses PCI device BDF and INTx as coordinates
> to assert IRQ while
On Wed, 2023-04-19 at 14:38 +0200, Thomas Gleixner wrote:
>
> I'm leaning towards disabling the CPUID lead 0x01 based discovery and be
> done with it.
Makes sense. The large machines where users really want the parallel
startup all ought to have X2APIC and hence CPUID 0x0b.
smime.p7s
Descripti
On Thu, 2025-01-02 at 15:16 +0100, Jürgen Groß wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before
On Tue, 2025-01-07 at 09:20 +0100, Jan Beulich wrote:
>
> How about we adjust the behavior in Xen instead: We could latch the size
> on every hypercall, making sure to invoke update_domain_wallclock_time()
> only when the size actually changed (to not incur the extra overhead),
> unless originatin
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
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
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
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
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
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
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
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
('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 Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
> Xen Security Advisory CVE-2024-53241 / XSA-466
> version 3
>
> Xen hypercall page unsafe against speculative attacks
>
> UPDATES IN VERSION 3
>
>
> Update
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
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
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
}_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
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/net/xen_nic.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/hw
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
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 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;
> > }
> >
> > -
On Thu, 2025-01-02 at 15:16 +0100, Jürgen Groß wrote:
> On 02.01.25 15:06, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > > > Are you suggesting that you're able to enable the CPU-specific CFI
> > > > protections before
On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
> On 23.12.24 15:24, David Woodhouse wrote:
> > On Tue, 2024-12-17 at 12:18 +, Xen.org security team wrote:
> > > Xen Security Advisory CVE-2024-53241 / XSA-466
> > >
On Thu, 2025-01-02 at 14:38 +0100, Jürgen Groß wrote:
> On 02.01.25 13:53, David Woodhouse wrote:
> > On Thu, 2025-01-02 at 13:07 +0100, Jürgen Groß wrote:
> > > On 23.12.24 15:24, David Woodhouse wrote:
> > > > On Tue, 2024-12-17 at 12:18 +000
On Thu, 2025-01-02 at 15:02 +0100, Jürgen Groß wrote:
> > Are you suggesting that you're able to enable the CPU-specific CFI
> > protections before you even know whether it's an Intel or AMD CPU?
>
> Not before that, but maybe rather soon afterwards. And the hypercall page
> needs to be decommissi
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
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
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
_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
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
801 - 900 of 912 matches
Mail list logo
