flight 144580 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 144517
build-i386-libvirt
On Wed, Dec 04, 2019 at 02:27:26PM +0100, Jan Beulich wrote:
> On 04.12.2019 08:14, Jeremi Piotrowski wrote:
> > Any suggestions how to proceed?
>
> Actually here's a better version (I think).
>
> Jan
>
> lz4: refine commit 9143a6c55ef7 for the 64-bit case
>
> I clearly went too far there:
05.12.2019 17:58, Vladimir Sementsov-Ogievskiy wrote:
> 05.12.2019 15:36, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> 04.12.2019 17:59, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be
05.12.2019 15:36, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> 04.12.2019 17:59, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy writes:
>>>
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.
Vladimir Sementsov-Ogievskiy writes:
> 04.12.2019 17:59, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>>> functions with errp OUT parameter.
>>>
>>> It has three goals:
>>>
>>> 1. Fix issue with
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf
flight 144558 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144558/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 8 host-ping-check-xen fail in 144544 pass in 144558
test-armhf-armhf-xl-credit2
flight 144552 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144552/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144525
flight 144564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144564/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0f9395d7c5cc6ae2beaa2d87008fe158d04a8069
baseline version:
ovmf
From: Lars Kurth
Date: Thursday, 28 November 2019 at 19:39
To: Rich Persaud
Cc: 'Jan Beulich' , "lars.ku...@xenproject.org"
, Stefano Stabellini ,
"xen-...@lists.xenproject.org" ,
"minios-de...@lists.xenproject.org" ,
"committ...@xenproject.org" ,
"mirageos-de...@lists.xenproject.org" ,
These hypercalls each use continue_hypercall_on_cpu(), whose API is about to
switch to use -ERESTART. Update the soon-to-be affected paths to cope,
folding existing contination logic where applicable.
In addition:
* For platform op and sysctl, insert a cpu_relax() into what is otherwise a
Most users pass a vcpu pointer, and only stopmachine_action() takes an integer
parameter. Switch to using void * to substantially reduce the number of
explicit casts.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano
More paths are going start using hypercall continuations. We could add extra
calls to hypercall_create_continuation() but it is much easier to handle
-ERESTART once at the top level.
One complication is XEN_DOMCTL_shadow_op, which for XSA-97 and ABI
compatibility in a security fix, turn a DOMCTL
Some hypercalls tasklets want to create a continuation, rather than fail the
hypercall with a hard error. By the time the tasklet is executing, it is too
late to create the continuation, and even continue_hypercall_on_cpu() doesn't
have enough state to do it correctly.
All callers of
Tasklet context is now capable of using handling continuations. Use this
rather than -EBUSY as it is a more efficient way to restart the hypercall.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/sysctl.c | 9 +++--
1 file changed, 7
This is the Post "x86/smt: Support for enabling/disabling SMT at runtime" work
which stumbled into discovering XSA-296, for the purpose of making
continuations more efficient.
From testing this series, I have re-confirmed the previous reported
observation that:
# while :; do xen-hptool
The use of return_reg() assumes ARM's 32bit ABI. Therefore, a failure such as
-EINVAL will appear as a large positive number near 4 billion to a 64bit ARM
guest which happens to use continue_hypercall_on_cpu().
Introduce a new arch_hypercall_tasklet_result() hook which is implemented by
both
flight 144562 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144562/
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
Hi all,
the minutes are at
https://cryptpad.fr/pad/#/2/pad/view/T-vK-ZiXDrnpve64l4hvP+evA5najcmoxOOVJ8TGeBs/
and attached
There were a few items, where the connection was bad and where I am missing
things
ACTIONS and everything important are marked in red
The next meeting is on Jan 9, not Jan 2
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf
flight 144545 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144545/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 138748
Hi,
On 05/12/2019 19:17, Jeff Kubascik wrote:
On 12/3/2019 1:04 PM, Julien Grall wrote:
Hi,
On 26/11/2019 21:13, Jeff Kubascik wrote:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per
On 12/3/2019 1:04 PM, Julien Grall wrote:
> Hi,
>
> On 26/11/2019 21:13, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the ARMv8 Reference Manual (ARM DDI
> It actually occurs to me that the "named struct elements of union" would
> still technically open up a window for divergence: i.e., if somehow the
> type of the named struct didn't match up with the union element.
>
> I.e., the following *shouldn't* happen, but technically it *could*:
>
>
>
> So first of all, I noticed that the marshalling code for Union structs
> does what I suggest. :-)
Yeah I realized that. I must have figured out that my previous way
wasn't necessary, but forgot to go back and change it.
> I'm not super-strong on this, so I don't want to bike-shed. But I think
On 05/12/2019 15:43, Jan Beulich wrote:
> Add model 0x86 to relevant switch() statements, as per SDM 069 Vol 4.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 05/12/2019 15:42, Jan Beulich wrote:
> This only added dead code. Use "if" instead of "depends on" to make
> (halfway) clear that other guest options should also go in thae same
> block. Move the option down such that the shim related options get
> presented first, avoiding to ask the question
On 12/5/19 4:38 PM, Nick Rosbrook wrote:
>> You should probably say here explicitly what kinds of elements you're
>> supporting and not supporting in this patch; specifically:
>>
>> - You're converting built-ins (or is this any struct-like type?)
>
> Any struct-like type, since the fromC
flight 144544 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144544/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 8 host-ping-check-xen fail REGR. vs. 138829
Tests which
On 12/5/19 8:58 AM, Vladimir Sementsov-Ogievskiy wrote:
What about you provide the examples, and then I try to polish the prose?
1: error_fatal problem
Assume the following code flow:
int f1(errp) {
...
ret = f2(errp);
if (ret < 0) {
error_append_hint(errp, "very
On 12/5/19 4:53 PM, Nick Rosbrook wrote:
>>> It looks like this is duplicating (differently!) the field-copying code
>>> from golang_define_from_C. Is there any reason you couldn't have a
>>> single function, `xenlight_golang_fields_from_C`, which would be used
>>> for both?
>
> No, I should be
This is the package (or, one of the packages) containing rst2html.
This is now needed for builds of libvirt upstream.
Really this packages install call should be ts-libvirt-build, but:
Historically we have done it all in ts-xen-build-prep. In the
meantime we have put a lock around the call to
> Sorry to come back to this... I think this would be better explicitly
> listing out the files that are needed. As I said, the current way of
> doing things means gengotypes.py will *always* be re-run; and the
> result, when experimenting with the `typeof` before, was that my local
> changes to
On 05.12.2019 16:47, Andrew Cooper wrote:
> On 05/12/2019 15:34, Jan Beulich wrote:
>> Translated domains shouldn't see host physical addresses. While the
>> address is also not supposed to be handed back even to non-translated
>> domains when GNTMAP_device_map is not set (as explicitly stated by
> > It looks like this is duplicating (differently!) the field-copying code
> > from golang_define_from_C. Is there any reason you couldn't have a
> > single function, `xenlight_golang_fields_from_C`, which would be used
> > for both?
No, I should be able to re-factor that. Thanks.
> Actually,
On 05.12.2019 17:27, Julien Grall wrote:
> On 05/12/2019 15:33, Jan Beulich wrote:
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -23,6 +23,49 @@ enum system_state system_state = SYS_STA
>> xen_commandline_t saved_cmdline;
>> static const char __initconst opt_builtin_cmdline[]
> You should probably say here explicitly what kinds of elements you're
> supporting and not supporting in this patch; specifically:
>
> - You're converting built-ins (or is this any struct-like type?)
Any struct-like type, since the fromC functions are all defined in
this patch (excluding array
Hi,
On 05/12/2019 15:33, Jan Beulich wrote:
In order to avoid permanently having to ask that no new command line
options using underscores be introduced (albeit I'm likely to still make
remarks), and in order to also allow extending the use of hyphens to
pre-existing ones, introduce custom
On Thu, Dec 05, 2019 at 04:42:08PM +0100, Jan Beulich wrote:
>
> This only added dead code. Use "if" instead of "depends on" to make
> (halfway) clear that other guest options should also go in thae same
s/thae/the/
> block. Move the option down such that the shim related options get
>
On Thu, 5 Dec 2019 at 15:41, Jan Beulich wrote:
>
> This only added dead code. Use "if" instead of "depends on" to make
> (halfway) clear that other guest options should also go in thae same
> block. Move the option down such that the shim related options get
> presented first, avoiding to ask
On 05/12/2019 15:47, Andrew Cooper wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -1394,7 +1401,7 @@ unmap_common(
>>
>> op->mfn = act->mfn;
>>
>> -if ( op->dev_bus_addr &&
>> +if ( op->dev_bus_addr && (flags & GNTMAP_device_map) &&
> Drop the
On 12/5/19 3:41 PM, Jan Beulich wrote:
> It's bogusly non-static. It making the call sites actually less easy to
> read, and there being another open-coded use in the file - let's just
> get rid of it.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm/hap/nested_ept.c
> +++
flight 144547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144547/
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 05/12/2019 15:41, Jan Beulich wrote:
> It's bogusly non-static. It making the call sites actually less easy to
> read, and there being another open-coded use in the file - let's just
> get rid of it.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 05/12/2019 15:34, Jan Beulich wrote:
> Translated domains shouldn't see host physical addresses. While the
> address is also not supposed to be handed back even to non-translated
> domains when GNTMAP_device_map is not set (as explicitly stated by a
> comment in the public header), PV kernels
Add model 0x86 to relevant switch() statements, as per SDM 069 Vol 4.
Signed-off-by: Jan Beulich
---
v2: Drop spec_ctrl.c adjustments.
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -238,6 +238,8 @@ static void do_get_hw_residencies(void *
case 0x5F:
/*
It's bogusly non-static. It making the call sites actually less easy to
read, and there being another open-coded use in the file - let's just
get rid of it.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/hap/nested_ept.c
+++ b/xen/arch/x86/mm/hap/nested_ept.c
@@ -54,11 +54,6 @@
#define
This only added dead code. Use "if" instead of "depends on" to make
(halfway) clear that other guest options should also go in thae same
block. Move the option down such that the shim related options get
presented first, avoiding to ask the question when the answer may end
up being discarded.
> Same thing with casting.
Ack for all such cases of this casting. That's a good way to simplify.
-NR
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Translated domains shouldn't see host physical addresses. While the
address is also not supposed to be handed back even to non-translated
domains when GNTMAP_device_map is not set (as explicitly stated by a
comment in the public header), PV kernels (Linux at least) assume the
field to get
In order to avoid permanently having to ask that no new command line
options using underscores be introduced (albeit I'm likely to still make
remarks), and in order to also allow extending the use of hyphens to
pre-existing ones, introduce custom comparison functions treating both
characters as
On 02/12/2019 19:51, Andrew Cooper wrote:
> Hello,
>
> Now that 4.13 is on its way out of the door, it is time to look to
> ongoing work.
(and some more...)
* Shim: Removal of an M2P.
Within the shim, two M2P's are constructed, and one of them is entirely
unused. Both take up a decent chunk of
On 12/5/19 3:23 PM, Nick Rosbrook wrote:
>> I implemented some tests for these methods to make sure everything
>> worked as expected (they did); but there's an unexpected side-effect:
>>
>> - *_test.go files cannot `import "C"`
>
> Yeah, this is unfortunate.
>
>> - The fromC / toC methods
> I implemented some tests for these methods to make sure everything
> worked as expected (they did); but there's an unexpected side-effect:
>
> - *_test.go files cannot `import "C"`
Yeah, this is unfortunate.
> - The fromC / toC methods aren't exported
>
> So it's not possible to do the
On 05.12.19 16:09, SeongJae Park wrote:
> From: SeongJae Park
>
> Each `blkif` has a free pages pool for the grant mapping. The size of
> the pool starts from zero and be increased on demand while processing
> the I/O requests. If current I/O requests handling is finished or 100
> milliseconds
On 05.12.19 16:09, SeongJae Park wrote:
> Each `blkif` has a free pages pool for the grant mapping. The size of
> the pool starts from zero and be increased on demand while processing
> the I/O requests. If current I/O requests handling is finished or 100
> milliseconds has passed since last I/O
On 11/15/19 7:44 PM, Nick Rosbrook wrote:
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> index 0987305224..681f32c234 100644
> --- a/tools/golang/xenlight/Makefile
> +++ b/tools/golang/xenlight/Makefile
> @@ -7,20 +7,21 @@ GOCODE_DIR ?= $(prefix)/share/gocode/
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-19579 / XSA-306
version 3
Device quarantine for alternate pci assignment methods
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
...and make it static
xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of PV
frontends when a guest is rebooted. Indeed the function waits for a
conpletion which is only set by a call to xenbus_frontend_closed().
This patch removes the shutdown() method from backends and moves
Patch #1 is clean-up for an apparent mis-feature.
Paul Durrant (4):
xenbus: move xenbus_dev_shutdown() into frontend code...
xenbus: limit when state is forced to closed
xen/interface: don't discard pending work in FRONT/BACK_RING_ATTACH
xen-blkback: support dynamic unbind/bind
Only force state to closed in the case when the toolstack may need to
clean up. This can be detected by checking whether the state in xenstore
has been set to closing prior to device removal.
Signed-off-by: Paul Durrant
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
---
Currently these macros will skip over any requests/responses that are
added to the shared ring whilst it is detached. This, in general, is not
a desirable semantic since most frontend implementations will eventually
block waiting for a response which would either never appear or never be
By simply re-attaching to shared rings during connect_ring() rather than
assuming they are freshly allocated (i.e assuming the counters are zero)
it is possible for vbd instances to be unbound and re-bound from and to
(respectively) a running guest.
This has been tested by running:
while true;
I mean... I was taught so as well but I was also taught an exception
which is using it for error handling and cleaning up. I am not sure if
using alternatives would result in cleaner code in this situation.
Hongyan
On Thu, 2019-12-05 at 12:12 +0100, Jan Beulich wrote:
> On 05.12.2019 12:02,
Hi all,
a quick note to say that George may start the call: however, the call-in
details remain the same. We have a scheduled power outage this morning, which I
was only informed about yesterday. As the power outage affects almost the
entire pacific coast in CR, it is conceivable that I won't
On 04/12/2019 09:43, Andrew Cooper wrote:
> The type name is poor because the type is also used for the IDT vectoring
> field, not just for the event injection field. Rename it to intinfo_t which
> is how the APM refers to the data.
>
> Rearrange the union to drop the .fields infix, and rename
On 05.12.2019 13:20, Durrant, Paul wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 05 December 2019 12:14
>> To: xen-devel@lists.xenproject.org
>> Cc: jbeul...@suse.com; li...@eikelenboom.it; Durrant, Paul
>> ; Igor Druzhinin
>> Subject: [PATCH v2] passthrough: drop break
On 05/12/2019 12:20, Durrant, Paul wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 05 December 2019 12:14
>> To: xen-devel@lists.xenproject.org
>> Cc: jbeul...@suse.com; li...@eikelenboom.it; Durrant, Paul
>> ; Igor Druzhinin
>> Subject: [PATCH v2] passthrough: drop break
On 12/4/19 6:40 PM, George Dunlap wrote:
> On 11/15/19 7:44 PM, Nick Rosbrook wrote:
>> From: Nick Rosbrook
>>
>> Switch over union key to determine how to populate 'union' in Go struct.
>>
>> Since the unions of C types cannot be directly accessed, add C structs in
>> cgo preamble to assist in
> -Original Message-
> From: Igor Druzhinin
> Sent: 05 December 2019 12:14
> To: xen-devel@lists.xenproject.org
> Cc: jbeul...@suse.com; li...@eikelenboom.it; Durrant, Paul
> ; Igor Druzhinin
> Subject: [PATCH v2] passthrough: drop break statement following c/s
> cd7dedad820
>
> The
The locking responsibilities have changed and a premature break in
this section now causes the following assertion:
Assertion '!preempt_count()' failed at preempt.c:36
Suggested-by: Paul Durrant
Reported-by: Sander Eikelenboom
Signed-off-by: Igor Druzhinin
---
xen/drivers/passthrough/pci.c |
On 03.12.19 03:05, Lars Kurth wrote:
Dear community members,
please send me agenda items for this Friday’s community call (sorry for the late notice, I was on PTO last week). A draft agenda is at https://cryptpad.fr/pad/#/2/pad/edit/PCtBphoXkCTiXABJ8cdL0KuZ/
Please add agenda items to the
04.12.2019 17:59, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>> functions with errp OUT parameter.
>>
>> It has three goals:
>>
>> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
On 02.08.2019 11:22, Roger Pau Monne wrote:
> Switch rmrr_identity_mapping to use iommu_{un}map in order to
> establish RMRR mappings for PV domains, like it's done in
> arch_iommu_hwdom_init. This solves the issue of a PV hardware domain
> not getting RMRR mappings because
On 05.12.2019 12:02, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 05 December 2019 10:26
>> To: Xia, Hongyan
>> Cc: andrew.coop...@citrix.com; xen-devel@lists.xenproject.org; w...@xen.org;
>> roger@citrix.com
>> Subject: Re:
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 05 December 2019 10:26
> To: Xia, Hongyan
> Cc: andrew.coop...@citrix.com; xen-devel@lists.xenproject.org; w...@xen.org;
> roger@citrix.com
> Subject: Re: [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop
branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf
On 05.12.2019 11:51, Andrew Cooper wrote:
> The function is init, so can use boot_cpu_data directly.
>
> There is no need to write 0 to svm_feature_flags in the case of a CPUID
> mismatch (not least because this is dead code on real hardware), and no need
> to use locked atomic operations.
>
>
The function is init, so can use boot_cpu_data directly.
There is no need to write 0 to svm_feature_flags in the case of a CPUID
mismatch (not least because this is dead code on real hardware), and no need
to use locked atomic operations.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
Okay let me be explicit this time. Cross checked with mails from
lore.kernel.org, issues not touched from v3 to v4:
- _new or not _new
- splitting map_pages_to_xen; introduction of labels. Although I just
responded to these two issues.
- const not added to suggested variables since a lot of them
On 05.12.2019 11:21, Xia, Hongyan wrote:
>> On 02.10.2019 19:16, Hongyan Xia wrote:
>>> We will soon need to clean up mappings whenever the out most loop is
>>> ended. Add a new label and turn relevant continue's into goto's.
>>
>> I think already when this still was RFC I did indicate that I'm
>On 02.10.2019 19:16, Hongyan Xia wrote:
>> We will soon need to clean up mappings whenever the out most loop is
>> ended. Add a new label and turn relevant continue's into goto's.
>
>I think already when this still was RFC I did indicate that I'm not
>happy about the introduction of these labels
flight 144525 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144525/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 144522
Tests which did not
On 05.12.2019 10:41, Xia, Hongyan wrote:
> I have addressed the comments that I can find in the archive.
That's still pretty vague - is there reason to assume you were
not able to find some comments there?
> Some big
> debates (like _new or not _new, whether to modularise map_pages_to_xen)
>
On 04.12.2019 17:20, Roger Pau Monne wrote:
> x2APIC mode doesn't mandate interrupt remapping, and hence can be
> enabled independently. This patch enables x2APIC when available,
> regardless of whether there's interrupt remapping support.
>
> This is beneficial specially when running on
I have addressed the comments that I can find in the archive. Some big
debates (like _new or not _new, whether to modularise map_pages_to_xen)
have not been touched. Various acked-by and reviewed-by added.
Hongyan
On Thu, 2019-12-05 at 10:14 +0100, Jan Beulich wrote:
> On 04.12.2019 18:10,
On 04.12.2019 17:20, Roger Pau Monne wrote:
> Check that the processor to be woken up APIC ID is addressable in the
> current APIC mode.
>
> Note that in practice systems with APIC IDs > 255 should already have
> x2APIC enabled by the firmware, and hence this is mostly a safety
> belt.
>
>
On 04.12.2019 17:20, Roger Pau Monne wrote:
> Cluster mode can only be used with interrupt remapping support, since
> the top 16bits of the APIC ID are filled with the cluster ID, and
> hence on systems where the physical ID is still smaller than 255 the
> cluster ID is not. Force x2APIC to use
On 04.12.2019 17:20, Roger Pau Monne wrote:
> The IO-APIC code assumes that x2apic being enabled also implies
> interrupt remapping being enabled, and hence will use the 32bit
> destination field in the IO-APIC entry.
>
> This is safe now, but there's no reason to not enable x2APIC even
> without
On 04.12.2019 18:10, Hongyan Xia wrote:
> NOTE: My email address has changed due to some HR management. I have
> lost all my previous emails and I could only salvage some of the
> comments to v3 from the mailing list archive. I will reply to the
> comments from v3 in this v4 series.
I'm afraid
On 04.12.2019 20:38, Andrew Cooper wrote:
> On 04/12/2019 09:43, Andrew Cooper wrote:
>> @@ -420,10 +420,10 @@ struct vmcb_struct {
>> u64 exitcode; /* offset 0x70 */
>> u64 exitinfo1; /* offset 0x78 */
>> u64 exitinfo2; /* offset 0x80 */
>> -
On 04.12.2019 22:31, Igor Druzhinin wrote:
> The locking responsibilities have changed and a premature break in
> this section now causes the following assertion:
>
> Assertion '!preempt_count()' failed at preempt.c:36
>
> Reported-by: Sander Eikelenboom
> Signed-off-by: Igor Druzhinin
> ---
>
On 04.12.2019 21:04, Andrew Cooper wrote:
> Net delta is:
>
> diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
> b/xen/include/asm-x86/hvm/svm/vmcb.h
> index 02b5e86b49..864618ccf9 100644
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -419,17 +419,15 @@
flight 144527 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144527/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 94d4efb54ec4ca894287276ce22d29b6261dbc0b
baseline version:
ovmf
> -Original Message-
> From: Jan Beulich
> Sent: 05 December 2019 08:44
> To: Durrant, Paul
> Cc: Sander Eikelenboom ; xen-
> de...@lists.xenproject.org; Igor Druzhinin ;
> Paul Durrant
> Subject: Re: xen-unstable (4.14 to be): Assertion '!preempt_count()'
> failed at preempt.c:36
>
>
On 05.12.2019 09:35, Durrant, Paul wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1696,16 +1696,12 @@ int iommu_do_pci_domctl(
>
> pcidevs_lock();
> ret = device_assigned(seg, bus, devfn);
> -if ( domctl->cmd ==
On 04.12.2019 19:01, Xia, Hongyan wrote:
>>> @@ -5272,6 +5279,7 @@ int map_pages_to_xen(
>>> ((1u << PAGETABLE_ORDER) - 1)) == 0)) )
>>> {
>>> unsigned long base_mfn;
>>> +l1_pgentry_t *l1t;
>>
>> const, as this looks to be used
> -Original Message-
> From: Xen-devel On Behalf Of
> Sander Eikelenboom
> Sent: 04 December 2019 21:04
> To: Jan Beulich
> Cc: xen-devel@lists.xenproject.org; Igor Druzhinin
> ; Paul Durrant
> Subject: Re: [Xen-devel] xen-unstable (4.14 to be): Assertion
> '!preempt_count()' failed at
98 matches
Mail list logo
