Using indirect pointers in an ioctl command argument means that the
layout is architecture specific, in particular we can't use the same one
from 32-bit compat tasks. The general recommendation is to have __u64
members and use u64_to_user_ptr() to access it from the kernel if we are
unable to avoid
_IOC() an internal helper that we should not use in driver code. In
particular, we got the data direction wrong here, which breaks a number
of tools, as having "_IOC_NONE" should never be paired with a nonzero
size.
Use _IOW() instead.
Fixes: f8941e6c4c71 ("xen: privcmd: Add support for irqfd")
Virtio guests send VIRTIO_MMIO_QUEUE_NOTIFY notification when they need
to notify the backend of an update to the status of the virtqueue. The
backend or another entity, polls the MMIO address for updates to know
when the notification is sent.
It works well if the backend does this polling by itse
Hello,
Now that irqfd support (backend to guest interrupt) is already merged, this
series solves the other part of the problem, i.e. ioeventfd (guest to
backend interrupt).
More details inside the commits.
Arnd reported few issues with the ioctl macro usage and argument's layout, fixed
them for
Currently the handling of events is supported either in the kernel or
userspace, but not both.
In order to support fast delivery of interrupts from the guest to the
backend, we need to handle the Queue notify part of Virtio protocol in
kernel and the rest in userspace.
Update the interrupt handle
On 16.10.23 09:11, Viresh Kumar wrote:
Using indirect pointers in an ioctl command argument means that the
layout is architecture specific, in particular we can't use the same one
from 32-bit compat tasks. The general recommendation is to have __u64
members and use u64_to_user_ptr() to access it
On 16.10.23 09:11, Viresh Kumar wrote:
_IOC() an internal helper that we should not use in driver code. In
particular, we got the data direction wrong here, which breaks a number
of tools, as having "_IOC_NONE" should never be paired with a nonzero
size.
Use _IOW() instead.
Fixes: f8941e6c4c71
On 16.10.23 09:11, Viresh Kumar wrote:
Currently the handling of events is supported either in the kernel or
userspace, but not both.
In order to support fast delivery of interrupts from the guest to the
backend, we need to handle the Queue notify part of Virtio protocol in
kernel and the rest i
On 16.10.23 09:11, Viresh Kumar wrote:
Virtio guests send VIRTIO_MMIO_QUEUE_NOTIFY notification when they need
to notify the backend of an update to the status of the virtqueue. The
backend or another entity, polls the MMIO address for updates to know
when the notification is sent.
It works well
On 14.10.23 01:06, Stefano Stabellini wrote:
From: George Dunlap
Commit fc2b57c9a ("xenstored: send an evtchn notification on
introduce_domain") introduced the sending of an event channel to the
guest when first introduced, so that dom0less domains waiting for the
connection would know that xen
On Mon, Oct 16, 2023 at 8:38 AM Juergen Gross wrote:
> On 14.10.23 01:06, Stefano Stabellini wrote:
> > + /* Notify the domain that xenstore is available */
>
> Please add a "." at the end of the sentence while you are moving this line.
CODING_STYLE explicitly allows the omission of a
On 16.10.23 09:45, George Dunlap wrote:
On Mon, Oct 16, 2023 at 8:38 AM Juergen Gross wrote:
On 14.10.23 01:06, Stefano Stabellini wrote:
+ /* Notify the domain that xenstore is available */
Please add a "." at the end of the sentence while you are moving this line.
CODING_STYL
Hi,
On 13/10/2023 14:26, Leo Yan wrote:
>
>
> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
> the physical memory regions are:
>
> DRAM memory regions:
> Node[0] Region[0]: 0x8000 - 0x
> Node[0] Region[1]: 0x0800 - 0x08007fff
On 29.09.2023 02:47, Elliott Mitchell wrote:
> On Mon, Sep 25, 2023 at 08:27:31AM +0200, Jan Beulich wrote:
>> On 22.09.2023 17:42, Elliott Mitchell wrote:
>>> On Fri, Sep 22, 2023 at 10:21:21AM +0200, Jan Beulich wrote:
On 21.09.2023 18:18, Elliott Mitchell wrote:
> As such these incompl
Hi,
On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter names, no functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/include/asm/gic.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch
Hi,
On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter names, no functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/include/asm/cpufeature.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/include/asm/cpufeature.h
On 14/10/2023 00:34, Stefano Stabellini wrote:
On Fri, 13 Oct 2023, Stefano Stabellini wrote:
On Fri, 13 Oct 2023, Federico Serafini wrote:
Add missing parameter names, no functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/include/asm/cpufeature.h | 8
1 file
Hi,
On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter name, no functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ce89f16404..5aa
On Fri, Nov 18, 2022 at 04:49:23PM +0100, Marek Marczykowski-Górecki wrote:
> Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
> the table is filled. Then it disables INTx just before clearing MASKALL
> bit. Currently this approach is rejected by xen-pciback.
> According to t
Hi,
On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter names, no functional change.
Signed-off-by: Federico Serafini
---
xen/drivers/passthrough/arm/smmu.c | 6 +++---
This file is using the Linux coding style because it is imported from
Linux. I was under the impression w
Hi Dan,
On 10/10/2023 18:11, Driscoll, Dan wrote:
Julien,
Verified this patch works on Graviton 2... so looks good from this
perspective.
Thanks for testing. I will commit the patch then to staging so it will
be included in the next release (4.18.0).
Cheers,
--
Julien Grall
On 05.10.2023 01:32, Stefano Stabellini wrote:
> On Wed, 4 Oct 2023, Luca Fancellu wrote:
>>> On 4 Oct 2023, at 11:29, Nicola Vetrini wrote:
>>> On 04/10/2023 12:06, Luca Fancellu wrote:
Hi Nicola,
> On 4 Oct 2023, at 10:56, andrew.coop...@citrix.com wrote:
> On 03/10/2023 9:46 pm, St
flight 183379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183379/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183373
test-armhf-armhf-libvirt 16 save
On 29.09.2023 15:01, Tamas K Lengyel wrote:
> On Thu, Sep 28, 2023 at 9:19 AM Jan Beulich wrote:
>>
>> On 28.09.2023 14:57, Tamas K Lengyel wrote:
>>> On Thu, Sep 28, 2023 at 7:08 AM Roger Pau Monné
>>> wrote:
On Thu, Sep 28, 2023 at 12:11:02PM +0200, Jan Beulich wrote:
> On 28.09.2023
On 04.10.2023 15:53, Roger Pau Monne wrote:
> @@ -1950,7 +1978,15 @@ int mem_sharing_fork_reset(struct domain *d, bool
> reset_state,
>
> state:
> if ( reset_state )
> +{
> rc = copy_settings(d, pd);
> +if ( rc == -ERESTART )
> +/*
> + * Transl
On 05.10.2023 20:58, Andrew Cooper wrote:
> I see this series has been committed. But it's broken in a really
> fundamental way.
>
>
> This is a new extension with persistent side effects to an existing part
> of the guest ABI.
>
> Yet there doesn't appear to be any enumeration that the interfa
On 02.10.2023 17:11, Roger Pau Monne wrote:
> Since it was indicated that introducing specific new vCPU ops may be
> beneficial independent of the introduction of a fully physical-
> address-based ABI flavor, here we go. There continue to be a few open
> questions throughout the series, resolving o
On 29.09.2023 23:13, Stefano Stabellini wrote:
> [PATCH v2] bitmap: fix nbits signess
>
> To avoid potentially dangerous sign conversions in bitmap_switch, all
> the callers of the bitmap_switch macro (which are all within bitmap.h)
> should pass an unsigned int as first parameter.
>
> Signed-off
On 04.10.2023 15:23, Nicola Vetrini wrote:
> On 05/09/2023 09:31, Nicola Vetrini wrote:
>> Given its use in the declaration
>> 'DECLARE_BITMAP(features, IOMMU_FEAT_count)' the argument
>> 'bits' has essential type 'enum iommu_feature', which is not
>> allowed by the Rule as an operand to the additi
On 06.10.2023 00:01, Andrew Cooper wrote:
> On 05/10/2023 10:38 pm, andrew.coop...@citrix.com wrote:
>> On 05/10/2023 8:43 am, Luca Fancellu wrote:
On 5 Oct 2023, at 00:46, Stefano Stabellini wrote:
Hi MISRA C working group (Jan, Roger, Andrew, Julien, Bertrand, George)
in
On Mon, Oct 09, 2023 at 01:51:34PM +0100, George Dunlap wrote:
> Just like Intel's PENDING_VIRT_INTR, AMD's VINTR doesn't need an HVM
> trace record. Expect that.
>
> Signed-off-by: George Dunlap
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Mon, Oct 09, 2023 at 01:51:33PM +0100, George Dunlap wrote:
> If a vmentry/exit arc unexpectedly doesn't have a handler, we throw an
> error, and then log the information under HVM event 0; thus those
> particular traces within the vmexit reason will have stats gathered,
> and will show up with
On Mon, Oct 09, 2023 at 01:51:35PM +0100, George Dunlap wrote:
> Neither vmx nor svm trace anything, nor is there anything obvious
> worth tracing.
>
> Signed-off-by: George Dunlap
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Mon, Oct 09, 2023 at 01:51:36PM +0100, George Dunlap wrote:
> EIP lists are generalized across several use cases. For many of them,
> it make sense to have a cycle per sample; but not really for interrupt
> EIP lists. For this reason, it normally just passes 0 as for the tsc
> value, which wil
On Mon, Oct 09, 2023 at 01:51:37PM +0100, George Dunlap wrote:
> We warn when we see data for a vcpu moving into a non-RUNNING state,
> just so that people know why we're ignoring it. On full traces, this
> happens only once. However, if the trace was limited to a subset of
> pcpus, then this wil
On Mon, Oct 16, 2023 at 11:55:25AM +0200, Jan Beulich wrote:
> On 04.10.2023 15:53, Roger Pau Monne wrote:
> > @@ -1950,7 +1978,15 @@ int mem_sharing_fork_reset(struct domain *d, bool
> > reset_state,
> >
> > state:
> > if ( reset_state )
> > +{
> > rc = copy_settings(d, pd);
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) )
> +d->iomem_caps = rangeset_new(d,
On 29.09.2023 10:51, Nicola Vetrini wrote:
> while fixing a violation of R8.4 related to a missing include in
> x86/hvm/grant_table.c
> I included , since that file contains just the
> declarations needed
> by the .c file. However, since the declaration uses the type mfn_t,
> which is defined in
On 29.09.2023 00:24, Stefano Stabellini wrote:
> On Thu, 28 Sep 2023, Jan Beulich wrote:
>> On 28.09.2023 15:17, Simone Ballarin wrote:
>>> On 28/09/23 14:51, Jan Beulich wrote:
On 28.09.2023 14:46, Simone Ballarin wrote:
> On 13/09/23 10:02, Jan Beulich wrote:
>> On 12.09.2023 11:36,
On 16/10/2023 13:20, Jan Beulich wrote:
On 29.09.2023 10:51, Nicola Vetrini wrote:
while fixing a violation of R8.4 related to a missing include in
x86/hvm/grant_table.c
I included , since that file contains just the
declarations needed
by the .c file. However, since the declaration uses the typ
On 06.10.2023 15:00, Roger Pau Monne wrote:> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1601,7 +1601,7 @@ int map_guest_area(struct vcpu *v, paddr_t gaddr,
> unsigned int size,
> unmap:
> if ( pg )
> {
> -unmap_domain_page_global(map);
> +unmap_domain_p
On 06.10.2023 15:00, Roger Pau Monne wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1580,6 +1580,10 @@ long do_vcpu_op(int cmd, unsigned int vcpuid,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> struct vcpu_register_time_memory_area area;
>
> +rc = -EN
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from indirect to
direct calls via a special alternative patching option.
This removes _some_ of the paravirt macro
As a preparation for replacing paravirt patching completely by
alternative patching, move some backend functions and #defines to
alternative code and header.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/alternative.h| 16
arch/x86/i
On Mon, Oct 16, 2023 at 02:30:12PM +0200, Jan Beulich wrote:
> On 06.10.2023 15:00, Roger Pau Monne wrote:> --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -1601,7 +1601,7 @@ int map_guest_area(struct vcpu *v, paddr_t gaddr,
> > unsigned int size,
> > unmap:
> > if ( pg )
> >
At the moment, we do not check a return code from scan_pfdt_node()
called recursively. This means that any issue that may occur while
parsing and copying the passthrough nodes is hidden and Xen continues
to boot a domain despite errors. This may lead to incorrect device tree
generation and various
On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote:
> On 06.10.2023 15:00, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1580,6 +1580,10 @@ long do_vcpu_op(int cmd, unsigned int vcpuid,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> > {
> >
On Mon, Oct 16, 2023 at 11:05:10AM +0200, Roger Pau Monné wrote:
> On Fri, Nov 18, 2022 at 04:49:23PM +0100, Marek Marczykowski-Górecki wrote:
> > Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
> > the table is filled. Then it disables INTx just before clearing MASKALL
> >
> On 16 Oct 2023, at 13:45, Michal Orzel wrote:
>
> At the moment, we do not check a return code from scan_pfdt_node()
> called recursively. This means that any issue that may occur while
> parsing and copying the passthrough nodes is hidden and Xen continues
> to boot a domain despite errors.
Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
the table is filled. Then it disables INTx just before clearing MASKALL
bit. Currently this approach is rejected by xen-pciback.
According to the PCIe spec, device cannot use INTx when MSI/MSI-X is
enabled (in other words: enab
On 06.10.2023 17:27, Roger Pau Monné wrote:
> On Fri, Oct 06, 2023 at 04:09:19PM +0100, Julien Grall wrote:
>> On 06/10/2023 15:44, Andrew Cooper wrote:
>>> From: Alejandro Vallejo
>>>
>>> Adds a new compile-time flag to allow disabling PDX compression and
>>> compiles out compression-related code
flight 183382 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183382/
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 06.10.2023 18:01, Andrew Cooper wrote:
> On 06/10/2023 4:09 pm, Julien Grall wrote:
>>
>>
>> On 06/10/2023 15:44, Andrew Cooper wrote:
>>> From: Alejandro Vallejo
>>>
>>> Adds a new compile-time flag to allow disabling PDX compression and
>>> compiles out compression-related code/data. It also
Hi Michal,
> On 16 Oct 2023, at 14:45, Michal Orzel wrote:
>
> At the moment, we do not check a return code from scan_pfdt_node()
> called recursively. This means that any issue that may occur while
> parsing and copying the passthrough nodes is hidden and Xen continues
> to boot a domain despit
On Mon, Oct 16, 2023 at 03:04:36PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Oct 16, 2023 at 11:05:10AM +0200, Roger Pau Monné wrote:
> > On Fri, Nov 18, 2022 at 04:49:23PM +0100, Marek Marczykowski-Górecki wrote:
> > > Linux enables MSI-X before disabling INTx, but keeps MSI-X masked unti
Hi Julien,
> On 16 Oct 2023, at 11:07, Julien Grall wrote:
>
> Hi,
>
> On 13/10/2023 16:24, Federico Serafini wrote:
>> Add missing parameter names, no functional change.
>> Signed-off-by: Federico Serafini
>> ---
>> xen/drivers/passthrough/arm/smmu.c | 6 +++---
>
> This file is using the Li
On 13.10.2023 10:56, Roger Pau Monne wrote:
> The mapping of memory regions below the 1MB mark was all done by the PVH dom0
> builder code, causing the region to be avoided by the arch specific IOMMU
> hardware domain initialization code. That lead to the IOMMU being enabled
> without reserved reg
On 16/10/2023 14:31, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 16 Oct 2023, at 11:07, Julien Grall wrote:
Hi,
On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter names, no functional change.
Signed-off-by: Federico Serafini
---
xen/drivers/passthrough/arm/sm
On Mon, Oct 16, 2023 at 03:19:22PM +0200, Jan Beulich wrote:
> On 06.10.2023 17:27, Roger Pau Monné wrote:
> > On Fri, Oct 06, 2023 at 04:09:19PM +0100, Julien Grall wrote:
> >> On 06/10/2023 15:44, Andrew Cooper wrote:
> >>> From: Alejandro Vallejo
> >>>
> >>> Adds a new compile-time flag to allo
Hi,
> On 13 Oct 2023, at 14:26, Leo Yan wrote:
>
> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
> the physical memory regions are:
>
> DRAM memory regions:
>Node[0] Region[0]: 0x8000 - 0x
>Node[0] Region[1]: 0x0800 - 0x08007ff
On 11.10.2023 14:46, Nicola Vetrini wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -109,13 +109,16 @@
>
> #define offsetof(a,b) __builtin_offsetof(a,b)
>
> +/* Access the field of structure type, without defining a local variable */
> +#define access_field(ty
Hi Julien,
> On 16 Oct 2023, at 15:38, Julien Grall wrote:
>
>
>
> On 16/10/2023 14:31, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 16 Oct 2023, at 11:07, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter n
On 11.10.2023 18:56, andrew.coop...@citrix.com wrote:
> On 11/10/2023 8:46 pm, Nicola Vetrini wrote:
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index ee7aed0609d2..1b00e4e3e9b7 100644
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -199,6 +1
On Mon, Oct 16, 2023 at 03:32:54PM +0200, Jan Beulich wrote:
> On 13.10.2023 10:56, Roger Pau Monne wrote:
> > The mapping of memory regions below the 1MB mark was all done by the PVH
> > dom0
> > builder code, causing the region to be avoided by the arch specific IOMMU
> > hardware domain initial
On 16/10/2023 09:44, Michal Orzel wrote:
Hi,
Hi,
On 13/10/2023 14:26, Leo Yan wrote:
On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
the physical memory regions are:
DRAM memory regions:
Node[0] Region[0]: 0x8000 - 0x
Node[0] Re
On Mon, Oct 16, 2023 at 01:40:26PM +, Bertrand Marquis wrote:
[...]
> > This patch enlarges identity map space to 10TB, allowing module loading
> > within the range of [0x0 .. 0x09ff__].
> >
> > Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to
> > prepare/enable/disable")
On 16.10.2023 15:00, Roger Pau Monné wrote:
> On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote:
>> On 06.10.2023 15:00, Roger Pau Monne wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v,
>>> XEN_GUES
Hi
+Luca and Rahul
> On 16 Oct 2023, at 15:54, Julien Grall wrote:
>
>
>
> On 16/10/2023 09:44, Michal Orzel wrote:
>> Hi,
>
> Hi,
>
>> On 13/10/2023 14:26, Leo Yan wrote:
>>>
>>>
>>> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
>>> the physical memory regions
On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote:
> On 16.10.2023 15:00, Roger Pau Monné wrote:
> > On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote:
> >> On 06.10.2023 15:00, Roger Pau Monne wrote:
> >>> --- a/xen/common/domain.c
> >>> +++ b/xen/common/domain.c
> >>> @@ -1998
On 16.10.2023 15:40, Roger Pau Monné wrote:
> On Mon, Oct 16, 2023 at 03:19:22PM +0200, Jan Beulich wrote:
>> On 06.10.2023 17:27, Roger Pau Monné wrote:
>>> On Fri, Oct 06, 2023 at 04:09:19PM +0100, Julien Grall wrote:
On 06/10/2023 15:44, Andrew Cooper wrote:
> From: Alejandro Vallejo
>
On 16.10.2023 16:01, Roger Pau Monné wrote:
> On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote:
>> On 16.10.2023 15:00, Roger Pau Monné wrote:
>>> On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote:
On 06.10.2023 15:00, Roger Pau Monne wrote:
> --- a/xen/common/domain.c
On Mon, 16 Oct 2023 at 14:54, Julien Grall wrote:
>
>
>
> On 16/10/2023 09:44, Michal Orzel wrote:
> > Hi,
>
> Hi,
>
> > On 13/10/2023 14:26, Leo Yan wrote:
> >>
> >>
> >> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
> >> the physical memory regions are:
> >>
> >>DR
On 16.10.2023 15:51, Roger Pau Monné wrote:
> On Mon, Oct 16, 2023 at 03:32:54PM +0200, Jan Beulich wrote:
>> On 13.10.2023 10:56, Roger Pau Monne wrote:
>>> The mapping of memory regions below the 1MB mark was all done by the PVH
>>> dom0
>>> builder code, causing the region to be avoided by the
> On 16 Oct 2023, at 15:00, Bertrand Marquis wrote:
>
> Hi
>
> +Luca and Rahul
>
>> On 16 Oct 2023, at 15:54, Julien Grall wrote:
>>
>>
>>
>> On 16/10/2023 09:44, Michal Orzel wrote:
>>> Hi,
>>
>> Hi,
>>
>>> On 13/10/2023 14:26, Leo Yan wrote:
On ADLink AVA platform (Am
On Mon, 16 Oct 2023 at 15:13, Luca Fancellu wrote:
>
>
>
> > On 16 Oct 2023, at 15:00, Bertrand Marquis wrote:
> >
> > Hi
> >
> > +Luca and Rahul
> >
> >> On 16 Oct 2023, at 15:54, Julien Grall wrote:
> >>
> >>
> >>
> >> On 16/10/2023 09:44, Michal Orzel wrote:
> >>> Hi,
> >>
> >> Hi,
> >>
> >>>
On 10.10.2023 11:57, Andrew Cooper wrote:
> MISRA doesn't like !!CONST being used in place of a 1 (Rule 10.1). Update the
> expression to just be a plain 1, which still matches the description.
>
> No functional change.
>
> Reported-by: Nicola Vetrini
> Signed-off-by: Andrew Cooper
Acked-by:
>>>
>>> @Rahul or Luca: could you give an answer here ?
>>> I know you used Xen on an AVA platform but was it booting out of the box ?
>>
>> I can’t say for Xen 4.17, but our nightly job has run successfully on AVA
>> for the commit 730406ab81094115d9fb5ca00ba8d53cec1279b3
>> (docs/misra: add de
On 09.10.2023 08:54, Nicola Vetrini wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -249,7 +249,7 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> return (p2ma != p2m_access_n2rwx);
> }
>
> -int p2m_set_altp2m_mem_access(struct domain *d,
On Mon, Oct 16, 2023 at 04:04:34PM +0200, Jan Beulich wrote:
> On 16.10.2023 16:01, Roger Pau Monné wrote:
> > On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote:
> >> On 16.10.2023 15:00, Roger Pau Monné wrote:
> >>> On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote:
> On 0
CC Henry
Hi Alexey,
On 16/10/2023 15:24, Alexey Klimov wrote:
On Mon, 16 Oct 2023 at 15:13, Luca Fancellu wrote:
On 16 Oct 2023, at 15:00, Bertrand Marquis wrote:
Hi
+Luca and Rahul
On 16 Oct 2023, at 15:54, Julien Grall wrote:
On 16/10/2023 09:44, Michal Orzel wrote:
Hi,
Hi,
On 09.10.2023 08:54, Nicola Vetrini wrote:
> Some variables with external linkage used in C code do not have
> a visible declaration where they are defined. Providing such
> declaration also resolves violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
This is a mix of differen
On Mon, Oct 16, 2023 at 04:07:22PM +0200, Jan Beulich wrote:
> On 16.10.2023 15:51, Roger Pau Monné wrote:
> > On Mon, Oct 16, 2023 at 03:32:54PM +0200, Jan Beulich wrote:
> >> On 13.10.2023 10:56, Roger Pau Monne wrote:
> >>> The mapping of memory regions below the 1MB mark was all done by the PVH
On 09.10.2023 08:54, Nicola Vetrini wrote:
> --- a/xen/include/xen/consoled.h
> +++ b/xen/include/xen/consoled.h
> @@ -12,7 +12,7 @@ size_t consoled_guest_tx(char c);
>
> #else
>
> -size_t consoled_guest_tx(char c) { return 0; }
> +static inline size_t consoled_guest_tx(char c) { return 0; }
Hi Leo,
On 16/10/2023 14:54, Leo Yan wrote:
On Mon, Oct 16, 2023 at 01:40:26PM +, Bertrand Marquis wrote:
[...]
This patch enlarges identity map space to 10TB, allowing module loading
within the range of [0x0 .. 0x09ff__].
Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers
On 16.10.2023 16:51, Roger Pau Monné wrote:
> On Mon, Oct 16, 2023 at 04:07:22PM +0200, Jan Beulich wrote:
>> On 16.10.2023 15:51, Roger Pau Monné wrote:
>>> On Mon, Oct 16, 2023 at 03:32:54PM +0200, Jan Beulich wrote:
On 13.10.2023 10:56, Roger Pau Monne wrote:
> The mapping of memory reg
On 09.10.2023 08:54, Nicola Vetrini wrote:
> These variables are only used by asm code, and therefore
> the lack of a declaration is justified by the corresponding
> deviation comment.
Hmm, you say "declaration" here, but according to my understanding ...
> --- a/xen/arch/x86/include/asm/asm_defn
On 09.10.2023 08:54, 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, hence these functions are deviated.
> This also fixes violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
On 29.09.2023 22:51, Stefano Stabellini wrote:
> On Fri, 29 Sep 2023, Federico Serafini wrote:
>> Add missing parameter names and make function declarations and
>> definitions consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Acked-b
On Fri, Oct 13, 2023 at 11:45:36AM +0300, Emmanouil Pitsidianakis wrote:
> In preparation of raising -Wimplicit-fallthrough to 5, replace all
> fall-through comments with the fallthrough attribute pseudo-keyword.
>
> Signed-off-by: Emmanouil Pitsidianakis
> ---
> hw/block/dataplane/xen-block.c |
On 29.09.2023 22:53, Stefano Stabellini wrote:
> On Fri, 29 Sep 2023, Federico Serafini wrote:
>> Make function declarations and definitions consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
On 29.09.2023 22:53, Stefano Stabellini wrote:
> On Fri, 29 Sep 2023, Federico Serafini wrote:
>> Make function declaration and definition consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
On 29.09.2023 22:54, Stefano Stabellini wrote:
> On Fri, 29 Sep 2023, Federico Serafini wrote:
>> Make function declaration and definition consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
Hi,
> On 16 Oct 2023, at 16:46, Julien Grall wrote:
>
> CC Henry
>
> Hi Alexey,
>
> On 16/10/2023 15:24, Alexey Klimov wrote:
>> On Mon, 16 Oct 2023 at 15:13, Luca Fancellu wrote:
>>>
>>>
>>>
On 16 Oct 2023, at 15:00, Bertrand Marquis
wrote:
Hi
+Luca and R
On 03.10.2023 00:46, Stefano Stabellini wrote:
> On Mon, 2 Oct 2023, Federico Serafini wrote:
>> Make function declaration and definition consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
On 03.10.2023 02:19, Henry Wang wrote:
>> On Oct 3, 2023, at 06:46, Stefano Stabellini wrote:
>>
>> On Mon, 2 Oct 2023, Federico Serafini wrote:
>>> Make function declaration and definition consistent.
>>> No functional change.
>>>
>>> Signed-off-by: Federico Serafini
>>
>> Reviewed-by: Stefano S
On 03.10.2023 00:45, Stefano Stabellini wrote:
> On Mon, 2 Oct 2023, Federico Serafini wrote:
>> Add missing parameter names. No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
On 03.10.2023 02:19, Henry Wang wrote:
>> On Oct 3, 2023, at 06:45, Stefano Stabellini wrote:
>>
>> On Mon, 2 Oct 2023, Federico Serafini wrote:
>>> Add missing parameter names. No functional change.
>>>
>>> Signed-off-by: Federico Serafini
>>
>> Reviewed-by: Stefano Stabellini
>
> Release-acke
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 *kernel* would always return -EINVAL.
Linux does
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
Now that we can reliably tell whether a given device already exists, we
can allow the user to add console devices on the command line with just
'-device xen-console,chardev=foo'.
Start at 1, because we can't add the *primary* console; that's special
because the toolstack ha
1 - 100 of 160 matches
Mail list logo
