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
> -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]
> -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
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
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
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 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
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
>
> >
> > -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 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,
> > > >
> > >
>>> 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 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.
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
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
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
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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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
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
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 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
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 +++
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
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
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 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 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
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 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
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 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 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
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 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 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 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 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
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 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
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_
101 - 155 of 155 matches
Mail list logo
