On 13.10.23 00:36, Stefano Stabellini wrote:
On Thu, 12 Oct 2023, George Dunlap wrote:
Stop tinkering in the hope that it hides the problem. You're only
making it harder to fix properly.
Making it harder to fix properly would be a valid reason not to commit
the (maybe partial) fix. But lookin
flight 183360 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183360/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-migrupgrade 21 debian-fixup/dst_host fail in 183347 pass in
183360
test-armhf-armhf-xl
On 13/10/2023 1:26 am, Alejandro Vallejo wrote:
> If Zen4 runs with SMT and without STIBP, then it may corrupt its own code
> stream. This is erratum #1485 in the AMD specs.
I'm afraid this description isn't fully accurate, and I can't elaborate
any further at this juncture.
Just say "address AMD
On 13/10/2023 1:26 am, Alejandro Vallejo wrote:
> It slightly simplifies the code that uses them at no real cost because the
> code is very rarely executed. This makes it harder to confuse zen uarches
> due to missing or mistaken family checks.
I'm afraid I disagree.
It's bogus to do a family che
flight 183359 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183359/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 183344
Tests which did not succeed,
Hi Alejandro,
> On Oct 13, 2023, at 01:25, Alejandro Vallejo
> wrote:
>
> This patch should make it to 4.18, as it prevents random crashes on AMD
> Zen4 running outdated microcode.
Yes I agree, so for this series:
Release-acked-by: Henry Wang
Kind regards,
Henry
>
> Under certain conditi
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> The definition of MC_NCLASSES contained a violation of MISRA C:2012
> Rule 10.1, therefore by moving it as an enumeration constant resolves the
> violation and makes it more resilient to possible additions to that enum.
>
> Signed-off-by: Nicola Vetrini
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> The various definitions of macro CNT (and the related BUILD_BUG_ON)
> can be rewritten using LOWEST_BIT, encapsulating a violation of
> MISRA C:2012 Rule 10.1.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> The definition of PDX_GROUP_COUNT causes violations of
> MISRA C:2012 Rule 10.1, therefore the problematic part now uses
> the LOWEST_BIT macro, which encapsulates the pattern.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> The definitions of ffs{l}? violate Rule 10.1, by using the well-known
> pattern (x & -x); its usage is wrapped by the LOWEST_BIT macro.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Thu, 12 Oct 2023, Nicola Vetrini wrote:
> The purpose of this macro is to encapsulate the well-known expression
> 'x & -x', that in 2's complement architectures on unsigned integers will
> give 2^ffs(x), where ffs(x) is the position of the lowest set bit in x.
>
> A deviation for ECLAIR is also
On Wed, 11 Oct 2023, Nicola Vetrini wrote:
> The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
> compile-time check to detect non-scalar types; its usage for this
> purpose is deviated.
>
> Furthermore, the 'access_field' and 'typeof_field' macros are
> introduced as a general way to
On Wed, 11 Oct 2023, Nicola Vetrini wrote:
> Using enumerators declared in a named enum, such as the one modified,
> as operands to arithmetic operators is not allowed by MISRA C:2012 Rule 10.1.
> The enumerators of an anonymous enum can be used instead.
>
> Signed-off-by: Nicola Vetrini
Reviewe
On Wed, 11 Oct 2023, Julien Grall wrote:
> On 11/10/2023 11:53, Luca Fancellu wrote:
> >
> > > > >
> > > > > Luca answered to a similar, more generic, question a few days ago
> > > > > about
> > > > > Coverity: https://marc.info/?l=xen-devel&m=169657904027210
> > > > Interesting.
> > > > >
> > >
On Wed, 11 Oct 2023, Nicola Vetrini wrote:
> On 11/10/2023 17:00, Nicola Vetrini wrote:
> > > > > > > +
> > > > > > > + * - R2.1
> > > > > > > + - The compiler implementation guarantees that the
> > > > > > > unreachable code
> > > > > > > is
> > > > > > > + removed. Constant expression
On Thu, Oct 12, 2023 at 11:22 PM H. Peter Anvin wrote:
>
> On 10/12/23 14:17, Uros Bizjak wrote:
> >>
> >> Are you PIC-adjusting the percpu variables as well?
> >
> > After this patch (and after fixing percpu_stable_op to use "a" operand
> > modifier on GCC), the only *one* remaining absolute refe
On Thu, 12 Oct 2023, George Dunlap wrote:
> > > Stop tinkering in the hope that it hides the problem. You're only
> > > making it harder to fix properly.
> >
> > Making it harder to fix properly would be a valid reason not to commit
> > the (maybe partial) fix. But looking at the fix again:
> >
>
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by: Oleksan
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an error back to MMIO handler, otherwise it is possible to
provide more data than requested: i.e. guest issues LDRB instruction
to read one byte, but we are w
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
Plea
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs g
From: Stewart Hildebrand
Move iomem_caps initialization earlier (before arch_domain_create()).
Signed-off-by: Stewart Hildebrand
---
Changes in v10:
* fix off-by-one
* also permit access to GUEST_VPCI_PREFETCH_MEM_ADDR
Changes in v9:
* new patch
This is sort of a follow-up to:
baa6ea700386
Add per-domain d->pci_lock that protects access to
d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
that underlying pdev will not disappear under feet. This is a rw-lock,
but this patch adds only write_lock()s. There will be read_lock()
users in the next patches.
This lock sho
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's view of this will want to be zero initially, the host having set
it to 1 may not easily be overwritten with 0, or else
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned we need to
initialize/de-initialize vPCI state for the device.
Also, rename vpci_add_handlers() to vpci_assign_device() and
vpci_remove_device() to vpci_deassign_device() to better reflect role
of the functions.
Signed-of
This function can be used when user wants to remove all rangeset
entries but do not want to destroy rangeset itself.
Signed-off-by: Volodymyr Babchuk
---
Changes in v10:
- New in v10. The function is used in "vpci/header: handle p2m range sets per
BAR"
---
xen/common/rangeset.c | 9 +++
Previously pci_enable_msi() function obtained pdev pointer by itself,
but taking into account upcoming changes to PCI locking, it is better
when caller passes already acquired pdev pointer to the function.
Note that ns16550 driver does not check validity of obtained pdev
pointer because pci_enable
Hello all,
This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.
in v10:
- Removed patch ("xen/arm: vpci: check guest range"), proper fix
for the issue is part of ("vpci/header: emulate PCI_COMMAND
register for guests")
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that rangese
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity
From: Oleksandr Andrushchenko
Use a previously introduced per-domain read/write lock to check
whether vpci is present, so we are sure there are no accesses to the
contents of the vpci struct if not. This lock can be used (and in a
few cases is used right away) so that vpci removal can be performe
Introduce "fail" label in init_bars() function to have the centralized
error return path. This is the pre-requirement for the future changes
in this function.
This patch does not introduce functional changes.
Signed-off-by: Volodymyr Babchuk
Suggested-by: Roger Pau Monné
Acked-by: Roger Pau Mon
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest vi
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
On 10/12/23 14:17, Uros Bizjak wrote:
Are you PIC-adjusting the percpu variables as well?
After this patch (and after fixing percpu_stable_op to use "a" operand
modifier on GCC), the only *one* remaining absolute reference to
percpu variable remain in xen-head.S, where:
movq$INIT_PER
On Thu, Oct 12, 2023 at 11:08 PM H. Peter Anvin wrote:
>
> On 10/12/23 13:59, Uros Bizjak wrote:
> > On Thu, Oct 12, 2023 at 10:53 PM Dave Hansen wrote:
> >>
> >> On 10/12/23 13:12, Uros Bizjak wrote:
> >>> The last patch introduces (%rip) suffix and uses it for x86_64 target,
> >>> resulting in
On 10/12/23 13:59, Uros Bizjak wrote:
On Thu, Oct 12, 2023 at 10:53 PM Dave Hansen wrote:
On 10/12/23 13:12, Uros Bizjak wrote:
The last patch introduces (%rip) suffix and uses it for x86_64 target,
resulting in a small code size decrease: text data bss dec hex filename
25510677 4386685 80838
On 10/12/23 14:02, H. Peter Anvin wrote:>
%fs??
>
Nevermind, I forgot that we changed from %gs to %fs on i386 at some
point in the now-distant past.
-hpa
On Thu, Oct 12, 2023 at 11:02 PM H. Peter Anvin wrote:
>
> On October 12, 2023 9:10:36 AM PDT, Uros Bizjak wrote:
> >PER_CPU_VAR macro is intended to be applied to a symbol, it is not
> >intended to be used as a selector between %fs and %gs segment
> >registers for general operands.
> >
> >The ad
On October 12, 2023 9:10:36 AM PDT, Uros Bizjak wrote:
>PER_CPU_VAR macro is intended to be applied to a symbol, it is not
>intended to be used as a selector between %fs and %gs segment
>registers for general operands.
>
>The address to these emulation functions is passed in a register, so
>use ex
On Thu, Oct 12, 2023 at 10:53 PM Dave Hansen wrote:
>
> On 10/12/23 13:12, Uros Bizjak wrote:
> > The last patch introduces (%rip) suffix and uses it for x86_64 target,
> > resulting in a small code size decrease: text data bss dec hex filename
> > 25510677 4386685 808388 30705750 1d48856 vmlinux-
On 10/12/23 13:12, Uros Bizjak wrote:
> The last patch introduces (%rip) suffix and uses it for x86_64 target,
> resulting in a small code size decrease: text data bss dec hex filename
> 25510677 4386685 808388 30705750 1d48856 vmlinux-new.o 25510629 4386685
> 808388 30705702 1d48826 vmlinux-old.o
Introduce x86_64 %rip-relative addressing to PER_CPU_VAR macro.
Instruction with %rip-relative address operand is one byte shorter than
its absolute address counterpart and is also compatible with position
independent executable (-fpie) build.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Pet
PER_CPU_VAR macro should be applied to a symbol and its addend.
Inconsisten usage is currently harmless, but needs to be corrected
before %rip-relative addressing is introduced to PER_CPU_VAR macro.
No functional changes intended.
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: Thomas Gleixner
Cc: I
The following patch series introduces %rip-relative addressing to
PER_CPU_VAR macro. Instruction with %rip-relative address operand is
one byte shorter than its absolute address counterpart and is also
compatible with position independent executable (-fpie) build.
The first three patches are clean
PER_CPU_VAR macro is intended to be applied to a symbol and should not
be used with general operands. Introduce new PER_CPU_ARG macro and
use it in cmpxchg{8,16}b_emu.S instead.
PER_CPU_VAR macro will be repurposed for %rip-relative addressing.
Also add a missing function comment to this_cpu_cmpx
PER_CPU_VAR macro should be applied to a symbol and its addend.
Inconsistent usage is currently harmless, but needs to be corrected
before %rip-relative addressing is introduced to PER_CPU_VAR macro.
No functional changes intended.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Da
flight 183357 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183357/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-pair 28 guest-migrate/dst_host/src_host/debian.repeat
fail in 183350 pass in 183357
On Thu, Oct 12, 2023 at 7:54 PM Uros Bizjak wrote:
> > This will break on !SMP builds, where per-cpu variables are just
> > regular data and not accessed with a segment prefix.
>
> Ugh, indeed. Let me rethink this a bit.
Something like this:
#ifdef CONFIG_SMP
#define PER_CPU_ARG(arg)%__percp
On Thu, Oct 12, 2023 at 7:45 PM Brian Gerst wrote:
>
> On Thu, Oct 12, 2023 at 12:13 PM Uros Bizjak wrote:
> >
> > PER_CPU_VAR macro is intended to be applied to a symbol, it is not
> > intended to be used as a selector between %fs and %gs segment
> > registers for general operands.
> >
> > The a
On Thu, Oct 12, 2023 at 12:13 PM Uros Bizjak wrote:
>
> PER_CPU_VAR macro is intended to be applied to a symbol, it is not
> intended to be used as a selector between %fs and %gs segment
> registers for general operands.
>
> The address to these emulation functions is passed in a register, so
> us
It slightly simplifies the code that uses them at no real cost because the
code is very rarely executed. This makes it harder to confuse zen uarches
due to missing or mistaken family checks.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/cpu/amd.c | 5 +
If Zen4 runs with SMT and without STIBP, then it may corrupt its own code
stream. This is erratum #1485 in the AMD specs.
Fix adapted off Linux's mailing list:
https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
Signed-off-by: Alejandro Vallejo
---
xen/arch/x
This patch should make it to 4.18, as it prevents random crashes on AMD
Zen4 running outdated microcode.
Under certain conditions Zen4 may corrupt its own code stream when SMT is
enabled and STIBP is not. The Linux thread in which this was highlighted is
in patch2's commit message.
NOTE: Still ru
flight 183351 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183351/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183338
test-armhf-armhf-libvirt-qcow2 15 saveres
The following patch series introduces %rip-relative addressing to
PER_CPU_VAR macro. Instruction with %rip-relative address operand is
one byte shorter than its absolute address counterpart and is also
compatible with position independent executable (-fpie) build.
The first three patches are clean
PER_CPU_VAR macro should be applied to a symbol and its addend.
Inconsisten usage is currently harmless, but needs to be corrected
before %rip-relative addressing is introduced to PER_CPU_VAR macro.
No functional changes intended.
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: Thomas Gleixner
Cc: I
Introduce x86_64 %rip-relative addressing to PER_CPU_VAR macro.
Instruction with %rip-relative address operand is one byte shorter than
its absolute address counterpart and is also compatible with position
independent executable (-fpie) build.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Pet
PER_CPU_VAR macro is intended to be applied to a symbol, it is not
intended to be used as a selector between %fs and %gs segment
registers for general operands.
The address to these emulation functions is passed in a register, so
use explicit segment registers to access percpu variable instead.
A
PER_CPU_VAR macro should be applied to a symbol and its addend.
Inconsistent usage is currently harmless, but needs to be corrected
before %rip-relative addressing is introduced to PER_CPU_VAR macro.
No functional changes intended.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Da
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/common/vmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 4fd6b3067ec1..34e99d780c03 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -53,7 +53,7 @@ static voi
This series replaces two instances of the pattern (x & -x) with the
macro LOWEST_BIT, introduced by the series [1]. Therefore, these patches should
be applied on top of patch 1 from that series.
[1] https://marc.info/?l=xen-devel&m=169712438716424&w=2
Nicola Vetrini (2):
xen/vmap: use LOWEST_BI
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/drivers/passthrough/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index f9a9f53dbd44..558700788d4a 100644
--- a/xen/drivers/passthrough/iomm
> > Stop tinkering in the hope that it hides the problem. You're only
> > making it harder to fix properly.
>
> Making it harder to fix properly would be a valid reason not to commit
> the (maybe partial) fix. But looking at the fix again:
>
> diff --git a/tools/xenstored/domain.c b/tools/xenstore
The definition of MC_NCLASSES contained a violation of MISRA C:2012
Rule 10.1, therefore by moving it as an enumeration constant resolves the
violation and makes it more resilient to possible additions to that enum.
Signed-off-by: Nicola Vetrini
---
Note that the use of an enum constant as operan
The definition of PDX_GROUP_COUNT causes violations of
MISRA C:2012 Rule 10.1, therefore the problematic part now uses
the LOWEST_BIT macro, which encapsulates the pattern.
Signed-off-by: Nicola Vetrini
---
xen/include/xen/pdx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
The definition of IO_APIC_BASE contains a sum of an essentially enum
value (FIX_IO_APIC_BASE_0) that is positive with an index that, in all
instances, is unsigned, therefore the former is cast to unsigned, so that
the operands are of the same essential type.
No functional change.
---
xen/arch/x86
The purpose of this macro is to encapsulate the well-known expression
'x & -x', that in 2's complement architectures on unsigned integers will
give 2^ffs(x), where ffs(x) is the position of the lowest set bit in x.
A deviation for ECLAIR is also introduced.
Signed-off-by: Nicola Vetrini
---
Chan
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 addition operator
in macro 'BITS_TO_LONGS'.
This construct is deviated with a deviation comment.
Signed-
The various definitions of macro CNT (and the related BUILD_BUG_ON)
can be rewritten using LOWEST_BIT, encapsulating a violation of
MISRA C:2012 Rule 10.1.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/x86_64/mm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/
The widely-used construct
(x & -x), where x is an unsigned integer quantity represented in 2's complement,
does yield the expected result. Since all architectures that are targets for
compliance do fulfill such requirements, the construct is deemed safe and
deviated.
The use of 'DECLARE_BITMAP(fea
BUILD_BUG_ON is the preferred way to induce a build error
upon statically determined incorrect conditions.
This also fixes a MISRA C:2012 Rule 10.1 violation in the
previous formulation.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- replace the construct with a BUILD_BUG_ON.
---
xen/includ
The definitions of ffs{l}? violate Rule 10.1, by using the well-known
pattern (x & -x); its usage is wrapped by the LOWEST_BIT macro.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/arm/include/asm/bitops.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Thu, 2023-10-12 at 15:05 +0100, Matthew Wilcox wrote:
> On Thu, Oct 12, 2023 at 02:53:05PM +0100, David Woodhouse wrote:
> > > + arch_enter_lazy_mmu_mode();
> > > + for (;;) {
> > > + set_pte(ptep, pte);
> > > + if (--nr == 0)
> > > +
flight 183347 xen-unstable real [real]
flight 183358 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183347/
http://logs.test-lab.xenproject.org/osstest/logs/183358/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Thu, Oct 12, 2023 at 02:53:05PM +0100, David Woodhouse wrote:
> > + arch_enter_lazy_mmu_mode();
> > + for (;;) {
> > + set_pte(ptep, pte);
> > + if (--nr == 0)
> > + break;
> > + ptep++;
> > + pte = __pte(p
On Wed, 2023-08-02 at 16:13 +0100, Matthew Wilcox (Oracle) wrote:
> Most architectures can just define set_pte() and PFN_PTE_SHIFT to
> use this definition. It's also a handy spot to document the guarantees
> provided by the MM.
>
> Suggested-by: Mike Rapoport (IBM)
> Signed-off-by: Matthew Wilc
On Wed, Oct 11, 2023 at 12:34:27AM +0800, Andrew Cooper wrote:
> On 10/10/2023 10:18 pm, Javi Merino wrote:
> > Most of the work for python3 compatibility was done in
> > 1430c5a8cad4 (tools/python: Python 3 compatibility, 2019-12-18). This
> > just adds a few builtins needed for python3.
> >
> >
On Tue, Oct 10, 2023 at 05:27:03PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 10, 2023 at 03:18:45PM +0100, Javi Merino wrote:
> > Most of the work for python3 compatibility was done in
> > 1430c5a8cad4 (tools/python: Python 3 compatibility, 2019-12-18). This
> > just adds a few builti
flight 183344 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183344/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail blocked in
183322
test-amd64-amd64-xl-qemut-win7-a
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 +199,11 @@ Devia
A new pre-release of our guest agent prototype written in Rust is
available, numbered 0.2.0 [1]. Identified issues and work to be done
are tracked in Gitlab issue tracker [3].
More details can be found in this blog post [2].
As always, feedback will be greatly appreciated!
[1] https://gitlab
flight 183355 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183355/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 326b9e1d815c4ae4b0b207fcb0bfa16864af5400
baseline version:
ovmf eebd446875a4b1e4879e0
flight 183350 xen-4.16-testing real [real]
flight 183356 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183350/
http://logs.test-lab.xenproject.org/osstest/logs/183356/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 183352 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183352/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eebd446875a4b1e4879e03764f63c6c358fd64f5
baseline version:
ovmf 95c9f470ca6eab23bfd01
On 12/10/2023 4:21 pm, David Woodhouse wrote:
> On Thu, 2023-10-12 at 10:13 +0800, andrew.coop...@citrix.com wrote:
>> On 11/10/2023 7:34 pm, David Woodhouse wrote:
>>> But why does the shim even need to turn it off when switching to the
>>> guest context? Its guest isn't running in supervisor mode
On Thu, 2023-10-12 at 10:13 +0800, andrew.coop...@citrix.com wrote:
> On 11/10/2023 7:34 pm, David Woodhouse wrote:
> > But why does the shim even need to turn it off when switching to the
> > guest context? Its guest isn't running in supervisor mode so surely it
> > doesn't *matter* whether SMEP i
On Mon, Aug 07, 2023 at 04:04:56PM -0700, Vishal Moola (Oracle) wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
>
91 matches
Mail list logo
