The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other cases
they are a NOP.
In the end both callbacks are meant to register an address space with
the underl
On 06.02.2023 22:23, Stefano Stabellini wrote:
> On Mon, 6 Feb 2023, Jan Beulich wrote:
>> On 03.02.2023 20:55, Stefano Stabellini wrote:
>>> On Fri, 3 Feb 2023, Luca Fancellu wrote:
And then, if the file is not subject to backport and now we “own” the
file, there is no more the need to
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, February 6, 2023 6:11 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 20/40] xen/mpu: plump early_fdt_map in M
On Tue, Feb 07, 2023 at 05:16:21AM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 06, 2023 at 10:10:33PM -0500, Demi Marie Obenour wrote:
> > Obtaining code over an insecure transport is a terrible idea for
> > blatently obvious reasons. Even for non-executable data, insecure
> > transport
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, February 6, 2023 5:46 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 19/40] xen/mpu: populate a new region in
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, February 6, 2023 5:32 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 16/40] xen/arm: introduce setup_mm_mappi
On Mon, Feb 06, 2023 at 10:10:33PM -0500, Demi Marie Obenour wrote:
> Obtaining code over an insecure transport is a terrible idea for
> blatently obvious reasons. Even for non-executable data, insecure
> transports are considered deprecated.
>
> This patch was created by doing a tree-wide search
Hi,
> -Original Message-
> From: Julien Grall
> Sent: Monday, February 6, 2023 5:30 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 15/40] xen/arm: move MMU-specific memory
> man
On Mon, Feb 06, 2023 at 07:27:05PM -0800, Elliott Mitchell wrote:
> On Mon, Feb 06, 2023 at 10:10:33PM -0500, Demi Marie Obenour wrote:
> > Obtaining code over an insecure transport is a terrible idea for
> > blatently obvious reasons. Even for non-executable data, insecure
> > transports are cons
flight 176413 linux-5.4 real [real]
flight 176435 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176413/
http://logs.test-lab.xenproject.org/osstest/logs/176435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On Mon, Feb 06, 2023 at 10:10:33PM -0500, Demi Marie Obenour wrote:
> Obtaining code over an insecure transport is a terrible idea for
> blatently obvious reasons. Even for non-executable data, insecure
> transports are considered deprecated.
I completely agree with the premise, but I would sugge
Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons. Even for non-executable data, insecure
transports are considered deprecated.
This patch was created by doing a tree-wide search and replace with sed,
then reverting changes that were pointless or wrong.
S
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first. However, Qubes OS's GUI protocol is subject to the constraints
of the X Window
On Mon, Feb 06, 2023 at 10:32:22PM +, Julien Grall wrote:
> Hi,
>
> On 06/02/2023 20:30, Elliott Mitchell wrote:
> > On Mon, Feb 06, 2023 at 05:07:50PM +, Julien Grall wrote:
> >>
> >> On 06/02/2023 16:09, Elliott Mitchell wrote:
> >>> On Mon, Feb 06, 2023 at 10:38:32AM +, Julien Grall
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first. However, Qubes OS's GUI protocol is subject to the constraints
of the X Window
+George
On Mon, 6 Feb 2023, Julien Grall wrote:
> On 06/02/2023 20:30, Elliott Mitchell wrote:
> > The situation is changing in large entities are pushing ACPI for ARM. If
> > they succeed (likely) then it will be a case of Xen/ARM MUST support
> > ACPI, or else the project will die.
We need to
flight 176411 linux-linus real [real]
flight 176430 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176411/
http://logs.test-lab.xenproject.org/osstest/logs/176430/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
Hi,
On 06/02/2023 20:30, Elliott Mitchell wrote:
On Mon, Feb 06, 2023 at 05:07:50PM +, Julien Grall wrote:
On 06/02/2023 16:09, Elliott Mitchell wrote:
On Mon, Feb 06, 2023 at 10:38:32AM +, Julien Grall wrote:
On 06/02/2023 07:29, Jan Beulich wrote:
On 22.07.2020 19:43, Elliott Mit
On Mon, 6 Feb 2023, Jan Beulich wrote:
> On 03.02.2023 20:55, Stefano Stabellini wrote:
> > On Fri, 3 Feb 2023, Luca Fancellu wrote:
> >> And then, if the file is not subject to backport and now we “own” the
> >> file, there is no more the need to list it
> >> in the external file, a commit search
On Mon, Feb 06, 2023 at 05:07:50PM +, Julien Grall wrote:
>
> On 06/02/2023 16:09, Elliott Mitchell wrote:
> > On Mon, Feb 06, 2023 at 10:38:32AM +, Julien Grall wrote:
> >>
> >> On 06/02/2023 07:29, Jan Beulich wrote:
> >>> On 22.07.2020 19:43, Elliott Mitchell wrote:
> Unlike other
flight 176426 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176426/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aea8a9c954a79029ded443eadf7c92716c1753cc
baseline version:
ovmf b98e2113b53fa9c7474a8
Hi Stefano,
On 19/01/2023 23:24, Stefano Stabellini wrote:
On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
One should now be able to use 'paddr_t' to represent address and size.
Consequently, one should use 'PRIpaddr' as a format specifier for paddr_t.
Signed-off-by: Ayan Kumar Halder
---
Chan
flight 176424 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176424/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 20/01/2023 7:44 pm, Anthony PERARD wrote:
> No need for $(AUTOSRCS), GNU make can generate them as needed when
> trying to build them as needed when trying to build the object. Also,
> those two AUTOSRCS don't need to be a prerequisite of "all". As for
> the "clean" target, those two files are a
Hi all,
On Wed, 2023-02-01 at 09:06 +, Julien Grall wrote:
> Hi Andrew,
>
> On 01/02/2023 00:21, Andrew Cooper wrote:
> > On 31/01/2023 11:17 pm, Alistair Francis wrote:
> > > On Tue, Jan 31, 2023 at 10:03 PM Julien Grall
> > > wrote:
> > > > On 31/01/2023 11:44, Alistair Francis wrote:
> >
On Tue, 2023-01-31 at 17:30 -0800, Stefano Stabellini wrote:
> On Mon, 30 Jan 2023, Jan Beulich wrote:
> > On 30.01.2023 12:54, Oleksii wrote:
> > > Hi Jan,
> > >
> > > On Fri, 2023-01-27 at 15:24 +0100, Jan Beulich wrote:
> > > > On 27.01.2023 14:59, Oleksii Kurochko wrote:
> > > > > --- /dev/nul
Hi Elliott,
On 06/02/2023 16:09, Elliott Mitchell wrote:
On Mon, Feb 06, 2023 at 10:38:32AM +, Julien Grall wrote:
On 06/02/2023 07:29, Jan Beulich wrote:
On 22.07.2020 19:43, Elliott Mitchell wrote:
Unlike other unsupportted options, ACPI support is required to *boot*
for a number of pl
On 06.02.2023 17:09, Elliott Mitchell wrote:
> On Mon, Feb 06, 2023 at 10:38:32AM +, Julien Grall wrote:
>>
>> On 06/02/2023 07:29, Jan Beulich wrote:
>>> On 22.07.2020 19:43, Elliott Mitchell wrote:
Unlike other unsupportted options, ACPI support is required to *boot*
for a number of
On 06.02.2023 17:30, Xenia Ragiadakou wrote:
> On 2/6/23 15:11, Xenia Ragiadakou wrote:
>> On 2/6/23 15:01, Jan Beulich wrote:
>>> On 06.02.2023 13:42, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -34,7 +34,7 @@
#include
#i
flight 176409 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176409/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 176386
test-amd64-i386-xl-qemuu-win7-amd64
On 2/6/23 15:11, Xenia Ragiadakou wrote:
On 2/6/23 15:01, Jan Beulich wrote:
On 06.02.2023 13:42, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+#include
#include
#include
To b
Hi Andrew,
In the previous version of the patch series you mentioned that it is
possible to re-use some parts from the existing code base.
Could you please provide me with an example?
I assume that __ASM_STR should be present somewhere but other parts of
the header looks like it is arch-specific
flight 176422 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176422/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b98e2113b53fa9c7474a820bcd94fffb352acdf6
baseline version:
ovmf 9d669016d968b0f3e17ce
On Mon, Feb 06, 2023 at 01:33:03PM +0100, Jan Beulich wrote:
> Now that they're properly represented in the public interface, stop
> using literal numbers.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Mon, Feb 06, 2023 at 10:38:32AM +, Julien Grall wrote:
>
> On 06/02/2023 07:29, Jan Beulich wrote:
> > On 22.07.2020 19:43, Elliott Mitchell wrote:
> >> Unlike other unsupportted options, ACPI support is required to *boot*
> >> for a number of platforms. Users on these platforms are unable
Hi Jan,
On Tue, 2023-01-31 at 10:14 +0100, Jan Beulich wrote:
> On 31.01.2023 01:21, Alistair Francis wrote:
> > On Sat, Jan 28, 2023 at 12:00 AM Oleksii Kurochko
> > wrote:
> > >
> > > Work with some registers requires csr command which is part of
> > > Zicsr.
> > >
> > > Signed-off-by: Oleksi
On 20/01/2023 7:44 pm, Anthony PERARD wrote:
> When there isn't a version-script for a shared library (like for
> unstable libs), we create one based on the current Xen version. But
> that version-script became out-of-date as soon as Xen's version
> changes and make as no way to regenerate the vers
On 06.02.23 13:05, Samuel Thibault wrote:
Juergen Gross, le lun. 06 févr. 2023 11:17:27 +0100, a ecrit:
On 06.02.23 11:13, Samuel Thibault wrote:
Juergen Gross, le ven. 03 févr. 2023 10:18:09 +0100, a ecrit:
This patch is missing the limitation of read/write messages to stay
below the max. su
flight 176407 qemu-mainline real [real]
flight 176421 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/176407/
http://logs.test-lab.xenproject.org/osstest/logs/176421/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 06.02.23 13:33, Jan Beulich wrote:
Now that they're properly represented in the public interface, stop
using literal numbers.
No functional change intended.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
On 27.01.2023 18:47, Andrew Cooper wrote:
> On 27/01/2023 7:51 am, Jan Beulich wrote:
>> On 26.01.2023 21:49, Andrew Cooper wrote:
>>> On 25/01/2023 3:26 pm, Jan Beulich wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2015,7 +2015,8 @@ void context_switch(struct vc
> On 6 Feb 2023, at 14:37, Michal Orzel wrote:
>
> Hi Luca,
>
> On 06/02/2023 15:31, Luca Fancellu wrote:
>>
>>
>> Hi Xenia,
>>
>>> On 3 Feb 2023, at 19:09, Xenia Ragiadakou wrote:
>>>
>>> Signed-off-by: Xenia Ragiadakou
>>> ---
>>>
>>> Changes in v3:
>>> - the fixes are based solely to
> On 6 Feb 2023, at 14:51, Xenia Ragiadakou wrote:
>
> Hi Luca
>
> On 2/6/23 16:42, Luca Fancellu wrote:
>>> On 3 Feb 2023, at 19:09, Xenia Ragiadakou wrote:
>>>
>>> Macro dt_irq() is broken because the macro parameter has the same name with
>>> the struct dt_irq member "irq".
>> I’m not sur
Hi Luca
On 2/6/23 16:42, Luca Fancellu wrote:
On 3 Feb 2023, at 19:09, Xenia Ragiadakou wrote:
Macro dt_irq() is broken because the macro parameter has the same name with
the struct dt_irq member "irq".
I’m not sure about the wording “broken”, it should work anyway or am I wrong?
No, it
> On 3 Feb 2023, at 19:09, Xenia Ragiadakou wrote:
>
> Macro dt_irq() is broken because the macro parameter has the same name with
> the struct dt_irq member "irq".
I’m not sure about the wording “broken”, it should work anyway or am I wrong?
> Macro dt_irq_flags() is broken as well because s
Hi Luca,
On 06/02/2023 15:31, Luca Fancellu wrote:
>
>
> Hi Xenia,
>
>> On 3 Feb 2023, at 19:09, Xenia Ragiadakou wrote:
>>
>> Signed-off-by: Xenia Ragiadakou
>> ---
>>
>> Changes in v3:
>> - the fixes are based solely to Eclair findings (the tool has been
>>adjusted to report only those
Hi Xenia,
> On 3 Feb 2023, at 19:09, Xenia Ragiadakou wrote:
>
> Signed-off-by: Xenia Ragiadakou
> ---
>
> Changes in v3:
> - the fixes are based solely to Eclair findings (the tool has been
>adjusted to report only those violations that can result to a bug)
> - reflect this in the commi
> On 6 Feb 2023, at 13:05, Michal Orzel wrote:
>
> This might be helpful in providing additional debugging information (in
> most cases, at least to distinguish -EINVAL from -ENOMEM), so modify the
> code to include printing return code in panic message. In create_dom0,
> move the call to allo
On 26.01.2023 21:43, Andrew Cooper wrote:
> On 25/01/2023 3:26 pm, Jan Beulich wrote:
>> In order to avoid clobbering Xen's own predictions, defer the barrier as
>> much as possible.
>
> I can't actually think of a case where this matters. We've done a
> reasonable amount of work to get rid of in
On 2/6/23 15:32, Andrew Cooper wrote:
On 06/02/2023 12:58 pm, Xenia Ragiadakou wrote:
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 270bc98195..6138dc0885 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3011,6 +3011,10 @@ const struct h
On 26.01.2023 21:27, Andrew Cooper wrote:
> On 26/01/2023 8:02 am, Jan Beulich wrote:
>> On 25.01.2023 22:10, Andrew Cooper wrote:
>>> On 25/01/2023 3:25 pm, Jan Beulich wrote:
In order to be able to defer the context switch IBPB to the last
possible point, add logic to the exit-to-guest
On 06/02/2023 12:33 pm, Jan Beulich wrote:
> Now that they're properly represented in the public interface, stop
> using literal numbers.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
(Take 2, trying to sort out my email aliases properly.)
On 06/02/2023 12:33 pm, Jan Beulich wrote:
> Now that they're properly represented in the public interface, stop
> using literal numbers.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 06/02/2023 12:58 pm, Xenia Ragiadakou wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 270bc98195..6138dc0885 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3011,6 +3011,10 @@ const struct hvm_function_table * __init
> sta
On 25.01.2023 19:27, Per Bilse wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -306,6 +306,90 @@ config MEM_SHARING
> bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
> depends on HVM
>
> +config REBOOT_SYSTEM_DEFAULT
> + bool "Xen-defined reboo
On 06/02/2023 12:31 pm, Jan Beulich wrote:
> Now that they're properly represented in the public interface, let's do
> away with our private #define-s.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 2/6/23 15:01, Jan Beulich wrote:
On 06.02.2023 13:42, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+#include
#include
#include
To be honest I'd prefer if only the HVM-specifi
This might be helpful in providing additional debugging information (in
most cases, at least to distinguish -EINVAL from -ENOMEM), so modify the
code to include printing return code in panic message. In create_dom0,
move the call to alloc_dom0_vcpu0() to a separate condition and call a
meaningful p
On 06.02.2023 13:42, Xenia Ragiadakou wrote:
> Since none of the declarations and macro definitions in asm/hvm/support.h is
> referred in x86/cpu/hygon.c, remove the unnecessary include.
>
> To resolve the subsequent build error for implicit declaration of wrmsrl()
> and rdmsrl() triggered in asm/
On 06.02.2023 13:42, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/emul-i8254.c
> +++ b/xen/arch/x86/emul-i8254.c
> @@ -34,7 +34,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
To be honest I'd prefer if only the HVM-specific part of this file had
thi
APIC virtualization support is currently implemented only for Intel VT-x.
To aid future work on separating AMD-V from Intel VT-x code, instead of
calling directly vmx_vlapic_msr_changed() from common hvm code, add a stub
to the hvm_function_table, named set_virtual_apic_mode (to match the name
of t
flight 176417 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176417/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
+ adding Bertrand in the CC, apologies for forgetting you in the first mail
> On 6 Feb 2023, at 12:38, Jan Beulich wrote:
>
> On 06.02.2023 13:21, Luca Fancellu wrote:
>>> On 6 Feb 2023, at 10:01, Jan Beulich wrote:
>>> On 03.02.2023 10:30, Luca Fancellu wrote:
origin_path: relative path i
Since none of the declarations and macro definitions in asm/hvm/support.h is
referred in x86/cpu/hygon.c, remove the unnecessary include.
To resolve the subsequent build error for implicit declaration of wrmsrl()
and rdmsrl() triggered in asm/spec_ctrl.h, replace asm/msr-index.h with
asm/msr.h in
When none of the declarations and macro definitions in asm/hvm/support.h is
referred in the file, do not include the header.
To fix subsequent build errors, which were not triggered before due to the
indirect inclusion of the missing headers by asm/hvm/support.h, include any
missing headers.
No f
While working on the separation between AMD and Intel code, I noticed that
the header asm/hvm/support.h is included in many files even if none of its
declarations and macro definitions is referred in those files.
This patch series aims to remove any redundant includes of asm/hvm/support.h.
The cha
On 06.02.2023 13:21, Luca Fancellu wrote:
>> On 6 Feb 2023, at 10:01, Jan Beulich wrote:
>> On 03.02.2023 10:30, Luca Fancellu wrote:
>>> origin_path: relative path in the original project, mostly linked to the
>>> original_revision field
>>>
>>> origin_revision: revision of the changes in the re
Now that they're properly represented in the public interface, stop
using literal numbers.
No functional change intended.
Signed-off-by: Jan Beulich
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -1,5 +1,6 @@
#include "libxl_internal.h"
#include "libxl_arch.h"
+#incl
Now that they're properly represented in the public interface, let's do
away with our private #define-s.
No functional change intended.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#i
Hi Jan,
Thank you for leaving your feedbacks, really appreciated.
> On 6 Feb 2023, at 10:01, Jan Beulich wrote:
>
> On 03.02.2023 10:30, Luca Fancellu wrote:
>> I’m starting a proposal for the external files that needs to be removed from
>> the MISRA scan,
>> the work was originally started by
On Mon, Feb 6, 2023 at 5:40 PM Jan Beulich wrote:
>
> On 20.01.2023 09:40, Jan Beulich wrote:
> > While this has been there forever, it's not clear to me what it was
> > (thought to be) needed for. In fact, all three instances of the header
> > already exclude their entire bodies when __ASSEMBLY__
Juergen Gross, le lun. 06 févr. 2023 11:17:27 +0100, a ecrit:
> On 06.02.23 11:13, Samuel Thibault wrote:
> >
> > Juergen Gross, le ven. 03 févr. 2023 10:18:09 +0100, a ecrit:
> > > This patch is missing the limitation of read/write messages to stay
> > > below the max. supported message size.
> >
On 06/02/2023 07:29, Jan Beulich wrote:
On 22.07.2020 19:43, Elliott Mitchell wrote:
Unlike other unsupportted options, ACPI support is required to *boot*
for a number of platforms. Users on these platforms are unable to use
distribution builds and must rebuild from source to use Xen.
Signe
On 06.02.23 10:40, Samuel Thibault wrote:
Juergen Gross, le ven. 03 févr. 2023 10:18:07 +0100, a ecrit:
+/*
+ * Using an opportunistic approach for receiving data: in case multiple
+ * requests are outstanding (which is very unlikely), we nevertheless need
+ * to consume all data available until
On 06.02.23 11:13, Samuel Thibault wrote:
Juergen Gross, le ven. 03 févr. 2023 10:18:09 +0100, a ecrit:
This patch is missing the limitation of read/write messages to stay
below the max. supported message size.
It should at least be asserted.
It can easily be limited by returning the result
On 06.02.23 11:05, Samuel Thibault wrote:
Juergen Gross, le ven. 03 févr. 2023 10:18:08 +0100, a ecrit:
+static unsigned int get_fid(struct dev_9pfs *dev)
+{
+unsigned int fid;
+
+fid = ffs(dev->fid_mask);
+if ( fid )
+dev->fid_mask &= 1ULL << (fid - 1);
Isn't that missing
Hello,
Juergen Gross, le ven. 03 févr. 2023 10:18:02 +0100, a ecrit:
> This series is adding minimal support to use 9pfs in Mini-OS. It is
> adding a PV 9pfs frontend and the ability to open, close, read and
> write files.
Nice, thanks! :)
Samuel
Juergen Gross, le ven. 03 févr. 2023 10:18:09 +0100, a ecrit:
> This patch is missing the limitation of read/write messages to stay
> below the max. supported message size.
It should at least be asserted.
> +static int p9_read(struct dev_9pfs *dev, uint32_t fid, uint64_t offset,
> +
Hi,
A few more remarks.
On 13/01/2023 05:28, Penny Zheng wrote:
In MPU system, device tree binary can be packed with Xen
image through CONFIG_DTB_FILE, or provided by bootloader through x0.
In MPU system, each section in xen.lds.S is PAGE_SIZE aligned.
So in order to not overlap with the previ
Juergen Gross, le ven. 03 févr. 2023 10:18:08 +0100, a ecrit:
> +static unsigned int get_fid(struct dev_9pfs *dev)
> +{
> +unsigned int fid;
> +
> +fid = ffs(dev->fid_mask);
> +if ( fid )
> +dev->fid_mask &= 1ULL << (fid - 1);
Isn't that missing a ~ ?
> @@ -459,6 +522,134 @@ s
On 03.02.2023 10:30, Luca Fancellu wrote:
> I’m starting a proposal for the external files that needs to be removed from
> the MISRA scan,
> the work was originally started by Michal here:
> https://patchwork.kernel.org/project/xen-devel/patch/20221116092032.4423-1-michal.or...@amd.com/
> so I sta
On 03.02.2023 20:55, Stefano Stabellini wrote:
> On Fri, 3 Feb 2023, Luca Fancellu wrote:
>> And then, if the file is not subject to backport and now we “own” the file,
>> there is no more the need to list it
>> in the external file, a commit search can reveal when it was converted to
>> Xen code
flight 176414 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176414/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Juergen Gross, le lun. 06 févr. 2023 10:22:10 +0100, a ecrit:
> On 06.02.23 10:01, Samuel Thibault wrote:
> > Juergen Gross, le ven. 03 févr. 2023 10:18:06 +0100, a ecrit:
> > > +void *init_9pfront(unsigned int id, const char *mnt)
> > > +{
> > [...]
> > > +free(xenbus_watch_path_token(XBT_NIL,
Juergen Gross, le ven. 03 févr. 2023 10:18:07 +0100, a ecrit:
> +/*
> + * Using an opportunistic approach for receiving data: in case multiple
> + * requests are outstanding (which is very unlikely), we nevertheless need
> + * to consume all data available until we reach the desired request.
> + *
On 05.02.23 13:45, Samuel Thibault wrote:
Juergen Gross, le ven. 03 févr. 2023 10:18:04 +0100, a ecrit:
+int open(const char *pathname, int flags, ...)
+{
+unsigned int m, mlen;
+struct mount_point *mnt;
+mode_t mode = 0;
+va_list ap;
+
+if ( flags & O_CREAT )
+{
+
On 04.02.23 15:01, Samuel Thibault wrote:
Hello,
Juergen Gross, le ven. 03 févr. 2023 10:18:03 +0100, a ecrit:
+char *xenbus_read_unsigned(xenbus_transaction_t xbt, const char *dir,
+ const char *node, unsigned int *value)
+{
+char path[BUFFER_SIZE];
+char *msg
On 06.02.23 10:01, Samuel Thibault wrote:
Juergen Gross, le ven. 03 févr. 2023 10:18:06 +0100, a ecrit:
+void *init_9pfront(unsigned int id, const char *mnt)
+{
[...]
+free(xenbus_watch_path_token(XBT_NIL, bepath, bepath, &dev->events));
Better check for errors, otherwise the rest will h
Juergen Gross, le ven. 03 févr. 2023 10:18:06 +0100, a ecrit:
> +void *init_9pfront(unsigned int id, const char *mnt)
> +{
[...]
> +free(xenbus_watch_path_token(XBT_NIL, bepath, bepath, &dev->events));
Better check for errors, otherwise the rest will hang without useful
feedback.
> +for (
89 matches
Mail list logo
