On Thu, Apr 23, 2020 at 1:22 PM George Dunlap wrote:
>
>
> > On Apr 23, 2020, at 12:49 PM, George Dunlap
> > wrote:
> >
> >
> >
> >> On Apr 23, 2020, at 12:27 PM, Ian Jackson wrote:
> >>
> >> Ian Jackson writes ("Re: Golang Xen packages and the golang packaging
> >> system"):
> >>> This is
flight 149764 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149764/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail in 149743 pass in
By default, if the go compiler is found by the configure script, build
the golang tools. If the compiler is not found, and --enable-golang was
not explicitly set, do not build to the golang tools.
The corresponding make variable is CONFIG_GOLANG. Remove CONFIG_GOLANG
from tools/Rules.mk since the
These patches add support for the golang tools in the build system.
The behavior of configure with respect to the make variable,
CONFIG_GOLANG is copied from other components, such as the Ocaml
tools. Namely, build the tools by default if the go compiler is found.
Changes in v2:
- Change make
This series adds wrappers to the xenlight package for various libxl
functions, which are now trivial to add with the generated types and
marshaling helpers. In particular, these are functions that would allow
redctl to begin making the transition to using the xenlight package. For
reference, I
Many exported functions in xenlight require a domid as an argument. Make
it easier for package users to use these functions by adding wrappers
for the libxl utility functions libxl_name_to_domid and
libxl_domid_to_name.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 38
flight 149766 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149766/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d5339c04d7cd47c061ec146a7b062052e3dc56ca
baseline version:
ovmf
flight 149768 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149768/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-laxton1 2 hosts-allocate starved n/a
examine-fiano12
flight 149752 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 149741
build-i386
Hello,
I see that in the xl binary in xen 4.13.0, the acquire_lock() and
release_lock() functions are only called from create_domain() in
xl_vmcontrol.c, so I assume the lock provides inter-PROCESS
synchronization in the case that multiple instances of xl are running
and creating multiple domains
flight 149769 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149769/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 21/04/2020 08:48, Jan Beulich wrote:
> On 20.04.2020 16:59, Andrew Cooper wrote:
>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -441,12 +441,18 @@ struct tss_page {
>> };
>> DECLARE_PER_CPU(struct tss_page, tss_page);
>>
>> +/*
>> + * Interrupt Stack
On 21/04/2020 08:24, Jan Beulich wrote:
> On 20.04.2020 16:59, Andrew Cooper wrote:
>> @@ -46,24 +36,13 @@ void restore_rest_processor_state(void)
>> /* Restore full CR4 (inc MCE) now that the IDT is in place. */
>> write_cr4(mmu_cr4_features);
>>
>> -/* Recover syscall MSRs */
>>
flight 149749 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149749/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 15 guest-saverestorefail like 149709
test-armhf-armhf-xl-rtds 16
> The underscore thing though — I think it’s a bad idea to mix `-` and `_`;
> —enable-golang_tools just isn’t a good idea IMHO. :-)
>
> Do you need _tools? Could it just be —enable-golang?
I agree, I don't like mixing the '-' and '_'. From what I could tell,
that was how the other options were
On 21/04/2020 07:02, Jan Beulich wrote:
> On 20.04.2020 20:05, Andrew Cooper wrote:
>> On 20/04/2020 15:05, Jan Beulich wrote:
>>> I'm in particular
>>> concerned that we may gain a large number of such printk()s over
>>> time, if we added them in such cases.
>> The printk() was a bit of an
> On Apr 23, 2020, at 5:03 PM, Nick Rosbrook wrote:
>
> On Thu, Apr 23, 2020 at 9:44 AM George Dunlap wrote:
>>
>>
>>
>> On Thu, Apr 23, 2020 at 1:51 AM Nick Rosbrook wrote:
>>>
>>> By default, if the go compiler is found by the configure script, build
>>> the golang tools. If the
> On Apr 23, 2020, at 12:49 PM, George Dunlap wrote:
>
>
>
>> On Apr 23, 2020, at 12:27 PM, Ian Jackson wrote:
>>
>> Ian Jackson writes ("Re: Golang Xen packages and the golang packaging
>> system"):
>>> This is quite unpleasant. In particular, it makes a git tree out of
>>> output
On 21.04.2020 18:12, Anthony PERARD wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -123,6 +123,7 @@ $(obj-bin-y): XEN_CFLAGS := $(filter-out
> -flto,$(XEN_CFLAGS))
>
> c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) '-D__OBJECT_FILE__="$@"'
> a_flags = -MMD -MP -MF $(@D)/.$(@F).d
On 21.04.2020 18:11, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it. The
> only flags left to be generated are
On 23.04.2020 16:56, Roger Pau Monne wrote:
> Introduce a specific flag to request a HVM guest linear TLB flush,
> which is an ASID/VPID tickle that forces a guest linear to guest
> physical TLB flush for all HVM guests.
>
> This was previously unconditionally done in each pre_flush call, but
>
On Thu, Apr 23, 2020 at 6:25 AM Wei Liu wrote:
>
> On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > By default, if the go compiler is found by the configure script, build
> > the golang tools. If the compiler is not found, and
> > --enable-golang_tools was not explicitly set, do
On Thu, Apr 23, 2020 at 9:44 AM George Dunlap wrote:
>
>
>
> On Thu, Apr 23, 2020 at 1:51 AM Nick Rosbrook wrote:
>>
>> By default, if the go compiler is found by the configure script, build
>> the golang tools. If the compiler is not found, and
>> --enable-golang_tools was not explicitly set,
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
When resetting a VM fork we ought to only remove pages that were allocated for
the fork during it's execution and the contents copied over from the parent.
This can be determined if the page is sharable as special pages used by the
fork for other purposes will not pass this test. Unfortunately
> -Original Message-
> From: Jan Beulich
> Sent: 23 April 2020 12:09
> To: p...@xen.org; 'Varad Gautam'
> Cc: xen-devel@lists.xenproject.org; 'Julien Grall' ; 'Roger
> Pau Monné'
> ; 'Andrew Cooper'
> Subject: Re: [PATCH v4] x86: irq: Do not BUG_ON multiple unbind calls for
> shared
Roger Pau Monne writes ("[PATCH OSSTEST] examine/cpu: fix fetching number of
threads"):
> The way to fetch the number of threads from the output of xl info is
> wrong, as the result of =~ is either true or false, but will never be a
> numeric value.
>
> Fix the regex to have a capture group in
Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32
Hello,
This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.
Thanks, Roger.
Roger Pau Monne (3):
x86/tlb: introduce a flush HVM ASIDs flag
x86/tlb: allow disabling the TLB clock
x86/tlb: use
The way to fetch the number of threads from the output of xl info is
wrong, as the result of =~ is either true or false, but will never be a
numeric value.
Fix the regex to have a capture group in order to fetch the number of
threads, and store the capture in the threads variable.
Signed-off-by:
flight 149747 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149747/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a3a3af4a29ee36b1db11842d40b74f2de892a35
baseline version:
ovmf
flight 149743 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
flight 149744 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149744/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149737
flight 149760 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149760/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Apr 23, 2020 at 1:51 AM Nick Rosbrook wrote:
> By default, if the go compiler is found by the configure script, build
> the golang tools. If the compiler is not found, and
> --enable-golang_tools was not explicitly set, do not build to the golang
> tools.
>
> The new corresponding make
On Thu, Apr 23, 2020 at 6:22 AM George Dunlap wrote:
>
>
>
> > On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
> >
> > Add DevicePciAdd and DevicePciRemove as wrappers for
> > libxl_device_pci_add and libxl_device_pci remove.
> >
> > Signed-off-by: Nick Rosbrook
>
> For 4.14, we should
On Thu, Apr 23, 2020 at 01:09:43PM +0100, George Dunlap wrote:
> On Thu, Apr 23, 2020 at 11:25 AM Wei Liu wrote:
>
> > On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > > By default, if the go compiler is found by the configure script, build
> > > the golang tools. If the
On Thu, Apr 23, 2020 at 12:57:44PM +0200, Roger Pau Monné wrote:
> On Thu, Apr 23, 2020 at 12:41:49PM +0200, Jan Beulich wrote:
> > On 23.04.2020 12:30, Wei Liu wrote:
> > > On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
> > >> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau
On Thu, Apr 23, 2020 at 11:25 AM Wei Liu wrote:
> On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > By default, if the go compiler is found by the configure script, build
> > the golang tools. If the compiler is not found, and
> > --enable-golang_tools was not explicitly set, do
flight 149748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149748/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
> On Apr 23, 2020, at 12:27 PM, Ian Jackson wrote:
>
> Ian Jackson writes ("Re: Golang Xen packages and the golang packaging
> system"):
>> This is quite unpleasant. In particular, it makes a git tree out of
>> output files. What will we do when someone sends us patches to the
>> bindings
Ian Jackson writes ("Re: Golang Xen packages and the golang packaging system"):
> This is quite unpleasant. In particular, it makes a git tree out of
> output files. What will we do when someone sends us patches to the
> bindings ?
Also, anyone who redistributes your proposed golang package is
George Dunlap writes ("Golang Xen packages and the golang packaging system"):
> So currently, our build system will install the xenlight package into
> $PREFIX/share/gocode/src/golang.xenproject.org/xenlight. However, it
> actually takes a bit of wrestling to get golang to use this location,
> On Apr 22, 2020, at 7:55 PM, Nick Rosbrook wrote:
>
>> One question I have from the above is how the xen.git RELEASE-X.Y.Z should
>> correspond to the vA.B.C in the golang package repo.
>>
>> The obvious answer, of course, is (A, B, C) = (X, Y, Z); that is, xen.git
>> tag RELEASE-4.14.0
On 23.04.2020 12:57, Roger Pau Monné wrote:
> On Thu, Apr 23, 2020 at 12:41:49PM +0200, Jan Beulich wrote:
>> On 23.04.2020 12:30, Wei Liu wrote:
>>> On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> @@
On 31.03.2020 13:51, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 31 March 2020 08:41
>>
>> On 17.03.2020 16:23, Paul Durrant wrote:
>>> That looks like it will do the job. I'll see if I can get it tested.
>>
>> Any luck with this, yet?
>
> I have asked Varad to test it. He hopes to get to
On 23/04/2020 11:19, Pawel Wieczorkiewicz wrote:
Add FreeBSD's implementation of strtol() and strtoul() functions from:
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtoul.c
I would suggest to specify the baseline used in each commit. This will
allows us to track any
On Thu, Apr 23, 2020 at 12:41:49PM +0200, Jan Beulich wrote:
> On 23.04.2020 12:30, Wei Liu wrote:
> > On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
> >> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> >>> @@ -254,3 +257,14 @@ unsigned int
On 23.04.2020 12:30, Wei Liu wrote:
> On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
>> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
>>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned
>>> int flags)
>>>
>>> return flags;
In arch_setup() detect Xen version by issuing xen_version hypercall
and optionally pass the version to main_xtf().
Signed-off-by: Pawel Wieczorkiewicz
---
Changed since v1:
* Do not limit setup_pv_console() to HVM only. It does not crash.
It merely panics because the callbacks array wasn't
The explicit LFCR sequence guarantees proper line by line formatting
in the output.
The '\n' character alone on some terminals is not automatically
converted to LFCR.
Signed-off-by: Pawel Wieczorkiewicz
---
Changed since v1:
* Emit CRLF instead of LFCR
common/libc/vsnprintf.c | 10 ++
From: Paul Semel
setup.c: PV console writing is not working in Xen 4.2 for hvm
guests, so we make xtf write to COM1 serial port to get its output
Signed-off-by: Paul Semel
Signed-off-by: Pawel Wieczorkiewicz
---
Changed since v1:
* Increase callbacks array
arch/x86/setup.c | 14
This is the first series of XTF patches I intend to send.
It covers some relatively small changes displaying Xen version on test
start, as well as adding serial consol support for HVM guests..
Paul Semel (1):
Enabled serial writing for hvm guests
Pawel Wieczorkiewicz (3):
lib: Add
These are just a simple macros obtaining major, minor values as
returned by xen_version hypercall.
Signed-off-by: Pawel Wieczorkiewicz
---
include/xtf/lib.h| 3 +++
tests/xsa-213/main.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/xtf/lib.h
The function was derived from:
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtoul.c
Sligthly modified to use ctypes helpers and ignore locale.
Signed-off-by: Pawel Wieczorkiewicz
---
common/libc/strtol.c | 69
These ctype.h derived helper functions simplify strtol() code and will
help simplify strtoul().
Signed-off-by: Pawel Wieczorkiewicz
---
common/lib.c| 8
common/libc/strtol.c| 9 +++--
common/libc/vsnprintf.c | 8
include/xtf/libc.h | 29
From: Paul Semel
Added freebsd libc implementation of the strtol() function.
Original can be found here :
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtol.c
Signed-off-by: Paul Semel
---
build/files.mk | 1 +
common/libc/strtol.c | 135
Signed-off-by: Pawel Wieczorkiewicz
---
common/libc/string.c | 11 +++
include/xtf/libc.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/common/libc/string.c b/common/libc/string.c
index 5c25e27..d81e324 100644
--- a/common/libc/string.c
+++ b/common/libc/string.c
@@ -56,6
Add FreeBSD's implementation of strtol() and strtoul() functions from:
https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/strtoul.c
The FreeBSD code being added as a separate file (common/libc/strtol.c)
is under the BSD 3-clause license. Modification to COPYING file might
be needed.
> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
>
> This series adds wrappers to the xenlight package for various libxl
> functions, which are now trivial to add with the generated types and
> marshaling helpers. In particular, these are functions that would allow
> redctl to begin
On Wed, Apr 22, 2020 at 06:33:38PM +0200, Roger Pau Monné wrote:
> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> > @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned
> > int flags)
> >
> > return flags;
> > }
> > +
> > +void
On Wed, Apr 22, 2020 at 08:25:26PM -0400, Nick Rosbrook wrote:
> The generated go files were tracked temporarily while the initial
> implementation of gengotypes.py was in progress. They can now be removed
> and ignored by git and hg.
>
> While here, make sure generated files are removed by make
On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> By default, if the go compiler is found by the configure script, build
> the golang tools. If the compiler is not found, and
> --enable-golang_tools was not explicitly set, do not build to the golang
--enable-golang-tools here.
>
> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
>
> Add DeviceUsbdevAdd and DeviceUsbdevRemove as wrappers for
> libxl_device_usbdev_add and libxl_device_usbdev_remove.
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
>
> Add DevicePciAdd and DevicePciRemove as wrappers for
> libxl_device_pci_add and libxl_device_pci remove.
>
> Signed-off-by: Nick Rosbrook
For 4.14, we should really look at adding functions to the IDL so that all this
can be
> On Apr 22, 2020, at 8:46 PM, Nick Rosbrook wrote:
>
>> libxl.h defines INVALID_DOMID — do we want to define an exported constant
>> with the same name and use that here? (Although part of me wonders if
>> DOMID_INVALID would be a better option.)
>
> Yeah, that makes sense. I'll add that.
flight 149741 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149741/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149705
Where gprintk()s get touched anyway to switch to PRI_gfn, also switch to
%pd for the domain logged.
Signed-off-by: Jan Beulich
---
v2: Use gfn_t for local var in mod_l1_entry(). Use PRI_gfn when printk()
arg is gfn_x(). Re-base.
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@
Do a little bit of style adjustment along the way, and drop the
"p2m_mem_paging_" prefixes from the now static functions.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,6 +25,421 @@
#include
#include
+#include "mm-locks.h"
+
+/*
+ *
While full checking is impossible (as the lock is being acquired/
released down the call tree), perform at least a lock level check.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1813,6 +1813,7 @@ int p2m_mem_paging_prep(struct domain *d
While it should have been this way from the beginning, not doing so will
become an actual problem with PVH Dom0. The interface change is binary
compatible, but requires tools side producers to be re-built.
Drop the bogus/unnecessary page alignment restriction on the input
buffer at the same time.
Communicating errors from p2m_set_entry() to the caller is not enough:
Neither the M2P nor the stats updates should occur in such a case.
Instead the allocated page needs to be freed again; for cleanliness
reasons also properly take into account _PGC_allocated there.
Signed-off-by: Jan Beulich
The condition of the second can be true only if the condition of the
first was met; the second half of the condition of the second then also
is redundant with an earlier check. Combine them, drop a pointless
local variable, and re-flow the affected gdprintk().
Signed-off-by: Jan Beulich
---
Repeatedly looking at varying parts of this code has lead to
me accumulating a few adjustments.
1: fold p2m_mem_paging_prep()'s main if()-s
2: correct p2m_mem_paging_prep()'s error handling
3: use guest handle for XENMEM_paging_op_prep
4: add minimal lock order enforcement to
On 23/04/2020 09:16, Jan Beulich wrote:
On 23.04.2020 10:10, Julien Grall wrote:
Hi,
On 23/04/2020 08:38, Jan Beulich wrote:
On 17.04.2020 19:16, Julien Grall wrote:
On 16/04/2020 13:19, Jan Beulich wrote:
On 16.04.2020 13:24, Julien Grall wrote:
From: Julien Grall
At the moment,
On 23.04.2020 10:10, Julien Grall wrote:
> Hi,
>
> On 23/04/2020 08:38, Jan Beulich wrote:
>> On 17.04.2020 19:16, Julien Grall wrote:
>>> On 16/04/2020 13:19, Jan Beulich wrote:
On 16.04.2020 13:24, Julien Grall wrote:
> From: Julien Grall
>
> At the moment,
Hi,
On 23/04/2020 08:38, Jan Beulich wrote:
On 17.04.2020 19:16, Julien Grall wrote:
On 16/04/2020 13:19, Jan Beulich wrote:
On 16.04.2020 13:24, Julien Grall wrote:
From: Julien Grall
At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked
flight 149746 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 22.04.2020 18:33, Roger Pau Monné wrote:
> On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
>> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>>
>> return flags;
>> }
>> +
>> +void guest_flush_tlb_mask(const struct domain *d,
On 17.04.2020 19:16, Julien Grall wrote:
> On 16/04/2020 13:19, Jan Beulich wrote:
>> On 16.04.2020 13:24, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>> data to guest handle marked const.
>>>
>>> Thankfully, no
flight 149742 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149742/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 93f6df5f3b2553b8f5188d2a6ba70f3f5cfab0bb
baseline version:
ovmf
On 22.04.2020 18:31, Stefano Stabellini wrote:
> On Wed, 22 Apr 2020, Jan Beulich wrote:
>> On 22.04.2020 15:07, Juergen Gross wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -3626,12 +3626,12 @@ do_grant_table_op(
>>> if (
84 matches
Mail list logo
