On 22/11/17 15:05, Jan Beulich wrote:
> Jürgen, Boris,
>
> am I trying something that's not allowed, but selectable via Kconfig?
> On system with multiple IO-APICs (I assume that's what triggers the
> problem) I get
>
> Kernel panic - not syncing: Max apic_id exceeded!
Generally I don't think 32
where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 22/11/17 05:46, Andy Lutomirski wrote:
> On Tue, Nov 21, 2017 at 8:11 PM, Andy Lutomirski wrote:
>> On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski wrote:
>>> I'm doing:
>>>
>>> /usr/bin/qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -net none
>>> -nographic -kernel xen-4.8.2 -initrd './
Today Mini-OS will print all console output via the hypervisor, too.
Make this behavior configurable instead and default it to "off".
Signed-off-by: Juergen Gross
Acked-by: Samuel Thibault
---
V2: keep comment (Samuel Thibault)
---
Config.mk | 4
arch/x86
Today Mini-OS will print all console output via the hypervisor, too.
Make this behavior configurable instead and default it to "off".
Signed-off-by: Juergen Gross
---
Config.mk | 2 ++
arch/x86/testbuild/all-no | 1 +
arch/x86/testbuild/all-yes| 1 +
On 21/11/17 12:27, Jan Beulich wrote:
On 21.11.17 at 12:06, wrote:
>> The "special pages" for PVH guests include the frames for console and
>> Xenstore ring buffers. Those have to be marked as "Reserved" in the
>> guest's E820 map, as otherwise conflicts might arise later e.g. when
>> hotplug
On 21/11/17 11:42, Andrew Cooper wrote:
> On 21/11/17 07:44, Jan Beulich wrote:
> On 20.11.17 at 17:59, wrote:
>>> On 11/20/2017 11:43 AM, Jan Beulich wrote:
>>> On 20.11.17 at 17:28, wrote:
> On 11/20/2017 11:26 AM, Jan Beulich wrote:
> On 20.11.17 at 17:14, wrote:
>>> W
The "special pages" for PVH guests include the frames for console and
Xenstore ring buffers. Those have to be marked as "Reserved" in the
guest's E820 map, as otherwise conflicts might arise later e.g. when
hotplugging memory into the guest.
Signed-off-by: Juergen Gross
On 21/11/17 09:46, Jan Beulich wrote:
On 21.11.17 at 09:13, wrote:
>> On 21/11/17 08:50, Jan Beulich wrote:
>> On 20.11.17 at 19:28, wrote:
On 20/11/17 17:14, Jan Beulich wrote:
On 20.11.17 at 16:24, wrote:
>> So without my patch the RSDP table is loaded e.g. at about
On 21/11/17 08:50, Jan Beulich wrote:
On 20.11.17 at 19:28, wrote:
>> On 20/11/17 17:14, Jan Beulich wrote:
>> On 20.11.17 at 16:24, wrote:
On 20/11/17 15:20, Jan Beulich wrote:
On 20.11.17 at 15:14, wrote:
>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>> On 11/20/
On 20/11/17 17:14, Boris Ostrovsky wrote:
> On 11/20/2017 10:27 AM, Juergen Gross wrote:
>> On 20/11/17 15:25, Boris Ostrovsky wrote:
>>> On 11/20/2017 09:14 AM, Juergen Gross wrote:
>>>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>>>> On 11/20/2
On 20/11/17 17:14, Jan Beulich wrote:
On 20.11.17 at 16:24, wrote:
>> On 20/11/17 15:20, Jan Beulich wrote:
>> On 20.11.17 at 15:14, wrote:
On 20/11/17 14:56, Boris Ostrovsky wrote:
> On 11/20/2017 06:50 AM, Jan Beulich wrote:
> On 20.11.17 at 12:20, wrote:
>>> Whic
On 20/11/17 15:25, Boris Ostrovsky wrote:
> On 11/20/2017 09:14 AM, Juergen Gross wrote:
>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>>>>>> On 20.11.17 at 12:20, wrote:
>>>>> Which restri
On 20/11/17 15:20, Jan Beulich wrote:
On 20.11.17 at 15:14, wrote:
>> On 20/11/17 14:56, Boris Ostrovsky wrote:
>>> On 11/20/2017 06:50 AM, Jan Beulich wrote:
>>> On 20.11.17 at 12:20, wrote:
> Which restriction? I'm loading the RSDP table to its architectural
> correct addres if
On 20/11/17 14:56, Boris Ostrovsky wrote:
> On 11/20/2017 06:50 AM, Jan Beulich wrote:
> On 20.11.17 at 12:20, wrote:
>>> Which restriction? I'm loading the RSDP table to its architectural
>>> correct addres if possible, otherwise it will be loaded to the same
>>> address as without my patch.
On 20/11/17 11:57, Andrew Cooper wrote:
> On 20/11/17 10:43, Juergen Gross wrote:
>> On 20/11/17 11:21, Andrew Cooper wrote:
>>> On 20/11/17 10:04, Juergen Gross wrote:
>>>> On 20/11/17 10:58, Andrew Cooper wrote:
>>>>> On 20/11/2017 09:55, Juergen Gro
On 20/11/17 11:49, Wei Liu wrote:
> CC netfront maintainers.
>
> On Mon, Nov 20, 2017 at 11:41:09AM +0100, Eduardo Otubo wrote:
>> When unloading module xen_netfront from guest, dmesg would output
>> warning messages like below:
>>
>> [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in
On 20/11/17 11:21, Andrew Cooper wrote:
> On 20/11/17 10:04, Juergen Gross wrote:
>> On 20/11/17 10:58, Andrew Cooper wrote:
>>> On 20/11/2017 09:55, Juergen Gross wrote:
>>>> On 20/11/17 10:51, Roger Pau Monné wrote:
>>>>> Adding xen-devel, dropped i
On 20/11/17 10:58, Andrew Cooper wrote:
> On 20/11/2017 09:55, Juergen Gross wrote:
>> On 20/11/17 10:51, Roger Pau Monné wrote:
>>> Adding xen-devel, dropped it on my reply.
>>>
>>> Replying from my phone, sorry for the formatting.
>>>
>
On 20/11/17 10:51, Roger Pau Monné wrote:
> Adding xen-devel, dropped it on my reply.
>
> Replying from my phone, sorry for the formatting.
>
>
> El 20 nov. 2017 9:35, "Juergen Gross" <mailto:jgr...@suse.com>> escribió:
>
> For
loaded kernel if this space hasn't been used before.
Signed-off-by: Juergen Gross
---
Not sure if this is acceptable for 4.10, but I think PVH guest support
should include the possibility to use grub2 as a boot loader.
So please consider this patch for 4.10.
---
tools/libxc/xc_dom_hvmloader.c
On 17/11/17 20:42, Josh Poimboeuf wrote:
> On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote:
>> On 17/11/17 19:07, Borislav Petkov wrote:
>>> On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote:
>>>> Convert the hard-coded native patch asse
On 17/11/17 19:07, Borislav Petkov wrote:
> On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote:
>> Convert the hard-coded native patch assembly code strings to macros to
>> facilitate sharing common code between 32-bit and 64-bit.
>>
>> These macros will also be used by a future patch w
On 17/11/17 12:47, Juergen Gross wrote:
> Make sure the HVM mmio area (especially console and Xenstore pages) is
> marked as "reserved" in the guest's E820 map, as otherwise conflicts
> might arise later, e.g. when hotplugging memory into the guest.
>
> Signed-off-b
On 17/11/17 13:26, Jan Beulich wrote:
On 17.11.17 at 12:47, wrote:
>> Make sure the HVM mmio area (especially console and Xenstore pages) is
>> marked as "reserved" in the guest's E820 map, as otherwise conflicts
>> might arise later, e.g. when hotplugging memory into the guest.
>
> This is
Make sure the HVM mmio area (especially console and Xenstore pages) is
marked as "reserved" in the guest's E820 map, as otherwise conflicts
might arise later, e.g. when hotplugging memory into the guest.
Signed-off-by: Juergen Gross
---
This is a bugfix for PVH and HVM guests.
On 16/11/17 22:10, Anshul Makkar wrote:
> [Trimming the Cc-list a bit]
>
>
> On 9/14/17 7:37 AM, Juergen Gross wrote:
>> On 12/09/17 02:45, anshulmakkar wrote:
>>> Introduces scheduler specific parameter at libxl level which are
>>> passed on to libxc. eg run
On 16/11/17 21:50, Josh Poimboeuf wrote:
> On Wed, Oct 25, 2017 at 11:33:43AM +0200, Juergen Gross wrote:
>> On 04/10/17 17:58, Josh Poimboeuf wrote:
>>> Some of the paravirt '*_CLOBBERS' macros refer to output constraints
>>> instead of clobbers, which makes
On 16/11/17 22:19, Josh Poimboeuf wrote:
> On Wed, Oct 25, 2017 at 01:25:02PM +0200, Juergen Gross wrote:
>> On 04/10/17 17:58, Josh Poimboeuf wrote:
>>> Add alternative patching support for replacing an instruction with an
>>> indirect call. This will be needed fo
interface
- a series by Juergen Gross to add support for Xen pv guests to be able
to run on 5 level paging hosts
- a series by Stefano Stabellini adding the Xen pvcalls frontend driver
using a paravirtualized socket interface
Thanks.
Juergen
MAINTAINERS|2
On 15/11/17 22:20, Stefano Stabellini wrote:
> On Wed, 15 Nov 2017, Boris Ostrovsky wrote:
>> On 11/15/2017 02:09 PM, Stefano Stabellini wrote:
>>> On Wed, 15 Nov 2017, Juergen Gross wrote:
>>>>>>> while(mutex_is_locked(&map->active.in_mutex.o
attribution.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
commits in that range mention
> libelf so the most likely reason is a consequence of a change to some
> configuration interactions (ie, probably, an expansion of the scope of
> an existing dependency).
>
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Boris Ost
On 14/11/17 22:46, Boris Ostrovsky wrote:
> On 11/14/2017 04:11 AM, Juergen Gross wrote:
>> On 13/11/17 19:33, Stefano Stabellini wrote:
>>> On Mon, 13 Nov 2017, Juergen Gross wrote:
>>>> On 11/11/17 00:57, Stefano Stabellini wrote:
>>>>> On Tue, 7 Nov
On 14/11/17 12:43, Quan Xu wrote:
>
>
> On 2017/11/14 18:27, Juergen Gross wrote:
>> On 14/11/17 10:38, Quan Xu wrote:
>>>
>>> On 2017/11/14 15:30, Juergen Gross wrote:
>>>> On 14/11/17 08:02, Quan Xu wrote:
>>>>> On 2017/11/13 18:53,
On 14/11/17 10:38, Quan Xu wrote:
>
>
> On 2017/11/14 15:30, Juergen Gross wrote:
>> On 14/11/17 08:02, Quan Xu wrote:
>>>
>>> On 2017/11/13 18:53, Juergen Gross wrote:
>>>> On 13/11/17 11:06, Quan Xu wrote:
>>>>> From: Quan Xu
>
On 13/11/17 19:33, Stefano Stabellini wrote:
> On Mon, 13 Nov 2017, Juergen Gross wrote:
>> On 11/11/17 00:57, Stefano Stabellini wrote:
>>> On Tue, 7 Nov 2017, Juergen Gross wrote:
>>>> On 06/11/17 23:17, Stefano Stabellini wrote:
>>>>> mutex_trylock(
On 14/11/17 08:02, Quan Xu wrote:
>
>
> On 2017/11/13 18:53, Juergen Gross wrote:
>> On 13/11/17 11:06, Quan Xu wrote:
>>> From: Quan Xu
>>>
>>> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
>>> in idle path which
On 11/11/17 00:57, Stefano Stabellini wrote:
> On Tue, 7 Nov 2017, Juergen Gross wrote:
>> On 06/11/17 23:17, Stefano Stabellini wrote:
>>> mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
>>> take in_mutex on the first try, but you can't ta
> to poll for a while and do not enter real idle path if we can get the
> schedule event during polling.
>
> Poll may cause the CPU waste so we adopt a smart polling mechanism to
> reduce the useless poll.
>
> Signed-off-by: Yang Zhang
> Signed-off-by: Quan Xu
> Cc:
On 10/11/17 10:33, Roger Pau Monné wrote:
> On Sat, Nov 04, 2017 at 11:14:35PM +, osstest service owner wrote:
>> flight 11 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/11/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> inclu
: dmitry.torok...@gmail.com
Cc: xdeguill...@vmware.com
Cc: moltm...@vmware.com
Cc: a...@arndb.de
Cc: gre...@linuxfoundation.org
Cc: linux-in...@vger.kernel.org
Signed-off-by: Juergen Gross
---
arch/x86/hyperv/hv_init.c | 2 +-
arch/x86/include/asm/hypervisor.h | 23 ++-
arch/x86
en-de...@lists.xenproject.org
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_hvm.c | 24 ++--
arch/x86/xen/enlighten_pvh.c | 9 -
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
...@linuxdriverproject.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: k...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Suggested-by: Ingo Molnar
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/hypervisor.h | 25 --
arch/x86/include/asm/x86_init.h | 24
...@arndb.de
Cc: gre...@linuxfoundation.org
Cc: linux-in...@vger.kernel.org
Cc: r...@rjwysocki.net
Cc: len.br...@intel.com
Cc: pa...@ucw.cz
Cc: linux...@vger.kernel.org
Juergen Gross (5):
x86: merge x86_hyper into x86_platform and x86_init
x86: add enum for hypervisors to replace x86_hyper
x86/acpi: add
On 09/11/17 13:31, Wei Liu wrote:
> On Thu, Nov 09, 2017 at 01:10:12PM +0100, Juergen Gross wrote:
>> Since carving out Mini-OS from the Xen repository there hasn't been a
>> description of the preferred coding style. Copy the Xen CODING_STYLE
>> file.
>>
>
&
Since carving out Mini-OS from the Xen repository there hasn't been a
description of the preferred coding style. Copy the Xen CODING_STYLE
file.
Signed-off-by: Juergen Gross
---
CODING_STYLE | 109 +++
1 file changed, 109 inser
On 08/11/17 16:00, Govinda Tatti wrote:
> Thanks Roger for your review comments. Please see below for my comments.
>
> On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
>> On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
>>> +out:
>>> + if (!err)
>>> + err = count;
>>> +
>>> +
On 08/11/17 15:10, Boris Ostrovsky wrote:
> On 11/08/2017 08:36 AM, Juergen Gross wrote:
>>
>> Regarding ACPI tables: current PVH implementation in Linux kernel
>> seems not to make use of the special information presented in the boot
>> information block.
>
> It
On 08/11/17 14:37, Boris Ostrovsky wrote:
> On 11/08/2017 04:07 AM, Juergen Gross wrote:
>> Booting a Xen PVH guest requires a special boot entry as it is
>> mandatory to setup some Xen-specific interfaces rather early. When grub
>> or OVMF are used as boot loaders, however
On 08/11/17 13:58, Jan Beulich wrote:
On 08.11.17 at 13:45, wrote:
>> On 08/11/17 13:31, Jan Beulich wrote:
>> On 08.11.17 at 12:55, wrote:
On 08/11/17 12:18, Jan Beulich wrote:
On 08.11.17 at 10:07, wrote:
>> In case we are booted via the default boot entry by a gener
s never read
>
> Signed-off-by: Colin Ian King
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 08/11/17 13:31, Jan Beulich wrote:
On 08.11.17 at 12:55, wrote:
>> On 08/11/17 12:18, Jan Beulich wrote:
>> On 08.11.17 at 10:07, wrote:
In case we are booted via the default boot entry by a generic loader
like grub or OVMF it is necessary to distinguish between a HVM guest
On 08/11/17 13:26, Paolo Bonzini wrote:
> On 08/11/2017 13:24, Juergen Gross wrote:
>>> My understanding of Xen is very rusty at this point, but I think a
>>> "completely" legacy-free HVM domain will still have a PCI bus and the
>>> Xen platform device on t
On 08/11/17 13:03, Paolo Bonzini wrote:
> On 08/11/2017 12:55, Juergen Gross wrote:
>> On 08/11/17 12:18, Jan Beulich wrote:
>>>>>> On 08.11.17 at 10:07, wrote:
>>>> In case we are booted via the default boot entry by a generic loader
>>>> like
On 08/11/17 12:18, Jan Beulich wrote:
On 08.11.17 at 10:07, wrote:
>> In case we are booted via the default boot entry by a generic loader
>> like grub or OVMF it is necessary to distinguish between a HVM guest
>> with a device model supporting legacy devices and a PVH guest without
>> device
On 08/11/17 10:40, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>>> Plus add a default empty function (which hypervisors can override). This
>>> avoids
>>> all the hidden conditions and wrappery.
>>
>> Hmm, x86_hyper is just a pointer being
On 08/11/17 10:13, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> Add a new guest_late_init hook to the hypervisor_x86 structure. It
>> will replace the current kvm_guest_init() call which is changed to
>> make use of the new hook.
>>
>> Signed-off
Add a test for ACPI_FADT_NO_VGA when scanning the FADT and set the new
flag x86_platform.legacy.no_vga accordingly.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/acpi/boot.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/arch/x86/include
Add a new guest_late_init hook to the hypervisor_x86 structure. It
will replace the current kvm_guest_init() call which is changed to
make use of the new hook.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/hypervisor.h | 11 +++
arch/x86/include/asm/kvm_para.h | 2 --
arch
x86_platform.legacy.rtc cleared, while both won't be true for HVM
guests.
Test for both conditions in the guest_late_init hook and set xen_pvh
to true if they are met.
Move some of the early PVH initializations to the new hook in order
to avoid duplicated code.
Signed-off-by: Juergen Gross
---
arch/x8
involved for filling in
the boot parameters.
Juergen Gross (3):
x86/acpi: add test for ACPI_FADT_NO_VGA
x86: add guest_late_init hook to hypervisor_x86 structure
x86/xen: use guest_late_init to detect Xen PVH guest
arch/x86/include/asm/hypervisor.h | 11 +++
arch/x86/include/asm
On 06/11/17 12:36, Juergen Gross wrote:
> On 03/11/17 13:17, Roger Pau Monné wrote:
>> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>>> On 29/09/17 17:51, Roger Pau Monné wrote:
>>>> On Fri, Sep 29, 2017 at 03:33:58PM +, Juergen Gross wrote:
>
On 06/11/17 17:42, Boris Ostrovsky wrote:
> On 11/06/2017 10:05 AM, Juergen Gross wrote:
>> On 06/11/17 15:51, Boris Ostrovsky wrote:
>>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>>>> On 03/11/17 20:00, Boris Ostrovsky wrote:
>>>>> On 11/03/2017 0
On 06/11/17 23:17, Stefano Stabellini wrote:
> mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
> take in_mutex on the first try, but you can't take out_mutex. Next times
> you call mutex_trylock() in_mutex is going to fail. It's an endless
> loop.
>
> Solve the problem by m
On 06/11/17 15:51, Boris Ostrovsky wrote:
> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>> On 03/11/17 20:00, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>>>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>>>>> On 11/03/2017 0
On 03/11/17 13:17, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>> On 29/09/17 17:51, Roger Pau Monné wrote:
>>> On Fri, Sep 29, 2017 at 03:33:58PM +0000, Juergen Gross wrote:
>>>> On 29/09/17 17:24, Roger Pau Monné wrote:
&g
On 06/11/17 10:57, Waseem, Amna wrote:
> Hello All,
>
> I am a little confused about mapping mechanism in Xen for page from DomU to
> Dom0.
>
> When Dom0 maps DomU page to its applied host_addr, Page table entries are
> created by Xen hypervisor for mapping applied host_addr vritual address o
On 03/11/17 20:00, Boris Ostrovsky wrote:
> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>>>> On 03/11/17 19:19, Boris Ostrovsky wrote:
>>>>> On 11/03/2017 0
On 03/11/17 19:37, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 07:23:50PM +0100, Juergen Gross wrote:
>> On 03/11/17 19:19, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>>>
>>>> So again the question
On 03/11/17 19:35, Boris Ostrovsky wrote:
> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>> On 03/11/17 19:19, Boris Ostrovsky wrote:
>>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>>> So again the question: how to tell whether we are PVH or HVM in
>>>&g
On 03/11/17 19:29, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 05:57:52PM +, George Dunlap wrote:
>> On 11/03/2017 02:52 PM, George Dunlap wrote:
>>> On 11/03/2017 02:14 PM, Roger Pau Monné wrote:
On Thu, Nov 02, 2017 at 09:55:11AM +, Paul Durrant wrote:
> Hmm. I wonder whethe
On 03/11/17 19:19, Boris Ostrovsky wrote:
> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>
>> So again the question: how to tell whether we are PVH or HVM in
>> init_hypervisor_platform()? ACPi tables are scanned way later...
>
> Can we make grub/OVMF append
On 03/11/17 16:27, Juergen Gross wrote:
> On 03/11/17 16:10, Boris Ostrovsky wrote:
>> On 11/03/2017 10:59 AM, Juergen Gross wrote:
>>> On 03/11/17 15:36, Boris Ostrovsky wrote:
>>>> On 11/03/2017 10:24 AM, Juergen Gross wrote:
>>>>> On 03/11/17 15:07,
On 03/11/17 16:10, Boris Ostrovsky wrote:
> On 11/03/2017 10:59 AM, Juergen Gross wrote:
>> On 03/11/17 15:36, Boris Ostrovsky wrote:
>>> On 11/03/2017 10:24 AM, Juergen Gross wrote:
>>>> On 03/11/17 15:07, Roger Pau Monné wrote:
>>>>> On Fri, Nov 03,
On 03/11/17 15:36, Boris Ostrovsky wrote:
> On 11/03/2017 10:24 AM, Juergen Gross wrote:
>> On 03/11/17 15:07, Roger Pau Monné wrote:
>>> On Fri, Nov 03, 2017 at 01:50:11PM +0100, Juergen Gross wrote:
>>>> On 03/11/17 13:17, Roger Pau Monné wrote:
>>>>
On 03/11/17 15:07, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:50:11PM +0100, Juergen Gross wrote:
>> On 03/11/17 13:17, Roger Pau Monné wrote:
>>> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>>>> On 29/09/17 17:51, Roger Pau Monné wrote:
&g
On 03/11/17 13:17, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>> On 29/09/17 17:51, Roger Pau Monné wrote:
>>> On Fri, Sep 29, 2017 at 03:33:58PM +0000, Juergen Gross wrote:
>>>> On 29/09/17 17:24, Roger Pau Monné wrote:
&g
On 29/09/17 17:51, Roger Pau Monné wrote:
> On Fri, Sep 29, 2017 at 03:33:58PM +0000, Juergen Gross wrote:
>> On 29/09/17 17:24, Roger Pau Monné wrote:
>>> On Fri, Sep 29, 2017 at 02:46:53PM +0000, Juergen Gross wrote:
>>> Then, I also wonder whether it would make
quot;)
>
> Fixes: cb1c7d9bbc87 ("xen/pvcalls: implement connect command")
> Signed-off-by: Colin Ian King
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
.
>
> Detected by CoverityScan, CID#1460358 ("Unsigned compared against 0")
>
> Fixes: 219681909913 ("xen/pvcalls: connect to the backend")
> Signed-off-by: Colin Ian King
Reviewed-by: Juergen Gross
Juergen
___
GCC is expecting to find.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 02/11/17 19:41, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Addresses-Coverity-ID: 146562
> Addresses-Coverity-ID: 146563
> Signed-off-by: Gustavo A. R. Silva
Reviewed
On 02/11/17 23:18, Boris Ostrovsky wrote:
> For any other error sync_cmos_clock() will reschedule itself
> every second or so, for no good reason.
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen G
On 02/11/17 08:37, Rakesh Awanti wrote:
>>> Hello,
>>>
>>> I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB
>>> frontend and backend code from
>
>>So from where?
>
>
> https://lists.xen.org/archives/html/xen-devel/2015-02/msg03245.html
The backend driver was discarded a
On 02/11/17 14:25, Waiman Long wrote:
> On 11/01/2017 06:01 PM, Boris Ostrovsky wrote:
>> On 11/01/2017 04:58 PM, Waiman Long wrote:
>>> +/* TODO: To be removed in a future kernel version */
>>> static __init int xen_parse_nopvspin(char *arg)
>>> {
>>> - xen_pvspin = false;
>>> + pr_warn("xen
On 02/11/17 08:56, Francesco De Francesco wrote:
> Hi everyone,
>
> I need to address an issue that prevents me from running Xen on new
> hardware. It's an HPE DL360 Gen10 with double Xeon Silver 4108 CPU and
> 256GB ECC DDR4 RDIMM. It happens with both CentOS6 and CentOS7.
>
> When I try to boot
Update arch/x86/include/asm/xen/cpuid.h from the Xen tree to get newest
definitions.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/cpuid.h | 42 ++--
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/xen/cpuid.h
-off-by: Juergen Gross
---
V2:
- remove update_trans_entry() from gnttab_ops (Boris Ostrovsky)
---
drivers/xen/grant-table.c | 150 --
include/xen/grant_table.h | 25
2 files changed, 175 deletions(-)
diff --git a/drivers/xen/grant-table.c b
to specify the grant interface version
via a boot parameter.
Signed-off-by: Juergen Gross
---
V2:
- use cpuid on pv and max_possible_pfn on hvm for version select
---
drivers/xen/grant-table.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a
for version select
Juergen Gross (5):
xen: re-introduce support for grant v2 interface
xen: limit grant v2 interface to the v1 functionality
xen: add grant interface version dependent constants to gnttab_ops
xen: update arch/x86/include/asm/xen/cpuid.h
xen: select grant interface vers
s machines with more than 16TB of memory are expected to be more
common in the near future support of grant v2 is mandatory in order
to be able to run a Xen pv domain at any memory location.
So re-add grant v2 support basically by reverting above commit.
Signed-off-by: Juergen Gross
---
arch/arm
Instead of having multiple variables with constants like
grant_table_version or grefs_per_grant_frame add those to struct
gnttab_ops and access them just via the gnttab_interface pointer.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 73
On 02/11/17 07:57, Rakesh Awanti wrote:
> Hello,
>
> I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB
> frontend and backend code from
So from where?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
On 01/11/17 16:32, Waiman Long wrote:
> Currently, there are 3 different lock types that can be chosen for
> the x86 architecture:
>
> - qspinlock
> - pvqspinlock
> - unfair lock
>
> One of the above lock types will be chosen at boot time depending on
> a number of different factors.
>
> Idea
On 01/11/17 14:45, Paul Durrant wrote:
>> -Original Message-
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 01 November 2017 13:40
>> To: Paul Durrant ; x...@kernel.org; xen-
>> de...@lists.xenproject.org; linux-ker...@vger.kernel.org
>> C
through to the approprate
> xlate_mmu function if the feature is present.
>
> This patch also moves xen_remap_domain_gfn_range() into the PV-only MMU
> code and #ifdefs the (only) calling code in privcmd accordingly.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Boris Ostro
On 30/10/17 09:05, Arthur Borsboom wrote:
> Hi Juergen,
>
> I needed to wait until the VM guest crashed again, so that caused this
> delay.
> I have extracted the hypervisor dmesg and the dom0 dmesg which can be
> found in the PasteBins.
> It is always the same domain crashing, if that is of any h
e8 df 2a 7b 00 5b
> 41 5c 5d c3 48 89 fa 48 c7 c6 40 93 a3 81 48 c7 c7 00 8b cb 81 e8 95 b5
> f3 ff <0f> ff eb a8 0f ff eb b3 48 89 df e8 14 fc ff ff eb c7 66 90 e8
> [ 0.00] ---[ end trace c12d07f00399ce78 ]---
> [ 0.00] Built 2 zonelists, mobility grouping on. Tot
On 30/10/17 06:26, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_clock(
1 - 100 of 3777 matches
Mail list logo
