flight 183518 linux-linus real [real]
flight 183520 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183518/
http://logs.test-lab.xenproject.org/osstest/logs/183520/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
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 while(1) and alike are allowed.
> >
> > + * -
flight 183517 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183517/
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 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:
> - refine configurations and justifications
> ---
> au
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 by the Rule.
> >
> > Mechanical changes.
> >
> >
On Tue, 24 Oct 2023, Jan Beulich wrote:
> On 24.10.2023 15:31, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 23/10/2023 21:47, Stefano Stabellini wrote:
> >> On Mon, 23 Oct 2023, Jan Beulich wrote:
> >>> On 21.10.2023 01:26, Stefano Stabellini wrote:
> On Fri, 20 Oct 2023, Jan Beulich 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 2 TiB to simplify
> > the logic to e
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.rst, functions used only in asm code
> >
On 10/16/23 07:00, Jan Beulich wrote:
> On 13.10.2023 00:09, Volodymyr Babchuk wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -695,6 +695,9 @@ struct domain *domain_create(domid_t domid,
>> radix_tree_init(&d->pirq_tree);
>> }
>>
>> +if ( !is_idle_domain(d)
On Tue, 24 Oct 2023, Henry Wang wrote:
> Hi Stefano,
>
> > On Oct 24, 2023, at 04:56, Stefano Stabellini
> > wrote:
> >
> > Signed-off-by: Stefano Stabellini
>
> I saw I was CCed so:
>
> Release-acked-by: Henry Wang
Thanks everyone for the acks. For simplicity I'll add it to my for-4.19
br
On Tue, 24 Oct 2023, Bertrand Marquis wrote:
> Hi Julien,
>
> > On 23 Oct 2023, at 19:52, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > The 'break' the XEN_DOMCTL_set_address_size is unreachable and tools
> > like Eclair will report as a violation of Misra Rule 2.1.
> >
> > Furthermo
flight 183516 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183516/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d85bf54b7f462eb0297351b5f8dfde09adf617fb
baseline version:
ovmf e17e58e81b356a347102e
flight 183510 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183510/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183503
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Stewart,
On 04/10/2023 15:55, Stewart Hildebrand wrote:
From: Oleksandr Tyshchenko
Move code for processing DT IOMMU specifier to a separate helper.
This helper will be re-used for adding PCI devices by the subsequent
patches as we will need exact the same actions for processing
DT PCI-IOMM
On Tue, 2023-10-24 at 17:22 +0100, Paul Durrant wrote:
> On 24/10/2023 16:48, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 16:44 +0100, Paul Durrant wrote:
> > > On 19/10/2023 16:40, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
> > > > On soft reset, the prinary console event
On 23/10/2023 10:21, Henry Wang wrote:
Hi all,
Hi Henry,
This series should be the final CHANGELOG changes for 4.18.
The first patch is mentioning the MISRA-C improvement during the
4.18 dev cycle, second patch is added as a clean-up patch during
the review of this series, so these shoul
Hi Henry,
On 23/10/2023 10:21, Henry Wang wrote:
Signed-off-by: Henry Wang
Acked-by: Julien Grall
>
flight 183511 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183511/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e17e58e81b356a347102ee6d780bf699544e9b81
baseline version:
ovmf fb044b7fe893a4545995b
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 wrote:
> > > > > On 16/10/2023 16
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 wrote:
On 16/10/2023 16:19, David Woodhouse wrote:
From: David Woodhouse
The primary console is spec
On 24/10/2023 16:48, David Woodhouse wrote:
On Tue, 2023-10-24 at 16:44 +0100, Paul Durrant wrote:
On 19/10/2023 16:40, David Woodhouse wrote:
From: David Woodhouse
On soft reset, the prinary console event channel needs to be rebound to
the backend port (in the xen-console driver). We could p
On 24/10/2023 16:17, David Woodhouse wrote:
[snip]
I don't think that's really a valid state for a network frontend. Linux
netback just ignores it.
Must we? I was thinking of making the ->frontend_changed() methods
optional and allowing backends to just provide ->connect() and
->disconnect() m
On Tue, 2023-10-24 at 16:24 +0100, Alex Bennée wrote:
>
> David Woodhouse writes:
>
> > I hadn't got round to getting the PV shim running yet; I thought it would
> > need work on the multiboot loader. Turns out it doesn't. I *did* need to
> > fix a couple of brown-paper-bag bugs in the per-vCPU
On 24.10.2023 17:22, Federico Serafini wrote:
> On 24/10/23 16:32, Jan Beulich wrote:
>> On 24.10.2023 15:22, Federico Serafini wrote:
>>> Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
>>> an object or function shall use the same names and type qualifiers")
>>> for the follo
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 wrote:
> > > On 16/10/2023 16:19, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
> > > > The primary console is special because th
On Tue, 2023-10-24 at 16:44 +0100, Paul Durrant wrote:
> On 19/10/2023 16:40, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > On soft reset, the prinary console event channel needs to be rebound to
> > the backend port (in the xen-console driver). We could put that into the
> > xen-conso
On 19/10/2023 16:40, David Woodhouse wrote:
From: David Woodhouse
On soft reset, the prinary console event channel needs to be rebound to
the backend port (in the xen-console driver). We could put that into the
xen-console driver itself, but it's slightly less ugly to keep it within
the KVM/Xen
On 24/10/2023 16:37, David Woodhouse wrote:
On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant wrote:
On 16/10/2023 16:19, David Woodhouse wrote:
From: David Woodhouse
The primary console is special because the toolstack maps a page at a
fixed GFN and also allocates the guest-side event channel.
On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant wrote:
> On 16/10/2023 16:19, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The primary console is special because the toolstack maps a page at a
> > fixed GFN and also allocates the guest-side event channel. Add support
> > for that in e
On 19/10/2023 16:40, David Woodhouse wrote:
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. But Xen populates them, and it does
allow guests to
David Woodhouse writes:
> I hadn't got round to getting the PV shim running yet; I thought it would
> need work on the multiboot loader. Turns out it doesn't. I *did* need to
> fix a couple of brown-paper-bag bugs in the per-vCPU upcall vector support,
> and implement Xen console support though
On Tue, 2023-10-24 at 16:19 +0100, Paul Durrant wrote:
> On 19/10/2023 16:40, David Woodhouse wrote:
> > 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
On Tue, 2023-10-24 at 15:32 +0100, Paul Durrant wrote:
> On 17/10/2023 19:25, David Woodhouse wrote:
> > 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
On 24/10/23 16:32, Jan Beulich wrote:
On 24.10.2023 15:22, Federico Serafini wrote:
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same names and type qualifiers")
for the following functions:
- set_px_pminfo();
- guest_walk_tables_[0-9]
On 19/10/2023 16:40, David Woodhouse wrote:
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
On Tue, 2023-10-24 at 15:47 +0100, Paul Durrant wrote:
> On 17/10/2023 19:25, David Woodhouse wrote:
> > +
> > +#define xen_pv_printf(a, n, ...) qemu_printf(__VA_ARGS__)
>
> Why define this...
In the first place, just to make it build in the short term. Then I
forgot to clean it up before posting
On 24/10/2023 16:56, Jan Beulich wrote:
On 24.10.2023 16:31, Nicola Vetrini wrote:
@@ -225,8 +225,8 @@ static const struct dmi_system_id __initconstrel
reboot_dmi_table[] = {
.ident = "Dell OptiPlex 745",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-
On 19/10/2023 16:40, David Woodhouse wrote:
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
On 19/10/2023 16:39, David Woodhouse wrote:
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_evt
On 24.10.2023 16:31, Nicola Vetrini wrote:
> @@ -225,8 +225,8 @@ static const struct dmi_system_id __initconstrel
> reboot_dmi_table[] = {
> .ident = "Dell OptiPlex 745",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> -DMI_MATCH(DMI_PRODUCT_NA
Sporadically we have seen the following during AP bringup on AMD platforms
only:
microcode: CPU59 updated from revision 0x830107a to 0x830107a, date = 2023-05-17
microcode: CPU60 updated from revision 0x830104d to 0x830107a, date = 2023-05-17
CPU60: No irq handler for vector 27 (IRQ -2147483648)
m
On 24.10.2023 16:31, Nicola Vetrini wrote:
> Fully explicit initialization of the cmd array resolves a violation of
> MISRA C:2012 Rule 9.3.
>
> Signed-off-by: Nicola Vetrini
While I'm not overly happy, we accepted the rule, so
Acked-by: Jan Beulich
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 by the Rule.
>
> Mechanical changes.
>
> Signed-off-by: Nicola Vetrini
While not overly bad, I
On 17/10/2023 19:25, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 9 +
hw/net/xen_nic.c | 426 +-
hw/xenpv/xen_machine_pv.c | 1 -
4 files c
On 24.10.2023 16:01, Federico Serafini wrote:
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -692,7 +692,7 @@ static void iommu_check_ppr_log(struct amd_iommu *iommu)
> spin_unlock_irqrestore(&iommu->lock, flags);
> }
>
> -static void
On Tue, 2023-10-24 at 15:10 +0100, Paul Durrant wrote:
> On 16/10/2023 16:19, David Woodhouse wrote:
> > --- a/hw/char/xen_console.c
> > +++ b/hw/char/xen_console.c
> > @@ -468,7 +468,7 @@ static void
> > xen_console_device_create(XenBackendInstance *backend,
> > Chardev *cd = NULL;
> >
On 24.10.2023 15:22, Federico Serafini wrote:
> Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
> an object or function shall use the same names and type qualifiers")
> for the following functions:
> - set_px_pminfo();
> - guest_walk_tables_[0-9]+_levels().
>
> Update file do
On 17/10/2023 19:25, David Woodhouse wrote:
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
Fully explicit initialization of the cmd array resolves a violation of
MISRA C:2012 Rule 9.3.
Signed-off-by: Nicola Vetrini
---
xen/drivers/passthrough/amd/iommu_cmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c
b/xen/drivers/pas
This series addresses some of the violations of Rule 9.3, which is about
partially initialized arrays. The resolution strategy proposed in these patches
uses designated initializers, except in patch 4, allowed by MISRA for
sparse initialization. The reason why I chose this method is that, given tha
Partially explicitly initalized .matches arrays result in violations
of Rule 9.3; this is resolved by using designated initializers,
which is permitted by the Rule.
Mechanical changes.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/shutdown.c | 152
1 fi
On 10/24/23 03:39, Roger Pau Monné wrote:
> On Tue, Oct 24, 2023 at 09:09:45AM +0200, Jan Beulich wrote:
>> On 23.10.2023 18:36, Stewart Hildebrand wrote:
>>> During xl pci-assignable-add, pciback may reset the device while memory
>>> decoding
>>> (PCI_COMMAND_MEMORY) is enabled. After device rese
Partially explicitly initalized .matches arrays result in violations
of Rule 9.3; this is resolved by using designated initializers,
which is permitted by the Rule.
Mechanical changes.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/quirks.c | 20 ++--
1 file changed, 10 inse
Partially explicitly initalized .matches arrays result in violations
of Rule 9.3; this is resolved by using designated initializers,
which is permitted by the Rule.
Mechanical changes.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/ioport_emulate.c | 32
1 file
On 24.10.2023 15:40, Nicola Vetrini wrote:
> On 24/10/2023 10:12, Jan Beulich wrote:
>> On 24.10.2023 09:58, Nicola Vetrini wrote:
>>> On 24/10/2023 09:32, Jan Beulich wrote:
On 23.10.2023 11:56, Nicola Vetrini wrote:
> --- a/xen/arch/x86/include/asm/asm_defns.h
> +++ b/xen/arch/x86/in
On 24.10.2023 15:31, Julien Grall wrote:
> Hi Stefano,
>
> On 23/10/2023 21:47, Stefano Stabellini wrote:
>> On Mon, 23 Oct 2023, Jan Beulich wrote:
>>> On 21.10.2023 01:26, Stefano Stabellini wrote:
On Fri, 20 Oct 2023, Jan Beulich wrote:
> On 19.10.2023 18:19, Stefano Stabellini wrote:
On 16/10/2023 16:19, David Woodhouse wrote:
From: David Woodhouse
The primary console is special because the toolstack maps a page at a
fixed GFN and also allocates the guest-side event channel. Add support
for that in emulated mode, so that we can have a primary console.
Add a *very* rudiment
flight 183505 libvirt real [real]
flight 183512 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183505/
http://logs.test-lab.xenproject.org/osstest/logs/183512/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
On 16/10/2023 16:19, David Woodhouse wrote:
From: David Woodhouse
Ensure that we have a XenBackendInstance for every device regardless
of whether it was "discovered" in XenStore or created directly in QEMU.
This allows the backend_list to be a source of truth about whether a
given backend exis
Change parameter name and emphasize that it is deliberately not used through a
comment followed by the statement '(void) data;'.
This also addresses a violation of MISRA C:2012 Rule 2.7 ("A function should
not contain unused parameters").
No functional change.
Signed-off-by: Federico Serafini
--
The current implementation of x2APIC requires to either use Cluster Logical or
Physical mode for all interrupts. However the selection of Physical vs Logical
is not done at APIC setup, an APIC can be addressed both in Physical or Logical
destination modes concurrently.
Introduce a new x2APIC mode
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:
- refine configurations and justifications
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 10 ++
d
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 triple-faults when bringing it back online
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.rst, functions used only in asm code
are allowed to have no prior declaration visible when being
defined, hen
On 24/10/2023 10:12, Jan Beulich wrote:
On 24.10.2023 09:58, Nicola Vetrini wrote:
On 24/10/2023 09:32, Jan Beulich wrote:
On 23.10.2023 11:56, Nicola Vetrini wrote:
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@ -31,6 +31,7 @@ asm ( "\t.equ CONFIG_IND
On 24/10/2023 14:29, David Woodhouse wrote:
On Tue, 2023-10-24 at 13:59 +0100, Paul Durrant wrote:
On 24/10/2023 13:56, David Woodhouse wrote:
On Tue, 2023-10-24 at 13:42 +0100, Paul Durrant wrote:
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -711,8 +711,16 @@ static void xen_device_fron
Hi Julien,
> On 23 Oct 2023, at 19:52, Julien Grall wrote:
>
> From: Julien Grall
>
> The 'break' the XEN_DOMCTL_set_address_size is unreachable and tools
> like Eclair will report as a violation of Misra Rule 2.1.
>
> Furthermore, the nested switch is not very easy to read. So move
> out the
Hi Stefano,
On 23/10/2023 21:47, Stefano Stabellini wrote:
On Mon, 23 Oct 2023, Jan Beulich wrote:
On 21.10.2023 01:26, Stefano Stabellini wrote:
On Fri, 20 Oct 2023, Jan Beulich wrote:
On 19.10.2023 18:19, Stefano Stabellini wrote:
On Thu, 19 Oct 2023, Jan Beulich wrote:
On 19.10.2023 02:4
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 2 TiB to simplify
> the logic to enable the MMU. The limit was decided based on
> how known platf
Hi Stefano,
> On 23 Oct 2023, at 22:56, Stefano Stabellini wrote:
>
> Signed-off-by: Stefano Stabellini
Acked-by: Bertrand Marquis
Cheers
Bertrand
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f61b5a32a1..a5a5f2bffb 100644
> -
On Tue, 2023-10-24 at 13:59 +0100, Paul Durrant wrote:
> On 24/10/2023 13:56, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 13:42 +0100, Paul Durrant wrote:
> > >
> > > > --- a/hw/xen/xen-bus.c
> > > > +++ b/hw/xen/xen-bus.c
> > > > @@ -711,8 +711,16 @@ static void xen_device_frontend_create(Xe
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same names and type qualifiers")
for the following functions:
- set_px_pminfo();
- guest_walk_tables_[0-9]+_levels().
Update file docs/misra/deviations.rst accordingly.
No functional change.
On Tue, 2023-10-24 at 13:29 +0100, Paul Durrant wrote:
>
> > + /* If the guest has set a per-vCPU callback vector, prefer that. */
> > + if (gsi && kvm_xen_has_vcpu_callback_vector()) {
> > + in_kernel = kvm_xen_has_cap(EVTCHN_SEND);
> > + gsi = 0;
> > + }
> > +
>
> So this
On 16/10/2023 16:19, David Woodhouse wrote:
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.
Th
On Tue, Oct 24, 2023 at 02:08:42PM +0200, Jan Beulich wrote:
> On 24.10.2023 14:06, Jan Beulich wrote:
> > On 24.10.2023 13:36, Roger Pau Monné wrote:
> >> What is your reasoning for wanting the smp_processor_id() check in
> >> the caller rather than bogus_8259A_irq()? It does seem fine to me to
>
On 16/10/2023 16:19, David Woodhouse wrote:
This allows (non-primary) console devices to be created on the command
line.
Signed-off-by: David Woodhouse
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 502 +++-
hw/xen/xen-legacy-backend.
Hi,
On 23/10/2023 21:56, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi Jan,
On 23/10/2023 11:33, Jan Beulich wrote:
On 23.10.2023 12:17, Oleksii wrote:
On Thu, 2023-10-19 at 13:12 +0100, Julien Grall wrote:
Hi,
On 19/10/2023 12:41, Jan Beulich wrote:
On 19.10.2023 13:27, Julien Grall wrote:
that doesn't involve one arch to symlink headers from another
arch.
On 24/10/2023 13:56, David Woodhouse wrote:
On Tue, 2023-10-24 at 13:42 +0100, Paul Durrant wrote:
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -711,8 +711,16 @@ static void xen_device_frontend_create(XenDevice *xendev,
Error **errp)
{
ERRP_GUARD();
XenBus *xenbus = XE
On Tue, 2023-10-24 at 13:16 +0100, Paul Durrant wrote:
> On 16/10/2023 16:18, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The per-vCPU upcall vector support had two problems. Firstly it was
> > using the wrong hypercall argument and would always return -EFAULT.
> > And secondly it wa
On Tue, 2023-10-24 at 13:42 +0100, Paul Durrant wrote:
>
> > --- a/hw/xen/xen-bus.c
> > +++ b/hw/xen/xen-bus.c
> > @@ -711,8 +711,16 @@ static void xen_device_frontend_create(XenDevice
> > *xendev, Error **errp)
> > {
> > ERRP_GUARD();
> > XenBus *xenbus = XEN_BUS(qdev_get_parent
On Tue, 2023-10-24 at 13:35 +0100, Paul Durrant wrote:
> On 16/10/2023 16:19, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > This is kind of redundant since without being able to get these
> > through
> > ome other method (HVMOP_get_param) the guest wouldn't be able to
> > access
>
> ^
On Mon, 2023-10-23 at 12:47 +0200, Jan Beulich wrote:
> On 23.10.2023 12:43, Oleksii wrote:
> > On Thu, 2023-10-19 at 11:44 +0200, Jan Beulich wrote:
> > > On 14.09.2023 16:56, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/iommu.h
> > > > @@ -0,0 +1,17 @@
> > >
On 16/10/2023 16:19, David Woodhouse wrote:
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 a
On Mon, 2023-10-23 at 13:58 +0200, Jan Beulich wrote:
> On 23.10.2023 12:50, Oleksii wrote:
> > On Thu, 2023-10-19 at 11:55 +0200, Jan Beulich wrote:
> > > While more involved, I still wonder whether xen/pci.h could also
> > > avoid
> > > including asm/pci.h when !HAS_PCI. Of course there's more th
On 16/10/2023 16:19, David Woodhouse wrote:
From: David Woodhouse
This is kind of redundant since without being able to get these through
ome other method (HVMOP_get_param) the guest wouldn't be able to access
^ typo
XenStore in order to find them. But Xen populates them, and it does
allow
On 16/10/2023 16:19, David Woodhouse wrote:
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
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
Revie
On 16/10/2023 16:19, David Woodhouse wrote:
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
---
hw/i386/kvm/xen_xenstore.c| 2 +-
include/hw/xen/interface/ar
On 16/10/2023 16:18, David Woodhouse wrote:
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_evt
On 16/10/2023 16:18, David Woodhouse wrote:
From: David Woodhouse
The per-vCPU upcall vector support had two problems. Firstly it was
using the wrong hypercall argument and would always return -EFAULT.
And secondly it was using the wrong ioctl() to pass the vector to
the kernel and thus the *ke
On 24.10.2023 14:06, Jan Beulich wrote:
> On 24.10.2023 13:36, Roger Pau Monné wrote:
>> What is your reasoning for wanting the smp_processor_id() check in
>> the caller rather than bogus_8259A_irq()? It does seem fine to me to
>> do such check in bogus_8259A_irq(), as whether the IRQ is bogus als
On 24.10.23 12:41, Juergen Gross wrote:
On 24.10.23 09:43, David Woodhouse wrote:
On Tue, 2023-10-24 at 08:53 +0200, Juergen Gross wrote:
I'm puzzled. This path doesn't contain any of the RCU usage I've added in
commit 87797fad6cce.
Are you sure that with just reverting commit 87797fad6cce th
On 24.10.2023 13:36, Roger Pau Monné wrote:
> On Tue, Oct 24, 2023 at 12:51:08PM +0200, Jan Beulich wrote:
>> On 24.10.2023 12:14, Roger Pau Monné wrote:
>>> On Tue, Oct 24, 2023 at 11:33:21AM +0200, Jan Beulich wrote:
On 23.10.2023 14:46, Roger Pau Monne wrote:
> --- a/xen/arch/x86/i8259.
flight 183506 ovmf real [real]
flight 183508 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183506/
http://logs.test-lab.xenproject.org/osstest/logs/183508/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-
On Sun, Oct 22, 2023 at 16:51:23 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> Signed-off-by: David Woodhouse
Reviewed-by: Leif Lindholm
> ---
> hw/arm/sbsa-ref.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
>
On Tue, Oct 24, 2023 at 12:51:08PM +0200, Jan Beulich wrote:
> On 24.10.2023 12:14, Roger Pau Monné wrote:
> > On Tue, Oct 24, 2023 at 11:33:21AM +0200, Jan Beulich wrote:
> >> On 23.10.2023 14:46, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/i8259.c
> >>> +++ b/xen/arch/x86/i8259.c
> >>> @@ -37
flight 183503 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183503/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183499
test-amd64-amd64-xl-qemuu-win7-amd64
On 24.10.2023 12:14, Roger Pau Monné wrote:
> On Tue, Oct 24, 2023 at 11:33:21AM +0200, Jan Beulich wrote:
>> On 23.10.2023 14:46, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/i8259.c
>>> +++ b/xen/arch/x86/i8259.c
>>> @@ -37,6 +37,15 @@ static bool _mask_and_ack_8259A_irq(unsigned int irq);
>>>
On 24.10.23 09:43, David Woodhouse wrote:
On Tue, 2023-10-24 at 08:53 +0200, Juergen Gross wrote:
I'm puzzled. This path doesn't contain any of the RCU usage I've added in
commit 87797fad6cce.
Are you sure that with just reverting commit 87797fad6cce the issue doesn't
manifest anymore? I'd rat
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 platform boot plus some slack.
We had a recent report that this is not sufficien
1 - 100 of 123 matches
Mail list logo
