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"
>> workarou
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
> +++ b/xen/includ
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 Beu
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 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
test-arm64-arm64-ex
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 shadow/h
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 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 name
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
> opera
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)
> ---
> include/linux/mm
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 modificat
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 suc
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 saveresto
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 posi
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 XEN_CPUID_HOST_T
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
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:
--- a/xen/includ
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 xen_domc
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 and
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
> > configu
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 mem
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 2
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 cp
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 *dom0_llc_colors(unsigned
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
test-amd64-i386-xl
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 37d3eb026a766b2405daa
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 configurati
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 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;
> > -
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 errors
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 t
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 cas
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 result
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 1
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
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 xc_domain_create(xc_interface
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 t
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.
>
> Si
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 e
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 CON
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, Ta
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 voi
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 pendin
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 part
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.
>
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
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
> > +++ b/to
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 al
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 Ja
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 1
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 19
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
> ---
> [...]
> drivers/hsi/cl
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
bo
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
> > +++ b/xen/include/public/arch-x86/cp
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
> > */
> >
> > +#defi
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, 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 followin
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 specific
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 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 be
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 +2
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
> locks
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 stru
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 gue
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 li
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. R
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 git://xenbits
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
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 d0ff1cae3a1ab20ffd5a1
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 fa
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 errors
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: hos
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 :=
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 --gi
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
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 cas
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 result
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 ( opt_ibpb_ctxt_swi
80 matches
Mail list logo
