On Fri, Nov 19, 2021 at 08:47:49AM -0800, Dave Hansen wrote:
> On 11/19/21 7:39 AM, Juergen Gross wrote:
> > The prototype of mem_map_via_hcall() is missing in its header, so add
> > it.
> >
> > Reported-by: kernel test robot
> > Fixes: a43fb7da53007e67ad ("xen/pvh: Move Xen code for getting mem
flight 166194 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166194/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166188
test-amd64-amd64-qemuu-nested-amd
On Fri, 19 Nov 2021, Oleksandr wrote:
> On 19.11.21 03:19, Stefano Stabellini wrote:
> > 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
Juergen please see the bottom of the email
On Fri, 19 Nov 2021, Oleksandr wrote:
> On 19.11.21 02:59, Stefano Stabellini wrote:
> > 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.
> > >
flight 166193 xen-4.14-testing real [real]
flight 166202 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166193/
http://logs.test-lab.xenproject.org/osstest/logs/166202/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Fri, 19 Nov 2021, Ayan Kumar Halder wrote:
> At present, post indexing instructions are not emulated by Xen.
> When Xen gets the exception, EL2_ESR.ISV bit not set. Thus as a
> result, data abort is triggered.
>
> Added the logic to decode ldr/str post indexing instructions.
> With this, Xen
On 11/19/21 3:29 PM, Stefano Stabellini wrote:
From: Stefano Stabellini
If the xenstore page hasn't been allocated properly, reading the value
of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return
error. Instead, it will succeed and return zero. Instead of attempting
to
On 11/19/21 10:39 AM, Juergen Gross wrote:
The prototype of mem_map_via_hcall() is missing in its header, so add
it.
Reported-by: kernel test robot
Fixes: a43fb7da53007e67ad ("xen/pvh: Move Xen code for getting mem map via hcall out
of common file")
Signed-off-by: Juergen Gross
flight 166197 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166197/
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
From: Stefano Stabellini
If the xenstore page hasn't been allocated properly, reading the value
of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return
error. Instead, it will succeed and return zero. Instead of attempting
to xen_remap a bad guest physical address, detect this
On 19.11.21 03:19, Stefano Stabellini wrote:
Hi Stefano
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
flight 166192 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166192/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 166169
test-armhf-armhf-libvirt-qcow2
On Fri, 19 Nov 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 18/11/2021 02: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
On 19.11.21 02:32, Stefano Stabellini wrote:
Hi Stefano
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
There is also a lot of redundancy in the table. 8 vectors head to do_trap(),
3 are handled in the IST logic, and that only leaves 7 others not heading to
the do_reserved_trap() catch-all. This also removes the fragility that any
accidental NULL entry in the table becomes a ticking timebomb.
do{_reserved,}_trap() should use fatal_trap() rather than opencoding part of
it. This lets the remote stack trace logic work in more fatal error
conditions.
With do_trap() converted, there is only one single user of trapstr()
remaining. Tweak the formatting in pv_inject_event(), and remove
The unconditional nmi_callback() call in do_nmi() calls dummy_nmi_callback()
in all cases other than for a few specific and rare tasks (alternative
patching, microcode loading, etc).
Indirect calls are expensive under retpoline, so rearrange the logic to use
NULL as the default, and skip the call
NMI hooking in the crash path has undergone several revisions since its
introduction. What we have now is not sufficiently different from the regular
nmi_callback() mechanism to warrant special casing.
Use set_nmi_callback() directly, and do away with patching a read-only data
structure via a
This causes NMIs, #DB and #MC to be counted, rather than being reported as 0.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/x86_64/entry.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/x86/x86_64/entry.S
Andrew Cooper (5):
x86/traps: Collect PERFC_exceptions stats for IST vectors too
x86/traps: Drop dummy_nmi_callback()
x86/crash: Drop manual hooking of exception_table[]
x86/traps: Drop exception_table[] and use if/else dispatching
x86/traps: Clean up diagnostics
xen/arch/x86/crash.c
On 19.11.21 02:59, Stefano Stabellini wrote:
Hi Stefano
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
flight 166195 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166195/
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
Hi Stefano,
On 18/11/2021 02: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
Hi Ayan,
On 19/11/2021 16:52, Ayan Kumar Halder wrote:
At present, post indexing instructions are not emulated by Xen.
Can you explain in the commit message why this is a problem?
When Xen gets the exception, EL2_ESR.ISV bit not set. Thus as a
result, data abort is triggered.
Added the
Andrew Cooper writes ("Re: Xen 4.16 development update - tree status"):
> On 19/11/2021 15:15, Ian Jackson wrote:
> > Open issues and potential blockers
> > ==
Thanks, Andrew, for this helpful information.
> > I am aware of three issues for which I don't know the
Andrew Cooper writes ("Re: [PATCH for-4.16 v3] efi: fix alignment of function
parameters in compat mode"):
> Some hardtabs appear to have slipped in.
Thanks. Fixed.
> Jan gave a conditional R-by which permitted a change along these lines,
> but he's left the office now too, so you'll have to
Hi Stefano/Julien/Bertrand,
Thanks a lot for your inputs.
On 18/11/2021 01:11, Stefano Stabellini wrote:
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
At present, post indexing instructions are not emulated by Xen.
When Xen gets the exception, EL2_ESR.ISV bit not set. Thus as a
result, data abort is triggered.
Added the logic to decode ldr/str post indexing instructions.
With this, Xen can decode instructions like these:-
ldr w2, [x1], #4
Thus,
On 11/19/21 7:39 AM, Juergen Gross wrote:
> The prototype of mem_map_via_hcall() is missing in its header, so add
> it.
>
> Reported-by: kernel test robot
> Fixes: a43fb7da53007e67ad ("xen/pvh: Move Xen code for getting mem map via
> hcall out of common file")
> Signed-off-by: Juergen Gross
$
flight 166190 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166190/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 165976
Tests which did not
On 19/11/2021 15:24, Ian Jackson wrote:
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index 375b94229e..089bb0eb1b 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -638,16 +641,36 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
>
>
On 19/11/2021 15:15, Ian Jackson wrote:
> Open issues and potential blockers
> ==
>
> I am aware of three issues for which I don't know the current
> disposition:
>
> * "x86/IOMMU: enabled / intremap handling"
> 3/3 "AMD/IOMMU: iommu_enable vs iommu_intremap"
>
The prototype of mem_map_via_hcall() is missing in its header, so add
it.
Reported-by: kernel test robot
Fixes: a43fb7da53007e67ad ("xen/pvh: Move Xen code for getting mem map via
hcall out of common file")
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/hypervisor.h | 1 +
1 file
From: Roger Pau Monne
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
Tree status
===
We are now in deep code freeze, during which we will try to discover
and eliminate serious bugs and regressions.
All patches other than documentation patches need a Release-Ack.
Fixes for serious bugs, and test improvements, will get such an ack.
I have decided to branch
Nick Rosbrook writes ("Re: [XEN PATCH for-4.16] golang/xenlight: regen
generated code"):
> Acked-by: Nick Rosbrook
Thanks all.
Acked-by: Ian Jackson
Release-Acked-by: Ian Jackson
and pushed.
Ian.
On 19.11.21 16:23, Roger Pau Monné wrote:
> On Fri, Nov 19, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Hi, all!
>>>
>>> This patch series is focusing on vPCI and adds support for non-identity
>>>
Jan Beulich writes ("[PATCH 0/7] (mainly) xz imports from Linux"):
> While going through their 5.15.3 log I did notice two changes, which made
> me go check what else we might be missing. The series here is the result.
> Linux has also updated zstd, but that includes a pretty large change which
>
On 11/17/2021 10:00 PM, Tianyu Lan wrote:
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
On Fri, Nov 19, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko
> >
> > Hi, all!
> >
> > This patch series is focusing on vPCI and adds support for non-identity
> > PCI BAR mappings which is required while
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28710 / XSA-390
certain VT-d IOMMUs may not work in shared page table mode
ISSUE DESCRIPTION
=
For efficiency reasons, address translation control structures (page
tables) may (and,
On 19.11.21 15:57, Jan Beulich wrote:
> On 19.11.2021 14:41, Oleksandr Andrushchenko wrote:
>>
>> On 19.11.21 15:16, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
@@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pdev)
On 19.11.21 15:56, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Hi, all!
>>
>> This patch series is focusing on vPCI and adds support for non-identity
>> PCI BAR mappings which is required while passing through a PCI device to
On 19/11/2021 14:01, Jan Beulich wrote:
> On 19.11.2021 14:44, Andrew Cooper wrote:
>> This is a simple comma separated list, so use the normal form.
>>
>> * Don't cease processing subsequent elements on an error
>> * Do report -EINVAL for things like `dom0_nodes=4foo`
>> * Don't opencode the
On 19.11.2021 14:44, Andrew Cooper wrote:
> This is a simple comma separated list, so use the normal form.
>
> * Don't cease processing subsequent elements on an error
> * Do report -EINVAL for things like `dom0_nodes=4foo`
> * Don't opencode the cmdline_strcmp() helper
>
> Signed-off-by:
On 19.11.2021 14:41, Oleksandr Andrushchenko wrote:
>
>
> On 19.11.21 15:16, Jan Beulich wrote:
>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>> @@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pdev)
>>> INIT_LIST_HEAD(>vpci->handlers);
>>>
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hi, all!
>
> This patch series is focusing on vPCI and adds support for non-identity
> PCI BAR mappings which is required while passing through a PCI device to
> a guest. The highlights are:
>
> - Add
This is a simple comma separated list, so use the normal form.
* Don't cease processing subsequent elements on an error
* Do report -EINVAL for things like `dom0_nodes=4foo`
* Don't opencode the cmdline_strcmp() helper
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
On 19.11.21 15:16, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> @@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pdev)
>> INIT_LIST_HEAD(>vpci->handlers);
>> spin_lock_init(>vpci->lock);
>>
>> +header = >vpci->header;
>> +for ( i =
On 19.11.21 15:29, Jan Beulich wrote:
> On 19.11.2021 14:19, Oleksandr Andrushchenko wrote:
>>
>> On 19.11.21 15:06, Jan Beulich wrote:
>>> On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
On 19.11.21 14:45, Jan Beulich wrote:
> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
On 19.11.21 15:25, Jan Beulich wrote:
> On 19.11.2021 14:16, Oleksandr Andrushchenko wrote:
>> On 19.11.21 15:00, Jan Beulich wrote:
>>> On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
Possible locking and other work needed:
===
1.
On 19.11.2021 14:19, Oleksandr Andrushchenko wrote:
>
>
> On 19.11.21 15:06, Jan Beulich wrote:
>> On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
>>> On 19.11.21 14:45, Jan Beulich wrote:
On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
> On 19.11.21 14:05, Jan Beulich wrote:
On Fri, Nov 19, 2021 at 10:29:48AM +, Anthony PERARD wrote:
> Fixes: 7379f9e10a3b ("gnttab: allow setting max version per-domain")
> Signed-off-by: Anthony PERARD
> ---
> tools/golang/xenlight/helpers.gen.go | 4
> tools/golang/xenlight/types.gen.go | 2 ++
> 2 files changed, 6
On 19.11.2021 14:16, Oleksandr Andrushchenko wrote:
> On 19.11.21 15:00, Jan Beulich wrote:
>> On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
>>> Possible locking and other work needed:
>>> ===
>>>
>>> 1. pcidevs_{lock|unlock} is too heavy and is per-host
On 19.11.21 15:06, Jan Beulich wrote:
> On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:45, Jan Beulich wrote:
>>> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
On 19.11.21 14:05, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>
On 19.11.21 15:00, Jan Beulich wrote:
> On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
>> Possible locking and other work needed:
>> ===
>>
>> 1. pcidevs_{lock|unlock} is too heavy and is per-host
>> 2. pdev->vpci->lock cannot be used as vpci is freed by
On 19.11.21 15:02, Jan Beulich wrote:
> On 19.11.2021 13:54, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:49, Jan Beulich wrote:
>>> On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
On 19.11.21 14:37, Jan Beulich wrote:
> On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
>>
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> @@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pdev)
> INIT_LIST_HEAD(>vpci->handlers);
> spin_lock_init(>vpci->lock);
>
> +header = >vpci->header;
> +for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
> +{
> +
On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
> On 19.11.21 14:45, Jan Beulich wrote:
>> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
>>> On 19.11.21 14:05, Jan Beulich wrote:
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
>
On 19.11.2021 13:54, Oleksandr Andrushchenko wrote:
> On 19.11.21 14:49, Jan Beulich wrote:
>> On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
>>> On 19.11.21 14:37, Jan Beulich wrote:
On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
> On 19.11.21 13:58, Jan Beulich wrote:
>>
On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
> Possible locking and other work needed:
> ===
>
> 1. pcidevs_{lock|unlock} is too heavy and is per-host
> 2. pdev->vpci->lock cannot be used as vpci is freed by vpci_remove_device
> 3. We may want a
On 19.11.21 14:49, Jan Beulich wrote:
> On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:37, Jan Beulich wrote:
>>> On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
On 19.11.21 13:58, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>
On 19.11.21 14:45, Jan Beulich wrote:
> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:05, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the
On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
> On 19.11.21 14:37, Jan Beulich wrote:
>> On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
>>> On 19.11.21 13:58, Jan Beulich wrote:
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/vpci/header.c
> +++
On 19.11.21 14:37, Jan Beulich wrote:
> On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
>> On 19.11.21 13:58, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device
On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
> On 19.11.21 14:05, Jan Beulich wrote:
>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Instead of handling a single range set, that contains all the memory
>>> regions of all the BARs and ROM,
On 19.11.21 14:33, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Take into account guest's BAR view and program its p2m accordingly:
>> gfn is guest's view of the BAR and mfn is the physical BAR value as set
>> up by the host
flight 166189 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166189/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166185
test-armhf-armhf-libvirt 16
On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
> On 19.11.21 13:58, Jan Beulich wrote:
>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Add relevant vpci register handlers when assigning PCI device to a domain
>>> and remove those when
Hi, Roger, Jan!
On 18.11.21 17:53, Jan Beulich wrote:
> 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
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Take into account guest's BAR view and program its p2m accordingly:
> gfn is guest's view of the BAR and mfn is the physical BAR value as set
> up by the host bridge in the hardware domain.
I'm sorry to be
On 19.11.21 14:05, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Instead of handling a single range set, that contains all the memory
>> regions of all the BARs and ROM, have them per BAR.
> Iirc Roger did indicate agreement with
On 19.11.21 13:58, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers when assigning PCI device to a domain
>> and remove those when de-assigning. This allows having different
>> handlers for
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Instead of handling a single range set, that contains all the memory
> regions of all the BARs and ROM, have them per BAR.
Iirc Roger did indicate agreement with the spitting. May I nevertheless
ask that for
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add relevant vpci register handlers when assigning PCI device to a domain
> and remove those when de-assigning. This allows having different
> handlers for different domains, e.g. hwdom and other guests.
>
>
Hi Oleksandr,
On 19/11/2021 09:34, Oleksandr wrote:
On 19.11.21 09:59, Roger Pau Monné wrote:
Hi Roger, all
On Thu, Nov 18, 2021 at 09:04:30PM +0200, Oleksandr wrote:
On 18.11.21 19:33, Roger Pau Monné wrote:
Hi Roger
On Thu, Nov 18, 2021 at 06:11:07PM +0200, Oleksandr Tyshchenko
On Fri, Nov 19, 2021 at 10:38:04AM +, Andrew Cooper wrote:
> On 19/11/2021 10:29, Anthony PERARD wrote:
> > Fixes: 7379f9e10a3b ("gnttab: allow setting max version per-domain")
> > Signed-off-by: Anthony PERARD
>
> Fixes: 1e6706b0d123 ("xen/arm: Introduce gpaddr_bits field to struct
>
On 19/11/2021 10:29, Anthony PERARD wrote:
> Fixes: 7379f9e10a3b ("gnttab: allow setting max version per-domain")
> Signed-off-by: Anthony PERARD
Fixes: 1e6706b0d123 ("xen/arm: Introduce gpaddr_bits field to struct
xen_domctl_getdomaininfo")
as well, by the looks of things.
~Andrew
Fixes: 7379f9e10a3b ("gnttab: allow setting max version per-domain")
Signed-off-by: Anthony PERARD
---
tools/golang/xenlight/helpers.gen.go | 4
tools/golang/xenlight/types.gen.go | 2 ++
2 files changed, 6 insertions(+)
diff --git a/tools/golang/xenlight/helpers.gen.go
From: Lasse Collin
This might matter, for example, if the underlying type of enum xz_check
was a signed char. In such a case the validation wouldn't have caught an
unsupported header. I don't know if this problem can occur in the kernel
on any arch but it's still good to fix it because some
From: Lasse Collin
It's a more logical place even if the resetting needs to be done
only once per LZMA2 stream (if lzma_reset() called in the middle
of an LZMA2 stream, .len will already be 0).
Link: https://lore.kernel.org/r/20211010213145.17462-4-xi...@kernel.org
Signed-off-by: Lasse Collin
From: Lasse Collin
uncompressible -> incompressible
non-splitted -> non-split
Link: https://lore.kernel.org/r/20211010213145.17462-6-xi...@kernel.org
Signed-off-by: Lasse Collin
[Linux commit: 0a434e0a2c9f4395e4560aac22677ef25ab4afd9]
Signed-off-by: Jan Beulich
--- a/xen/common/unxz.c
+++
From: Lasse Collin
With valid files, the safety margin described in lib/decompress_unxz.c
ensures that these buffers cannot overlap. But if the uncompressed size
of the input is larger than the caller thought, which is possible when
the input file is invalid/corrupt, the buffers can overlap.
From: Zhen Lei
Fix some spelling mistakes in comments:
sentinal ==> sentinel
compresed ==> compressed
immediatelly ==> immediately
dervied ==> derived
splitted ==> split
nore ==> not
independed ==> independent
asumed ==> assumed
Link:
From: Lasse Collin
s->dict.allocated was initialized to 0 but never set after a successful
allocation, thus the code always thought that the dictionary buffer has
to be reallocated.
Link: http://lkml.kernel.org/r/20191104185107.3b633...@tukaani.org
Reported-by: Yu Sun
Signed-off-by: Lasse
From: Lasse Collin
It's good style. I was also told that GCC 7 is more strict and might
give a warning when such comments are missing.
Suggested-by: Andrei Borzenkov
Signed-off-by: Lasse Collin
[Linux commit: 5a244f48ecbbd03a11eb84819c5c599db81823ee]
Signed-off-by: Jan Beulich
---
Linux has
While going through their 5.15.3 log I did notice two changes, which made
me go check what else we might be missing. The series here is the result.
Linux has also updated zstd, but that includes a pretty large change which
I'm not ready to deal with right now. Them moving closer to the upstream
flight 166188 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166188/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166184
test-armhf-armhf-libvirt 16
On 19.11.21 09:59, Roger Pau Monné wrote:
Hi Roger, all
On Thu, Nov 18, 2021 at 09:04:30PM +0200, Oleksandr wrote:
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
flight 166191 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166191/
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 18.11.2021 23:24, Boris Ostrovsky wrote:
> 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
On Thu, Nov 18, 2021 at 09:04:30PM +0200, Oleksandr wrote:
>
> 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
>
92 matches
Mail list logo
