All functions in arch/x86/xen/irq.c and arch/x86/xen/xen-asm*.S are
specific to PV guests. Include them in the kernel with
CONFIG_XEN_PV only.
Make the PV specific code in arch/x86/entry/entry_*.S dependent on
CONFIG_XEN_PV instead of CONFIG_XEN.
The HVM specific code should depend on CONFIG_XEN_
flight 125781 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125781/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
flight 125794 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125794/
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 wh
flight 125773 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Tue, Aug 7, 2018 at 2:26 AM, Lars Kurth wrote:
> Dear community members,
>
> please send me agenda items for next week’s community call by this Friday.
>
>
If there is time available on the call, I'd like to ask about Xen's memory
scrubbing, to better understand the changes made to it in recen
flight 125793 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125793/
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 wh
> On Aug 7, 2018, at 11:49 AM, Boris Ostrovsky
> wrote:
>
>> On 08/07/2018 01:20 PM, George Dunlap wrote:
>>> On Mon, Aug 6, 2018 at 8:10 PM, Chris Brannon wrote:
>>> I just got the following patch from a colleague. It's a backport of
>>> the XSA 274 kernel patch to 4.9.x kernels. The kerne
flight 125792 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125792/
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 wh
On 8/7/18 12:15 PM, Greg KH wrote:
> On Tue, Aug 07, 2018 at 12:08:07PM -0700, Srivatsa S. Bhat wrote:
>> Also, upstream commit e01e80634ecdde1 (fork: unconditionally clear
>> stack on fork) applies cleanly on 4.14 stable, so it would be great to
>> cherry-pick it to 4.14 stable as well.
>
> It is
On Tue, Aug 07, 2018 at 12:08:07PM -0700, Srivatsa S. Bhat wrote:
> Also, upstream commit e01e80634ecdde1 (fork: unconditionally clear
> stack on fork) applies cleanly on 4.14 stable, so it would be great to
> cherry-pick it to 4.14 stable as well.
It is already in the 4.14.60 release, did I someh
On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall wrote:
> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
>>
>> Hi, Julien
>
>
> Hi Oleksandr,
Hi Julien
>
>
>>
>> On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From
On 8/7/18 6:49 AM, Greg KH wrote:
> On Fri, Aug 03, 2018 at 04:20:31PM -0700, Srivatsa S. Bhat wrote:
>> On 8/2/18 3:22 PM, Kees Cook wrote:
>>> On Thu, Aug 2, 2018 at 12:22 PM, Srivatsa S. Bhat
>>> wrote:
On 7/26/18 4:09 PM, Kees Cook wrote:
> On Tue, Jul 24, 2018 at 3:02 PM, Jiri Kosina
flight 125779 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125779/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 08/07/2018 01:20 PM, George Dunlap wrote:
> On Mon, Aug 6, 2018 at 8:10 PM, Chris Brannon wrote:
>> I just got the following patch from a colleague. It's a backport of
>> the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in
>> the XSA would not apply cleanly. Would someone mi
On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
Hi, Julien
Hi Oleksandr,
On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall wrote:
Hi,
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Renesas "Stout" development board (with different expansion boards)
is also based o
On Mon, Aug 6, 2018 at 8:10 PM, Chris Brannon wrote:
> I just got the following patch from a colleague. It's a backport of
> the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in
> the XSA would not apply cleanly. Would someone mind reviewing it? It
> would be much appreciated.
On Tue, Aug 7, 2018 at 6:22 PM, Julien Grall wrote:
>
>
> On 07/08/18 15:28, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall wrote:
>>>
>>> Hi,
Hi, Julien
>>
>>
>> Hi, Julien
>>
>>>
>>> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr
Hi, Julien
On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall wrote:
> Hi,
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Renesas "Stout" development board (with different expansion boards)
>> is also based on R-Car Gen2 SoC. So extend compat array with
>> bo
This patch adds driver for UART controller present on Amlogic S905 SoC.
https://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf
Signed-off-by: Amit Singh Tomar
---
xen/drivers/char/Kconfig | 8 ++
xen/drivers/char/Makefile | 1 +
xen/drivers/char/meson-uart.c | 290 +++
This small series enabled XEN booting on NanoPI K2 board[1] based
on Amlogic SoC.
It has been tested by booting Dom0 Kernel.
TODO:
* Wiki page to capture XEN boot info.
[1]: https://www.friendlyarm.com/index.php?route=product/product&product_id=186
Amit Singh Tomar (2):
xen/arm: Add A
Signed-off-by: Amit Singh Tomar
---
docs/misc/arm/early-printk.txt | 1 +
xen/arch/arm/Rules.mk | 1 +
xen/arch/arm/arm64/debug-meson.inc | 50 ++
3 files changed, 52 insertions(+)
create mode 100644 xen/arch/arm/arm64/debug-meson.inc
diff
flight 125791 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125791/
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 wh
This run is configured for baseline tests only.
flight 75052 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-i38
On Tue, Aug 7, 2018 at 10:45 AM Tamas K Lengyel
wrote:
>
> On Tue, Aug 7, 2018 at 10:04 AM Tamas K Lengyel
> wrote:
> >
> > On Tue, Aug 7, 2018 at 9:09 AM Roger Pau Monné wrote:
> > >
> > > On Tue, Aug 07, 2018 at 08:45:07AM -0600, Tamas K Lengyel wrote:
> > > > On Tue, Aug 7, 2018 at 8:37 AM Ro
On Tue, Aug 7, 2018 at 10:04 AM Tamas K Lengyel
wrote:
>
> On Tue, Aug 7, 2018 at 9:09 AM Roger Pau Monné wrote:
> >
> > On Tue, Aug 07, 2018 at 08:45:07AM -0600, Tamas K Lengyel wrote:
> > > On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Tue, Aug 07, 2018 at 08:
On 08/07/2018 11:21 AM, Juergen Gross wrote:
> On 07/08/18 16:00, Boris Ostrovsky wrote:
>> On 08/07/2018 09:10 AM, Juergen Gross wrote:
>>> On 17/07/18 14:01, Juergen Gross wrote:
Some Xen related cleanups:
- move some pv-only code from CONFIG_XEN to CONFIG_XEN_PV
- use CONFIG_XEN_P
On 08/07/2018 11:17 AM, Juergen Gross wrote:
> On 07/08/18 16:02, Boris Ostrovsky wrote:
>> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>>> On 13/06/18 11:58, Juergen Gross wrote:
Using privcmd_call() for a singleton multicall seems to be wrong, as
privcmd_call() is using stac()/clac() t
On Tue, Aug 07, 2018 at 05:46:06AM -0600, Jan Beulich wrote:
> >>> On 07.08.18 at 12:00, wrote:
> > --- a/xen/include/asm-x86/hvm/domain.h
> > +++ b/xen/include/asm-x86/hvm/domain.h
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> Why? struct vcpu_hvm_context
>>> On 07.08.18 at 18:13, wrote:
> On Tue, Aug 07, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
>> >>> On 07.08.18 at 12:00, wrote:
>> > --- /dev/null
>> > +++ b/xen/include/asm-x86/hvm/event.h
>> > @@ -0,0 +1,14 @@
>> > +#ifndef ASM_HVM_EVENT_H
>> > +#define ASM_HVM_EVENT_H
>> > +
>> > +#if CONF
On Tue, Aug 07, 2018 at 10:18:36AM -0600, Jan Beulich wrote:
> >>> On 07.08.18 at 18:08, wrote:
> > On Tue, Aug 07, 2018 at 04:44:13AM -0600, Jan Beulich wrote:
> >> >>> On 07.08.18 at 12:00, wrote:
> >> > --- a/xen/arch/x86/x86_64/traps.c
> >> > +++ b/xen/arch/x86/x86_64/traps.c
> >> > @@ -352,1
On Tue, Aug 07, 2018 at 05:33:35AM -0600, Jan Beulich wrote:
> >>> On 07.08.18 at 12:00, wrote:
> > This function is common to both PV and HVM. Move it to x86 common
> > code.
>
> I'm afraid that's the wrong way round: p2m_memory_type_changed()
> is HVM (in fact EPT) specific. The only uses of th
>>> On 07.08.18 at 18:08, wrote:
> On Tue, Aug 07, 2018 at 04:44:13AM -0600, Jan Beulich wrote:
>> >>> On 07.08.18 at 12:00, wrote:
>> > --- a/xen/arch/x86/x86_64/traps.c
>> > +++ b/xen/arch/x86/x86_64/traps.c
>> > @@ -352,12 +352,19 @@ void subarch_percpu_traps_init(void)
>> > void hypercall_pa
>>> On 07.08.18 at 18:04, wrote:
>> > > > (XEN) [VT-D]iommu.c:919: iommu_fault_status: Fault Overflow
>> > > > (XEN) [VT-D]iommu.c:921: iommu_fault_status: Primary Pending Fault
>> > > > (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
>> > > > 4625f3a000, iommu reg = 82c00
On Tue, Aug 07, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
> >>> On 07.08.18 at 12:00, wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-x86/hvm/event.h
> > @@ -0,0 +1,14 @@
> > +#ifndef ASM_HVM_EVENT_H
> > +#define ASM_HVM_EVENT_H
> > +
> > +#if CONFIG_HVM
> > +
> > +int hvm_local_events_need_
On Tue, Aug 07, 2018 at 04:44:13AM -0600, Jan Beulich wrote:
> >>> On 07.08.18 at 12:00, wrote:
> > --- a/xen/arch/x86/x86_64/traps.c
> > +++ b/xen/arch/x86/x86_64/traps.c
> > @@ -352,12 +352,19 @@ void subarch_percpu_traps_init(void)
> > void hypercall_page_initialise(struct domain *d, void *hyp
On Tue, Aug 7, 2018 at 9:09 AM Roger Pau Monné wrote:
>
> On Tue, Aug 07, 2018 at 08:45:07AM -0600, Tamas K Lengyel wrote:
> > On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné wrote:
> > >
> > > On Tue, Aug 07, 2018 at 08:29:49AM -0600, Tamas K Lengyel wrote:
> > > > On Tue, Aug 7, 2018 at 8:04 AM
On 07/08/18 16:14, Roger Pau Monné wrote:
> On Tue, Aug 07, 2018 at 08:31:31AM +0200, Juergen Gross wrote:
>> On 06/08/18 18:16, Roger Pau Monné wrote:
>>> On Mon, Aug 06, 2018 at 01:34:01PM +0200, Juergen Gross wrote:
Add a periodic cleanup function to remove old persistent grants which
My recent patch [1] to qemu-xen-traditional removes the last use of the
'default' ioreq server in Xen. (This is a catch-all ioreq server that is
used if no explicitly registered I/O range is targetted).
This patch can be applied once that patch is committed, to remove the
(>100 lines of) redundant
On 07/08/18 15:28, Oleksandr Tyshchenko wrote:
On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall wrote:
Hi,
Hi, Julien
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatib
On 07/08/18 16:00, Boris Ostrovsky wrote:
> On 08/07/2018 09:10 AM, Juergen Gross wrote:
>> On 17/07/18 14:01, Juergen Gross wrote:
>>> Some Xen related cleanups:
>>> - move some pv-only code from CONFIG_XEN to CONFIG_XEN_PV
>>> - use CONFIG_XEN_PVHVM in Makefile instead of #ifdef around a complete
Hi Oleksandr,
On 07/08/18 16:01, Oleksandr Tyshchenko wrote:
On Tue, Aug 7, 2018 at 4:43 PM, Julien Grall wrote:
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
I would prefer if you introduce a local variable for the params. This would
avoid to write uart->params everywhere.
Agree. Do you wan
On 07/08/18 15:45, Tamas K Lengyel wrote:
> On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné wrote:
>> On Tue, Aug 07, 2018 at 08:29:49AM -0600, Tamas K Lengyel wrote:
>>> On Tue, Aug 7, 2018 at 8:04 AM Roger Pau Monne wrote:
Hello,
The following series implement a workaround for mis
Hi,
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Renesas "Stout" development board (with different expansion boards)
is also based on R-Car Gen2 SoC. So extend compat array with
board's compatible strings.
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellin
On 07/08/18 16:02, Boris Ostrovsky wrote:
> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>> On 13/06/18 11:58, Juergen Gross wrote:
>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>> Linux user space.
>>> On 07.08.18 at 17:02, wrote:
>>
>> >
>> > -hvm_get_guest_pat(v, &hw_mtrr.msr_pat_cr);
>> > +memcpy(hw_mtrr.msr_mtrr_fixed, mtrr_state->fixed_ranges,
>> > NUM_FIXED_MSR);
>> You want to BUILD_BUG_ON() array sizes differing, and then use
>> sizeof() in the call to memcpy().
>>
>
On Tue, Aug 07, 2018 at 08:45:07AM -0600, Tamas K Lengyel wrote:
> On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné wrote:
> >
> > On Tue, Aug 07, 2018 at 08:29:49AM -0600, Tamas K Lengyel wrote:
> > > On Tue, Aug 7, 2018 at 8:04 AM Roger Pau Monne
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > >
>
> >
> > -hvm_get_guest_pat(v, &hw_mtrr.msr_pat_cr);
> > +memcpy(hw_mtrr.msr_mtrr_fixed, mtrr_state->fixed_ranges,
> > NUM_FIXED_MSR);
> You want to BUILD_BUG_ON() array sizes differing, and then use
> sizeof() in the call to memcpy().
>
In this case sizes are different:
msr_mtrr_fi
On Tue, Aug 7, 2018 at 4:43 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Extend existing driver to be able to handle SCIFA interface as well.
>> SCIF and SCIFA have lot in common, though SCIFA has d
flight 125775 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125775/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 91a5b13650752a54cf766791aa369495c3426485
baseline version:
ovmf d3bc33731f5b039bf3df7
flight 125787 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125787/
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 wh
flight 125770 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné wrote:
>
> On Tue, Aug 07, 2018 at 08:29:49AM -0600, Tamas K Lengyel wrote:
> > On Tue, Aug 7, 2018 at 8:04 AM Roger Pau Monne wrote:
> > >
> > > Hello,
> > >
> > > The following series implement a workaround for missing RMRR
> > > entries for a PVH
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 August 2018 15:31
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [PATCH v2] x86/hvm: remove default ioreq server
>
> >>> On 07.08.18 at 16:02, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 August 2018 15:37
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: RE: [PATCH v20 1/2]
On Tue, Aug 07, 2018 at 04:18:21PM +0200, Roger Pau Monné wrote:
> On Mon, Aug 06, 2018 at 06:20:50PM +0100, Anthony PERARD wrote:
> > On Thu, Aug 02, 2018 at 05:50:52PM +0200, Roger Pau Monné wrote:
> > > On Fri, Jul 27, 2018 at 03:06:13PM +0100, Anthony PERARD wrote:
> > > Can you provide a comme
On Tue, Aug 07, 2018 at 08:29:49AM -0600, Tamas K Lengyel wrote:
> On Tue, Aug 7, 2018 at 8:04 AM Roger Pau Monne wrote:
> >
> > Hello,
> >
> > The following series implement a workaround for missing RMRR
> > entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
> > option.
> >
> >
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 07 August 2018 15:03
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ; Ju
>>> On 07.08.18 at 16:14, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 August 2018 14:38
>>
>> >>> On 06.08.18 at 14:54, wrote:
>> > --- a/xen/common/grant_table.c
>> > +++ b/xen/common/grant_table.c
>> > @@ -3860,6 +3860,38 @@ int mem_sharing_gref_to_gfn(struct
>> grant_ta
>>> On 07.08.18 at 16:02, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4093,12 +4093,15 @@ static int hvm_allow_set_param(struct domain *d,
> case HVM_PARAM_CONSOLE_EVTCHN:
> case HVM_PARAM_X87_FIP_WIDTH:
> break;
> +/* The following parameters
On Tue, Aug 7, 2018 at 8:04 AM Roger Pau Monne wrote:
>
> Hello,
>
> The following series implement a workaround for missing RMRR
> entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
> option.
>
> The PVH workaround identity maps all regions marked as reserved in the
> memory ma
On Tue, Aug 7, 2018 at 4:48 PM, Julien Grall wrote:
> Hi,
Hi, Julien
>
> On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Add support for Renesas "Stout" development board based on
>> R-Car H2 SoC which has SCIFA compatible UART.
>>
>> Actually existing SCIF
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 07 August 2018 15:03
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Ian Jackson ; Tim
>
On Mon, Aug 06, 2018 at 06:20:50PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 05:50:52PM +0200, Roger Pau Monné wrote:
> > On Fri, Jul 27, 2018 at 03:06:13PM +0100, Anthony PERARD wrote:
> > Can you provide a comment explaining how is this supposed to work? The
> > current code is alrea
On Tue, Aug 07, 2018 at 08:31:31AM +0200, Juergen Gross wrote:
> On 06/08/18 18:16, Roger Pau Monné wrote:
> > On Mon, Aug 06, 2018 at 01:34:01PM +0200, Juergen Gross wrote:
> >> Add a periodic cleanup function to remove old persistent grants which
> >> are no longer in use on the backend side. Thi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 August 2018 14:38
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v20 1/2]
Hello,
The following series implement a workaround for missing RMRR
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option.
The PVH workaround identity maps all regions marked as reserved in the
memory map.
Note that this workaround is enabled by default on Intel hardware.
Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults on Intel hardware. Those faults
are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
be worked around on VTd hardware by manually adding RMRR entries on
the command line, this is
Introduce a new dom0-iommu=inclusive generic option that supersedes
iommu_inclusive_mapping. The previous behaviour is preserved and the
option should only be enabled by default on Intel hardware.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Fix typo in
To select the iommu configuration used by Dom0. This option supersedes
iommu=dom0-strict|dom0-passthrough.
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
---
Changes since v2:
- Change the style and text used in the xen command line document.
- Don't allow none
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.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/d
My recent patch [1] to qemu-xen-traditional removes the last use of the
'default' ioreq server in Xen. (This is a catch-all ioreq server that is
used if no explicitly registered I/O range is targetted).
This patch can be applied once that patch is committed, to remove the
(>100 lines of) redundant
On 08/07/2018 09:11 AM, Juergen Gross wrote:
> On 13/06/18 11:58, Juergen Gross wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Add a new xen_single_call() function to b
On 08/07/2018 09:10 AM, Juergen Gross wrote:
> On 17/07/18 14:01, Juergen Gross wrote:
>> Some Xen related cleanups:
>> - move some pv-only code from CONFIG_XEN to CONFIG_XEN_PV
>> - use CONFIG_XEN_PVHVM in Makefile instead of #ifdef around a complete source
>> - add SPDX identifier where missing
>
On Fri, Aug 03, 2018 at 04:20:31PM -0700, Srivatsa S. Bhat wrote:
> On 8/2/18 3:22 PM, Kees Cook wrote:
> > On Thu, Aug 2, 2018 at 12:22 PM, Srivatsa S. Bhat
> > wrote:
> >> On 7/26/18 4:09 PM, Kees Cook wrote:
> >>> On Tue, Jul 24, 2018 at 3:02 PM, Jiri Kosina wrote:
> On Tue, 24 Jul 2018,
Hi,
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SCIF UART support (debug-scif.inc) and
newly added SCIFA UART support (debug-scifa.inc) diff
Hi Oleksandr,
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.
Use compatible string to recognize wh
On Tue, Aug 07, 2018 at 10:26:11AM +0100, Lars Kurth wrote:
> Dear community members,
>
> please send me agenda items for next week’s community call by this Friday.
> Note that this a week later than normal, because I had community calls in
> my diary as the week before Advisory Board meetings
flight 125769 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
>>> On 06.08.18 at 14:54, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3860,6 +3860,38 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt,
> grant_ref_t ref,
> }
> #endif
>
> +/* caller must hold read or write lock */
> +static int gnttab_get_status_frame_
Hi Oleksandr,
On 06/08/18 19:35, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Tyshchenko
CC: Stefano Stabellini
CC: Julien Grall
Acked-by: Julien Grall
Cheers,
---
xen/drivers/char/scif-uart.c| 4
xen/include/asm-arm/scif-uart.h | 11 ---
On 13/06/18 11:58, Juergen Gross wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
>
> Add a new xen_single_call() function to be use for that purpose.
>
> Reported-by: Jan Beuli
On 17/07/18 14:01, Juergen Gross wrote:
> Some Xen related cleanups:
> - move some pv-only code from CONFIG_XEN to CONFIG_XEN_PV
> - use CONFIG_XEN_PVHVM in Makefile instead of #ifdef around a complete source
> - add SPDX identifier where missing
>
> Juergen Gross (4):
> xen: move pv irq related
>>> On 03.08.18 at 15:53, wrote:
> Alexandru Isaila (14):
>
> x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func
> x86/hvm: Introduce hvm_save_tsc_adjust_one() func
> x86/hvm: Introduce hvm_save_cpu_ctxt_one func
> x86/hvm: Introduce hvm_save_cpu_xsave_states_one
> x86/hvm: Introduce hvm_save_cpu_
>>> On 03.08.18 at 15:53, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -591,12 +591,12 @@ long arch_do_domctl(
> !is_hvm_domain(d) )
> break;
>
> -domain_pause(d);
> +vcpu_pause(d->vcpu[domctl->u.hvmcontext_partial.instance]);
flight 125771 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125771/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
>>> On 03.08.18 at 15:53, wrote:
> @@ -155,7 +152,7 @@ int hvm_save_one(struct domain *d, unsigned int typecode,
> unsigned int instance,
> if ( !ctxt.data )
> return -ENOMEM;
>
> -if ( (rv = hvm_sr_handlers[typecode].save(d, &ctxt)) != 0 )
> +if ( (rv = hvm_sr_handlers[ty
>>> On 03.08.18 at 15:53, wrote:
> @@ -226,15 +225,14 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h)
> /* Save all available kinds of state */
> for ( i = 0; i <= HVM_SAVE_CODE_MAX; i++ )
> {
> -handler = hvm_sr_handlers[i].save;
> -save_one_handler = hvm
On Ma, 2018-08-07 at 06:09 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 03.08.18 at 15:53, wrote:
> > This is used to save data from a single instance.
> >
> > Signed-off-by: Alexandru Isaila
> > ---
> > xen/arch/x86/hvm/vlapic.c | 27 +++
> > 1 file changed
>>> On 03.08.18 at 15:53, wrote:
> This patch drops the use of save functions in hvm_save.
But quite a few types still have this set to NULL? How do things work
at this point of the series? Am I overlooking anything? I think this
needs to be swapped with patch 13.
Jan
>>> On 03.08.18 at 15:53, wrote:
> --- a/xen/arch/x86/hvm/save.c
> +++ b/xen/arch/x86/hvm/save.c
> @@ -196,7 +196,10 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h)
> struct hvm_save_header hdr;
> struct hvm_save_end end;
> hvm_save_handler handler;
> +hvm_save_vcpu_h
>>> On 03.08.18 at 15:53, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/arch/x86/hvm/vlapic.c | 27 +++
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/
flight 125782 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125782/
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 wh
>>> On 03.08.18 at 15:53, wrote:
> +for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
> +{
> +/* save physbase */
> +hw_mtrr.msr_mtrr_var[i * 2] = mtrr_state->var_ranges->base;
> +/* save physmask */
> +hw_mtrr.msr_mtrr_var[i * 2 + 1] = m
flight 75051 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-build fail REGR. vs. 75030
test-amd64-i386-
>>> On 07.08.18 at 12:00, wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
Why? struct vcpu_hvm_context only needs a forward declaration, just
like was the case originally. Full structu
>>> On 07.08.18 at 12:00, wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1144,6 +1144,7 @@ void force_update_vcpu_system_time(struct vcpu *v)
>
> static void update_domain_rtc(void)
> {
> +#if CONFIG_HVM
> struct domain *d;
>
> rcu_read_lock(&domlist_read_lock
>>> On 07.08.18 at 12:00, wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2732,3 +2732,11 @@ int allocate_and_map_msi_pirq(struct domain *d, int
> index, int *pirq_p,
>
> return ret;
> }
> +
> +void arch_evtchn_inject(struct vcpu *v)
> +{
> +#if CONFIG_HVM
> +if ( i
>>> On 07.08.18 at 12:00, wrote:
> This function is common to both PV and HVM. Move it to x86 common
> code.
I'm afraid that's the wrong way round: p2m_memory_type_changed()
is HVM (in fact EPT) specific. The only uses of the function that aren't
already HVM-specific are from domctl.c and from io
>>> On 07.08.18 at 12:48, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 August 2018 11:37
>>
>> >>> On 07.08.18 at 12:03, wrote:
>> > @@ -4373,13 +4372,6 @@ static int hvm_allow_get_param(struct domain
>> *d,
>> > case HVM_PARAM_ALTP2M:
>> > case HVM_PARAM_X87_FIP_
flight 125767 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
1 - 100 of 155 matches
Mail list logo
