Prior to b11380f6cd58 ("x86/spec-ctrl: Build with BRANCH_HARDEN lfences
by default") LFENCE was the dominant entry. But even without it there's
still quite a bit of redundancy, much of which can be eliminated by
marking the sections as mergable. This of course also requires splitting
them by "eleme
I'm puzzled about two inconsistencies with other alternative_vcall()
here: There's a check missing that the supplied function pointer is
actually pointing to a function taking no args. And there's a pointless
pair of parentheses. Correct both.
Fixes: 67d01cdb5518 ("x86: infrastructure to allow con
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When a vPCI is removed for a PCI device it is possible that we have
> scheduled a delayed work for map/unmap operations for that device.
> For example, the following scenario can illustrate the problem:
>
> p
On 13.09.2021 11:02, Jan Beulich wrote:
> libxl__domain_config_setdefault() checks whether PoD is going to be
> enabled and fails domain creation if at the same time devices would get
> assigned. Nevertheless setting up of IOMMU page tables is allowed.
> However, when later assigning a device to a
On Wed, Nov 17, 2021 at 09:39:17AM +0100, Jan Beulich wrote:
> On 13.09.2021 11:02, Jan Beulich wrote:
> > libxl__domain_config_setdefault() checks whether PoD is going to be
> > enabled and fails domain creation if at the same time devices would get
> > assigned. Nevertheless setting up of IOMMU p
flight 166157 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 165976
test-armhf-armhf-xl
Hello,
The following changes are preparation work for the 4.16 release. This
is my first pass at the log for the release, it's likely missing more
entries.
I'm Ccing all maintainers in this cover letter and also in patch #2 for
further feedback on missing items.
Thanks, Roger.
Roger Pau Monne (
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index e5ab49e779..ad1a8c2bc2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -22,7 +22,7 @@ The format is based on [Keep a
Changelog](https://keepachang
Document some of the relevant changes during the 4.16 release cycle,
likely more entries are missing.
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 11 +++
1 file changed, 11 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index ad1a8c2bc2..8b0bdd9cf0 100644
--- a/CHANGELOG.m
Currently Xen creates a default cpupool0 that contains all the cpu brought up
during boot and it assumes that the platform has only one kind of CPU.
This assumption does not hold on big.LITTLE platform, but putting different
type of CPU in the same cpupool can result in instability and security iss
Introduce an architecture specific way to create different
cpupool at boot time, this is particularly useful on ARM
biglittle system where there might be the need to have
different cpupools for each type of core, but also systems
using NUMA can have different cpu pool for each node.
Signed-off-by:
With the introduction of boot time cpupools, Xen can
create at boot time many cpupools different from the
cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, name them with the same convention
used for the cpupool 0: Pool-.
Signed-off-by: Luca Fancellu
---
too
flight 166165 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166165/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 2d72d2784eb71d8532bfbd6462d261739c9e82e4
baseline version:
xen c7a7
The subject is wrong, nothing x86-specific here. Please use
"swiotlb: " as the prefix
> + * @vaddr: The vaddr of the swiotlb memory pool. The swiotlb
> + * memory pool may be remapped in the memory encrypted case and
> store
Please avoid the overly long line.
> + /*
> + *
Hi,
On 17/11/2021 09:53, Roger Pau Monne wrote:
Document some of the relevant changes during the 4.16 release cycle,
likely more entries are missing.
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 11 +++
1 file changed, 11 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
This doesn't really have much to do with normal DMA mapping,
so why does this direct through the dma ops?
On 17.11.21 10:53, Roger Pau Monne wrote:
Document some of the relevant changes during the 4.16 release cycle,
likely more entries are missing.
Signed-off-by: Roger Pau Monné
---
CHANGELOG.md | 11 +++
1 file changed, 11 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index a
On 17.11.2021 09:55, Roger Pau Monné wrote:
> On Wed, Nov 17, 2021 at 09:39:17AM +0100, Jan Beulich wrote:
>> On 13.09.2021 11:02, Jan Beulich wrote:
>>> libxl__domain_config_setdefault() checks whether PoD is going to be
>>> enabled and fails domain creation if at the same time devices would get
>
On 17.11.2021 10:53, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
I'm puzzled how we managed to have missed that.
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -22,7 +22,7 @@ The format is based on [Keep a
> Changelog](https://keepachangelog.com/en/1.0.0/)
>
Hi Luca,
On 17/11/2021 09:57, Luca Fancellu wrote:
Currently Xen creates a default cpupool0 that contains all the cpu brought up
during boot and it assumes that the platform has only one kind of CPU.
This assumption does not hold on big.LITTLE platform, but putting different
type of CPU in the s
On Wed, Nov 17, 2021 at 11:21:34AM +0100, Jan Beulich wrote:
> On 17.11.2021 10:53, Roger Pau Monne wrote:
> > Signed-off-by: Roger Pau Monné
>
> Acked-by: Jan Beulich
>
> I'm puzzled how we managed to have missed that.
>
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -22,7 +22,7 @@ The
On 17.11.21 11:26, Julien Grall wrote:
Hi Luca,
On 17/11/2021 09:57, Luca Fancellu wrote:
Currently Xen creates a default cpupool0 that contains all the cpu
brought up
during boot and it assumes that the platform has only one kind of CPU.
This assumption does not hold on big.LITTLE platform, b
On 17.11.21 10:57, Luca Fancellu wrote:
Introduce an architecture specific way to create different
cpupool at boot time, this is particularly useful on ARM
biglittle system where there might be the need to have
different cpupools for each type of core, but also systems
using NUMA can have differe
flight 166162 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166162/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 17/11/2021 10:13, Jan Beulich wrote:
On 17.11.2021 09:55, Roger Pau Monné wrote:
On Wed, Nov 17, 2021 at 09:39:17AM +0100, Jan Beulich wrote:
On 13.09.2021 11:02, Jan Beulich wrote:
libxl__domain_config_setdefault() checks whether PoD is going to be
enabled and fails domain creation if at t
On 17.11.21 10:57, Luca Fancellu wrote:
With the introduction of boot time cpupools, Xen can
create at boot time many cpupools different from the
cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, name them with the same convention
used for the cpupool 0: Pool
Hi Oleksandr,
> On 5 Nov 2021, at 6:33 am, Oleksandr Andrushchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> There is no reason to use void pointer while passing ECAM ops to the
> pci_host_common_probe function as it is anyway casted to struct pci_ecam_ops
> inside. For that reason remove t
Hi Julien,
> On 17 Nov 2021, at 10:26, Julien Grall wrote:
>
> Hi Luca,
>
> On 17/11/2021 09:57, Luca Fancellu wrote:
>> Currently Xen creates a default cpupool0 that contains all the cpu brought up
>> during boot and it assumes that the platform has only one kind of CPU.
>> This assumption doe
Andrew Cooper writes ("Re: [PATCH for-4.16 4/4] tools/python: fix python libxc
bindings to pass a max grant version"):
> On 15/11/2021 12:17, Roger Pau Monne wrote:
> > Such max version should be provided by the caller, otherwise the
> > bindings will default to specifying a max version of 2, whic
On 17.11.21 12:16, Bertrand Marquis wrote:
Hi Julien,
On 17 Nov 2021, at 10:26, Julien Grall wrote:
Hi Luca,
On 17/11/2021 09:57, Luca Fancellu wrote:
Currently Xen creates a default cpupool0 that contains all the cpu brought up
during boot and it assumes that the platform has only one kind
On 17.11.2021 12:09, Andrew Cooper wrote:
> On 17/11/2021 10:13, Jan Beulich wrote:
>> On 17.11.2021 09:55, Roger Pau Monné wrote:
>>> On Wed, Nov 17, 2021 at 09:39:17AM +0100, Jan Beulich wrote:
On 13.09.2021 11:02, Jan Beulich wrote:
> libxl__domain_config_setdefault() checks whether PoD
Roger Pau Monne writes ("[PATCH for-4.16 0/2] CHANGELOG: start to populate
entries for 4.16"):
> The following changes are preparation work for the 4.16 release. This
> is my first pass at the log for the release, it's likely missing more
> entries.
>
> I'm Ccing all maintainers in this cover let
Jan Beulich writes ("Re: [PATCH for-4.16 1/2] CHANGELOG: set Xen 4.15 release
date"):
> I'm puzzled how we managed to have missed that.
Manual faff and eyes glazing over I think...
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -22,7 +22,7 @@ The format is based on [Keep a
> > Changelog](
On Mon, Nov 15, 2021 at 01:17:41PM +0100, Roger Pau Monne wrote:
> Such max version should be provided by the caller, otherwise the
> bindings will default to specifying a max version of 2, which is
> inline with the current defaults in the hypervisor.
>
> Fixes: 7379f9e10a ('gnttab: allow setting
Hi,
On 17.11.2021 11:00, Julien Grall wrote:
> Hi,
>
> On 17/11/2021 09:53, Roger Pau Monne wrote:
>> Document some of the relevant changes during the 4.16 release cycle,
>> likely more entries are missing.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> CHANGELOG.md | 11 +++
>> 1 fil
On 17/11/2021 11:16, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 17 Nov 2021, at 10:26, Julien Grall wrote:
Hi Luca,
On 17/11/2021 09:57, Luca Fancellu wrote:
Currently Xen creates a default cpupool0 that contains all the cpu brought up
during boot and it assumes that the platform has only
> On 17 Nov 2021, at 11:10, Juergen Gross wrote:
>
> On 17.11.21 10:57, Luca Fancellu wrote:
>> With the introduction of boot time cpupools, Xen can
>> create at boot time many cpupools different from the
>> cpupool with id 0.
>> Since these newly created cpupools can't have an
>> entry in Xen
On 17.11.21 12:52, Luca Fancellu wrote:
On 17 Nov 2021, at 11:10, Juergen Gross wrote:
On 17.11.21 10:57, Luca Fancellu wrote:
With the introduction of boot time cpupools, Xen can
create at boot time many cpupools different from the
cpupool with id 0.
Since these newly created cpupools can'
Hi Julien,
> On 17 Nov 2021, at 11:48, Julien Grall wrote:
>
> On 17/11/2021 11:16, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi,
>
>>> On 17 Nov 2021, at 10:26, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 17/11/2021 09:57, Luca Fancellu wrote:
Currently Xen creates a default cpupo
On Wed, Nov 17, 2021 at 12:44:25PM +0100, Michal Orzel wrote:
> Hi,
>
> On 17.11.2021 11:00, Julien Grall wrote:
> > Hi,
> >
> > On 17/11/2021 09:53, Roger Pau Monne wrote:
> >> Document some of the relevant changes during the 4.16 release cycle,
> >> likely more entries are missing.
> >>
> >> Si
The designated maintainer email address for the remus entry is
bouncing, so remove it and declare the entry as orphaned as there's no
other maintainer.
Signed-off-by: Roger Pau Monné
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
i
flight 166159 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166159/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 166155
test-amd64-amd64-xl-qemuu-win7-amd6
Roger Pau Monne writes ("[PATCH for-4.16] MAINTAINERS: declare REMUS support
orphaned"):
> The designated maintainer email address for the remus entry is
> bouncing, so remove it and declare the entry as orphaned as there's no
> other maintainer.
Hrm, :-(.
Acked-by: Ian Jackson
On 17/11/2021 11:23, Jan Beulich wrote:
On 17.11.2021 12:09, Andrew Cooper wrote:
On 17/11/2021 10:13, Jan Beulich wrote:
On 17.11.2021 09:55, Roger Pau Monné wrote:
On Wed, Nov 17, 2021 at 09:39:17AM +0100, Jan Beulich wrote:
On 13.09.2021 11:02, Jan Beulich wrote:
libxl__domain_config_setd
On 11/17/2021 3:12 AM, Borislav Petkov wrote:
What you should do, instead, is add an isol. VM specific
hv_cc_platform_has() just like amd_cc_platform_has() and handle
the cc_attrs there for your platform, like return false for
CC_ATTR_GUEST_MEM_ENCRYPT and then you won't need to add that hv_*
Hi Christoph:
Thanks for your review.
On 11/17/2021 5:59 PM, Christoph Hellwig wrote:
The subject is wrong, nothing x86-specific here. Please use
"swiotlb: " as the prefix
OK. Will update. Thanks.
+ * @vaddr: The vaddr of the swiotlb memory pool. The swiotlb
+ * memo
flight 166160 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166160/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail like
166135
test-amd64-amd64-xl-qemuu-win7-
On 11/17/2021 6:01 PM, Christoph Hellwig wrote:
This doesn't really have much to do with normal DMA mapping,
so why does this direct through the dma ops?
According to the previous discussion, dma_alloc_noncontigous()
and dma_vmap_noncontiguous() may be used to handle the noncontigous
memory al
Hi Roger,
> On 17 Nov 2021, at 09:53, Roger Pau Monne wrote:
>
> Document some of the relevant changes during the 4.16 release cycle,
> likely more entries are missing.
>
> Signed-off-by: Roger Pau Monné
> ---
> CHANGELOG.md | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a
Currently the max_store_size, remain_store_size and max_size in
compat_pf_efi_runtime_call are 4 byte aligned, which makes clang
complain with:
In file included from compat.c:30:
./runtime.c:646:13: error: passing 4-byte aligned argument to 8-byte aligned
parameter 2 of 'QueryVariableInfo' may re
On 17/11/2021 15:33, Roger Pau Monne wrote:
Currently the max_store_size, remain_store_size and max_size in
compat_pf_efi_runtime_call are 4 byte aligned, which makes clang
complain with:
In file included from compat.c:30:
./runtime.c:646:13: error: passing 4-byte aligned argument to 8-byte alig
Hi Ayan,
> On 16 Nov 2021, at 16:24, Ayan Kumar Halder
> wrote:
>
> Hi Bertrand,
>
> Thanks for looking into it.
>
> On 16/11/2021 15:36, Bertrand Marquis wrote:
>> Hi Ayan,
>>> On 16 Nov 2021, at 15:27, Ayan Kumar Halder
>>> wrote:
>>>
>>> Hi Xen/Arm experts,
>>>
>>> I am facing a very s
Roger Pau Monne writes ("[PATCH for-4.16] efi: fix alignment of function
parameters in compat mode"):
> Currently the max_store_size, remain_store_size and max_size in
> compat_pf_efi_runtime_call are 4 byte aligned, which makes clang
> complain with:
>
> In file included from compat.c:30:
> ./ru
On 11/16/21 5:33 PM, Boris Ostrovsky wrote:
On 11/16/21 11:05 AM, Jan Beulich wrote:
On 16.11.2021 16:01, Juergen Gross wrote:
On 16.11.21 15:55, Jan Beulich wrote:
On 16.11.2021 15:33, Juergen Gross wrote:
config XEN_PRIVCMD
- tristate
+ tristate "Xen hypercall passthrough dr
Andrew Cooper writes ("Re: [PATCH for-4.16] efi: fix alignment of function
parameters in compat mode"):
> This will compile, but the caller won't get any data back unless you
> copy the opposite way here...
Well spotted. I feel quite the fool!
Ian.
On 11/15/21 5:27 PM, Stefano Stabellini wrote:
From: Stefano Stabellini
In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter),
we goto out_error but we forget to reset xen_store_domain_type to
XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls
will still
flight 166168 xen-unstable-smoke real [real]
flight 166173 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166168/
http://logs.test-lab.xenproject.org/osstest/logs/166173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
Hi Bertrand,
Many thanks for your response.
On 17/11/2021 15:48, Bertrand Marquis wrote:
Hi Ayan,
On 16 Nov 2021, at 16:24, Ayan Kumar Halder
wrote:
Hi Bertrand,
Thanks for looking into it.
On 16/11/2021 15:36, Bertrand Marquis wrote:
Hi Ayan,
On 16 Nov 2021, at 15:27, Ayan Kumar Halde
Hi Ayan,
> On 17 Nov 2021, at 16:21, Ayan Kumar Halder
> wrote:
>
> Hi Bertrand,
>
> Many thanks for your response.
>
> On 17/11/2021 15:48, Bertrand Marquis wrote:
>> Hi Ayan,
>>> On 16 Nov 2021, at 16:24, Ayan Kumar Halder
>>> wrote:
>>>
>>> Hi Bertrand,
>>>
>>> Thanks for looking into
flight 166161 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
There are several cases where the act of interrupting a remote processor has
the required side effect. Explicitly allow NULL function pointers so the
calling code doesn't have to provide a stub implementation.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
T
On Wed, Nov 17, 2021 at 04:05:43PM +, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH for-4.16] efi: fix alignment of function
> parameters in compat mode"):
> > This will compile, but the caller won't get any data back unless you
> > copy the opposite way here...
>
> Well spotted. I
Hi,
I will combine my answers for this thread in one single e-mail.
On 17/11/2021 16:35, Bertrand Marquis wrote:
On 17 Nov 2021, at 16:21, Ayan Kumar Halder
wrote:
Hi Bertrand,
Many thanks for your response.
On 17/11/2021 15:48, Bertrand Marquis wrote:
Hi Ayan,
On 16 Nov 2021, at 16:24,
TLB flushing is a hotpath, and function pointer calls are
expensive (especially under repoline) for what amounts to an identity
transform on the data. Just pass the vcpu_bitmap bitmap directly.
As we use NULL for all rather than none, introduce a flush_vcpu() helper to
avoid the risk of logical e
Roger Pau Monné writes ("Re: [PATCH for-4.16] efi: fix alignment of function
parameters in compat mode [and 1 more messages]"):
> On Wed, Nov 17, 2021 at 04:05:43PM +, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH for-4.16] efi: fix alignment of function
> > parameters in compat mo
(Prunning some CC to just leave Arm and sched folks)
On 17/11/2021 12:07, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 17 Nov 2021, at 11:48, Julien Grall wrote:
On 17/11/2021 11:16, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 17 Nov 2021, at 10:26, Julien Grall wrote:
Hi Luca,
flight 166176 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166176/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Oleksandr,
On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempt
Hi Oleksandr,
On 17/11/2021 06:56, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 16.11.21 20:48, Julien Grall wrote:
Hi Oleksander,
On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
If a PCI host bridge device is present in the device tree, but is
disabled,
Hi Oleksandr,
On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
There is no reason to use void pointer while passing ECAM ops to the
pci_host_common_probe function as it is anyway casted to struct pci_ecam_ops
inside. For that reason remove the void pointer and
Hi,
On 16/11/2021 20:38, Stefano Stabellini wrote:
On Tue, 16 Nov 2021, Luca Fancellu wrote:
So I think we can queue it in the Xen on ARM temporary for-next branch.
I have pushed it to for-next/4.17 on both my repo and gitlab (hopefully
this triggered a CI run).
Cheers,
Tested in this
On 08/11/2021 09:11, Jan Beulich wrote:
On 05.11.2021 14:55, Andrew Cooper wrote:
With alternative_call() capable of handling compound types, the three
remaining hooks can be optimised at boot time too.
Signed-off-by: Andrew Cooper
---
CC: Daniel De Graaf
CC: Daniel Smith
I'm on the fence a
On 08/11/2021 09:04, Jan Beulich wrote:
On 05.11.2021 14:55, Andrew Cooper wrote:
+void __init xsm_fixup_ops(struct xsm_ops *ops)
+{
+/*
+ * We make some simplifying assumptions about struct xsm_ops; that it is
+ * made exclusively of function pointers to non-init text.
+ *
+
On 08/11/2021 09:50, Jan Beulich wrote:
On 05.11.2021 14:55, Andrew Cooper wrote:
Currently, __HYPERVISOR_xsm_op enters xsm_ops.do_{xsm,compat}_op() which means
that if any other XSM module registers a handler, we'll break the hypercall
ABI totally by having the behaviour depend on the selected
On 17/11/2021 23:14, Andrew Cooper wrote:
On 08/11/2021 09:50, Jan Beulich wrote:
On 05.11.2021 14:55, Andrew Cooper wrote:
Currently, __HYPERVISOR_xsm_op enters xsm_ops.do_{xsm,compat}_op()
which means
that if any other XSM module registers a handler, we'll break the
hypercall
ABI totally by
On 12/11/2021 09:57, Jan Beulich wrote:
On 11.11.2021 18:57, Andrew Cooper wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1234,15 +1234,18 @@ int vcpu_unpause_by_systemcontroller(struct vcpu *v)
return 0;
}
-static void do_domain_pause(struct domain *d,
-
On Wed, 17 Nov 2021, Julien Grall wrote:
> On 16/11/2021 20:38, Stefano Stabellini wrote:
> > On Tue, 16 Nov 2021, Luca Fancellu wrote:
> > So I think we can queue it in the Xen on ARM temporary for-next branch.
>
> I have pushed it to for-next/4.17 on both my repo and gitlab (hopefully this
> tri
On 12/11/2021 10:43, Jan Beulich wrote:
On 11.11.2021 18:57, Andrew Cooper wrote:
Function pointers are expensive, and the raw parameter is a constant from all
callers, meaning that it predicts very well with local branch history.
The code change is fine, but I'm having trouble with "all" here:
On Wed, 17 Nov 2021, Julien Grall wrote:
> I will combine my answers for this thread in one single e-mail.
>
> On 17/11/2021 16:35, Bertrand Marquis wrote:
> > > On 17 Nov 2021, at 16:21, Ayan Kumar Halder
> > > wrote:
> > >
> > > Hi Bertrand,
> > >
> > > Many thanks for your response.
> > >
>
On 12/11/2021 09:36, Julien Grall wrote:
On 11/11/2021 17:57, Andrew Cooper wrote:
Retpolines are expensive, and all these do are select between the
sync and
nosync helpers. Pass a boolean instead, and use direct calls
everywhere.
To be honest, I much prefer to read the old code. I am totall
On Wed, 17 Nov 2021, Julien Grall wrote:
> > > > > On 17 Nov 2021, at 10:26, Julien Grall wrote:
> > > > >
> > > > > Hi Luca,
> > > > >
> > > > > On 17/11/2021 09:57, Luca Fancellu wrote:
> > > > > > Currently Xen creates a default cpupool0 that contains all the cpu
> > > > > > brought up
> > >
On Wed, 17 Nov 2021, Jan Beulich wrote:
> On 17.11.2021 03:11, Stefano Stabellini wrote:
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -951,6 +951,18 @@ static int __init xenbus_init(void)
> > err = hvm_get_parameter(HVM_PARAM_STORE_PFN,
On Wed, 17 Nov 2021, Luca Fancellu wrote:
> Introduce an architecture specific way to create different
> cpupool at boot time, this is particularly useful on ARM
> biglittle system where there might be the need to have
> different cpupools for each type of core, but also systems
> using NUMA can ha
On Wed, 17 Nov 2021, Juergen Gross wrote:
> On 17.11.21 10:57, Luca Fancellu wrote:
> > Introduce an architecture specific way to create different
> > cpupool at boot time, this is particularly useful on ARM
> > biglittle system where there might be the need to have
> > different cpupools for each
flight 166164 linux-5.4 real [real]
flight 166181 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166164/
http://logs.test-lab.xenproject.org/osstest/logs/166181/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
On 18.11.21 04:01, Stefano Stabellini wrote:
On Wed, 17 Nov 2021, Juergen Gross wrote:
On 17.11.21 10:57, Luca Fancellu wrote:
Introduce an architecture specific way to create different
cpupool at boot time, this is particularly useful on ARM
biglittle system where there might be the need to ha
On 18.11.21 03:19, Stefano Stabellini wrote:
On Wed, 17 Nov 2021, Julien Grall wrote:
On 17 Nov 2021, at 10:26, Julien Grall wrote:
Hi Luca,
On 17/11/2021 09:57, Luca Fancellu wrote:
Currently Xen creates a default cpupool0 that contains all the cpu
brought up
during boot and it assumes that
On 18.11.21 03:37, Stefano Stabellini wrote:
On Wed, 17 Nov 2021, Jan Beulich wrote:
On 17.11.2021 03:11, Stefano Stabellini wrote:
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -951,6 +951,18 @@ static int __init xenbus_init(void)
err = hvm_
flight 166169 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166169/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 165521
test-armhf-armhf-libvirt 16
flight 166163 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 165976
test-armhf-armhf-xl
Hi Andrew,
On 2021/11/18 0:48, Andrew Cooper wrote:
There are several cases where the act of interrupting a remote processor has
the required side effect. Explicitly allow NULL function pointers so the
calling code doesn't have to provide a stub implementation.
Signed-off-by: Andrew Cooper
--
Hi, Julien!
On 16.11.21 21:22, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Currently Xen maps all IRQs and memory ranges for all devices except
>> those marked for passthrough, e.g. it doesn't pay attention to
On 2021/11/17 16:00, Jan Beulich wrote:
I'm puzzled about two inconsistencies with other alternative_vcall()
here: There's a check missing that the supplied function pointer is
actually pointing to a function taking no args. And there's a pointless
pair of parentheses. Correct both.
Fixes: 67
Hi, Julien!
On 17.11.21 23:33, Julien Grall wrote:
> Hi Oleksandr,
>
> On 17/11/2021 06:56, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 16.11.21 20:48, Julien Grall wrote:
>>> Hi Oleksander,
>>>
>>> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, Julien!
On 16.11.21 21:12, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> In order for vPCI to work it needs to maintain guest and hardware
>> domain's views of the configuration space. For example, BARs and
>
Hi, Julien!
On 17.11.21 23:45, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> There is no reason to use void pointer while passing ECAM ops to the
>> pci_host_common_probe function as it is anyway casted to struct
On 17.11.21 10:28, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a vPCI is removed for a PCI device it is possible that we have
>> scheduled a delayed work for map/unmap operations for that device.
>> For example, the followi
97 matches
Mail list logo
