flight 181765 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-vhd 13 guest-start fail REGR. vs. 180278
test-arm64-arm64-li
flight 181766 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181766/
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
flight 181763 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181763/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-pair 10 xen-install/src_host fail pass in 181756
test-amd64-amd64-xl-qemut-debian
On Tue, 11 Jul 2023, Luca Fancellu wrote:
> > On 10 Jul 2023, at 21:28, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > Rule 9.4 is non-controversial and we have no violations.
> >
> > Rule 7.4 is considered a good idea with the caveat that assigning a
> > string literal to
From: Stefano Stabellini
Specify that {} is allowed for zero-initialization.
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 72aa986bce..29a777938a 100644
--- a/docs/misra/rule
When mapping BARs for vPCI, it's valid for a BAR start address to equal the BAR
end address (i.e. s == e) since e is inclusive. However, pci_check_bar()
currently returns false in this case, which results in Xen not mapping the BAR.
In this example boot log, Linux has mapped the BARs, but since Xen
On 7/11/23 12:04, Roger Pau Monné wrote:
> On Tue, Jul 11, 2023 at 11:46:47AM -0400, Stewart Hildebrand wrote:
>> When mapping BARs for vPCI, it's valid for a BAR start address to equal the
>> BAR
>> end address (i.e. s == e). However, pci_check_bar() currently returns false
>> in
>> this case, w
Hi Jan,
Jan Beulich writes:
> On 11.07.2023 02:46, Volodymyr Babchuk wrote:
>> Add per-domain d->pci_lock that protects access to
>> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
>> that underlying pdev will not disappear under feet. Later it will also
>> protect pdev->v
On 7/11/23 12:10, Julien Grall wrote:
> Hi,
>
> On 11/07/2023 16:46, Stewart Hildebrand wrote:
>> When mapping BARs for vPCI, it's valid for a BAR start address to equal the
>> BAR
>> end address (i.e. s == e). However, pci_check_bar() currently returns false
>> in
>> this case, which results in
On Tue, Jul 11, 2023 at 10:41 AM Jan Beulich wrote:
>
> On 11.07.2023 16:16, Jason Andryuk wrote:
> > On Tue, Jul 11, 2023 at 4:18 AM Jan Beulich wrote:
> >> On 10.07.2023 17:22, Jason Andryuk wrote:
> >>> On Mon, Jul 10, 2023 at 9:13 AM Jan Beulich wrote:
> On 06.07.2023 20:54, Jason Andry
Hi there.
Mandatory Rule 19.1 (An object shall not be assigned or copied to an
overlapping object) is directly targeted at two undefined behaviors,
one of which is the subject of 6.5.16.1p3, namely:
If the value being stored in an object is read from another object
that overlaps in any way
flight 181761 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181761/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-vhd 13 guest-start fail REGR. vs. 180278
test-arm64-arm64-li
On 11.07.2023 17:43, Ayan Kumar Halder wrote:
> On 10/07/2023 11:08, Jan Beulich wrote:
>> On 07.07.2023 13:35, Ayan Kumar Halder wrote:
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -1342,13 +1342,9 @@ pci_uart_config(struct ns16550 *uart, bool_t
>>> skip_amt, u
Hi,
On 11/07/2023 16:46, Stewart Hildebrand wrote:
When mapping BARs for vPCI, it's valid for a BAR start address to equal the BAR
end address (i.e. s == e). However, pci_check_bar() currently returns false in
this case, which results in Xen not mapping the BAR. In this example boot log,
Linux h
Hi Michal,
On 11/07/2023 09:29, Michal Orzel wrote:
At the moment, we limit the allocation size when creating a domU dtb to
4KB, which is not enough when using a passthrough dtb with several nodes.
Improve the handling by accounting for a dtb bootmodule (if present)
size separately, while keepin
On Tue, Jul 11, 2023 at 11:46:47AM -0400, Stewart Hildebrand wrote:
> When mapping BARs for vPCI, it's valid for a BAR start address to equal the
> BAR
> end address (i.e. s == e). However, pci_check_bar() currently returns false in
> this case, which results in Xen not mapping the BAR. In this ex
Hi,
On 11/07/2023 10:15, Luca Fancellu wrote:
On 11 Jul 2023, at 09:29, Michal Orzel wrote:
Fix the error path in domain_handle_dtb_bootmodule(), so that the memory
previously mapped is unmapped before returning the error code. This is
because the function shall not make assumptions on the
From: Petr Tesařík Sent: Monday, July 10, 2023 2:36 AM
>
> On Sat, 8 Jul 2023 15:18:32 +
> "Michael Kelley (LINUX)" wrote:
>
> > From: Petr Tesařík Sent: Friday, July 7, 2023 3:22 AM
> > >
> > > On Fri, 7 Jul 2023 10:29:00 +0100
> > > Greg Kroah-Hartman wrote:
> > >
> > > > On Thu, Jul 06
When mapping BARs for vPCI, it's valid for a BAR start address to equal the BAR
end address (i.e. s == e). However, pci_check_bar() currently returns false in
this case, which results in Xen not mapping the BAR. In this example boot log,
Linux has mapped the BARs, but since Xen did not map them, Li
Hi Jan,
On 10/07/2023 11:08, Jan Beulich wrote:
On 07.07.2023 13:35, Ayan Kumar Halder wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1342,13 +1342,9 @@ pci_uart_config(struct ns16550 *uart, bool_t skip_amt,
unsigned int idx)
}
}
-if ( !skip
On 11.07.2023 16:16, Jason Andryuk wrote:
> On Tue, Jul 11, 2023 at 4:18 AM Jan Beulich wrote:
>> On 10.07.2023 17:22, Jason Andryuk wrote:
>>> On Mon, Jul 10, 2023 at 9:13 AM Jan Beulich wrote:
On 06.07.2023 20:54, Jason Andryuk wrote:
> @@ -510,6 +510,22 @@ choice of `dom0-kernel` is d
On Tue, Jul 11, 2023 at 4:18 AM Jan Beulich wrote:
>
> On 10.07.2023 17:22, Jason Andryuk wrote:
> > On Mon, Jul 10, 2023 at 9:13 AM Jan Beulich wrote:
> >> On 06.07.2023 20:54, Jason Andryuk wrote:
> >>> @@ -510,6 +510,22 @@ choice of `dom0-kernel` is deprecated and not
> >>> supported by all D
flight 181759 libvirt real [real]
flight 181764 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181759/
http://logs.test-lab.xenproject.org/osstest/logs/181764/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
On Tue, Jul 11, 2023 at 12:53:31PM +0200, Jan Beulich wrote:
> On 10.07.2023 16:43, Roger Pau Monné wrote:
> > On Mon, Jul 10, 2023 at 12:56:27PM +0200, Jan Beulich wrote:
> >> On 07.07.2023 11:53, Roger Pau Monne wrote:
> >>> The current logic to init the local APIC and the IO-APIC does init the
>
On 10.07.2023 22:59, Julien Grall wrote:
>> ---
>> I'm not really certain about XEN_DOMCTL_irq_permission: With pIRQ-s not
>> used, the prior pIRQ -> IRQ translation cannot have succeeded on Arm, so
>> quite possibly the entire domctl is unused there? Yet then how is access
>> to particular device
On 11.07.2023 09:27, Julien Grall wrote:
> On 10/07/2023 08:33, Jan Beulich wrote:
>> On 03.05.2023 17:31, Jan Beulich wrote:
>>> The 1st patch (new in v2) has the effect of the 2nd one no longer
>>> affecting Arm.
>>>
>>> 1: restrict concept of pIRQ to x86
>>> 2: cmdline: document and enforce "ext
On 10.07.2023 16:43, Roger Pau Monné wrote:
> On Mon, Jul 10, 2023 at 12:56:27PM +0200, Jan Beulich wrote:
>> On 07.07.2023 11:53, Roger Pau Monne wrote:
>>> The current logic to init the local APIC and the IO-APIC does init the
>>> former first before doing any kind of sanitation on the IO-APIC pi
On 11.07.2023 11:14, Roger Pau Monné wrote:
> On Mon, Jul 10, 2023 at 06:27:06PM +0200, Jan Beulich wrote:
>> On 10.07.2023 16:12, Roger Pau Monne wrote:
>>> Commit 9473d9a24182 set the ASK mode without checking if there was a
>>> `vga` option provided in the command line. This breaks existing
>>>
On 11.07.2023 02:46, Volodymyr Babchuk wrote:
> Add per-domain d->pci_lock that protects access to
> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
> that underlying pdev will not disappear under feet. Later it will also
> protect pdev->vpci structure and pdev access in modif
flight 181756 xen-unstable real [real]
flight 181762 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181756/
http://logs.test-lab.xenproject.org/osstest/logs/181762/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 10.07.2023 23:08, Stefano Stabellini wrote:
> On Mon, 10 Jul 2023, Federico Serafini wrote:
>> The headline of MISRA C:2012 Rule 8.3 states that:
>> "All declarations of an object or function shall use the same names and
>> type qualifiers".
>>
>> Change parameter names to meet the following req
> On 10 Jul 2023, at 21:28, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Rule 9.4 is non-controversial and we have no violations.
>
> Rule 7.4 is considered a good idea with the caveat that assigning a
> string literal to const void is allowed. I added a note to specify it.
>
Introduce support for handling MSR features in
libxl_cpuid_parse_config(). The MSR policies are added to the
libxl_cpuid_policy like the CPUID one, which gets passed to
xc_cpuid_apply_policy().
This allows existing users of libxl to provide MSR related features as
key=value pairs to libxl_cpuid_p
The current implementation in libxl_cpuid_parse_config() requires
keeping a list of cpuid feature bits that should be mostly in sync
with the contents of cpufeatureset.h.
Avoid such duplication by using the automatically generated list of
cpuid features in INIT_FEATURE_NAMES in order to map featur
Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
newly created cpuid_add() local helper. This is in preparation for
also adding MSR feature parsing support.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/libs/light/libxl_cpuid.c | 120 +
Like it's done with CPUID, introduce support for passing MSR values to
xc_cpuid_apply_policy(). The chosen format for expressing MSR policy
data matches the current one used for CPUID. Note that existing
callers of xc_cpuid_apply_policy() can pass NULL as the value for the
newly introduced 'msr'
Add a new array field to libxl_cpuid_policy in order to store the MSR
policies.
Note that libxl_cpuid_policy_list_{copy,length,parse_json,gen_json}
are not adjusted to deal with the new MSR array now part of
libxl_cpuid_policy_list.
Adding the MSR data in the libxl_cpuid_policy_list type is done
Currently libxl_cpuid_policy_list is an opaque type to the users of
libxl, and internally it's an array of xc_xend_cpuid objects.
Change the type to instead be a structure that contains one array for
CPUID policies, in preparation for it also holding another array for
MSR policies.
Signed-off-by:
Hello,
The following series adds support for handling guest MSR features as
defined in arch-x86/cpufeatureset.h.
The end result is the user being able to use such features with the
xl.cfg(5) cpuid option. This also involves adding support to all the
underlying layers, so both libxl and libxc als
On 10.07.2023 22:28, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Rule 9.4 is non-controversial and we have no violations.
>
> Rule 7.4 is considered a good idea with the caveat that assigning a
> string literal to const void is allowed. I added a note to specify it.
>
> Signed-off-
> On 11 Jul 2023, at 09:29, Michal Orzel wrote:
>
> At the moment, we limit the allocation size when creating a domU dtb to
> 4KB, which is not enough when using a passthrough dtb with several nodes.
> Improve the handling by accounting for a dtb bootmodule (if present)
> size separately, whil
> On 11 Jul 2023, at 09:29, Michal Orzel wrote:
>
> Fix the error path in domain_handle_dtb_bootmodule(), so that the memory
> previously mapped is unmapped before returning the error code. This is
> because the function shall not make assumptions on the way of handling
> its error code in the
On Mon, Jul 10, 2023 at 06:27:06PM +0200, Jan Beulich wrote:
> On 10.07.2023 16:12, Roger Pau Monne wrote:
> > Commit 9473d9a24182 set the ASK mode without checking if there was a
> > `vga` option provided in the command line. This breaks existing
> > behavior, so exit early without changes if `vg
flight 181760 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181760/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8dab4eebe435fc28cae329867a74cee45d040d3e
baseline version:
ovmf 964a4f032dcd15d7b0d92
At the moment, we limit the allocation size when creating a domU dtb to
4KB, which is not enough when using a passthrough dtb with several nodes.
Improve the handling by accounting for a dtb bootmodule (if present)
size separately, while keeping 4KB for the Xen generated nodes (still
plenty of spac
Fix the error path in domain_handle_dtb_bootmodule(), so that the memory
previously mapped is unmapped before returning the error code. This is
because the function shall not make assumptions on the way of handling
its error code in the callers. Today we call panic in case of domU
creation failure,
First patch with a fix (more for a logic than a bug) added to series for
ease of merging.
Michal Orzel (2):
xen/arm: Fix domain_handle_dtb_bootmodule() error path
xen/arm: Account for domU dtb bootmodule size separately
xen/arch/arm/domain_build.c | 27 ++-
1 file cha
On 10.07.2023 17:22, Jason Andryuk wrote:
> On Mon, Jul 10, 2023 at 9:13 AM Jan Beulich wrote:
>> On 06.07.2023 20:54, Jason Andryuk wrote:
>>> @@ -510,6 +510,22 @@ choice of `dom0-kernel` is deprecated and not
>>> supported by all Dom0 kernels.
>>> * `` and `` are integers which represent max a
Hi ,
> On 9 Jul 2023, at 1:10 am, Stefano Stabellini wrote:
>
> On Fri, 30 Jun 2023, Rahul Singh wrote:
>> Hi Oleksandr,
>>
>> Thanks for reviewing the code.
>>
>>> On 29 Jun 2023, at 7:06 pm, Oleksandr Tyshchenko
>>> wrote:
>>>
>>>
>>>
>>> On 29.06.23 18:46, Rahul Singh wrote:
>>>
>>> H
Hi Jan,
On 10/07/2023 08:33, Jan Beulich wrote:
On 03.05.2023 17:31, Jan Beulich wrote:
The 1st patch (new in v2) has the effect of the 2nd one no longer
affecting Arm.
1: restrict concept of pIRQ to x86
2: cmdline: document and enforce "extra_guest_irqs" upper bounds
REST- and Arm-maintaine
50 matches
Mail list logo
