On Fri, Aug 30, 2019 at 09:49:04AM +0200, Jan Beulich wrote:
>On 30.08.2019 04:09, Chao Gao wrote:
>> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> While testing xen-unstable, my AMD system crashes during early boot while
>>> loading microcode with an
Hi Peng,
On 30/08/2019 04:28, Peng Fan wrote:
> From: Peng Fan
>
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So introduce xen_set_gfp_dma for arm32/arm64 and using __GFP_DMA
>
flight 140829 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140829/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 140788 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140282
Tests which did
Performing soft reset should not opportunistically kill IOREQ servers
for device emulators that might be currently running for a domain.
Every emulator is supposed to clean up IOREQ servers for itself on exit.
This allows a toolstack to elect whether or not a particular device
model should be
On Wed, Aug 28, 2019 at 11:31:58AM -0700, Joseph Komlodi wrote:
> Hi all,
>
> I'm working on ARM64 Xen testing with Xilinx, and I have a few
> quick questions to ask.
>
> How is success vs failure determined with testing using Gitlab CI?
> It looks like everything goes into a log, but is there
On 29.08.2019 21:25, Igor Druzhinin wrote:
> On 29/08/2019 09:00, Roger Pau Monné wrote:
>>>
>>> I think we need to have this option to at least have a way to workaround
>>> problem (1). Problem (2) could be solved in Dom0 kernel by invoking
>>> xen_mcfg_late() earlier but before the first PCI bus
On 30.08.2019 08:33, Chao Gao wrote:
> On Thu, Aug 29, 2019 at 02:22:47PM +0200, Jan Beulich wrote:
>> On 19.08.2019 03:25, Chao Gao wrote:
>>> @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch)
>>> return ret;
>>> }
>>>
>>> +static int microcode_nmi_callback(const struct
Can we take a step back and figure out what we want to do here?
AFAICS this function allocates memory for the swiotlb-xen buffer,
and that means it must be <= 32-bit addressable to satisfy the DMA API
guarantees. That means we generally want to use GFP_DMA32 everywhere
that exists, but on
On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote:
> We would like to have a common maintainers email address for DornerWorks
> maintained code, which currently is the ARINC653 scheduler. This will
> enable us to better monitor and respond to the Xen community. This patch
> adds a
On 30.08.2019 05:22, Chao Gao wrote:
> On Thu, Aug 29, 2019 at 12:06:28PM +0200, Jan Beulich wrote:
>> On 22.08.2019 15:59, Roger Pau Monné wrote:
>>> Seeing how this works I'm not sure what's the best option here. As
>>> updating will be attempted on other CPUs, I'm not sure if it's OK to
>>>
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
These are revisions of the remaining uncommitted patches from my
previous series:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01737.html
Paul Durrant (6):
x86/domain: remove the 'oos_off' flag
domain: introduce XEN_DOMCTL_CDF_iommu flag
use is_iommu_enabled() where
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v3:
- Force 'oos_off' to be set for PV guests (to avoid call to
> -Original Message-
> From: Igor Druzhinin
> Sent: 30 August 2019 12:57
> To: xen-devel@lists.xenproject.org
> Cc: jbeul...@suse.com; Andrew Cooper ; Paul Durrant
> ; w...@xen.org; Roger Pau Monne
> ; Igor Druzhinin
>
> Subject: [PATCH] x86/domain: don't destroy IOREQ servers on soft
On 23.08.2019 16:25, Andrew Cooper wrote:
> We are now down to 0 SVM maintainers who are active and wish to hold the
> position. Fall back to general x86 maintenance until this position changes.
What you say above works for SVM, but ...
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -144,18
On 29.08.2019 19:36, Julien Grall wrote:
> On 29/08/2019 17:41, Jan Beulich wrote:
>> On 19.08.2019 16:26, Julien Grall wrote:
>>> No functional change intended.
>>>
>>> Only reasonable clean-ups are done in this patch. The rest will use _gfn
>>> for the time being.
>>>
>>> The code in
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled
(i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject
the flag
On 30.08.2019 04:09, Chao Gao wrote:
> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote:
>> L.S.,
>>
>> While testing xen-unstable, my AMD system crashes during early boot while
>> loading microcode with an "Early fatal page fault".
>> Reverting commit
Several public headers of the hypervisor contain structures with
variable length arrays. In order to be usable with different compilers
those definitions are depending on the compiler type and the standard
supported by the compiler.
In order to avoid open coding the different variants in each
On 30.08.2019 14:12, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 30 August 2019 12:57
>> To: xen-devel@lists.xenproject.org
>> Cc: jbeul...@suse.com; Andrew Cooper ; Paul
>> Durrant
>> ; w...@xen.org; Roger Pau Monne
>> ; Igor Druzhinin
>>
>> Subject:
> On 30 Aug 2019, at 09:29, Paul Durrant wrote:
>
> tools/ocaml/libs/xc/xenctrl.ml | 4 +
> tools/ocaml/libs/xc/xenctrl.mli | 4 +
> tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++-
The OCaml part looks good to me. Options are represented on the OCaml side as a
list (of an
On 30.08.19 17:22, Jan Beulich wrote:
On 30.08.2019 16:29, Juergen Gross wrote:
On 30.08.19 16:21, Jan Beulich wrote:
On 30.08.2019 10:32, Juergen Gross wrote:
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t);
On 30.08.2019 17:30, Juergen Gross wrote:
> On 30.08.19 17:22, Jan Beulich wrote:
>> On 30.08.2019 16:29, Juergen Gross wrote:
>>> On 30.08.19 16:21, Jan Beulich wrote:
On 30.08.2019 10:32, Juergen Gross wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@
In order for "acpi_sleep=s3_mode" to have any effect, we should record
the video mode we switched to during boot. Since right now there's mode
setting code for VESA modes only in the resume case, record the mode
just in that one case.
Signed-off-by: Jan Beulich
---
I'm wondering actually whether
To "compensate" for the code size growth by an earlier change:
- drop "trampoline" labels (in almost all cases the target label is
reachable with an 8-bit-displacement branch anyway, and a single 16-
bit-displacement branch is still better than a pair of two branches)
- drop an entirely dead
On 30.08.2019 10:29, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
> * default until we find a good solution to resolve it.
> */
> bool_t __read_mostly iommu_intpost;
On 30.08.2019 10:32, Juergen Gross wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t);
> DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>
> +/* Define a variable length array (depends on
On Fri, 2019-08-30 at 16:25 +0200, Jan Beulich wrote:
> On 21.08.2019 18:35, David Woodhouse wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -727,7 +727,17 @@ trampoline_setup:
> > /* Switch to low-memory stack which lives at the end of
> > trampoline
On 30.08.2019 16:29, Juergen Gross wrote:
> On 30.08.19 16:21, Jan Beulich wrote:
>> On 30.08.2019 10:32, Juergen Gross wrote:
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/xen.h
>>> @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t);
>>> DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> -Original Message-
> From: Jan Beulich
> Sent: 30 August 2019 15:08
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
>
On 30.08.2019 10:29, Paul Durrant wrote:
> This patch introduces a common domain creation flag to determine whether
> the domain is permitted to make use of the IOMMU. Currently the flag is
> always set (for both dom0 and domU) if the IOMMU is globally enabled
> (i.e. iommu_enabled == 1).
First and foremost make timer_softirq_action() avoid growing the heap
if its new size can't be stored without truncation. 64k entries is a
lot, and I don't think we're at risk of actually running into the issue,
but I also think it's better not to allow for hard to debug problems to
occur in the
When disabling SMT at runtime, secondary threads should no longer be
candidates for bringing back up in response to _PUD ACPI events. Purge
them from the tracking array.
Doing so involves adding locking to guard accounting data in the core
parking code. While adding the declaration for the lock,
On 19.08.2019 14:08, Eslam Elnikety wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1170,6 +1170,7 @@ long do_event_channel_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> case EVTCHNOP_init_control: {
> struct evtchn_init_control
On 30.08.19 16:21, Jan Beulich wrote:
On 30.08.2019 10:32, Juergen Gross wrote:
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t);
DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
+/* Define a
On Fri, 2019-08-30 at 17:10 +0200, Jan Beulich wrote:
> On 21.08.2019 18:35, David Woodhouse wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -699,14 +699,30 @@ trampoline_setup:
> > cmp $sym_offs(__trampoline_rel_stop),%edi
> > jb 1b
>
1: x86/ACPI: restore VESA mode upon resume from S3
2: x86: a little bit of 16-bit video mode setting code cleanup
3: x86: shrink video_{flags,mode} to {8,16} bits
Patch 1 is meant to address an issue I've observed while testing
the v1 patch that was committed already, and patch 2 is simply a
On 30.08.2019 15:38, Jan Beulich wrote:
> 1: x86/ACPI: restore VESA mode upon resume from S3
> 2: x86: a little bit of 16-bit video mode setting code cleanup
> 3: x86: shrink video_{flags,mode} to {8,16} bits
And (sadly) the patches as attachments again.
Jan
x86/ACPI: restore VESA mode upon
We really don't need them to be any wider.
Also remove the C level declaration (and hence also the GLOBAL) of
video_mode altogether; it's used in assembly code only.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/boot/wakeup.S
+++
On 30.08.2019 10:29, Paul Durrant wrote:
> Now that there is a per-domain IOMMU-enable flag, which should be set if
> any device is going to be passed through, stop deferring page table
> construction until the assignment is done. Also don't tear down the tables
> again when the last device is
On 21.08.2019 18:35, David Woodhouse wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -727,7 +727,17 @@ trampoline_setup:
> /* Switch to low-memory stack which lives at the end of trampoline
> region. */
> mov sym_fs(trampoline_phys),%edi
>
On 21.08.2019 18:35, David Woodhouse wrote:
> From: David Woodhouse
>
> Ditch the bootsym() access from C code for the variables populated by
> 16-bit boot code. As well as being cleaner this also paves the way for
> not having the 16-bit boot code in low memory for no-real-mode or EFI
> loader
On 30.08.2019 10:29, Paul Durrant wrote:
> --- a/xen/include/asm-x86/iommu.h
> +++ b/xen/include/asm-x86/iommu.h
> @@ -61,8 +61,17 @@ extern struct iommu_ops iommu_ops;
>
> #ifdef NDEBUG
> # include
> -# define iommu_call(ops, fn, args...) alternative_call(iommu_ops.fn, ##
> args)
> -#
flight 140786 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-amd64-amd64-xl-pvshim 20
On Fri, 2019-08-30 at 17:43 +0200, Jan Beulich wrote:
> On 21.08.2019 18:35, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Ditch the bootsym() access from C code for the variables populated by
> > 16-bit boot code. As well as being cleaner this also paves the way for
> > not having
flight 140836 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140836/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 140780 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 139876
See https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git-series
It solves some problems with git and makes managing series a little easier, but
you still have to use autosquash
So, it's not perfect
Lars
___
Xen-devel mailing list
flight 140804 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 139910
flight 140783 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 139936
Tests
> -Original Message-
> From: Jan Beulich
> Sent: 30 August 2019 14:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Suravee Suthikulpanit
> ; JulienGrall
> ; Andrew Cooper ; Roger Pau
> Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ; Jun Nakajima ; Kevin Tian
> ;
>
On 21.08.2019 18:35, David Woodhouse wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -699,14 +699,30 @@ trampoline_setup:
> cmp $sym_offs(__trampoline_rel_stop),%edi
> jb 1b
>
> -/* Patch in the trampoline segment. */
> +
flight 140817 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
This change provides sufficient information to allow get_maintainer.pl /
add_maintainers.pl scripts to be run on xen sister repositories such as
mini-os.git, osstest.git, etc
A suggested template for sister repositories of Xen is
This file
Instead of using a hardcoded location, inherit the
location from $0
Signed-off-by: Lars Kurth
---
scripts/add_maintainers.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 09e9f66..5a6d0f6 100755
---
Use-case: Allow using both scripts on xen repositories such as
mini-os.git, osstest.git,
Assumptions: the repository contains a MAINTAINERS file that
follows the same conventions as the file in xen.git
A suggested template for sister repositories of Xen
Specifically:
* Move check until after the MAINTAINERS file has been read
* Add get_xen_maintainers_file_version() for check
* Remove top_of_tree as not needed any more
* Faiul with extended error message when used out of tree
Signed-off-by: Lars Kurth
---
scripts/get_maintainer.pl | 58
flight 140807 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140807/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 37eef91017ad042035090cae46557f9d6e2d5917
baseline version:
ovmf
On 30/08/2019 09:49, Jan Beulich wrote:
> On 30.08.2019 04:09, Chao Gao wrote:
>> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> While testing xen-unstable, my AMD system crashes during early boot while
>>> loading microcode with an "Early fatal page fault".
flight 140830 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140830/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-check fail blocked in 140778
test-armhf-armhf-libvirt-raw 13
flight 140832 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail REGR. vs. 140282
build-amd64-xsm
+ Juergen, Boris
On Fri, 30 Aug 2019, Christoph Hellwig wrote:
> Can we take a step back and figure out what we want to do here?
>
> AFAICS this function allocates memory for the swiotlb-xen buffer,
> and that means it must be <= 32-bit addressable to satisfy the DMA API
> guarantees. That
flight 140822 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
140598
Tests which did
flight 140831 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140831/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 32e0aaee87996d207cd719c68dcdb0a5df7e44f6
baseline version:
freebsd
On Thu, Aug 29, 2019 at 02:22:47PM +0200, Jan Beulich wrote:
>On 19.08.2019 03:25, Chao Gao wrote:
>> @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch)
>> return ret;
>> }
>>
>> +static int microcode_nmi_callback(const struct cpu_user_regs *regs, int cpu)
>> +{
>> +/*
On Thu, Aug 29, 2019 at 02:11:10PM +0200, Jan Beulich wrote:
>On 27.08.2019 06:52, Chao Gao wrote:
>> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>>> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
On 19/08/2019 02:25, Chao Gao wrote:
> register an nmi
70 matches
Mail list logo
