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 (
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
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 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 )
+{
+
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.
> + *
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,
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
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
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
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
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: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,
> +
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
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
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 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/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
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 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__
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
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
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
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
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
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
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
+ 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
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
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
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
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/
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 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
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 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: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 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: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 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 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: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 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
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
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
> 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 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 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
> 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 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 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
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: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
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
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 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
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
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
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
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
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 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
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
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 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 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 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
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
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 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
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
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
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
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-
+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
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
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
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
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 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
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 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 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
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
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 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 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
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
89 matches
Mail list logo
