On 24.10.23 15:45, David Woodhouse wrote:
On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
I can probably change xen_send_IPI_one() to not need irq_get_chip_data().
David, could you test the attached patch, please? Build tested only.
No longer whines when offlining CPU1.
Still trip
Hi Julien,
> On Oct 24, 2023, at 18:28, Julien Grall wrote:
>
> From: Julien Grall
>
> In commit 9d267c049d92 ("xen/arm64: Rework the memory layout"),
> we decided to require Xen to be loaded below 2 TiB to simplify
> the logic to enable the MMU. The limit was decided based on
> how known plat
On Tue, 2023-10-24 at 15:47 +0100, Paul Durrant wrote:
>
> >
> > - if (netdev->xendev.be_state != XenbusStateConnected) {
> > + if (netdev->rx_ring.sring == NULL) {
>
> Why not a straight swap for xen_device_backend_get_state()? Hard to see
> whether there any hidden side effects of th
On 24.10.2023 22:27, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Jan Beulich wrote:
>> On 24.10.2023 16:31, Nicola Vetrini wrote:
>>> Partially explicitly initalized .matches arrays result in violations
>>> of Rule 9.3; this is resolved by using designated initializers,
>>> which is permitted
On 25.10.2023 03:15, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Jan Beulich wrote:
>> On 24.10.2023 01:31, Stefano Stabellini wrote:> --- a/docs/misra/rules.rst
>>> +++ b/docs/misra/rules.rst
>>> @@ -422,6 +422,13 @@ maintainers if you want to suggest a change.
>>>
>>> while(0) and
On 24.10.2023 21:59, Stefano Stabellini wrote:
> If I understood correctly I am fine with that. To make sure we are all
> on the same page, can you provide a couple of samples?
Taking the earlier example, instead of DRIVERS_PASSTHROUGH_VTD_DMAR_H it
would then be VTD_DMAR_H. arch/x86/pv/mm.h would
On Mon, 2023-10-23 at 12:35 +0200, Jan Beulich wrote:
> On 23.10.2023 12:12, Oleksii wrote:
> > On Thu, 2023-10-19 at 11:14 +0200, Jan Beulich wrote:
> > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/device.h
> > > > @@ -0,0 +1,65 @@
> >
On 24.10.2023 22:30, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Nicola Vetrini wrote:
>> As specified in rules.rst, these constants can be used
>> in the code.
>>
>> Signed-off-by: Nicola Vetrini
>> ---
>> Changes in v2:
>> - replace some SAF deviations with configurations
>> Changes in v3:
flight 183519 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183519/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183489
test-armhf-armhf-libvirt 16 save
At the moment, in order to use a different defconfig target than default,
one needs to specify KBUILD_DEFCONFIG= on the command line.
Switch to weak assignment, so that it can be also obtained from
environment similar to other KCONFIG/KBUILD variables.
This change will activate the use of KBUILD_D
On Tue, 2023-10-24 at 14:37 +0100, Paul Durrant wrote:
>
> > > Ok, but a prepend to say that a lack of path there means we skip
> > > frontend creation seems reasonable?
> >
> > No, it *is* returning an error. Perhaps I can make it
> >
>
> I understand it is returning an error. I thought the po
On 24/10/2023 17:34, David Woodhouse wrote:
On Tue, 2023-10-24 at 17:25 +0100, Paul Durrant wrote:
On 24/10/2023 16:49, David Woodhouse wrote:
On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant wrote:
On 24/10/2023 16:37, David Woodhouse wrote:
On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant wro
Hi all,
I’m sending this mail looking for feedbacks about generalising the
exclude-list.json, as suggested (IIRC) by Jan
this list can be used by multiple users and not only for MISRA, by adding a
field to every entry.
These are the modifications I would like to do to the list, I will implement
On 25.10.2023 10:35, Luca Fancellu wrote:
> I’m sending this mail looking for feedbacks about generalising the
> exclude-list.json, as suggested (IIRC) by Jan
> this list can be used by multiple users and not only for MISRA, by adding a
> field to every entry.
>
> These are the modifications I w
On Wed, 2023-10-25 at 09:31 +0100, Paul Durrant wrote:
> On 24/10/2023 17:34, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 17:25 +0100, Paul Durrant wrote:
> > > On 24/10/2023 16:49, David Woodhouse wrote:
> > > > On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant wrote:
> > > > > On 24/10/2023 16
On 25.10.2023 10:28, Michal Orzel wrote:
> At the moment, in order to use a different defconfig target than default,
> one needs to specify KBUILD_DEFCONFIG= on the command line.
> Switch to weak assignment, so that it can be also obtained from
> environment similar to other KCONFIG/KBUILD variable
On Thu, May 11, 2023 at 01:50:05PM +0200, Jan Beulich wrote:
> In particular pit_latch_status() and speaker_ioport_read() perform
> calculations which assume in-bounds values. Several of the state save
> record fields can hold wider ranges, though.
>
> Note that ->gate should only be possible to b
Hi,
On 25/10/2023 11:10, Jan Beulich wrote:
>
>
> On 25.10.2023 10:28, Michal Orzel wrote:
>> At the moment, in order to use a different defconfig target than default,
>> one needs to specify KBUILD_DEFCONFIG= on the command line.
>> Switch to weak assignment, so that it can be also obtained fro
On 25.10.2023 11:21, Michal Orzel wrote:
> On 25/10/2023 11:10, Jan Beulich wrote:
>> On 25.10.2023 10:28, Michal Orzel wrote:
>>> At the moment, in order to use a different defconfig target than default,
>>> one needs to specify KBUILD_DEFCONFIG= on the command line.
>>> Switch to weak assignment,
On 25/10/2023 11:26, Jan Beulich wrote:
>
>
> On 25.10.2023 11:21, Michal Orzel wrote:
>> On 25/10/2023 11:10, Jan Beulich wrote:
>>> On 25.10.2023 10:28, Michal Orzel wrote:
At the moment, in order to use a different defconfig target than default,
one needs to specify KBUILD_DEFCONF
On 25.10.2023 11:11, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 01:50:05PM +0200, Jan Beulich wrote:
>> In particular pit_latch_status() and speaker_ioport_read() perform
>> calculations which assume in-bounds values. Several of the state save
>> record fields can hold wider ranges, though.
>
flight 183521 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183521/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in
183505
test-armhf-armhf-libvirt-qcow2 15 save
On 25.10.2023 11:35, Michal Orzel wrote:
>
>
> On 25/10/2023 11:26, Jan Beulich wrote:
>>
>>
>> On 25.10.2023 11:21, Michal Orzel wrote:
>>> On 25/10/2023 11:10, Jan Beulich wrote:
On 25.10.2023 10:28, Michal Orzel wrote:
> At the moment, in order to use a different defconfig target than
Hi Stefano,
On 24/10/2023 20:52, Stefano Stabellini wrote:
On Tue, 24 Oct 2023, Bertrand Marquis wrote:
Hi Julien,
On 24 Oct 2023, at 12:28, Julien Grall wrote:
From: Julien Grall
In commit 9d267c049d92 ("xen/arm64: Rework the memory layout"),
we decided to require Xen to be loaded below
From: Edwin Török
By default stderr gets redirected to /dev/null because oxenstored daemonizes
itself.
This must be a left-over from pre-systemd days.
In ee7815f49f ("tools/oxenstored: Set uncaught exception handler") a workaround
was added to log exceptions
directly to syslog to cope with sta
Hi All.
This patch aims to add GICv3 support to the New VGIC. It adds support for
the GICv3 distributor, redistributor, sysreg and ITS interfaces. This will
allow Xen to emulate level-triggered interrupts with GICVb3 and will make
the NEW_VGIC more complete and usable.
The bulk of the code is tak
Add GICv3 ITS support for NEW VGIC. The code is ported from the Kernel
version 6.0. The code is adapted to Xen's coding style and hooked up
with Xen's interfaces. The code is adapted to Xen coding style and
conventions.
For this version ITS is supported only for hardware domains.
Remove unsupporte
New vgic code relies on lower address bits to calculate intid from
the address offset. 0x03001000 as DIST_BASE overlaps with
VGIC_ADDR_IRQ_MASK when bits_per_irq >= 64, breaking the intid calculation.
Move DIST_BASE to a safer location to fix this.
Signed-off-by: Mykyta Poturai
---
xen/include/p
We will need GICv3 code to access get/put irq to inject LPIs for new
VGIC similar to how the old one uses irq_to_pending now. So move
get/put irq to the same header file.
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/include/asm/vgic.h | 6 ++
xen/arch/arm/vgic/vgic.h| 3 ---
2 file
On Thu, May 11, 2023 at 01:50:33PM +0200, Jan Beulich wrote:
> Loading is_master from the state save record can lead to out-of-bounds
> accesses via at least the two container_of() uses by vpic_domain() and
> __vpic_lock(). Calculate the field from the supplied instance number
> instead. Adjust the
Add support for basic GICv3 functionality to new vgic. The code is
ported from Kernel version 6.0. The distributor, redistributor and
CPU interface are ported and hooked up to the XEN interfaces.
The code is adapted to Xen coding style and conventions.
Remove !NEW_VGIC dependency from GIC_V3 confi
Hi Mykyta,
This patch is far too big to review. Can this be split in smaller
logical change? The same goes for patch #3.
But some high level remarks.
On 25/10/2023 11:13, Mykyta Poturai wrote:
Add GICv3 ITS support for NEW VGIC. The code is ported from the Kernel
version 6.0. The code is ada
(+xen-devel)
Sorry I forgot to send to the list...
> On Oct 25, 2023, at 18:18, Henry Wang wrote:
>
> Hi committers,
>
> We will be branching the tree for Xen 4.18 in the next few days. Please
> avoid committing any new patches to staging until further notice.
>
> Kind regards,
> Henry
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
> +/* Low-level backend functions usable from alternative code replacements. */
> +DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
> +EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't really need the "x86_" prefix - "nop"
is per
Hi,
On 25/10/2023 11:13, Mykyta Poturai wrote:
New vgic code relies on lower address bits to calculate intid from > the
address offset. 0x03001000 as DIST_BASE overlaps with
VGIC_ADDR_IRQ_MASK when bits_per_irq >= 64, breaking the intid calculation.
Move DIST_BASE to a safer location to fix thi
On 25/10/2023 10:00, David Woodhouse wrote:
On Wed, 2023-10-25 at 09:31 +0100, Paul Durrant wrote:
On 24/10/2023 17:34, David Woodhouse wrote:
On Tue, 2023-10-24 at 17:25 +0100, Paul Durrant wrote:
On 24/10/2023 16:49, David Woodhouse wrote:
On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant wro
On Thu, May 11, 2023 at 01:51:06PM +0200, Jan Beulich wrote:
> Whether to handle this shouldn't depend on the present value of the
> index register. Since the handling is done outside of the lock anyway,
> pull it out into the sole caller and drop the no longer needed function
> parameter.
>
> Sig
On 25.10.2023 12:12, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 01:50:33PM +0200, Jan Beulich wrote:
>> Loading is_master from the state save record can lead to out-of-bounds
>> accesses via at least the two container_of() uses by vpic_domain() and
>> __vpic_lock(). Calculate the field from t
On Thu, May 11, 2023 at 02:05:11PM +0200, Jan Beulich wrote:
> This allows to initiate machine reset, which we don't want to permit
> Dom0 to invoke that way.
>
> While there insert blank lines and convert the sibling PCI config space
> port numbers to upper case, matching style earlier in the fun
On Thu, May 11, 2023 at 02:05:45PM +0200, Jan Beulich wrote:
> Somewhat like port CF9 this may have a bit controlling the CPU's INIT#
> signal, and it also may have a bit involved in the driving of A20M#.
> Neither of these - just like CF9 - we want to allow Dom0 to drive.
>
> Signed-off-by: Jan B
On Wed, Oct 25, 2023 at 01:51:05PM +0200, Jan Beulich wrote:
> On 25.10.2023 12:12, Roger Pau Monné wrote:
> > On Thu, May 11, 2023 at 01:50:33PM +0200, Jan Beulich wrote:
> >> Loading is_master from the state save record can lead to out-of-bounds
> >> accesses via at least the two container_of() u
Make function definition and declaration consistent and emphasize that
the formal parameter is deliberately not used.
No functional change.
Signed-off-by: Federico Serafini
---
Changes in v2:
- improved code format.
---
xen/drivers/passthrough/amd/iommu_init.c | 5 -
1 file changed, 4 insert
On Thu, May 11, 2023 at 02:06:25PM +0200, Jan Beulich wrote:
> Unlike PV, a PVH Dom0 has no sensible way of driving the address and
> page registers correctly, as it would need to translate guest physical
> addresses to host ones. Rather than allowing data corruption to occur
> from e.g. the use of
The clauses of a switch should be enclosed directly by a switch
statement to make the code more easily understandable and less
prone to errors.
Signed-off-by: Nicola Vetrini
---
This patch is mainly indended to probe how the community, especially the
maintainers, would receive such modifications
On 25.10.23 12:34, Borislav Petkov wrote:
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
+/* Low-level backend functions usable from alternative code replacements. */
+DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
+EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't real
On 25.10.2023 15:22, Nicola Vetrini wrote:
> The clauses of a switch should be enclosed directly by a switch
> statement to make the code more easily understandable and less
> prone to errors.
>
> Signed-off-by: Nicola Vetrini
> ---
> This patch is mainly indended to probe how the community, espe
On Wed, Oct 25, 2023 at 03:31:07PM +0200, Juergen Gross wrote:
> There is
>
> #define nop() asm volatile ("nop")
>
> in arch/x86/include/asm/special_insns.h already.
Then call it "nop_func" or so.
> It might not be needed now, but are you sure we won't need it in future?
No, I'm not.
What I'm
From: Edwin Török
The code currently uses GCC to compile OCaml C stubs directly,
and although in most cases this works, it is not entirely correct.
This will fail if the OCaml runtime has been recompiled to use and link with
ASAN for example
(or other situations where a flag needs to be used co
On 25.10.23 15:44, Borislav Petkov wrote:
On Wed, Oct 25, 2023 at 03:31:07PM +0200, Juergen Gross wrote:
There is
#define nop() asm volatile ("nop")
in arch/x86/include/asm/special_insns.h already.
Then call it "nop_func" or so.
Okay.
It might not be needed now, but are you sure we won
On 25.10.2023 14:36, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 02:05:11PM +0200, Jan Beulich wrote:
>> This allows to initiate machine reset, which we don't want to permit
>> Dom0 to invoke that way.
>>
>> While there insert blank lines and convert the sibling PCI config space
>> port number
On Wed, Oct 25, 2023 at 2:58 PM Edwin Török wrote:
> [...]
> Signed-off-by: Edwin Török
Sorry about the duplicate emails to the list, my 'git send-email'
isn't working quite right.
> On 25 Oct 2023, at 14:52, Edwin Török wrote:
>
> From: Edwin Török
>
> The code currently uses GCC to compile OCaml C stubs directly,
> and although in most cases this works, it is not entirely correct.
>
> This will fail if the OCaml runtime has been recompiled to use and link with
> AS
On 25.10.2023 15:52, Edwin Török wrote:
> --- a/tools/ocaml/Makefile.rules
> +++ b/tools/ocaml/Makefile.rules
> @@ -37,7 +37,7 @@ ALL_OCAML_OBJS ?= $(OBJS)
> $(call quiet-command, $(OCAMLYACC) -q $<,MLYACC,$@)
>
> %.o: %.c
> - $(call quiet-command, $(CC) $(CFLAGS) -c -o $@ $<,CC,$@)
>
On 24/10/2023 21:50, Stefano Stabellini wrote:
On Tue, 24 Oct 2023, Nicola Vetrini wrote:
On 24/10/2023 10:14, Jan Beulich wrote:
> On 24.10.2023 10:01, Nicola Vetrini wrote:
> > On 24/10/2023 09:50, Jan Beulich wrote:
> > > On 23.10.2023 11:56, Nicola Vetrini wrote:
> > > > As stated in rules.r
flight 183524 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183524/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1f21e11168dd6a071a92e41ecdffc7cd6e5f3f02
baseline version:
ovmf d85bf54b7f462eb029735
On 25.10.2023 14:49, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 02:05:45PM +0200, Jan Beulich wrote:
>> Somewhat like port CF9 this may have a bit controlling the CPU's INIT#
>> signal, and it also may have a bit involved in the driving of A20M#.
>> Neither of these - just like CF9 - we want
On 25/10/2023 15:44, Jan Beulich wrote:
On 25.10.2023 15:22, Nicola Vetrini wrote:
The clauses of a switch should be enclosed directly by a switch
statement to make the code more easily understandable and less
prone to errors.
Signed-off-by: Nicola Vetrini
---
This patch is mainly indended to
On 24/10/2023 08:14, Jan Beulich wrote:
On 23.10.2023 22:44, Stefano Stabellini wrote:
On Mon, 23 Oct 2023, Jan Beulich wrote:
On 23.10.2023 15:19, Nicola Vetrini wrote:
On 23/10/2023 11:19, Nicola Vetrini wrote:
On 23/10/2023 09:48, Jan Beulich wrote:
On 20.10.2023 17:28, Nicola Vetrini wro
From: David Woodhouse
The xen_evtchn_soft_reset() function requires the iothread mutex, but is
also called for the EVTCHNOP_reset hypercall. Ensure the mutex is taken
in that case.
Fixes: a15b10978fe6 ("hw/xen: Implement EVTCHNOP_reset")
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtch
From: David Woodhouse
The primary Xen console is special. The guest's side is set up for it by
the toolstack automatically and not by the standard PV init sequence.
Accordingly, its *frontend* doesn't appear in …/device/console/0 either;
instead it appears under …/console in the guest's XenStore
From: David Woodhouse
Add notes about console and network support, and how to launch PV guests.
Clean up the disk configuration examples now that that's simpler, and
remove the comment about IDE unplug on q35/AHCI now that it's fixed.
Also update stale avocado test filename in MAINTAINERS.
Sign
From: David Woodhouse
To support Xen guests using the Q35 chipset, the unplug protocol needs
to also remove AHCI disks.
Make pci_xen_ide_unplug() more generic, iterating over the children
of the PCI device and destroying the "ide-hd" devices. That works the
same for both AHCI and IDE, as does th
From: David Woodhouse
The primary console is special because the toolstack maps a page into
the guest for its ring, and also allocates the guest-side event channel.
The guest's grant table is even primed to export that page using a known
grant ref#. Add support for all that in emulated mode, so t
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
ISA NICs first and then calling pci_init_nic_devices() for the test.
It's important to do this *before* the subsequent patch which registers
the Xen PV network devices, because the code being remove her
From: David Woodhouse
Even on x86_64 the default protocol is the x86-32 one if the guest doesn't
specifically ask for x86-64.
Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and
disconnect functions...")
Signed-off-by: David Woodhouse
---
hw/block/xen-block.c | 6 +-
1
From: David Woodhouse
This confuses lscpu into thinking it's running in PVH mode.
Fixes: bedcc139248 ("i386/xen: implement HYPERVISOR_xen_version")
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/
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
---
net/net.c | 94 +
Round up a handful of outstanding fixes, add console support and fix up
per-vCPU upcall vector support (which was previously untested), and that
allows us to boot PV guests using the Xen "PV shim".
Having fixed up the per-vCPU upcall vector support, pull in slightly
newer Xen headers just for the
From: David Woodhouse
This is kind of redundant since without being able to get these through
some other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 11 +
From: David Woodhouse
... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature,
which will come in a subsequent commit.
Signed-off-by: David Woodhouse
Acked-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c| 2 +-
include/hw/xen/interface/arch-arm.h | 37
From: David Woodhouse
The refcounts actually correspond to 'active_ref' structures stored in a
GHashTable per "user" on the backend side (mostly, per XenDevice).
If we zero map_track[] on reset, then when the backend drivers get torn
down and release their mapping we hit the assert(s->map_track[
From: David Woodhouse
When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful
also to unplug the peer of the *Xen* PV NIC.
Signed-off-by: David Woodhouse
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/i386/xen/xe
From: David Woodhouse
The per-vCPU upcall vector support had three problems. Firstly it was
using the wrong hypercall argument and would always return -EFAULT when
the guest tried to set it up. Secondly it was using the wrong ioctl() to
pass the vector to the kernel and thus the *kernel* would al
From: David Woodhouse
A previous implementation of this stuff used a 64-bit field for all of
the port information (vcpu/type/type_val) and did atomic exchanges on
them. When I implemented that in Qemu I regretted my life choices and
just kept it simple with locking instead.
So there's no need fo
From: David Woodhouse
This allows (non-primary) console devices to be created on the command
line and hotplugged.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 532 +++-
hw/xen/xe
From: David Woodhouse
In net_cleanup() we only need to delete the netdevs, as those may have
state which outlives Qemu when it exits, and thus may actually need to
be cleaned up on exit.
The nics, on the other hand, are owned by the device which created them.
Most devices don't bother to clean u
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 variants on the theme around w
From: David Woodhouse
Upstream Xen now ignores this flag¹, since the only guest kernel ever to
use it was buggy.
¹ https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=19c6cbd909
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 20 ++---
From: David Woodhouse
This allows us to use Xen PV networking with emulated Xen guests, and to
add them on the command line or hotplug.
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 11 +
hw/net/xen_nic.c | 484
From: David Woodhouse
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code fr
From: David Woodhouse
The loop over nd_table[] to add PCI NICs is repeated in quite a few
places. Add a helper function to do it.
Some platforms also try to instantiate a specific model in a specific
slot, to match the real hardware. Add pci_init_nic_in_slot() for that
purpose.
Signed-off-by: D
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 launch emulated Xen guests with '-nic user', and this fixes
the setup for X
From: David Woodhouse
This will instantiate any NICs which live on a given bus type. Each bus
is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for
Xen it's xen → xen-net-device; no point in overengineering it unless we
actually want more).
Signed-off-by: David Woodhouse
---
From: David Woodhouse
There's no need to force the user to assign a vdev. We can automatically
assign one, starting at xvda and searching until we find the first disk
name that's unused.
This means we can now allow '-drive if=xen,file=xxx' to work without an
explicit separate -driver argument, j
From: David Woodhouse
This will allow Linux guests (since v6.0) to use the per-vCPU upcall
vector delivered as MSI through the local APIC.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386/kvm
From: David Woodhouse
When fire_watch_cb() found the response buffer empty, it would call
deliver_watch() to generate the XS_WATCH_EVENT message in the response
buffer and send an event channel notification to the guest… without
actually *copying* the response buffer into the ring. So there was
n
From: David Woodhouse
A guest which has configured the per-vCPU upcall vector may set the
HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero.
For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support
for HVMOP_set_evtchn_upcall_vector") will just do this after se
On 25.10.2023 16:50, Nicola Vetrini wrote:
> Ok, I'll send a revised version using MASK_LOWEST_BIT, taking into
> account also the
> other comments about the explanation on the macro definition
> (which some IDEs even show when hovering on its usage, which could
> partially address
> the latter c
flight 183525 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183525/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 10/22/23 12:51, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/riscv/microchip_pfsoc.c | 13 ++---
hw/riscv/sifive_u.c| 7 +--
2 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/risc
On Wed, 2023-10-25 at 12:42 -0300, Daniel Henrique Barboza wrote:
>
> I believe you forgot to remove the 'nd' variable. Building with this patch
> (applying
> patches 1 to 4 first) fails with:
>
>
> ../hw/riscv/microchip_pfsoc.c: In function ‘microchip_pfsoc_soc_realize’:
> ../hw/riscv/microchi
Hi,
On 25/10/2023 09:18, Jan Beulich wrote:
On 24.10.2023 21:59, Stefano Stabellini wrote:
If I understood correctly I am fine with that. To make sure we are all
on the same page, can you provide a couple of samples?
Taking the earlier example, instead of DRIVERS_PASSTHROUGH_VTD_DMAR_H it
wou
On 25.10.2023 17:58, Julien Grall wrote:
> On 25/10/2023 09:18, Jan Beulich wrote:
>> On 24.10.2023 21:59, Stefano Stabellini wrote:
>>> If I understood correctly I am fine with that. To make sure we are all
>>> on the same page, can you provide a couple of samples?
>>
>> Taking the earlier example
On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> On 24.10.23 15:45, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > >
> > > > I can probably change xen_send_IPI_one() to not need
> > > > irq_get_chip_data().
> > >
> > > David, could you test the at
flight 183522 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183522/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail pass in 183519
test-armhf-armhf-libvirt-qcow2 1
On 25/10/2023 17:01, Jan Beulich wrote:
On 25.10.2023 17:58, Julien Grall wrote:
On 25/10/2023 09:18, Jan Beulich wrote:
On 24.10.2023 21:59, Stefano Stabellini wrote:
If I understood correctly I am fine with that. To make sure we are all
on the same page, can you provide a couple of sample
Before the MMU is turned on, the address returned for any symbol will always be
physical address. Thus, one can use adr_l instead of load_paddr.
create_table_entry() now takes an extra argument to denote if it is called after
the mmu is turned on or not. If it is called with mmu on, then it uses
flight 183526 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183526/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 884ef984541c3e346d39e423fea53cf25066ff5a
baseline version:
ovmf 1f21e11168dd6a071a92e
Hi Ayan,
On 25/10/2023 19:03, Ayan Kumar Halder wrote:
> Before the MMU is turned on, the address returned for any symbol will always
> be
> physical address. Thus, one can use adr_l instead of load_paddr.
>
> create_table_entry() now takes an extra argument to denote if it is called
> after
>
A fix to the recent Ucode changes which I ultimately didn't insist on owing to
the Xen 4.18 timeline, and enough of the start on the CPU Kconfig to allow
randconfig to check the boundary.
There are many more ucode fixes to come...
Andrew Cooper (2):
x86/ucode: Move vendor specifics back out of
1 - 100 of 165 matches
Mail list logo
