On 29.11.2022 17:21, Andrew Cooper wrote:
> On 29/11/2022 16:05, Roger Pau Monné wrote:
>> On Tue, Nov 29, 2022 at 03:46:30PM +0100, Jan Beulich wrote:
>>> Four of them are used in apic.c only and hence better wouldn't be
>>> exposed to other CUs. To avoid the need for forward declarations, move
>>
On 29.11.2022 21:56, Andrew Cooper wrote:
> On 29/11/2022 14:55, Jan Beulich wrote:
>> By defining the constant to zero when !SHADOW_PAGING we give compilers
>> the chance to eliminate a little more dead code elsewhere in the tree.
>> Plus, as a minor benefit, the general reference count can be one
On 29.11.2022 21:36, Andrew Cooper wrote:
> On 29/11/2022 14:51, Jan Beulich wrote:
>> Up until f61685a66903 ("x86: remove defunct init/load/save_msr()
>> hvm_funcs") the check of the _rsvd field served as an error check for
>> the earlier hvm_funcs.save_msr() invocation. With that invocation gone
On 29.11.2022 17:44, Roger Pau Monné wrote:
> On Tue, Nov 29, 2022 at 03:47:53PM +0100, Jan Beulich wrote:
>> Neither page_get_owner() nor mfn_to_page() are entirely trivial
>> operations - don't do the same thing twice in close succession. Instead
>> help CSE (when MEM_SHARING=y) by introducing a
On 29.11.2022 17:01, Julien Grall wrote:
> On 29/11/2022 15:39, Jan Beulich wrote:
>> While not as inefficient as it would be on x86 (due to suitable constant
>> loading and register pair storing instructions being available to fill
>> some of the fields), having the compiler construct an array of
On 29.11.2022 19:18, Ayan Kumar Halder wrote:
> On 29/11/2022 15:52, Julien Grall wrote:
>> On 29/11/2022 16:23, Ayan Kumar Halder wrote:
>>> On 29/11/2022 14:52, Julien Grall wrote:
On 29/11/2022 14:57, Ayan Kumar Halder wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc
flight 174991 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174991/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
flight 174989 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174989/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174976
test-armhf-armhf-libvirt 16 sav
On Mon, 28 Nov 2022, Luca Fancellu wrote:
> Change cppcheck invocation method by using the xen-analysis.py
> script using the arguments --run-cppcheck.
>
> Now cppcheck analysis will build Xen while the analysis is performed
> on the source files, it will produce a text report and an additional
>
flight 174992 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174992/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dd3ba82d31a6d3cc4564dc83c9229e13773b55da
baseline version:
ovmf 8aff08c817728092fda57
On Mon, 28 Nov 2022, Luca Fancellu wrote:
> Currently the script convert_misra_doc.py is using a loop through
> range(1,22) to enumerate rules that needs to be skipped, however
> range function does not include the stop counter in the enumeration
> ending up into list rules until 21.21 instead of i
flight 174990 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174990/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8aff08c817728092fda5707ae27cfa6321108980
baseline version:
ovmf b92e0495221a3b298b069
On Tue, 29 Nov 2022, Roger Pau Monne wrote:
> The currently lockless access to the xen console list in
> vtermno_to_xencons() is incorrect, as additions and removals from the
> list can happen anytime, and as such the traversal of the list to get
> the private console data for a given termno needs
On Tue, 29 Nov 2022, Roger Pau Monne wrote:
> The hvc machinery registers both a console and a tty device based on
> the hv ops provided by the specific implementation. Those two
> interfaces however have different locks, and there's no single locks
> that's shared between the tty and the console
On 29/11/2022 20:56, Andrew Cooper wrote:
> On 29/11/2022 14:55, Jan Beulich wrote:
>> By defining the constant to zero when !SHADOW_PAGING we give compilers
>> the chance to eliminate a little more dead code elsewhere in the tree.
>> Plus, as a minor benefit, the general reference count can be one
flight 174988 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
On 29/11/2022 14:55, Jan Beulich wrote:
> By defining the constant to zero when !SHADOW_PAGING we give compilers
> the chance to eliminate a little more dead code elsewhere in the tree.
> Plus, as a minor benefit, the general reference count can be one bit
> wider. (To simplify things, have PGC_pag
On Fri, 19 Jul 2019, Jan Beulich wrote:
> For easy spotting of struct/union/enum definitions we already commonly
> place the opening braces on the initial line of such a definition.
>
> We also often don't place the opening brace of an initializer on a
> separate line.
>
> And finally for compoun
On Fri, 19 Jul 2019, Jan Beulich wrote:
> Since the behavior of "diff -p" to use an unindented label as context
> identifier often makes it harder to review patches, make explicit the
> requirement for labels to be indented.
>
> Signed-off-by: Jan Beulich
Acked-by: Stefano Stabellini
> --- a/
On 29/11/2022 14:36, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 29/11/2022 14:49, Jan Beulich wrote:
> There's no need to recalculate / refetch the value from the stack
> (pointer).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 29/11/2022 14:51, Jan Beulich wrote:
> Up until f61685a66903 ("x86: remove defunct init/load/save_msr()
> hvm_funcs") the check of the _rsvd field served as an error check for
> the earlier hvm_funcs.save_msr() invocation. With that invocation gone
> the check makes no sense anymore. While dropp
On Fri, Nov 25, 2022 at 06:30:35AM +0100, Juergen Gross wrote:
> On 24.11.22 17:39, Josh Poimboeuf wrote:
> > On Thu, Nov 24, 2022 at 08:47:47AM +0100, Juergen Gross wrote:
> > > > > +++ b/arch/x86/xen/smp_pv.c
> > > > > @@ -385,17 +385,9 @@ static void xen_pv_play_dead(void) /* used only
> > > > >
On 29/11/2022 15:52, Julien Grall wrote:
On 29/11/2022 16:23, Ayan Kumar Halder wrote:
On 29/11/2022 14:52, Julien Grall wrote:
On 29/11/2022 14:57, Ayan Kumar Halder wrote:
Hi All,
Hi,
Hi Julien,
Hi Julien,
Many thanks for your inputs.
I am trying to gather opinions on how to su
On 11/21/22 02:21, Roger Pau Monne wrote:
> When running as a Xen dom0 the number of CPUs available to Linux can
> be different from the number of CPUs present on the system, but in
> order to properly fetch processor performance related data _PDC must
> be executed on all the physical CPUs online
On 29/11/2022 16:41, Andrew Cooper wrote:
> As for the actual flags exposed, it would be very beneficial not to copy
> the exist proc interface. It would be better to expose a subdir that
> had files containing booleans, because that also gives userspace an easy
> way to figure out if the particul
On 29/11/2022 16:29, Boris Ostrovsky wrote:
> Why not simply show unprocessed xen_start_flags as a hex value?
Providing a text representation follows what is currently the case:
[root@lcy2-dt128 /proc/xen]# cat capabilities
control_d
[root@lcy2-dt128 /proc/xen]#
The migrated form would yield:
r
On Tue, Nov 29, 2022 at 03:47:53PM +0100, Jan Beulich wrote:
> Neither page_get_owner() nor mfn_to_page() are entirely trivial
> operations - don't do the same thing twice in close succession. Instead
> help CSE (when MEM_SHARING=y) by introducing a local variable holding
> the page owner.
>
> Sig
On 29/11/2022 15:27, Juergen Gross wrote:
> On 29.11.22 16:00, Per Bilse wrote:
>> /proc/xen is a legacy pseudo filesystem which predates Xen support
>> getting merged into Linux. It has largely been replaced with more
>> normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for
>> user
On 11/29/22 10:00 AM, Per Bilse wrote:
+static ssize_t flags_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+ static char const *const sifstr[SIFN_NUM_SIFN] = {
+ [SIFN_PRIV] = "privileged",
+ [SIFN_INIT] = "initdomain",
+ [SIFN_MULTI] =
On 29/11/2022 16:05, Roger Pau Monné wrote:
> On Tue, Nov 29, 2022 at 03:46:30PM +0100, Jan Beulich wrote:
>> Four of them are used in apic.c only and hence better wouldn't be
>> exposed to other CUs. To avoid the need for forward declarations, move
>> apic_intr_init() past the four handlers.
>>
>>
On Tue, Nov 29, 2022 at 03:46:30PM +0100, Jan Beulich wrote:
> Four of them are used in apic.c only and hence better wouldn't be
> exposed to other CUs. To avoid the need for forward declarations, move
> apic_intr_init() past the four handlers.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau
Ping?
So far I've got some feedback from Jan which I've replied to, but I
haven't got any more feedback.
Both patches 1 and 2 are required in order for Xen dom0s to properly
handle ACPI Processor related data to the hypervisor. Patch 3 can be
deal with later.
Thanks, Roger.
On Mon, Nov 21, 2022
Hi Jan,
On 29/11/2022 15:39, Jan Beulich wrote:
While not as inefficient as it would be on x86 (due to suitable constant
loading and register pair storing instructions being available to fill
some of the fields), having the compiler construct an array of constants
on the stack still looks odd to
Hi Jan,
On 29/11/2022 15:39, Jan Beulich wrote:
It is generally preferable to not hold locks around allocation
functions. And indeed in the hwdom case there's no point at all to hold
the paging lock. Reduce the locked regions to the non-hwdom case, while
at the same time arranging for p2m_alloc_
On 29/11/2022 16:23, Ayan Kumar Halder wrote:
On 29/11/2022 14:52, Julien Grall wrote:
On 29/11/2022 14:57, Ayan Kumar Halder wrote:
Hi All,
Hi,
Hi Julien,
Many thanks for your inputs.
I am trying to gather opinions on how to support 32 bit physical
addresses to enable Xen runnin
On 29.11.22 16:00, Per Bilse wrote:
/proc/xen is a legacy pseudo filesystem which predates Xen support
getting merged into Linux. It has largely been replaced with more
normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for
user devices). We want to compile xenfs support out of the
On Tue, Nov 29, 2022 at 10:15 AM Marek Marczykowski-Górecki
wrote:
>
> On Tue, Nov 29, 2022 at 09:32:54AM -0500, Alex Deucher wrote:
> > On Mon, Nov 28, 2022 at 8:59 PM Demi Marie Obenour
> > wrote:
> > >
> > > On Mon, Nov 28, 2022 at 11:18:00AM -0500, Alex Deucher wrote:
> > > > On Mon, Nov 28,
On 29/11/2022 14:52, Julien Grall wrote:
On 29/11/2022 14:57, Ayan Kumar Halder wrote:
Hi All,
Hi,
Hi Julien,
Many thanks for your inputs.
I am trying to gather opinions on how to support 32 bit physical
addresses to enable Xen running on R52.
Refer Cortex R52 TRM, Section 2.2.12
On Tue, Nov 29, 2022 at 09:32:54AM -0500, Alex Deucher wrote:
> On Mon, Nov 28, 2022 at 8:59 PM Demi Marie Obenour
> wrote:
> >
> > On Mon, Nov 28, 2022 at 11:18:00AM -0500, Alex Deucher wrote:
> > > On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
> > > wrote:
> > > >
> > > > Dear Christian:
>
/proc/xen is a legacy pseudo filesystem which predates Xen support
getting merged into Linux. It has largely been replaced with more
normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for
user devices). We want to compile xenfs support out of the dom0 kernel.
There is one item which
Hi Ayan,
On 28/11/2022 16:56, Ayan Kumar Halder wrote:
> One can now use GICv3 on AArch32 systems. However, ITS is not supported.
> The reason being currently we are trying to validate GICv3 on an AArch32_v8R
> system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
> "A Generic Interrupt Controller (GIC)
Hi Ayan,
On 28/11/2022 16:56, Ayan Kumar Halder wrote:
> Define missing assembly aliases for GIC registers on arm32, taking the ones
> defined already for arm64 as a base. Aliases are defined according to the
> GIC Architecture Specification ARM IHI 0069H.
>
> Defined the following registers:-
>
By defining the constant to zero when !SHADOW_PAGING we give compilers
the chance to eliminate a little more dead code elsewhere in the tree.
Plus, as a minor benefit, the general reference count can be one bit
wider. (To simplify things, have PGC_page_table change places with
PGC_extra.)
Signed-o
On 29/11/2022 14:57, Ayan Kumar Halder wrote:
Hi All,
Hi,
I am trying to gather opinions on how to support 32 bit physical
addresses to enable Xen running on R52.
Refer Cortex R52 TRM, Section 2.2.12 "Memory Model"
"...This is because the physical address is always the same as the
virt
Up until f61685a66903 ("x86: remove defunct init/load/save_msr()
hvm_funcs") the check of the _rsvd field served as an error check for
the earlier hvm_funcs.save_msr() invocation. With that invocation gone
the check makes no sense anymore. While dropping it also merge the two
paths setting "err" to
There's no need to recalculate / refetch the value from the stack
(pointer).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -417,7 +417,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t
* out of hardware.
*/
#ifdef CONFIG_HVM
-if ( v == c
Neither page_get_owner() nor mfn_to_page() are entirely trivial
operations - don't do the same thing twice in close succession. Instead
help CSE (when MEM_SHARING=y) by introducing a local variable holding
the page owner.
Signed-off-by: Jan Beulich
---
According to my observations gcc12 manages t
Four of them are used in apic.c only and hence better wouldn't be
exposed to other CUs. To avoid the need for forward declarations, move
apic_intr_init() past the four handlers.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -127,21 +127,6 @@ void ack_bad_irq(u
It is generally preferable to not hold locks around allocation
functions. And indeed in the hwdom case there's no point at all to hold
the paging lock. Reduce the locked regions to the non-hwdom case, while
at the same time arranging for p2m_alloc_page() to have just a single
return point.
Signed-
While not as inefficient as it would be on x86 (due to suitable constant
loading and register pair storing instructions being available to fill
some of the fields), having the compiler construct an array of constants
on the stack still looks odd to me.
Signed-off-by: Jan Beulich
---
Actual space
Signed-off-by: Jan Beulich
--- a/Config.mk
+++ b/Config.mk
@@ -232,7 +232,7 @@ OVMF_UPSTREAM_REVISION ?= 7b4a99be8a39c1
QEMU_UPSTREAM_REVISION ?= b746458e1ce1bec85e58b458386f8b7a0bedfaa6
MINIOS_UPSTREAM_REVISION ?= 5bcb28aaeba1c2506a82fab0cdad0201cd9b54b3
-SEABIOS_UPSTREAM_REVISION ?= rel-1.1
Hi Ayan,
On 28/11/2022 16:56, Ayan Kumar Halder wrote:
> Adapt save_aprn_regs()/restore_aprn_regs() for AArch32.
>
> For which we have defined the following registers:-
> 1. Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
> 2. Interrupt Controller Hyp Active Priorities Group1 Regi
Hi Ayan,
On 28/11/2022 16:56, Ayan Kumar Halder wrote:
>
>
> Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
>
> AArch64 System register ICH_LR_EL2 bits [31:0] are architecturally
> mapped to AArch32 System register ICH_LR[31:0].
> AArch64 System register ICH_LR_EL2
On Mon, Nov 28, 2022 at 8:59 PM Demi Marie Obenour
wrote:
>
> On Mon, Nov 28, 2022 at 11:18:00AM -0500, Alex Deucher wrote:
> > On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
> > wrote:
> > >
> > > Dear Christian:
> > >
> > > What is the status of the AMDGPU work for Xen dom0? That was menti
The currently lockless access to the xen console list in
vtermno_to_xencons() is incorrect, as additions and removals from the
list can happen anytime, and as such the traversal of the list to get
the private console data for a given termno needs to happen with the
lock held. Note users that modif
On 29.11.2022 09:40, Julien Grall wrote:
> On 28/11/2022 10:01, Jan Beulich wrote:
>> On 24.11.2022 22:29, Julien Grall wrote:
>>> On 19/10/2022 09:43, Jan Beulich wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1563,7 +1563,82 @@ int map_guest_area(struct vcpu *v, pad
Hi All,
I am trying to gather opinions on how to support 32 bit physical
addresses to enable Xen running on R52.
Refer Cortex R52 TRM, Section 2.2.12 "Memory Model"
"...This is because the physical address is always the same as the
virtual address...The virtual and physical address can be tr
flight 174985 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174985/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
> On 29 Nov 2022, at 09:46, Luca Fancellu wrote:
>
>
>
>> On 29 Nov 2022, at 01:55, Stefano Stabellini wrote:
>>
>> On Mon, 28 Nov 2022, Luca Fancellu wrote:
>>> This serie introduces a way to suppress a static analyser finding providing
>>> a
>>> proper justification for it.
>>> The proce
flight 174987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174987/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b92e0495221a3b298b069d9fb01e48fd2a0469f6
baseline version:
ovmf c8c978d32882413eeaf2b
The hvc machinery registers both a console and a tty device based on
the hv ops provided by the specific implementation. Those two
interfaces however have different locks, and there's no single locks
that's shared between the tty and the console implementations, hence
the driver needs to protect i
Hi,
> On 29 Nov 2022, at 00:18, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Add the new MISRA C rules agreed by the MISRA C working group to
> docs/misra/rules.rst.
>
> Add a comment for Rule 19.1 to explain that Eclair's findings are
> "caution" reports, not violations.
>
> S
> On 29 Nov 2022, at 09:42, Jan Beulich wrote:
>
> On 28.11.2022 16:37, Luca Fancellu wrote:
>>> On 28 Nov 2022, at 15:19, Jan Beulich wrote:
>>> On 28.11.2022 15:10, Luca Fancellu wrote:
Change cppcheck invocation method by using the xen-analysis.py
script using the arguments --run-
On 29.11.2022 01:18, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Add the new MISRA C rules agreed by the MISRA C working group to
> docs/misra/rules.rst.
>
> Add a comment for Rule 19.1 to explain that Eclair's findings are
> "caution" reports, not violations.
>
> Signed-off-by: St
> On 29 Nov 2022, at 01:55, Stefano Stabellini wrote:
>
> On Mon, 28 Nov 2022, Luca Fancellu wrote:
>> This serie introduces a way to suppress a static analyser finding providing a
>> proper justification for it.
>> The process is explained in the docs/misra/documenting-violations.rst
>> docum
On 28.11.2022 16:37, Luca Fancellu wrote:
>> On 28 Nov 2022, at 15:19, Jan Beulich wrote:
>> On 28.11.2022 15:10, Luca Fancellu wrote:
>>> Change cppcheck invocation method by using the xen-analysis.py
>>> script using the arguments --run-cppcheck.
>>>
>>> Now cppcheck analysis will build Xen whil
Hi,
On 29/11/2022 03:39, Jiamei Xie wrote:
This commit is to drop redundancy in the function vpl011_mmio_write
and vpl011_mmio_read:
- In vpl011_mmio_read switch block, all cases have a return. So the
outside one can be removed.
- Each switch case checks access by the same if statments. So we
Hi,
On 29/11/2022 03:39, Jiamei Xie wrote:
When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
Linux SBSA PL011 driver will access PL011 DMACR register in some
functions. As chapter "B Generic UART" in "ARM Server Base System
Architecture"[1] documentation describes, SBSA UART d
Hi Jan,
On 28/11/2022 10:01, Jan Beulich wrote:
On 24.11.2022 22:29, Julien Grall wrote:
On 19/10/2022 09:43, Jan Beulich wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1563,7 +1563,82 @@ int map_guest_area(struct vcpu *v, paddr
struct guest_area *area,
70 matches
Mail list logo
