flight 125851 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125851/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1aa9314e3a84b27f74f239155fc0ec3f58b66be0
baseline version:
ovmf
flight 125855 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125855/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
flight 125853 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125853/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Hi all,
This patch is an update over this old patch series:
https://marc.info/?l=xen-devel=148579695530482
I inherited the seriest from Edgar, I made significant changes over the
old version, including addressing (almost) all comments. The main
changes are:
- split the largest patch into
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E.
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function resposible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce data structs to implement basic access controls.
Introduce the following three functions:
domain_has_node_access: check access to the node
domain_has_reset_access: check access to the reset line
domain_has_mmio_access: check access
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
From: Zhongze Liu
Author: Zhongze Liu
Add a new structure to the IDL family to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
And deleted some trailing white spaces.
[1]
Shared memory regions need to be advertised to the guest. Fortunately, a
device tree binding for special memory regions already exist:
reserved-memory.
Add a reserved-memory node for each shared memory region, for both
masters and slaves.
Signed-off-by: Stefano Stabellini
---
Changes in v7:
-
Add a "xen-dmabuf" device node for every shared region, compatible
"xen,dmabuf". Each of these nodes refers to the corresponding
reserved-memory node using a phandle.
These device nodes can be used to bind drivers that export the region to
userspace, or do other operations based on the reserved
From: Zhongze Liu
Author: Zhongze Liu
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the following steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
From: Zhongze Liu
Author: Zhongze Liu
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs
From: Zhongze Liu
Author: Zhongze Liu
Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
Hi,
This series implements a new xl config entry. Users can use the new
config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each
other through the static shared memory areas.
It was originally developed by
From: Zhongze Liu
Author: Zhongze Liu
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a master: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For
From: Zhongze Liu
Author: Zhongze Liu
The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based
flight 125824 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125824/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 125825 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
This run is configured for baseline tests only.
flight 75061 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75061/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75060
flight 125850 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125850/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
flight 125844 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125844/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 10ea1b6853f977ce4ed0193230ad7953edbb1894
baseline version:
ovmf
flight 125849 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125849/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
On Fri, Aug 10, 2018 at 06:49:12PM +0100, Andrew Cooper wrote:
> All but one user wants mfn as mfn_t, so switch its type. offset is only ever
> used when multipled by 8, so fold that into its initial calculation. Fold all
> the pointer arithmic on pl1e together, to avoid needless casts.
>
> No
All but one user wants mfn as mfn_t, so switch its type. offset is only ever
used when multipled by 8, so fold that into its initial calculation. Fold all
the pointer arithmic on pl1e together, to avoid needless casts.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
On 10/08/18 17:30, George Dunlap wrote:
> On 08/10/2018 05:00 PM, Jan Beulich wrote:
> On 10.08.18 at 17:35, wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 10 August 2018 16:31
To: Paul Durrant
Cc: Andrew Cooper ; xen-devel >>>
On 08/10/2018 05:00 PM, Jan Beulich wrote:
On 10.08.18 at 17:35, wrote:
>>> -Original Message-
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: 10 August 2018 16:31
>>> To: Paul Durrant
>>> Cc: Andrew Cooper ; xen-devel >> de...@lists.xenproject.org>
>>> Subject: RE:
flight 125846 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125846/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
>>> On 10.08.18 at 17:35, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 16:31
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-devel > de...@lists.xenproject.org>
>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>
>> >>>
> -Original Message-
> From: Andrew Cooper
> Sent: 10 August 2018 16:57
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich
> Subject: Re: [PATCH] x86/hvm/viridian: set shutdown_code in response to
> CrashNotify
>
> On 10/08/18 16:43, Paul Durrant wrote:
> > When
On 10/08/18 16:43, Paul Durrant wrote:
> When Windows writes the CrashNotify bit in the CRASH_CTL MSR then we know
> it is crashing, so set the domain shutdown code appropriately.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/hvm/viridian.c |
When Windows writes the CrashNotify bit in the CRASH_CTL MSR then we know
it is crashing, so set the domain shutdown code appropriately.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/viridian.c | 4
1 file changed, 4 insertions(+)
diff --git
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 16:31
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 17:08, wrote:
> >>
>>> On 10.08.18 at 17:08, wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 10 August 2018 13:56
>> To: Paul Durrant ; 'Jan Beulich'
>>
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>
>> On 10/08/18 13:43, Paul Durrant wrote:
>> >>
> -Original Message-
> From: Andrew Cooper
> Sent: 10 August 2018 13:56
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> On 10/08/18 13:43, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich
flight 125818 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
hvm_select_ioreq_server() is used to route an ioreq to the appropriate
ioreq server. For MMIO this is done by comparing the range of the ioreq
to the ranges registered by the device models of each ioreq server.
Unfortunately the calculation of the range if the ioreq completely ignores
the
These are probably both candidates for back-port.
Paul Durrant (2):
x86/hvm/ioreq: MMIO range checking completely ignores direction flag
x86/hvm/emulate: make sure rep I/O emulation does not cross GFN
boundaries
xen/arch/x86/hvm/emulate.c | 19 +++
When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee
On 10/08/18 16:22, Boris Ostrovsky wrote:
> On 08/10/2018 07:52 AM, Juergen Gross wrote:
>> A large amount of paravirt ops is used by Xen PV guests only. Add a new
>> config option PARAVIRT_XXL which is selected by XEN_PV. Later we can
>> put the Xen PV only paravirt ops under the PARACVIRT_XXL
flight 125820 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125820/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
This run is configured for baseline tests only.
flight 75060 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75060/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75057
On 08/10/2018 07:52 AM, Juergen Gross wrote:
> A large amount of paravirt ops is used by Xen PV guests only. Add a new
> config option PARAVIRT_XXL which is selected by XEN_PV. Later we can
> put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella.
What does "XXL" stand for? My
flight 125821 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 125841 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317
Tests which did
This run is configured for baseline tests only.
flight 75059 seabios real [real]
http://osstest.xensource.com/osstest/logs/75059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10
flight 125843 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125843/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
>>> On 10.08.18 at 14:42, wrote:
> As it currently stands, 'xpti=dom0' is indistinguishable from the default
> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed
> hardware.
>
> Switch opt_xpti to use -1 as a default like all our other related options, and
> clobber
On 10/08/18 13:43, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 13:37
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>
> On 10.08.18 at 14:22, wrote:
Hi Oleksandr,
On 08/10/2018 12:47 PM, Oleksandr Tyshchenko wrote:
On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall wrote:
On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
I am quite
flight 125837 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125837/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b3e1e343fe34d0173a53a61b10296e6522ce1f7c
baseline version:
ovmf
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 13:37
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 14:22, wrote:
> >> -Original Message-
> >> From: Jan Beulich
As it currently stands, 'xpti=dom0' is indistinguishable from the default
value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed
hardware.
Switch opt_xpti to use -1 as a default like all our other related options, and
clobber it as soon as we have a string to parse.
In
>>> On 10.08.18 at 14:22, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 13:13
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>
>> >>> On 10.08.18 at 14:08, wrote:
>> >>
On 10/08/18 14:06, Jan Beulich wrote:
On 10.08.18 at 13:52, wrote:
>> --- a/arch/x86/hyperv/mmu.c
>> +++ b/arch/x86/hyperv/mmu.c
>> @@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void)
>>
>> if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
>>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 13:13
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 14:08, wrote:
> >> -Original Message-
> >> From: Jan Beulich
>>> On 10.08.18 at 14:08, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 10 August 2018 13:02
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>
>> >>> On 10.08.18 at 12:37, wrote:
>> > These are
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 12:59
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> >>>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 13:02
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>
> >>> On 10.08.18 at 12:37, wrote:
> > These are probably both candidates for back-port.
> >
>>> On 10.08.18 at 13:52, wrote:
> --- a/arch/x86/hyperv/mmu.c
> +++ b/arch/x86/hyperv/mmu.c
> @@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void)
>
> if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
> pr_info("Using hypercall for remote TLB flush\n");
> -
>>> On 10.08.18 at 12:37, wrote:
> These are probably both candidates for back-port.
>
> Paul Durrant (2):
> x86/hvm/ioreq: MMIO range checking completely ignores direction flag
> x86/hvm/emulate: make sure rep I/O emulation does not cross GFN
> boundaries
>
>
>>> On 10.08.18 at 12:37, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,8 +184,23 @@ static int hvmemul_do_io(
> hvmtrace_io_assist();
> }
>
> -vio->io_req = p;
> +/*
> + * Make sure that we truncate rep MMIO at any GFN
The clobbers parameter from paravirt_patch_default() et al isn't used
any longer. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 7 +++
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/paravirt.c| 14 +-
Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h | 38 ++-
arch/x86/include/asm/paravirt.h | 2 --
paravirt_patch_call() and paravirt_patch_jmp() are used in paravirt.c
only. Convert them to static.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 6 --
arch/x86/kernel/paravirt.c| 12 ++--
2 files changed, 6 insertions(+), 12 deletions(-)
Instead of using six globally visible paravirt ops structures combine
them in a single structure, keeping the original structures as
sub-structures.
This avoids the need to assemble struct paravirt_patch_template at
runtime on the stack each time apply_paravirt() is being called (i.e.
when
The macros ENABLE_INTERRUPTS_SYSEXIT, GET_CR0_INTO_EAX and
PARAVIRT_ADJUST_EXCEPTION_FRAME are used nowhere. Remove their
definitions.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h | 4
arch/x86/include/asm/paravirt.h | 9 +
arch/x86/kernel/asm-offsets.c | 1 -
Most of the paravirt ops defined in pv_mmu_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/fixmap.h | 2 +-
arch/x86/include/asm/mmu_context.h| 4 +-
arch/x86/include/asm/paravirt.h | 115
This series removes some no longer needed stuff from paravirt
infrastructure and puts large quantities of paravirt ops under a new
config option PARAVIRT_XXL which is selected by XEN_PV only.
A pvops kernel without XEN_PV being configured is about 2.5% smaller
with this series applied.
tip
Most of the paravirt ops defined in pv_cpu_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/debugreg.h | 2 +-
arch/x86/include/asm/desc.h | 4 ++--
arch/x86/include/asm/irqflags.h | 16
There is no need any longer to store the clobbers in struct
paravirt_patch_site. Remove clobbers from the struct and from the
related macros.
While at it fix some lines longer than 80 characters.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 33
All items but name in pv_info are needed by Xen PV only. Define them
with CONFIG_PARAVIRT_XXL set only.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 2 ++
arch/x86/include/asm/paravirt_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 2 +-
A large amount of paravirt ops is used by Xen PV guests only. Add a new
config option PARAVIRT_XXL which is selected by XEN_PV. Later we can
put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella.
Signed-off-by: Juergen Gross
---
arch/x86/Kconfig | 3 +++
arch/x86/xen/Kconfig | 1
On 10/08/18 12:50, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 10 August 2018 12:14
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich
>> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
>> does not cross GFN
> -Original Message-
> From: Andrew Cooper
> Sent: 10 August 2018 12:14
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich
> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> On 10/08/18 11:37, Paul Durrant wrote:
On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall wrote:
> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
>>
>> Hi Julien.
>
>
> Hi Oleksandr,
Hi Julien
>
>> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
>>>
>>>
>>>
>>> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>> On 10.08.18 at 12:04, wrote:
> On Wed, Aug 08, 2018 at 06:35:47AM -0600, Jan Beulich wrote:
>> >>> On 08.08.18 at 12:07, wrote:
>> > So it's done before the iommu is initialized. This is required in
>> > order to be able to fetch the MMCFG regions from the domain struct.
>>
>> Is this a
>>> On 10.08.18 at 11:49, wrote:
> On 10/08/2018 09:08, Jan Beulich wrote:
> On 09.08.18 at 18:38, wrote:
>>> As it currently stands, 'xpti=dom0' is indistinguishable from the default
>>> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on
> fixed
>>> hardware.
>>>
>>>
On 10/08/18 11:37, Paul Durrant wrote:
> When emulating a rep I/O operation it is possible that the ioreq will
> describe a single operation that spans multiple GFNs. This is fine as long
> as all those GFNs fall within an MMIO region covered by a single device
> model, but unfortunately the
On 10/08/18 11:37, Paul Durrant wrote:
> hvm_select_ioreq_server() is used to route an ioreq to the appropriate
> ioreq server. For MMIO this is done by comparing the range of the ioreq
> to the ranges registered by the device models of each ioreq server.
> Unfortunately the calculation of the
On 09/08/18 08:03, Xiao Liang wrote:
> There is a call trace generated after commit
> 2d408c0d4574b01b9ed45e02516888bf925e11a9(
> xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file
> found
> under /proc/irq/xx/.
>
> This patch only picks up device type and id as its
flight 125817 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125817/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
hvm_select_ioreq_server() is used to route an ioreq to the appropriate
ioreq server. For MMIO this is done by comparing the range of the ioreq
to the ranges registered by the device models of each ioreq server.
Unfortunately the calculation of the range if the ioreq completely ignores
the
When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee
These are probably both candidates for back-port.
Paul Durrant (2):
x86/hvm/ioreq: MMIO range checking completely ignores direction flag
x86/hvm/emulate: make sure rep I/O emulation does not cross GFN
boundaries
xen/arch/x86/hvm/emulate.c | 17 -
xen/arch/x86/hvm/ioreq.c
flight 125839 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125839/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
On Wed, Aug 08, 2018 at 06:35:47AM -0600, Jan Beulich wrote:
> >>> On 08.08.18 at 12:07, wrote:
> > So it's done before the iommu is initialized. This is required in
> > order to be able to fetch the MMCFG regions from the domain struct.
>
> Is this a useful change to make? Regions not reported
On 10/08/2018 09:08, Jan Beulich wrote:
On 09.08.18 at 18:38, wrote:
>> As it currently stands, 'xpti=dom0' is indistinguishable from the default
>> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on
>> fixed
>> hardware.
>>
>> Switch opt_xpti to use -1 as a default
On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
Hi Julien.
Hi Oleksandr,
On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
Somehow I thought the platform was 64-bit and
flight 75058 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75058/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
75042
baseline version:
flight
>>> On 09.08.18 at 18:38, wrote:
> As it currently stands, 'xpti=dom0' is indistinguishable from the default
> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed
> hardware.
>
> Switch opt_xpti to use -1 as a default like all our other related options, and
> clobber
flight 125827 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125827/
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 125181
test-amd64-amd64-xl-qemuu-ws16-amd64 17
On 08/09/2018 05:41 AM, David Woodhouse wrote:
> On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
>> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>>
>> This version applies to v4.9.
>
> I think you can kill the 'xorl %ebx,%ebx' from error_entry too but yes,
> this does want to
On 09/08/18 18:38, Andrew Cooper wrote:
> As it currently stands, 'xpti=dom0' is indistinguishable from the default
> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed
> hardware.
>
> Switch opt_xpti to use -1 as a default like all our other related options, and
>
flight 125838 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125838/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
97 matches
Mail list logo
