On 18.11.2021 19:05, Andrew Cooper wrote:
> On 18/11/2021 13:34, Jan Beulich wrote:
>> On 18.11.2021 14:20, Andrew Cooper wrote:
>>> On 18/11/2021 13:12, Jan Beulich wrote:
I've noticed the bugs fixed in patch 1 only while doing the other cleanup.
1: fix error code use
2: drop d
On 18.11.21 22:00, Stefano Stabellini wrote:
On Thu, 18 Nov 2021, Juergen Gross wrote:
On 18.11.21 09:47, Jan Beulich wrote:
On 18.11.2021 06:32, Juergen Gross wrote:
On 18.11.21 03:37, Stefano Stabellini wrote:
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@
flight 166183 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166183/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 165976
build-i386-pvops
flight 166185 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166185/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166172
test-armhf-armhf-libvirt 16 save
flight 166184 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166184/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166170
test-armhf-armhf-libvirt 16 sav
On Wed, 10 Nov 2021, Oleksandr wrote:
> On 28.10.21 04:40, Stefano Stabellini wrote:
>
> Hi Stefano
>
> I am sorry for the late response.
>
> > On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > This patch implements arch_xen_unpopulated_init() on Arm
On Tue, 9 Nov 2021, Oleksandr wrote:
> On 28.10.21 19:37, Stefano Stabellini wrote:
>
> Hi Stefano
>
> I am sorry for the late response.
>
> > On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > The main reason of this change is that unpopulated-alloc
On Thu, 11 Nov 2021, Oleksandr wrote:
> On 28.10.21 04:28, Stefano Stabellini wrote:
>
> Hi Stefano
>
> I am sorry for the late response.
>
> > On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > Read the start address of the grant table space from DT
On 11/18/21 4:00 PM, Stefano Stabellini wrote:
/*
* Avoid truncation on 32-bit.
* TODO: handle addresses >= 4G
*/
if ( v >= ~0UL ) {
err = -EINVAL;
goto out_error;
}
Since this is only relevant to 32-bit kern
On Thu, 18 Nov 2021, Juergen Gross wrote:
> On 18.11.21 09:47, Jan Beulich wrote:
> > On 18.11.2021 06:32, Juergen Gross wrote:
> > > On 18.11.21 03:37, Stefano Stabellini wrote:
> > > > --- a/drivers/xen/xenbus/xenbus_probe.c
> > > > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > > > @@ -951,6 +951,2
On 18.11.21 19:33, Roger Pau Monné wrote:
Hi Roger
On Thu, Nov 18, 2021 at 06:11:07PM +0200, Oleksandr Tyshchenko wrote:
On Wed, Nov 17, 2021 at 11:54 AM Roger Pau Monne
wrote:
Hi Roger, all
[Sorry for the possible format issues]
Document some of the relevant changes during the 4.16 rel
On 18/11/2021 18:48, Andrew Cooper wrote:
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_
On 18/11/2021 11:19, Andrew Cooper wrote:
On 18/11/2021 10:45, Jan Beulich wrote:
On 17.11.2021 19:26, Andrew Cooper wrote:
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_
On 18/11/2021 13:14, Jan Beulich wrote:
hvcall_{flush,ipi}_ex() use more almost identical code than what was
isolated into hv_vpset_to_vpmask(). Move that code there as well, to
have just one instance of it. This way all of HV_GENERIC_SET_SPARSE_4K
processing now happens in a single place.
Signe
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
On 18/11/2021 13:14, Jan Beulich wrote:
Both hvcall_flush_ex() and hvcall_ipi_ex() update "size" without
subsequently using the value; future compilers may warn about such.
Alongside dropping the updates, shrink the variables' scopes to
demonstrate that there are no outer scope uses.
Signed-off-
On 18/11/2021 13:13, Jan Beulich wrote:
Both the wrong use of HV_STATUS_* and the return type of
hv_vpset_to_vpmask() can lead to viridian_hypercall()'s
ASSERT_UNREACHABLE() triggering when translating error codes from Xen
to Viridian representation.
Fixes: b4124682db6e ("viridian: add ExProcess
On 18/11/2021 13:34, Jan Beulich wrote:
> On 18.11.2021 14:20, Andrew Cooper wrote:
>> On 18/11/2021 13:12, Jan Beulich wrote:
>>> I've noticed the bugs fixed in patch 1 only while doing the other cleanup.
>>>
>>> 1: fix error code use
>>> 2: drop dead variable updates
>>> 3: fold duplicate vpset r
On 18/11/2021 13:14, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -643,6 +647,18 @@ static int hv_vpset_to_vpmask(const stru
> {
> uint64_t bank_mask;
> unsigned int vp, bank = 0;
> +size_t size = si
On Thu, Nov 18, 2021 at 09:23:40AM -0800, Stefano Stabellini wrote:
> On Wed, 17 Nov 2021, 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 +++
On Thu, Nov 18, 2021 at 06:11:07PM +0200, Oleksandr Tyshchenko wrote:
> On Wed, Nov 17, 2021 at 11:54 AM Roger Pau Monne
> wrote:
>
> Hi Roger, all
>
> [Sorry for the possible format issues]
>
> Document some of the relevant changes during the 4.16 release cycle,
> > likely more entries are mis
On 18/11/2021 09:07, Jan Beulich wrote:
> On 18.11.2021 10:06, Jan Beulich wrote:
>> On 18.11.2021 01:32, Andrew Cooper wrote:
>>> 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
I like all your suggestions below!
On Thu, 18 Nov 2021, Juergen Gross wrote:
> 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 Wed, 17 Nov 2021, 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/CHAN
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> Since v3:
> - make use of VPCI_INIT
> - moved all new code to vpci.c which belongs to it
> - changed open-coded 31 to PCI_SLOT(~0)
> - revisited locking: add dedicated vdev list's lock
What is this about? I can't spot any locking in the pat
On Wed, Nov 17, 2021 at 11:54 AM Roger Pau Monne
wrote:
Hi Roger, all
[Sorry for the possible format issues]
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 fi
On 18.11.2021 16:46, Oleksandr Andrushchenko wrote:
> On 18.11.21 17:41, Jan Beulich wrote:
>> On 18.11.2021 16:21, Oleksandr Andrushchenko wrote:
>>> On 18.11.21 17:16, Jan Beulich wrote:
For the moment I can't help thinking that draining would
be preferable over canceling.
>>> Given
On 18.11.21 17:41, Jan Beulich wrote:
> On 18.11.2021 16:21, Oleksandr Andrushchenko wrote:
>> On 18.11.21 17:16, Jan Beulich wrote:
>>> On 18.11.2021 16:11, Oleksandr Andrushchenko wrote:
On 18.11.21 16:35, Jan Beulich wrote:
> On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
>>
On 18.11.2021 16:21, Oleksandr Andrushchenko wrote:
> On 18.11.21 17:16, Jan Beulich wrote:
>> On 18.11.2021 16:11, Oleksandr Andrushchenko wrote:
>>> On 18.11.21 16:35, Jan Beulich wrote:
On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
> On 18.11.21 16:04, Roger Pau Monné wrote:
>
On Wed, Nov 17, 2021 at 9:11 PM Julien Grall wrote:
Hi Julien, all
[Sorry for the possible format issues]
(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 18.11.21 17:16, Jan Beulich wrote:
> On 18.11.2021 16:11, Oleksandr Andrushchenko wrote:
>>
>> On 18.11.21 16:35, Jan Beulich wrote:
>>> On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
On 18.11.21 16:04, Roger Pau Monné wrote:
> Indeed. In the physdevop failure case this comes fro
On 18.11.2021 16:11, Oleksandr Andrushchenko wrote:
>
>
> On 18.11.21 16:35, Jan Beulich wrote:
>> On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
>>> On 18.11.21 16:04, Roger Pau Monné wrote:
Indeed. In the physdevop failure case this comes from an hypercall
context, so maybe you c
On 18.11.21 16:35, Jan Beulich wrote:
> On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
>> On 18.11.21 16:04, Roger Pau Monné wrote:
>>> Indeed. In the physdevop failure case this comes from an hypercall
>>> context, so maybe you could do the mapping in place using hypercall
>>> continuations
> On 18 Nov 2021, at 11:28, Julien Grall wrote:
>
>
>
> On 18/11/2021 11:14, Bertrand Marquis wrote:
>> Hi Roger,
>>> On 18 Nov 2021, at 10:37, Roger Pau Monné wrote:
>>>
>>> On Thu, Nov 18, 2021 at 10:01:08AM +, Bertrand Marquis wrote:
Hi Roger,
> On 18 Nov 2021, a
On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
> On 18.11.21 16:04, Roger Pau Monné wrote:
>> Indeed. In the physdevop failure case this comes from an hypercall
>> context, so maybe you could do the mapping in place using hypercall
>> continuations if required. Not sure how complex that would
On 18.11.21 16:04, Roger Pau Monné wrote:
> Sorry, I've been quite busy with other staff.
>
> On Thu, Nov 18, 2021 at 01:48:06PM +, Oleksandr Andrushchenko wrote:
>>
>> On 18.11.21 15:25, Jan Beulich wrote:
>>> On 18.11.2021 10:32, Oleksandr Andrushchenko wrote:
On 18.11.21 11:15, Jan Be
Sorry, I've been quite busy with other staff.
On Thu, Nov 18, 2021 at 01:48:06PM +, Oleksandr Andrushchenko wrote:
>
>
> On 18.11.21 15:25, Jan Beulich wrote:
> > On 18.11.2021 10:32, Oleksandr Andrushchenko wrote:
> >>
> >> On 18.11.21 11:15, Jan Beulich wrote:
> >>> On 18.11.2021 09:54, Ol
On 18.11.21 15:25, Jan Beulich wrote:
> On 18.11.2021 10:32, Oleksandr Andrushchenko wrote:
>>
>> On 18.11.21 11:15, Jan Beulich wrote:
>>> On 18.11.2021 09:54, Oleksandr Andrushchenko wrote:
On 18.11.21 10:36, Jan Beulich wrote:
> On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
On 18.11.2021 14:20, Andrew Cooper wrote:
> On 18/11/2021 13:12, Jan Beulich wrote:
>> I've noticed the bugs fixed in patch 1 only while doing the other cleanup.
>>
>> 1: fix error code use
>> 2: drop dead variable updates
>> 3: fold duplicate vpset retrieval code
>
> Oh, nice. This makes it rath
On 18.11.2021 10:32, Oleksandr Andrushchenko wrote:
>
>
> On 18.11.21 11:15, Jan Beulich wrote:
>> On 18.11.2021 09:54, Oleksandr Andrushchenko wrote:
>>> On 18.11.21 10:36, Jan Beulich wrote:
On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
> On 17.11.21 10:28, Jan Beulich wrote:
>>>
On 18/11/2021 13:12, Jan Beulich wrote:
> I've noticed the bugs fixed in patch 1 only while doing the other cleanup.
>
> 1: fix error code use
> 2: drop dead variable updates
> 3: fold duplicate vpset retrieval code
Oh, nice. This makes it rather easier to do the flush short-circuit for
HV_GENERI
hvcall_{flush,ipi}_ex() use more almost identical code than what was
isolated into hv_vpset_to_vpmask(). Move that code there as well, to
have just one instance of it. This way all of HV_GENERIC_SET_SPARSE_4K
processing now happens in a single place.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86
Both hvcall_flush_ex() and hvcall_ipi_ex() update "size" without
subsequently using the value; future compilers may warn about such.
Alongside dropping the updates, shrink the variables' scopes to
demonstrate that there are no outer scope uses.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/v
Both the wrong use of HV_STATUS_* and the return type of
hv_vpset_to_vpmask() can lead to viridian_hypercall()'s
ASSERT_UNREACHABLE() triggering when translating error codes from Xen
to Viridian representation.
Fixes: b4124682db6e ("viridian: add ExProcessorMasks variants of the flush
hypercalls"
I've noticed the bugs fixed in patch 1 only while doing the other cleanup.
1: fix error code use
2: drop dead variable updates
3: fold duplicate vpset retrieval code
Jan
On 18.11.2021 00:20, Andrew Cooper wrote:
> 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:
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -22,6 +22,8 @@
#include
#incl
On 18.11.2021 00: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
>>
Hi, Julien!
On 16.11.21 20:02, Julien Grall wrote:
> Hi Oleksandr,
>
> On 16/11/2021 14:24, Oleksandr Andrushchenko wrote:
>>
>>
>> On 16.11.21 16:12, Jan Beulich wrote:
>>> On 16.11.2021 14:41, Oleksandr Andrushchenko wrote:
On 16.11.21 10:23, Oleksandr Andrushchenko wrote:
> On 16.
flight 166182 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166182/
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
On 17.11.2021 23:37, Andrew Cooper wrote:
> 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
>>> + *
On 18/11/2021 11:14, Bertrand Marquis wrote:
Hi Roger,
On 18 Nov 2021, at 10:37, Roger Pau Monné wrote:
On Thu, Nov 18, 2021 at 10:01:08AM +, Bertrand Marquis wrote:
Hi Roger,
On 18 Nov 2021, at 08:58, Roger Pau Monné wrote:
On Wed, Nov 17, 2021 at 02:07:50PM +, Bertrand Marq
On 18/11/2021 10:45, Jan Beulich wrote:
> On 17.11.2021 19:26, Andrew Cooper wrote:
>> 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
Hi Roger,
> On 18 Nov 2021, at 10:37, Roger Pau Monné wrote:
>
> On Thu, Nov 18, 2021 at 10:01:08AM +, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>
>>> On 18 Nov 2021, at 08:58, Roger Pau Monné wrote:
>>>
>>> On Wed, Nov 17, 2021 at 02:07:50PM +, Bertrand Marquis wrote:
Hi Roger,
On 18/11/2021 10:20, Roger Pau Monné wrote:
> On Thu, Nov 18, 2021 at 10:46:32AM +0100, Jan Beulich wrote:
>> On 18.11.2021 09:28, 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
>>> 13.0
On 18.11.2021 11:20, Roger Pau Monné wrote:
> On Thu, Nov 18, 2021 at 10:46:32AM +0100, Jan Beulich wrote:
>> On 18.11.2021 09:28, 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
>>> 13.0
On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
> 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
>>> do
On 17.11.2021 19:26, Andrew Cooper wrote:
> 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
On Thu, Nov 18, 2021 at 10:01:08AM +, Bertrand Marquis wrote:
> Hi Roger,
>
>
> > On 18 Nov 2021, at 08:58, Roger Pau Monné wrote:
> >
> > On Wed, Nov 17, 2021 at 02:07:50PM +, Bertrand Marquis wrote:
> >> Hi Roger,
> >>
> >>> On 17 Nov 2021, at 09:53, Roger Pau Monne wrote:
> >>>
>
On 18/11/2021 09:58, Jan Beulich wrote:
> On 17.11.2021 17: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 implementat
On 18/11/2021 06:51, Wei Chen wrote:
> 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
On Thu, Nov 18, 2021 at 10:46:32AM +0100, Jan Beulich wrote:
> On 18.11.2021 09:28, 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
> > 13.0.0 complain with:
> >
> > In file included fro
Hi Roger,
> On 18 Nov 2021, at 08:58, Roger Pau Monné wrote:
>
> On Wed, Nov 17, 2021 at 02:07:50PM +, Bertrand Marquis wrote:
>> 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
On 17.11.2021 17: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
> ---
On 18.11.2021 07:51, Wei Chen wrote:
> On 2021/11/18 0:48, Andrew Cooper wrote:
>> --- a/xen/common/smp.c
>> +++ b/xen/common/smp.c
>> @@ -87,10 +87,14 @@ void smp_call_function_interrupt(void)
>>
>> irq_enter();
>>
>> +if ( unlikely(!func) )
>> +goto no_func;
>> +
>>
On 18.11.2021 10:34, Roger Pau Monné wrote:
> On Thu, Nov 18, 2021 at 09:51:52AM +0100, Jan Beulich wrote:
>> On 18.11.2021 09:33, Roger Pau Monné wrote:
>>> On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote:
On 04.11.2021 11:48, Andrew Cooper wrote:
> If your answer is "well act
On 18.11.2021 09:28, 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
> 13.0.0 complain with:
>
> In file included from compat.c:30:
> ./runtime.c:646:13: error: passing 4-byte aligned argume
flight 166172 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166172/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166160
test-amd64-amd64-qemuu-nested-amd 20
On Thu, Nov 18, 2021 at 09:51:52AM +0100, Jan Beulich wrote:
> On 18.11.2021 09:33, Roger Pau Monné wrote:
> > On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote:
> >> On 04.11.2021 11:48, Andrew Cooper wrote:
> >>> If your answer is "well actually, we didn't mean to say 'if a GSI is
> >>>
On 18.11.21 11:15, Jan Beulich wrote:
> On 18.11.2021 09:54, Oleksandr Andrushchenko wrote:
>> On 18.11.21 10:36, Jan Beulich wrote:
>>> On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
On 17.11.21 10:28, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>
Hi Andrew,
On 18/11/2021 01:47, Andrew Cooper wrote:
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
flight 166170 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166170/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166159
test-armhf-armhf-libvirt 16 sav
On 18.11.2021 09:54, Oleksandr Andrushchenko wrote:
> On 18.11.21 10:36, Jan Beulich wrote:
>> On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
>>> On 17.11.21 10:28, Jan Beulich wrote:
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When
On 18.11.2021 10:06, Jan Beulich wrote:
> On 18.11.2021 01:32, Andrew Cooper wrote:
>> 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 predict
On 18.11.2021 01:32, Andrew Cooper wrote:
> 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 c
On Wed, Nov 17, 2021 at 02:07:50PM +, Bertrand Marquis wrote:
> 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é
> > ---
On 18.11.21 10:36, Jan Beulich wrote:
> On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
>>
>> 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
On 18.11.21 09:47, Jan Beulich wrote:
On 18.11.2021 06:32, Juergen Gross wrote:
On 18.11.21 03:37, Stefano Stabellini wrote:
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -951,6 +951,28 @@ static int __init xenbus_init(void)
err = hvm_get_par
On 18.11.2021 09:33, Roger Pau Monné wrote:
> On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote:
>> On 04.11.2021 11:48, Andrew Cooper wrote:
>>> If your answer is "well actually, we didn't mean to say 'if a GSI is
>>> mapped' in the comment, and here's a different predicate which actuall
On 18.11.2021 06:32, Juergen Gross wrote:
> On 18.11.21 03:37, Stefano Stabellini wrote:
>> --- a/drivers/xen/xenbus/xenbus_probe.c
>> +++ b/drivers/xen/xenbus/xenbus_probe.c
>> @@ -951,6 +951,28 @@ static int __init xenbus_init(void)
>> err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v)
On 2021/11/17 22:07, Bertrand Marquis wrote:
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
On 18.11.2021 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)
>>>
On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
>
>
> 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 ma
On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote:
> On 04.11.2021 11:48, Andrew Cooper wrote:
> > If your answer is "well actually, we didn't mean to say 'if a GSI is
> > mapped' in the comment, and here's a different predicate which actually
> > inspects the state of a dpci object for v
Currently the max_store_size, remain_store_size and max_size in
compat_pf_efi_runtime_call are 4 byte aligned, which makes clang
13.0.0 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'
On 16.11.21 11:45, Oleksandr Andrushchenko wrote:
Hi, Geert!
On 16.11.21 11:36, Geert Uytterhoeven wrote:
Hi Oleksandr,
On Thu, Oct 28, 2021 at 8:15 AM Oleksandr Andrushchenko
wrote:
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be
On 17.11.2021 14:07, Andrew Cooper wrote:
> 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
86 matches
Mail list logo
