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 vcpu *prev, s
>>
>> ctxt_switch_levelling(next);
>>
>> -if (
On 27.01.23 08:40, Jan Beulich wrote:
On 27.01.2023 06:54, Juergen Gross wrote:
When loading a Xenstore stubdom the loader doesn't know whether the
lo be loaded kernel is a PVH or a PV one. So it tries to load it as
a PVH one first, and if this fails it is loading it as a PV kernel.
This
On 27.01.2023 06:54, Juergen Gross wrote:
> When loading a Xenstore stubdom the loader doesn't know whether the
> lo be loaded kernel is a PVH or a PV one. So it tries to load it as
> a PVH one first, and if this fails it is loading it as a PV kernel.
>
> This results in errors being logged in
On 26.01.2023 19:54, Stefano Stabellini wrote:
> Coming back to 18.2: it makes sense for Xen and the scanners today work
> well with this rule, so I think we are fine.
I disagree. Looking back at the sheet, it says "rule already followed by
the community in most cases" which I assume was based on
The test code in xenbus.c can easily be moved into test.c.
Signed-off-by: Juergen Gross
---
test.c | 108 +++-
xenbus.c | 113 ---
2 files changed, 106 insertions(+), 115 deletions(-)
diff
The SUBDIRS make variable has some stale entries, remove them.
Signed-off-by: Juergen Gross
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index f3acdd2f..747c7c01 100644
--- a/Makefile
+++ b/Makefile
@@ -34,7 +34,7 @@ EXTRA_OBJS =
TARGET
On 26.01.2023 19:02, Krister Johansen wrote:
> On Thu, Jan 26, 2023 at 10:57:01AM +0100, Jan Beulich wrote:
>> On 25.01.2023 19:45, Krister Johansen wrote:
>>> --- a/xen/include/public/arch-x86/cpuid.h
>>> +++ b/xen/include/public/arch-x86/cpuid.h
>>> @@ -72,6 +72,14 @@
>>> * Sub-leaf 2: EAX:
When loading a Xenstore stubdom the loader doesn't know whether the
lo be loaded kernel is a PVH or a PV one. So it tries to load it as
a PVH one first, and if this fails it is loading it as a PV kernel.
This results in errors being logged in case the stubdom is a PV kernel.
Suppress those
xen_pt_config_reg_init() reads only that many bytes as the size of the
register that is being initialized. It uses
xen_host_pci_get_{byte,word,long} and casts its last argument to
expected pointer type. This means for smaller registers higher bits of
'val' are not initialized. Then, the function
flight 176225 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176225/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ca573b86157e7fcd34cd44e79ebd10e89d8b8cc4
baseline version:
ovmf
flight 176223 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt-qcow2
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-vhd
testid guest-localmigrate
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
> Prior to this change, lifetime of pci_dev objects was protected by global
> pcidevs_lock(). We are going to get if of this lock, so we need some
> other mechanism to ensure that those objects will not disappear under
> feet of code that access them.
On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
> ATS subsystem has own list of PCI devices. As we are going to remove
> global pcidevs_lock() in favor to more granular locking, we need to
> ensure that this list is protected somehow. To do this, we need to add
> additional lock for each IOMMU, as
On Fri, Jan 20, 2023 at 11:33:19AM +, David Woodhouse wrote:
> From: David Woodhouse
>
> When running under Xen, hvmloader places a table at 0x1000 with the e820
> information and BIOS tables. If this isn't present, SeaBIOS will
> currently panic.
>
> We now have support for running Xen
On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
> This lock protects alldevs_list of struct pci_seg. As this, it should
> be used when we are adding, removing on enumerating PCI devices
> assigned to a PCI segment.
>
> Radix tree that stores PCI segment has own locking mechanism, also
> pci_seg
On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
> domain->pdevs_lock protects access to domain->pdev_list.
> As this, it should be used when we are adding, removing on enumerating
> PCI devices assigned to a domain.
>
> This enables more granular locking instead of one huge pcidevs_lock that
>
On 25/01/2023 3:26 pm, Jan Beulich wrote:
> When the outgoing vCPU had IBPB issued upon entering Xen there's no
> need for a 2nd barrier during context switch.
>
> Signed-off-by: Jan Beulich
> ---
> v3: Fold into series.
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2015,7
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 indirect branches, and rets were
already immaterial
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 paths to issue the
>>> barrier there, including
On 26/01/2023 8:50 am, Jan Beulich wrote:
> On 25.01.2023 17:53, Andrew Cooper wrote:
>> The OSSTest bisector identified an issue with c/s 1894049fa283 ("x86/shadow:
>> L2H shadow type is PV32-only") in !HVM builds.
>>
>> The bug is ultimately caused by sh_type_to_size[] not actually being
On Thu, 26 Jan 2023, Jan Beulich wrote:
> On 26.01.2023 16:59, Stefano Stabellini wrote:
> > On Thu, 26 Jan 2023, Jan Beulich wrote:
> >> On 25.01.2023 21:57, Stefano Stabellini wrote:
> >>> From: Stefano Stabellini
> >>>
> >>> As agreed during the last MISRA C discussion, I am adding the
Hello,Doesn't KVM need re-architecture? For example, Dom0 consumes memory and
if its number is large, it causes waste of memory in the system.
Tnx.
On Thu, Jan 26, 2023 at 10:57:01AM +0100, Jan Beulich wrote:
> On 25.01.2023 19:45, Krister Johansen wrote:
> > --- a/xen/include/public/arch-x86/cpuid.h
> > +++ b/xen/include/public/arch-x86/cpuid.h
> > @@ -72,6 +72,14 @@
> > * Sub-leaf 2: EAX: host tsc frequency in kHz
> > */
> >
> >
On Thu, Jan 26, 2023 at 09:57:43AM +0100, Jan Beulich wrote:
> On 25.01.2023 19:45, Krister Johansen wrote:
> > v2:
> > - Fix whitespace between comment and #defines (feedback from Jan Beulich)
>
> Hmm, ...
>
> > --- a/xen/include/public/arch-x86/cpuid.h
> > +++
On 20/01/2023 11:33, David Woodhouse wrote:
From: David Woodhouse
When running under Xen, hvmloader places a table at 0x1000 with the e820
information and BIOS tables. If this isn't present, SeaBIOS will
currently panic.
We now have support for running Xen guests natively in QEMU/KVM, which
Hi,
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> [...]
>
On Thu, Jan 26, 2023 at 11:48 AM Jan Beulich wrote:
>
> On 26.01.2023 16:41, Tamas K Lengyel wrote:
> > On Thu, Jan 26, 2023 at 3:14 AM Jan Beulich wrote:
> >>
> >> On 25.01.2023 16:34, Tamas K Lengyel wrote:
> >>> On Tue, Jan 24, 2023 at 6:19 AM Jan Beulich wrote:
>
> On 23.01.2023
flight 176151 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176151/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 26.01.2023 16:41, Tamas K Lengyel wrote:
> On Thu, Jan 26, 2023 at 3:14 AM Jan Beulich wrote:
>>
>> On 25.01.2023 16:34, Tamas K Lengyel wrote:
>>> On Tue, Jan 24, 2023 at 6:19 AM Jan Beulich wrote:
On 23.01.2023 19:32, Tamas K Lengyel wrote:
> On Mon, Jan 23, 2023 at 11:24 AM
On 26.01.2023 16:59, Stefano Stabellini wrote:
> On Thu, 26 Jan 2023, Jan Beulich wrote:
>> On 25.01.2023 21:57, Stefano Stabellini wrote:
>>> From: Stefano Stabellini
>>>
>>> As agreed during the last MISRA C discussion, I am adding the following
>>> MISRA C rules: 7.1, 7.3, 18.3.
>>>
>>> I am
Hi Anthony,
On Thu, Jan 26, 2023 at 3:22 PM Anthony PERARD
wrote:
>
> On Mon, Jan 23, 2023 at 04:47:29PM +0100, Carlo Nonato wrote:
> > diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
> > index e939d07157..064f54c349 100644
> > --- a/tools/libs/ctrl/xc_domain.c
> > +++
flight 176143 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 broken
test-arm64-arm64-xl-seattle
On 23.01.2023 16:47, Carlo Nonato wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -299,6 +299,20 @@ can be maintained with the pv-shim mechanism.
> cause Xen not to use Indirect Branch Tracking even when support is
> available in hardware.
On Thu, Jan 26, 2023 at 7:09 AM Matthew Wilcox wrote:
>
> On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> > On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > > +/* Use when VMA is not
On Thu, 26 Jan 2023, Jan Beulich wrote:
> On 25.01.2023 21:57, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > As agreed during the last MISRA C discussion, I am adding the following
> > MISRA C rules: 7.1, 7.3, 18.3.
> >
> > I am also adding 13.1 and 18.2 that were "agreed
On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > > +static inline
On Thu, Jan 26, 2023 at 3:14 AM Jan Beulich wrote:
>
> On 25.01.2023 16:34, Tamas K Lengyel wrote:
> > On Tue, Jan 24, 2023 at 6:19 AM Jan Beulich wrote:
> >>
> >> On 23.01.2023 19:32, Tamas K Lengyel wrote:
> >>> On Mon, Jan 23, 2023 at 11:24 AM Jan Beulich
wrote:
> On 23.01.2023 17:09,
On Wed, 25 Jan 2023, Vikram Garhwal wrote:
> Hi Stefano,
>
> On 1/25/23 2:20 PM, Stefano Stabellini wrote:
> > On Wed, 25 Jan 2023, Vikram Garhwal wrote:
> > > Add a new machine xenpvh which creates a IOREQ server to register/connect
> > > with
> > > Xen Hypervisor.
> > >
> > > Optional: When
On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > vm_flags are among VMA attributes which affect decisions like VMA merging
> > and splitting. Therefore all vm_flags modifications are performed after
> > taking
On Wed, Jan 25, 2023 at 12:38:51AM -0800, Suren Baghdasaryan wrote:
> mmap_assert_write_locked() is used in vm_flags modifiers. Because
> mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
> modified from from inside a module, it's necessary to export
> dump_mm() function.
>
>
On Thu, Jan 26, 2023 at 06:13:10AM +0100, Marek Marczykowski-Górecki wrote:
> Python < 3.10 by default uses 'int' type for data+size string types
> (s#), unless PY_SSIZE_T_CLEAN is defined - in which case it uses
> Py_ssize_t. The former behavior was removed in Python 3.10 and now it's
> required
On Mon, Jan 23, 2023 at 04:47:29PM +0100, Carlo Nonato wrote:
> diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
> index e939d07157..064f54c349 100644
> --- a/tools/libs/ctrl/xc_domain.c
> +++ b/tools/libs/ctrl/xc_domain.c
> @@ -28,6 +28,20 @@ int
On Thu, Jan 19, 2023 at 11:35:06AM -0800, H. Peter Anvin wrote:
> On January 18, 2023 1:45:44 AM PST, Peter Zijlstra
> wrote:
> >On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
> >> The boot trampolines from trampoline_64.S have code flow like:
> >>
> >> 16bit BIOS
flight 176146 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176146/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 26.01.23 13:42, Jan Beulich wrote:
On 26.01.2023 13:24, Juergen Gross wrote:
When loading a Xenstore stubdom the loader doesn't know whether the
lo be loaded kernel is a PVH or a PV one. So it tries to load it as
a PVH one first, and if this fails it is loading it as a PV kernel.
This
On 26.01.2023 13:24, Juergen Gross wrote:
> When loading a Xenstore stubdom the loader doesn't know whether the
> lo be loaded kernel is a PVH or a PV one. So it tries to load it as
> a PVH one first, and if this fails it is loading it as a PV kernel.
>
> This results in errors being logged in
On 26.01.2023 12:00, Carlo Nonato wrote:
> On Tue, Jan 24, 2023 at 5:50 PM Jan Beulich wrote:
>> On 23.01.2023 16:47, Carlo Nonato wrote:
>>> From: Luca Miccio
>>>
>>> This commit adds a new memory page allocator that implements the cache
>>> coloring mechanism. The allocation algorithm follows
When loading a Xenstore stubdom the loader doesn't know whether the
lo be loaded kernel is a PVH or a PV one. So it tries to load it as
a PVH one first, and if this fails it is loading it as a PV kernel.
This results in errors being logged in case the stubdom is a PV kernel.
Suppress those
On Thu, Jan 26, 2023 at 10:14:54AM +0100, Jan Beulich wrote:
> On 26.01.2023 06:13, Marek Marczykowski-Górecki wrote:
> > @@ -1774,7 +1775,7 @@ static PyObject *pyflask_load(PyObject *self,
> > PyObject *args, PyObject *kwds)
> > {
> > xc_interface *xc_handle;
> > char *policy;
> > -
On 21.10.2022 20:02, Julien Grall wrote:
> On 26/08/2022 13:51, Carlo Nonato wrote:
>> @@ -335,6 +337,12 @@ struct xen_arch_domainconfig {
>>*
>>*/
>> uint32_t clock_frequency;
>> +/* IN */
>> +uint8_t from_guest;
>
> There is an implicit padding here and ...
>> +
On 21.10.2022 20:02, Julien Grall wrote:
> On 26/08/2022 13:51, Carlo Nonato wrote:
>> This commit adds array pointers to domains as well as to the hypercall
>> and configuration structure employed in domain creation. The latter is used
>> both by the toolstack and by Xen itself to pass
flight 176144 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176144/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d0ff1cae3a1ab20ffd5a1d80658c38c113585651
baseline version:
ovmf
flight 176140 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-i386-xl 18 guest-localmigrate fail REGR. vs. 175994
Hi Julien and Jan,
On Thu, Jan 26, 2023 at 11:21 AM Julien Grall wrote:
>
> Hi,
>
> On 25/01/2023 16:27, Carlo Nonato wrote:
> > On Tue, Jan 24, 2023 at 5:29 PM Jan Beulich wrote:
> >>
> >> On 23.01.2023 16:47, Carlo Nonato wrote:
> >>> @@ -275,6 +276,19 @@ unsigned int
Hi Jan,
On Thu, Jan 26, 2023 at 8:25 AM Jan Beulich wrote:
>
> On 24.01.2023 17:29, Jan Beulich wrote:
> > On 23.01.2023 16:47, Carlo Nonato wrote:
> >> @@ -92,6 +92,10 @@ struct xen_domctl_createdomain {
> >> /* CPU pool to use; specify 0 or a specific existing pool */
> >> uint32_t
Hi Julien and Jan,
On Thu, Jan 26, 2023 at 11:16 AM Julien Grall wrote:
>
> Hi Jan,
>
> On 26/01/2023 08:06, Jan Beulich wrote:
> > On 25.01.2023 17:18, Carlo Nonato wrote:
> >> On Wed, Jan 25, 2023 at 2:10 PM Jan Beulich wrote:
> >>> On 25.01.2023 12:18, Carlo Nonato wrote:
> On Tue, Jan
Hi Julien,
On Thu, Jan 26, 2023 at 11:25 AM Julien Grall wrote:
>
> Hi Carlo,
>
> On 23/01/2023 15:47, Carlo Nonato wrote:
> > Cache colored domains can benefit from having p2m page tables allocated
> > with the same coloring schema so that isolation can be achieved also for
> > those kind of
Hi Jan,
On Tue, Jan 24, 2023 at 5:50 PM Jan Beulich wrote:
>
> On 23.01.2023 16:47, Carlo Nonato wrote:
> > From: Luca Miccio
> >
> > This commit adds a new memory page allocator that implements the cache
> > coloring mechanism. The allocation algorithm follows the given domain color
> >
Hi Carlo,
On 23/01/2023 15:47, Carlo Nonato wrote:
Cache colored domains can benefit from having p2m page tables allocated
with the same coloring schema so that isolation can be achieved also for
those kind of memory accesses.
In order to do that, the domain struct is passed to the allocator
Hi,
On 25/01/2023 16:27, Carlo Nonato wrote:
On Tue, Jan 24, 2023 at 5:29 PM Jan Beulich wrote:
On 23.01.2023 16:47, Carlo Nonato wrote:
@@ -275,6 +276,19 @@ unsigned int *dom0_llc_colors(unsigned int *num_colors)
return colors;
}
+unsigned int *llc_colors_from_guest(struct
Hi Jan,
On 26/01/2023 08:06, Jan Beulich wrote:
On 25.01.2023 17:18, Carlo Nonato wrote:
On Wed, Jan 25, 2023 at 2:10 PM Jan Beulich wrote:
On 25.01.2023 12:18, Carlo Nonato wrote:
On Tue, Jan 24, 2023 at 5:37 PM Jan Beulich wrote:
On 23.01.2023 16:47, Carlo Nonato wrote:
---
Hi Stefano,
On 25/01/2023 21:09, Stefano Stabellini wrote:
On Wed, 25 Jan 2023, Ayan Kumar Halder wrote:
1. One should use 'PRIpaddr' to display 'paddr_t' variables. However,
while creating nodes in fdt, the address (if present in the node name)
should be represented using 'PRIx64'. This is to
On 25.01.2023 19:45, Krister Johansen wrote:
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -72,6 +72,14 @@
> * Sub-leaf 2: EAX: host tsc frequency in kHz
> */
>
> +#define XEN_CPUID_TSC_EMULATED (1u << 0)
> +#define
On Wed, Jan 25, 2023 at 4:53 PM Andrew Cooper
wrote:
> The OSSTest bisector identified an issue with c/s 1894049fa283
> ("x86/shadow:
> L2H shadow type is PV32-only") in !HVM builds.
>
> The bug is ultimately caused by sh_type_to_size[] not actually being
> specific
> to HVM guests, and it's
flight 176139 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176139/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-raw 7 xen-install fail like 176116
test-armhf-armhf-libvirt 16
On Wed, Jan 25, 2023 at 12:38:50AM -0800, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in
On Wed, Jan 25, 2023 at 12:38:49AM -0800, Suren Baghdasaryan wrote:
> Replace indirect modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
> vm_flags
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
>
On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
>
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
>
On 26.01.2023 06:13, Marek Marczykowski-Górecki wrote:
> @@ -1774,7 +1775,7 @@ static PyObject *pyflask_load(PyObject *self, PyObject
> *args, PyObject *kwds)
> {
> xc_interface *xc_handle;
> char *policy;
> -uint32_t len;
> +Py_ssize_t len;
I find this suspicious - by the
On 25.01.2023 21:57, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> As agreed during the last MISRA C discussion, I am adding the following
> MISRA C rules: 7.1, 7.3, 18.3.
>
> I am also adding 13.1 and 18.2 that were "agreed pending an analysis on
> the amount of violations".
>
> In
On 25.01.2023 17:53, Andrew Cooper wrote:
> The OSSTest bisector identified an issue with c/s 1894049fa283 ("x86/shadow:
> L2H shadow type is PV32-only") in !HVM builds.
>
> The bug is ultimately caused by sh_type_to_size[] not actually being specific
> to HVM guests, and it's position in
On 25.01.2023 19:45, Krister Johansen wrote:
> v2:
> - Fix whitespace between comment and #defines (feedback from Jan Beulich)
Hmm, ...
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -72,6 +72,14 @@
> * Sub-leaf 2: EAX: host tsc frequency in kHz
flight 176135 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 8 xen-boot fail REGR. vs. 173462
On Wed, 2023-01-25 at 17:15 +, Andrew Cooper wrote:
> On 25/01/2023 5:01 pm, Oleksii wrote:
> > On Mon, 2023-01-23 at 09:39 +1000, Alistair Francis wrote:
> > > On Sat, Jan 21, 2023 at 1:00 AM Oleksii Kurochko
> > > wrote:
> > > > The patch introduces the function the purpose of which is to
>
On 25.01.2023 16:34, Tamas K Lengyel wrote:
> On Tue, Jan 24, 2023 at 6:19 AM Jan Beulich wrote:
>>
>> On 23.01.2023 19:32, Tamas K Lengyel wrote:
>>> On Mon, Jan 23, 2023 at 11:24 AM Jan Beulich wrote:
On 23.01.2023 17:09, Tamas K Lengyel wrote:
> On Mon, Jan 23, 2023 at 9:55 AM Jan
On 25.01.2023 17:18, Carlo Nonato wrote:
> On Wed, Jan 25, 2023 at 2:10 PM Jan Beulich wrote:
>> On 25.01.2023 12:18, Carlo Nonato wrote:
>>> On Tue, Jan 24, 2023 at 5:37 PM Jan Beulich wrote:
On 23.01.2023 16:47, Carlo Nonato wrote:
> --- a/xen/include/xen/sched.h
> +++
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 paths to issue the
>> barrier there, including the "IBPB doesn't flush the RSB/RAS"
>>
80 matches
Mail list logo
