flight 150313 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150313/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a2ad3ba9efdd0db4bf1b6c114eedb59d6c483ca
baseline version:
ovmf
On Thu, 21 May 2020, Julien Grall wrote:
> Hi,
>
> On 21/05/2020 00:45, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
> > instead. It will be useful not to have a start_dma_addr around with the
> > next patches.
>
flight 150310 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150310/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 150281
Tests which did
On Thu, 21 May 2020, Julien Grall wrote:
> Hi,
>
> On 21/05/2020 00:45, Stefano Stabellini wrote:
> > From: Boris Ostrovsky
> >
> > Don't just assume that virt_to_page works on all virtual addresses.
> > Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
> > virt addresses.
> @@ -1057,7 +1063,7 @@ static int xen_translate_vdev(int vdevice, int *minor,
> unsigned int *offset)
> case XEN_SCSI_DISK5_MAJOR:
> case XEN_SCSI_DISK6_MAJOR:
> case XEN_SCSI_DISK7_MAJOR:
> - *offset = (*minor / PARTS_PER_DISK) +
>
On 21/05/2020 22:43, Igor Druzhinin wrote:
> If a recalculation NPT fault hasn't been handled explicitly in
> hvm_hap_nested_page_fault() then it's potentially safe to retry -
> US bit has been re-instated in PTE and any real fault would be correctly
> re-raised next time.
>
> This covers a
From: Munehisa Kamata
S4 power transisiton states are much different than xen
suspend/resume. Former is visible to the guest and frontend drivers should
be aware of the state transistions and should be able to take appropriate
actions when needed. In transition to S4 we need to make sure that at
flight 150308 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150308/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150229
test-amd64-amd64-xl-qemuu-win7-amd64 17
flight 150297 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
150271
Tests
> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
> index 000e14af49..3814795e3f 100644
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -256,6 +256,10 @@ void vmx_intr_assist(void)
> if ( unlikely(v->arch.vm_event) &&
On 5/20/20 7:45 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Call dma_to_phys in is_xen_swiotlb_buffer.
> Call phys_to_dma in xen_phys_to_bus.
> Call dma_to_phys in xen_bus_to_phys.
>
> Everything is taken care of by these changes except for
> xen_swiotlb_alloc_coherent and
Toolstack side for creating forks with interrupt injection disabled.
Signed-off-by: Tamas K Lengyel
---
tools/libxc/include/xenctrl.h | 3 ++-
tools/libxc/xc_memshr.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h
When running shallow forks without device models it may be undesirable for Xen
to inject interrupts. With Windows forks we have observed the kernel going into
infinite loops when trying to process such interrupts. By disabling interrupt
injection the fuzzer can exercise the target code without
flight 150300 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150300/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 74f90d38c446e247469e2a775970eeed89216909
baseline version:
ovmf
On 5/21/20 2:46 PM, Marek Marczykowski-Górecki wrote:
> On Thu, May 21, 2020 at 01:22:03PM -0400, Boris Ostrovsky wrote:
>> On 3/19/20 3:14 AM, Juergen Gross wrote:
>>> There have been reports of races in evtchn_from_irq() where the info
>>> pointer has been NULL.
>>>
>>> Avoid that case by
If a recalculation NPT fault hasn't been handled explicitly in
hvm_hap_nested_page_fault() then it's potentially safe to retry -
US bit has been re-instated in PTE and any real fault would be correctly
re-raised next time.
This covers a specific case of migration with vGPU assigned on AMD:
global
flight 150296 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150296/
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. 150281
Tests which did
On Thu, 21 May 2020 at 21:08, Stefano Stabellini wrote:
>
> On Thu, 21 May 2020, Julien Grall wrote:
> > > @@ -97,8 +98,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
> > >phys_addr_t phys,
> > >dma_addr_t dev_addr)
> > > {
> > > - unsigned
On Tue, 19 May 2020, Julien Grall wrote:
> From: Julien Grall
>
> Hi all,
>
> At the moment, a user who wants to boot Xen on the Raspberry Pi 4 can
> only use the first GB of memory.
>
> This is because several devices cannot DMA above 1GB but Xen doesn't
> necessarily allocate memory for Dom0
On Thu, 21 May 2020, Julien Grall wrote:
> > @@ -97,8 +98,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
> >phys_addr_t phys,
> >dma_addr_t dev_addr)
> > {
> > - unsigned int xen_pfn = XEN_PFN_DOWN(phys);
> > - unsigned int bfn =
On Tue, Apr 28, 2020 at 03:36:40PM +, Wei Liu wrote:
> All callers within the same file pass in -1 (no override).
>
> Signed-off-by: Wei Liu
Applied to pci/virtualization for v5.8, thanks!
I don't see anything else in linux-next that touches this file, but if
somebody wants to merge this
From: Stefano Stabellini
Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
max allowed by the protocol.
We can't assume that all backends will support order 9. The xenstore
property max-ring-page-order specifies the max order supported by the
backend. We'll use
On Thu, May 21, 2020 at 01:22:03PM -0400, Boris Ostrovsky wrote:
> On 3/19/20 3:14 AM, Juergen Gross wrote:
> > There have been reports of races in evtchn_from_irq() where the info
> > pointer has been NULL.
> >
> > Avoid that case by testing info before dereferencing it.
> >
> > In order to avoid
On Thu, 21 May 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 20/05/2020 23:13, Stefano Stabellini wrote:
> > On Mon, 18 May 2020, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Hi all,
> > >
> > > At the moment, a user who wants to boot Xen on the Raspberry Pi 4 can
> > > only use
Hi Stefano,
On 20/05/2020 23:13, Stefano Stabellini wrote:
On Mon, 18 May 2020, Julien Grall wrote:
From: Julien Grall
Hi all,
At the moment, a user who wants to boot Xen on the Raspberry Pi 4 can
only use the first GB of memory.
This is because several devices cannot DMA above 1GB but Xen
On 4/28/20 11:36 AM, Wei Liu wrote:
> All callers within the same file pass in -1 (no override).
>
> Signed-off-by: Wei Liu
Reviewed-by: Boris Ostrovsky
On 3/19/20 3:14 AM, Juergen Gross wrote:
> There have been reports of races in evtchn_from_irq() where the info
> pointer has been NULL.
>
> Avoid that case by testing info before dereferencing it.
>
> In order to avoid accessing a just freed info structure do the kfree()
> via kfree_rcu().
On 05/05/2020 07:16, Jan Beulich wrote:
> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> expensive (but still needed only for the toggle_guest_mode() path), the
> effect of the latter on the exit-to-guest path is not insignificant.
> Move the logic into
On 21/05/2020 09:45, Roger Pau Monné wrote:
> On Wed, May 20, 2020 at 10:30:11PM +0100, Andrew Cooper wrote:
>> On 15/05/2020 14:58, Roger Pau Monne wrote:
>>> Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
>>> BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
>>>
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
Reviewed-by: Julien Grall
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Stefano Stabellini
v4:
- Add missing
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
Acked-by: Ian Jackson
---
Cc: Andrew Cooper
Cc: Wei Liu
NOTE: Ian requested ack from Andrew
v3:
- Re-worked to avoid
From: Paul Durrant
Paul Durrant (5):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-domctx to present domain context
common/domain: add a domain context record for
... in the save/restore code.
This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.
No modifications are made to the definition of the migration stream at
this point. Subsequent patches will
flight 150294 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150294/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail in 150273 pass in 150294
test-amd64-amd64-xl-rtds 15
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: The domain may or may not be using the embedded vcpu_info array so
ultimately separate context records will be added for vcpu_info when
this becomes necessary.
Signed-off-by: Paul
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a
Hi,
On 21/05/2020 17:00, Paul Durrant wrote:
-Original Message-
From: Paul Durrant
Sent: 21 May 2020 16:26
To: 'Julien Grall' ; xen-devel@lists.xenproject.org
Cc: 'Paul Durrant' ; 'Ian Jackson'
; 'Wei Liu'
; 'Andrew Cooper' ; 'George Dunlap'
;
'Jan Beulich' ; 'Stefano Stabellini'
> -Original Message-
> From: Paul Durrant
> Sent: 21 May 2020 16:26
> To: 'Julien Grall' ; xen-devel@lists.xenproject.org
> Cc: 'Paul Durrant' ; 'Ian Jackson'
> ; 'Wei Liu'
> ; 'Andrew Cooper' ; 'George Dunlap'
> ;
> 'Jan Beulich' ; 'Stefano Stabellini'
>
> Subject: RE: [PATCH v4 4/5]
> When generating documentation, pkg.go.dev and godoc.org assume a comment
> that immediately precedes the package declaration is a "package
> comment", and should be shown in the documentation. Add an empty line
> after the DO NOT EDIT comment in generated files to prevent these
> comments from
The reserved_bit_page_fault() paths effectively turn reserved bit faults into
a warning, but in the light of L1TF, the real impact is far more serious.
Make #PF[Rsvd] a hard error, irrespective of mode. Any new panic() caused by
this constitutes pagetable corruption, and probably an L1TF gadget
> -Original Message-
[snip]
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 7cc9526139..14e96c3bc2 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -33,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
>
Hi Paul,
On 21/05/2020 09:59, Paul Durrant wrote:
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: The domain may or may not be using the embedded vcpu_info array so
ultimately separate context records will be added for vcpu_info when
Hi Paul,
On 21/05/2020 09:59, Paul Durrant wrote:
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 21/05/2020 09:59, Paul Durrant wrote:
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via
When generating documentation, pkg.go.dev and godoc.org assume a comment
that immediately precedes the package declaration is a "package
comment", and should be shown in the documentation. Add an empty line
after the DO NOT EDIT comment in generated files to prevent these
comments from appearing
On 08/05/20 12:02, Philippe Mathieu-Daudé wrote:
> This code is not related to hardware emulation.
> Move it under accel/ with the other hypervisors.
>
> Reviewed-by: Paul Durrant
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> We could also move the memory management functions from
>
> -Original Message-
> From: George Dunlap
> Sent: 21 May 2020 15:22
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Paul Durrant ;
> Nick Rosbrook
>
> Subject: [PATCH] CHANGELOG: Add an entry for golang binding updates
>
> Wasn't sure whether this sort of thing was what was
Wasn't sure whether this sort of thing was what was wanted, but
thought it was worth trying.
Signed-off-by: George Dunlap
---
CC: Paul Durrant
CC: Nick Rosbrook
---
CHANGELOG.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index ccb5055c87..5aa6af612f
flight 150285 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150285/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150267
test-armhf-armhf-xl-rtds 16
On 19/05/20 06:34, Markus Armbruster wrote:
> Cédric Le Goater writes:
>
>> On 5/18/20 3:17 PM, Markus Armbruster wrote:
>>> Paolo Bonzini writes:
>>>
On 15/05/20 07:58, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Remove unnecessary casts using coccinelle
Paul Durrant writes ("[PATCH v4 5/5] tools/libxc: make use of domain context
SHARED_INFO record..."):
> ... in the save/restore code.
>
> This patch replaces direct mapping of the shared_info_frame (retrieved
> using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
> SHARED_INFO
Paul Durrant writes ("[PATCH v4 3/5] tools/misc: add xen-domctx to present
domain context"):
> This tool is analogous to 'xen-hvmctx' which presents HVM context.
> Subsequent patches will add 'dump' functions when new records are
> introduced.
This looks plausible to me.
Acked-by: Ian Jackson
On Thu, May 21, 2020 at 7:09 AM Andrew Cooper wrote:
>
> On 19/05/2020 02:54, Jason Andryuk wrote:
> > +static int connect_socket(const char *path_or_fd) {
> > +int fd;
> > +char *endptr;
> > +struct sockaddr_un addr;
> > +
> > +fd = strtoll(path_or_fd, , 0);
> > +if (*endptr
Hi Juergen,
On 19/05/2020 08:21, Juergen Gross wrote:
Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.
As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.
For custom runtime
Hi Juergen,
On 19/05/2020 08:20, Juergen Gross wrote:
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern multiple times in case
adding
flight 150293 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150293/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3f89db869028fa65a37756fd7f391cbd69f4579c
baseline version:
ovmf
On Thu, May 21, 2020 at 11:32:04AM +0100, Andrew Cooper wrote:
> On 21/05/2020 11:26, Roger Pau Monné wrote:
> > On Thu, May 21, 2020 at 10:04:28AM +0100, Andrew Cooper wrote:
> >> +static int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
> >> +
On 19/05/2020 02:54, Jason Andryuk wrote:
> +static int connect_socket(const char *path_or_fd) {
> +int fd;
> +char *endptr;
> +struct sockaddr_un addr;
> +
> +fd = strtoll(path_or_fd, , 0);
> +if (*endptr == '\0') {
> +set_nonblocking(fd, 1);
> +return fd;
> +
On 21/05/2020 11:26, Roger Pau Monné wrote:
> On Thu, May 21, 2020 at 10:04:28AM +0100, Andrew Cooper wrote:
>> When compiling with SHOPT_OUT_OF_SYNC disabled, the build fails with:
>>
>> common.c:41:12: error: ‘sh_remove_write_access_from_sl1p’ declared
>> ‘static’ but never defined
On 21/05/2020 11:12, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Andrew
>> Cooper
>> Sent: 21 May 2020 10:04
>> To: Xen-devel
>> Cc: Andrew Cooper ; Tim Deegan ;
>> Wei Liu ; Jan
>> Beulich ; Roger Pau Monné
>> Subject: [PATCH] x86/shadow: Reposition
On Thu, May 21, 2020 at 10:04:28AM +0100, Andrew Cooper wrote:
> When compiling with SHOPT_OUT_OF_SYNC disabled, the build fails with:
>
> common.c:41:12: error: ‘sh_remove_write_access_from_sl1p’ declared ‘static’
> but never defined [-Werror=unused-function]
>static int
> -Original Message-
> From: Xen-devel On Behalf Of Andrew
> Cooper
> Sent: 21 May 2020 10:04
> To: Xen-devel
> Cc: Andrew Cooper ; Tim Deegan ; Wei
> Liu ; Jan
> Beulich ; Roger Pau Monné
> Subject: [PATCH] x86/shadow: Reposition sh_remove_write_access_from_sl1p()
>
> When compiling
Hi all,
Code freeze for 4.14 is currently scheduled for CoB tomorrow (Friday May
22nd), however there is a public holiday today in many
countries meaning that a few maintainers and committers are not available. I am
also aware of a few pending series that are close to
being fully acked but
On Wed, May 20, 2020 at 11:17:25PM +0100, Andrew Cooper wrote:
> On 18/05/2020 14:19, Jan Beulich wrote:
> > Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
> >
> > There have been reports of RDRAND issues after resuming from suspend on
> > some AMD family 15h and family
Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
Dispatched Before an Interrupt of The Same Priority Completes".
Apply the errata to all server and client models (big cores) from
Broadwell to Cascade Lake. The
When compiling with SHOPT_OUT_OF_SYNC disabled, the build fails with:
common.c:41:12: error: ‘sh_remove_write_access_from_sl1p’ declared ‘static’
but never defined [-Werror=unused-function]
static int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
v4:
- Add missing zero pad
From: Paul Durrant
Paul Durrant (5):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-domctx to present domain context
common/domain: add a domain context record for
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
v3:
- Re-worked to avoid copying onto stack
- Added optional typecode and instance
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a
... in the save/restore code.
This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.
No modifications are made to the definition of the migration stream at
this point. Subsequent patches will
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: The domain may or may not be using the embedded vcpu_info array so
ultimately separate context records will be added for vcpu_info when
this becomes necessary.
Signed-off-by: Paul
The 'T' debugkey reliably wedges on one of my systems, which has a sparse
APIC_ID layout due to a non power-of-2 number of cores per socket. The
per_cpu(dt_cpu_data, cpu) calcution falls over the deliberately non-canonical
poison value.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei
On Wed, May 20, 2020 at 10:30:11PM +0100, Andrew Cooper wrote:
> On 15/05/2020 14:58, Roger Pau Monne wrote:
> > Apply a workaround for Intel errata BDX99, CLX30, SKX100, CFW125,
> > BDF104, BDH85, BDM135, KWB131: "A Pending Fixed Interrupt May Be
> > Dispatched Before an Interrupt of The Same
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Stefano Stabellini
Add a struct device* parameter to dma_cache_maint.
Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all the following pages, in
case of multipage handling.
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Stefano Stabellini
Add phys_to_dma/dma_to_phys calls to
xen_dma_sync_for_cpu, xen_dma_sync_for_device, and
xen_arch_need_swiotlb.
In xen_arch_need_swiotlb, take the opportunity to switch to the simpler
pfn_valid check we use everywhere
flight 150281 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150281/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail REGR. vs. 150266
Tests which did not
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Stefano Stabellini
Call dma_to_phys in is_xen_swiotlb_buffer.
Call phys_to_dma in xen_phys_to_bus.
Call dma_to_phys in xen_bus_to_phys.
Everything is taken care of by these changes except for
xen_swiotlb_alloc_coherent and
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.
Signed-off-by: Stefano Stabellini
---
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Boris Ostrovsky
Don't just assume that virt_to_page works on all virtual addresses.
Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
virt addresses.
Can you provide an example where swiotlb is used with
flight 150283 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 150172
Tests which are
On Thu, 2020-04-30 at 20:27 +0200, Dario Faggioli wrote:
> Hello,
>
> This short series contains some improvements for building Xen in
> openSUSE containers. In fact, the build dependencies inside the
> Tumbleweed container are updated and more handy helpers are added, in
> containerize, for
flight 150284 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150284/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bc5012b8fbf9f769a62d8a7a2dbf04343c16d398
baseline version:
ovmf
83 matches
Mail list logo
