[Xen-devel] Difference between normal Dom0 and PVH Dom0

Hi, all: From the article [1] and xen-colors picture from Brendan Gergg's blog [2], I have some understanding and question about PVH Dom0 as follows: 1. Even after pvops has been support in Linux mainline kernel, current XEN dom0 is still a "Full PV" domain (I will call it as "normal Dom

Re: [Xen-devel] [PATCH 4/4] VMX: replace plain numbers

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, January 22, 2015 10:01 PM > > ... making the code better document itself. No functional change > intended. > > Signed-off-by: Jan Beulich Acked-by: Kevin Tian ___ Xen-devel mailing li

Re: [Xen-devel] about the funtion call memory_type_changed()

> From: Li, Liang Z > Sent: Friday, January 23, 2015 1:55 PM > > > >>> On 22.01.15 at 08:44, wrote: > > > Tian, Kevin wrote on 2015-01-22: > > >>> From: Jan Beulich [mailto:jbeul...@suse.com] > > >>> Sent: Wednesday, January 21, 2015 6:31 PM > > >>> > > > > Yes, it's true. But I still d

Re: [Xen-devel] about the funtion call memory_type_changed()

> >>> On 22.01.15 at 08:44, wrote: > > Tian, Kevin wrote on 2015-01-22: > >>> From: Jan Beulich [mailto:jbeul...@suse.com] > >>> Sent: Wednesday, January 21, 2015 6:31 PM > >>> > > Yes, it's true. But I still don't understand why to do the > flush_all just when iommu_enable is true.

[Xen-devel] [Resend Patch v4 12/16] smp, x86: Kill SMP single function call interrupt

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so

[Xen-devel] [Resend Patch v4 11/16] smp, x86, xen: Kill SMP single function call interrupt

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so

Re: [Xen-devel] [PATCH RFC] efi: By default use the BOOT_ACPI method instead of BOOT_EFI unless on reduced ACPI hardware.

On Thu, Jan 22, 2015 at 03:22:10PM +, Jan Beulich wrote: > >>> On 22.01.15 at 16:01, wrote: > > On Thu, Jan 22, 2015 at 09:49:08AM +, Jan Beulich wrote: > >> >>> On 21.01.15 at 22:53, wrote: > >> > This mimics the behavior of the Linux kernel in which the reboot > >> > sequence by default

Re: [Xen-devel] [PATCH v2 03/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented()

On 2015/1/23 4:25, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 21, 2015 at 08:29:58AM +0800, Yijing Wang wrote: >> From: Arnd Bergmann >> >> Use pci_scan_root_bus() instead of deprecated function >> pci_scan_bus_parented(). >> >> Signed-off-by: Arnd Bergmann >> Signed-off-by: Yijing Wang >> CC: K

Re: [Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, 22 Jan 2015 17:40:27 -0800 Andy Lutomirski wrote: > > > > +/* > > + * CONFIG_PREEMPT=n kernels can end up triggering the softlock > > + * TASK_UNINTERRUPTIBLE hanger check (default 120 seconds) > > + * when certain multicalls are used [0] on large systems, in > > + * that case we need a w

Re: [Xen-devel] [RFC PATCH] dpci: Put the dpci back on the list if running on another CPU.

On Tue, Jan 13, 2015 at 10:20:00AM +, Jan Beulich wrote: > >>> On 12.01.15 at 17:45, wrote: > > There is race when we clear the STATE_SCHED in the softirq > > - which allows the 'raise_softirq_for' to progress and > > schedule another dpci. During that time the other CPU could > > receive an i

Re: [Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 4:29 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Xen has support for splitting heavy work work into a series > of hypercalls, called multicalls, and preempting them through > what Xen calls continuation [0]. Despite this though without > CONFIG_PREEMPT pre

Re: [Xen-devel] [RFC v4 1/2] x86/xen: add xen_is_preemptible_hypercall()

On Thu, Jan 22, 2015 at 4:29 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > On kernels with voluntary or no preemption we can run > into situations where a hypercall issued through userspace > will linger around as it addresses sub-operatiosn in kernel > context (multicalls). Such o

Re: [Xen-devel] [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough

On 2015/1/22 8:51, Chen, Tiejun wrote: On 2015/1/21 21:48, Gerd Hoffmann wrote: On Mi, 2015-01-21 at 11:37 +, Ian Jackson wrote: Tiejun Chen writes ("[RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough"): When we're working to support IGD GFX passthrough with qe

Re: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig

On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > This v3 addresses Stefano's feedback from the v2 series, namely > moving PCI stuff to x86 as its all x86 specific and also just > removing the CONFIG_TCG_XEN=m from the general config. To be > clear

[Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to be preempted

From: "Luis R. Rodriguez" Xen has support for splitting heavy work work into a series of hypercalls, called multicalls, and preempting them through what Xen calls continuation [0]. Despite this though without CONFIG_PREEMPT preemption won't happen, without preemption a system can become pretty us

[Xen-devel] [RFC v4 1/2] x86/xen: add xen_is_preemptible_hypercall()

From: "Luis R. Rodriguez" On kernels with voluntary or no preemption we can run into situations where a hypercall issued through userspace will linger around as it addresses sub-operatiosn in kernel context (multicalls). Such operations can trigger soft lockup detection. We want to address a way

[Xen-devel] [RFC v4 0/2] x86/xen: add xen hypercall preemption

From: "Luis R. Rodriguez" This v4 addresses some of the cleanups recommended and adds tracing option for when we do actually preempt a hypercall. I kept the NOKPROBE_SYMBOL() for now but did remove the 'notrace' stuff. This goes out as RFC still as I have not been able to test 32-bit. Can anyone

Re: [Xen-devel] [Qemu-devel] [PATCH] fix QEMU build on Xen/ARM

On 01/22/15 13:46, Stefano Stabellini wrote: > xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an > unsigned long argument (in fact xen_pfn_t is defined as uint64_t on > ARM). > > Also use xc_hvm_param_get instead of the deprecated xc_get_hvm_param. > > Signed-off-by: Stefano Stabel

Re: [Xen-devel] [Qemu-devel] [PATCH] fix QEMU build on Xen/ARM

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/22/15 13:46, Stefano Stabellini wrote: > xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an > unsigned long argument (in fact xen_pfn_t is defined as uint64_t > on ARM). > > Also use xc_hvm_param_get instead of the deprecated > xc

Re: [Xen-devel] [RFC v3 1/2] x86/xen: add xen_is_preemptible_hypercall()

On Thu, Jan 22, 2015 at 09:44:12PM +, Andrew Cooper wrote: > On 22/01/2015 21:09, Luis R. Rodriguez wrote: > > On Thu, Jan 22, 2015 at 12:01:50PM -0800, Andy Lutomirski wrote: > >> On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez > >> wrote: > >>> On Wed, Jan 21, 2015 at 07:07:36PM -0800,

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On 22/01/2015 20:58, Andy Lutomirski wrote: > On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt wrote: >> On Thu, 22 Jan 2015 12:24:47 -0800 >> Andy Lutomirski wrote: >> Also, please remove the "notrace", because function tracing goes an extra step to not require RCU being visible. The o

Re: [Xen-devel] [PATCH RFC] pvh: set need_iommu early

On Thu, Jan 22, 2015 at 07:08:22AM +, Tian, Kevin wrote: > > From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com] > > Sent: Thursday, January 22, 2015 4:53 AM > > > > need_iommu has to be set earler for dom0 pvh specific init > > functions. If not enabled, mmio regions are not mapped with

Re: [Xen-devel] [RFC v3 1/2] x86/xen: add xen_is_preemptible_hypercall()

On 22/01/2015 21:09, Luis R. Rodriguez wrote: > On Thu, Jan 22, 2015 at 12:01:50PM -0800, Andy Lutomirski wrote: >> On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez wrote: >>> On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote: On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodrigue

Re: [Xen-devel] [RFC PATCH] xen, apic: Setup our own APIC driver and validator for APIC IDs.

> > >>> + if (xen_check_x2apic()) > > >>> + xen_apic.apic_id_valid = xen_id_always_valid; > > >> > > >> Just always use xen_id_always_valid regardless of whether the machine > > >> has x2apic or not. It is possible to have more VCPUs that PCPUs. > > > > > > In which case perha

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 1:16 PM, Steven Rostedt wrote: > On Thu, 22 Jan 2015 12:58:00 -0800 > Andy Lutomirski wrote: > >> On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt wrote: >> > On Thu, 22 Jan 2015 12:24:47 -0800 >> > Andy Lutomirski wrote: >> >> >> >> >> The other issue, above and beyond

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, 22 Jan 2015 12:58:00 -0800 Andy Lutomirski wrote: > On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt wrote: > > On Thu, 22 Jan 2015 12:24:47 -0800 > > Andy Lutomirski wrote: > > > >> > Also, please remove the "notrace", because function tracing goes an > >> > extra step to not require R

Re: [Xen-devel] [RFC v3 1/2] x86/xen: add xen_is_preemptible_hypercall()

On Thu, Jan 22, 2015 at 12:01:50PM -0800, Andy Lutomirski wrote: > On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez wrote: > > On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote: > >> On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez > >> wrote: > >> > From: "Luis R. Rodriguez"

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 03:16:57PM -0500, Steven Rostedt wrote: > > [ Added Paul McKenney ] > > On Thu, 22 Jan 2015 19:39:13 +0100 > "Luis R. Rodriguez" wrote: > > > > Why not make this a tracepoint? Then you can enable it only when you > > > want to. As tracepoints are also hooks, you could ad

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt wrote: > On Thu, 22 Jan 2015 12:24:47 -0800 > Andy Lutomirski wrote: > >> > Also, please remove the "notrace", because function tracing goes an >> > extra step to not require RCU being visible. The only thing you get >> > with notrace is not being

Re: [Xen-devel] Release Manager for Xen 4.6

Didn't see the list was CC'ed From: Lars Kurth Sent: 22 January 2015 20:48 To: Konrad Rzeszutek Wilk; xen-de...@lists.xenproject.org; Stefano Stabellini Subject: RE: Release Manager for Xen 4.6 Could you let xen-devel know? Would like to talk to you re Open

Re: [Xen-devel] Release Manager for Xen 4.6

Could you let xen-devel know? Would like to talk to you re OpenStack. Both Stefano and I are getting more involved too Lars ___ From: Konrad Rzeszutek Wilk [konrad.w...@oracle.com] Sent: 22 January 2015 20:12 To: Lars Kurth; xen-de...@lists.xenproject.org; Stefa

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, 22 Jan 2015 12:24:47 -0800 Andy Lutomirski wrote: > > Also, please remove the "notrace", because function tracing goes an > > extra step to not require RCU being visible. The only thing you get > > with notrace is not being able to trace an otherwise traceable function. > > > > Is this a

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On 22/01/15 18:56, Luis R. Rodriguez wrote: > On Thu, Jan 22, 2015 at 01:10:49PM +, Julien Grall wrote: >> Hi Luis, >> >> On 22/01/15 02:17, Luis R. Rodriguez wrote: >>> diff --git a/drivers/xen/events/events_base.c >>> b/drivers/xen/events/events_base.c >>> index b4bca2d..23c526b 100644 >>> -

Re: [Xen-devel] [PATCH v2 03/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented()

On Wed, Jan 21, 2015 at 08:29:58AM +0800, Yijing Wang wrote: > From: Arnd Bergmann > > Use pci_scan_root_bus() instead of deprecated function > pci_scan_bus_parented(). > > Signed-off-by: Arnd Bergmann > Signed-off-by: Yijing Wang > CC: Konrad Rzeszutek Wilk > CC: xen-de...@lists.xenproject.o

Re: [Xen-devel] [PATCH v3 2/3] xen/pvh: check permissions when adding MMIO regions

On Thu, Jan 22, 2015 at 04:19:22PM +0100, Roger Pau Monne wrote: > Check that MMIO regions added to PVH Dom0 are allowed. Previously a PVH Dom0 > would have access to the full MMIO range. How do we do this for normal PV dom0? Do we enforce the same restriction? If not, should we ? > > Signed-off-

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 12:16 PM, Steven Rostedt wrote: > > [ Added Paul McKenney ] > > On Thu, 22 Jan 2015 19:39:13 +0100 > "Luis R. Rodriguez" wrote: > >> > Why not make this a tracepoint? Then you can enable it only when you >> > want to. As tracepoints are also hooks, you could add you own co

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

[ Added Paul McKenney ] On Thu, 22 Jan 2015 19:39:13 +0100 "Luis R. Rodriguez" wrote: > > Why not make this a tracepoint? Then you can enable it only when you > > want to. As tracepoints are also hooks, you could add you own code that > > hooks to it and does a printk as well. The advantage of

[Xen-devel] Release Manager for Xen 4.6

Hey, I will becoming more involved in OpenStack to the point that I cannot see myself wearing the Release Manager hat as well. As such I would like to hand the jacket off to the next victi^M^M^Mvolunteer. ___ Xen-devel mailing list Xen-devel@lists.xen.

Re: [Xen-devel] [PATCH] asm, x86: Set max CPUs to 512 instead of 256.

On Thu, Jan 22, 2015 at 05:04:12PM +, Andrew Cooper wrote: > On 22/01/15 16:52, Konrad Rzeszutek Wilk wrote: > > Contemporary servers sport now 480 CPUs or such. We should crank > > up the default amount of CPUs to a higher level to take advantage > > of this without having the distro to use 'm

Re: [Xen-devel] [RFC v3 1/2] x86/xen: add xen_is_preemptible_hypercall()

On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez wrote: > On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote: >> On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez >> wrote: >> > From: "Luis R. Rodriguez" >> > >> > On kernels with voluntary or no preemption we can run >> > into s

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Wed, Jan 21, 2015 at 07:18:46PM -0800, Andy Lutomirski wrote: > On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez > wrote: > > From: "Luis R. Rodriguez" > > > > Xen has support for splitting heavy work work into a series > > of hypercalls, called multicalls, and preempting them through > > wh

Re: [Xen-devel] [RFC v3 1/2] x86/xen: add xen_is_preemptible_hypercall()

On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote: > On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez > wrote: > > From: "Luis R. Rodriguez" > > > > On kernels with voluntary or no preemption we can run > > into situations where a hypercall issued through userspace > > will linger

Re: [Xen-devel] [RFC PATCH] xen, apic: Setup our own APIC driver and validator for APIC IDs.

On Thu, Jan 22, 2015 at 03:14:50PM +, David Vrabel wrote: > On 22/01/15 15:09, Konrad Rzeszutek Wilk wrote: > > On Thu, Jan 22, 2015 at 10:00:55AM +, David Vrabel wrote: > >> On 21/01/15 21:56, Konrad Rzeszutek Wilk wrote: > >>> +static struct apic xen_apic = { > >>> + .name = "Xen", > >>>

Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

On 01/22/2015 07:42 AM, Tim Deegan wrote: > At 13:54 -0800 on 19 Jan (1421672054), Ed White wrote: >>> Or: declare in the interface that the altp2ms are soft state that can >>> be dropped on migration, with some suitable callback (#VE injection?) >>> to the guest when an altp2m 'view' is not availa

Re: [Xen-devel] [Fedora-xen] Dom0 crashes with 3.17.8-300+

On Thu, Jan 22, 2015 at 11:21:14AM -0500, Bill McGonigle wrote: > Hi, all, > > My desktop is f21/Xen 4.4 and the Dom0 crashes if it's 3.17.8-300 or later. > 3.17.7-300 is stable. The crashing Dom0 kernels are stable as baremetal > kernels. > > I've tried getting 3.18 from -testing and rebuild

Re: [Xen-devel] [PATCH] asm, x86: Set max CPUs to 512 instead of 256.

On Thu, Jan 22, 2015 at 05:04:12PM +, Andrew Cooper wrote: > On 22/01/15 16:52, Konrad Rzeszutek Wilk wrote: > > Contemporary servers sport now 480 CPUs or such. We should crank > > up the default amount of CPUs to a higher level to take advantage > > of this without having the distro to use 'm

[Xen-devel] [PATCH] fix QEMU build on Xen/ARM

xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an unsigned long argument (in fact xen_pfn_t is defined as uint64_t on ARM). Also use xc_hvm_param_get instead of the deprecated xc_get_hvm_param. Signed-off-by: Stefano Stabellini diff --git a/include/hw/xen/xen_common.h b/include/h

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 01:10:49PM +, Julien Grall wrote: > Hi Luis, > > On 22/01/15 02:17, Luis R. Rodriguez wrote: > > diff --git a/drivers/xen/events/events_base.c > > b/drivers/xen/events/events_base.c > > index b4bca2d..23c526b 100644 > > --- a/drivers/xen/events/events_base.c > > +++ b/

Re: [Xen-devel] [PATCH OSSTEST v5 00/13] support for ARM32 arndale and cubietruck platforms

On Thu, 22 Jan 2015, Ian Campbell wrote: > On Thu, 2015-01-22 at 10:56 +, Ian Campbell wrote: > > I've managed to make a habit of forgetting to mention one important > > point (including hitting send on this bit in reply to v4!) > > > > Both the cubietruck and the arndale are (for different re

[Xen-devel] [linux-next test] 33627: regressions - FAIL

flight 33627 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33627/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 5 xen-boot fail REGR. vs. 33485 test-armhf-armhf-libvi

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 11:50:10AM +, Andrew Cooper wrote: > On 22/01/15 02:17, Luis R. Rodriguez wrote: > > --- a/drivers/xen/events/events_base.c > > +++ b/drivers/xen/events/events_base.c > > @@ -32,6 +32,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > >

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 08:56:49AM -0500, Steven Rostedt wrote: > On Thu, 22 Jan 2015 11:50:10 + > Andrew Cooper wrote: > > > On 22/01/15 02:17, Luis R. Rodriguez wrote: > > > --- a/drivers/xen/events/events_base.c > > > +++ b/drivers/xen/events/events_base.c > > > @@ -32,6 +32,8 @@ > > > #i

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On Thu, Jan 22, 2015 at 8:09 PM, Julien Grall wrote: > On 22/01/15 17:43, Oleksandr Tyshchenko wrote: >> On Thu, Jan 22, 2015 at 7:27 PM, Oleksandr Tyshchenko >> wrote: >>> On Thu, Jan 22, 2015 at 7:02 PM, Julien Grall >>> wrote: On 22/01/15 16:55, Oleksandr Tyshchenko wrote: > On Thu,

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On 22/01/15 17:43, Oleksandr Tyshchenko wrote: > On Thu, Jan 22, 2015 at 7:27 PM, Oleksandr Tyshchenko > wrote: >> On Thu, Jan 22, 2015 at 7:02 PM, Julien Grall >> wrote: >>> On 22/01/15 16:55, Oleksandr Tyshchenko wrote: On Thu, Jan 22, 2015 at 6:49 PM, Julien Grall wrote: > On

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 12:55:17PM +, David Vrabel wrote: > On 22/01/15 03:18, Andy Lutomirski wrote: > >> --- a/drivers/xen/events/events_base.c > >> +++ b/drivers/xen/events/events_base.c > >> @@ -32,6 +32,8 @@ > >> #include > >> #include > >> #include > >> +#include > >> +#include >

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On Thu, Jan 22, 2015 at 7:27 PM, Oleksandr Tyshchenko wrote: > On Thu, Jan 22, 2015 at 7:02 PM, Julien Grall wrote: >> On 22/01/15 16:55, Oleksandr Tyshchenko wrote: >>> On Thu, Jan 22, 2015 at 6:49 PM, Julien Grall >>> wrote: On 22/01/15 16:44, Oleksandr Tyshchenko wrote: > I understa

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

On Thu, Jan 22, 2015 at 04:42:52PM +0100, Roger Pau Monné wrote: > El 22/01/15 a les 16.18, Elena Ufimtseva ha escrit: > > > > - jbeul...@suse.com wrote: > > > > On 22.01.15 at 12:37, wrote: > >>> El 22/01/15 a les 12.09, Jan Beulich ha escrit: > >>> On 22.01.15 at 11:59, wrote: > >

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On Thu, Jan 22, 2015 at 7:02 PM, Julien Grall wrote: > On 22/01/15 16:55, Oleksandr Tyshchenko wrote: >> On Thu, Jan 22, 2015 at 6:49 PM, Julien Grall >> wrote: >>> On 22/01/15 16:44, Oleksandr Tyshchenko wrote: I understand, then I will implement local delay func in uart driver based

[Xen-devel] [RFC / PATCH] libxl: Prevent qemu closing QMP socket on shutdown before libxl is done with it.

While this fixes the race and error on shutdown of a HVM guest with pci-passthrough, i don't know if this could give problems in other areas (migration ?), hence posted as RFC. -- Sander 8< --- At present on shutdown when using pci-passthrough with qemu-xen, qemu closes the QMP socket b

[Xen-devel] [PATCH] libxl: Actually append the "-vga none" parameter to qemu when using qemu-xen

Commit 2e5738ff "libxl: Add none to vga parameter" introduced the "none" option for the Xen "vga=" config option but only appends the needed parameter for the qemu-traditional case. This patch fixes the qemu-xen case by appending the same "-vga none" qemu paramter. Signed-off-by: Sander Eikelenboo

Re: [Xen-devel] [PATCH] asm, x86: Set max CPUs to 512 instead of 256.

On 22/01/15 16:52, Konrad Rzeszutek Wilk wrote: > Contemporary servers sport now 480 CPUs or such. We should crank > up the default amount of CPUs to a higher level to take advantage > of this without having the distro to use 'max_phys_cpus' override. > > Signed-off-by: Konrad Rzeszutek Wilk /me

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On 22/01/15 16:55, Oleksandr Tyshchenko wrote: > On Thu, Jan 22, 2015 at 6:49 PM, Julien Grall wrote: >> On 22/01/15 16:44, Oleksandr Tyshchenko wrote: >>> I understand, then I will implement local delay func in uart driver >>> based on READ_SYSREG64(CNTPCT_EL0). >> >> Unless I miss something, ude

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On Thu, Jan 22, 2015 at 6:49 PM, Julien Grall wrote: > On 22/01/15 16:44, Oleksandr Tyshchenko wrote: >> I understand, then I will implement local delay func in uart driver >> based on READ_SYSREG64(CNTPCT_EL0). > > Unless I miss something, udelay should work in your case even if the > xen_init_ti

[Xen-devel] [PATCH] asm,x86: Set max CPUs to 512 instead of 256.

Contemporary servers sport now 480 CPUs or such. We should crank up the default amount of CPUs to a higher level to take advantage of this without having the distro to use 'max_phys_cpus' override. Signed-off-by: Konrad Rzeszutek Wilk --- xen/include/asm-x86/config.h | 2 +- 1 file changed, 1 in

Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

At 17:42 +0100 on 22 Jan (1421944966), Tamas K Lengyel wrote: > On Thu, Jan 22, 2015 at 5:25 PM, Jan Beulich wrote: > On 18.01.15 at 16:18, wrote: > >> +static int hvm_event_traps(long parameters, vm_event_request_t *req) > >> +{ > >> +int rc; > >> +struct vcpu *v = current; > >> +

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On 22/01/15 16:44, Oleksandr Tyshchenko wrote: > I understand, then I will implement local delay func in uart driver > based on READ_SYSREG64(CNTPCT_EL0). Unless I miss something, udelay should work in your case even if the xen_init_time is not called. Regards, -- Julien Grall

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On Thu, Jan 22, 2015 at 6:18 PM, Julien Grall wrote: > On 22/01/15 16:04, Oleksandr Tyshchenko wrote: >> >> >> On Thu, Jan 22, 2015 at 4:44 PM, Julien Grall > > wrote: > >> Hi Julien, > > Hi Oleksandr, > >>> >>> On 21/01/15 14:16, Iurii Konovalenko wrote: >>> > diff

Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

On Thu, Jan 22, 2015 at 5:25 PM, Jan Beulich wrote: On 18.01.15 at 16:18, wrote: >> +static int hvm_event_traps(long parameters, vm_event_request_t *req) >> +{ >> +int rc; >> +struct vcpu *v = current; >> +struct domain *d = v->domain; > > Unless the intention is to have an exact

Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

On Thu, Jan 22, 2015 at 5:32 PM, Andrew Cooper wrote: > On 18/01/15 15:18, Tamas K Lengyel wrote: >> -void hvm_event_cr0(unsigned long value, unsigned long old) >> -{ >> -vm_event_request_t req = { >> -.reason = VM_EVENT_REASON_CR0, >> -.vcpu_id = current->vcpu_id, >> -

Re: [Xen-devel] -EINTR return in domain_relinquish_resources

On Thu, Jan 22, 2015 at 10:00:35AM +, Jan Beulich wrote: > >>> On 21.01.15 at 22:27, wrote: > > As I was looking at some of the XSA I realized that the > > call-chain of: > > > > domain_relinquish_resources > >->vcpu_destroy_pagetables > > -> put_page_and_type_preemptible > >

Re: [Xen-devel] -EINTR return in domain_relinquish_resources

On Wed, Jan 21, 2015 at 10:57:05PM +, Andrew Cooper wrote: > On 21/01/2015 21:39, Andrew Cooper wrote: > > On 21/01/2015 21:27, Konrad Rzeszutek Wilk wrote: > >> As I was looking at some of the XSA I realized that the > >> call-chain of: > >> > >> domain_relinquish_resources > >>->vcpu_des

Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

>>> On 22.01.15 at 17:23, wrote: > On Thu, Jan 22, 2015 at 5:00 PM, Jan Beulich wrote: > On 22.01.15 at 16:34, wrote: >>> On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich wrote: >>> On 18.01.15 at 16:17, wrote: > --- a/xen/include/public/mem_event.h > +++ b/xen/include/public/mem_e

Re: [Xen-devel] [RFC PATCH V2 4/8] x86/hvm: rename hvm_memory_event_* functions to hvm_event_*

On Thu, Jan 22, 2015 at 4:56 PM, Andrew Cooper wrote: > On 18/01/15 15:17, Tamas K Lengyel wrote: >> The function names currently imply that these events are to be delivered via >> the memory_event subsystem. However, the naming is confusing as these events >> have nothing to do with actual memory

Re: [Xen-devel] [PATCH 3/3] grant-table: defer releasing pages acquired in a grant copy

At 18:19 + on 20 Jan (1421774389), David Vrabel wrote: > Acquiring a page for the source or destination of a grant copy is an > expensive operation. A common use case is for two adjacent grant copy > ops to operate on either the same source or the same destination page. > > Instead of always

Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

On 18/01/15 15:18, Tamas K Lengyel wrote: > -void hvm_event_cr0(unsigned long value, unsigned long old) > -{ > -vm_event_request_t req = { > -.reason = VM_EVENT_REASON_CR0, > -.vcpu_id = current->vcpu_id, > -.cr_event.new_value = value, > -.cr_event.old_value = o

Re: [Xen-devel] [PATCH 2/3] grant-table: refactor grant copy to reduce duplicate code

Hi, At 18:19 + on 20 Jan (1421774388), David Vrabel wrote: > +static s16 gnttab_copy_lock_domains(const struct gnttab_copy *op, > +struct gnttab_copy_buf *src, > +struct gnttab_copy_buf *dest) > +{ > +s16 rc; > + > +

Re: [Xen-devel] [RFC PATCH V2 8/8] x86/hvm: factor out vm_event related functions into separate file

>>> On 18.01.15 at 16:18, wrote: > +static int hvm_event_traps(long parameters, vm_event_request_t *req) > +{ > +int rc; > +struct vcpu *v = current; > +struct domain *d = v->domain; Unless the intention is to have an exact 1:1 copy of the original, please use curr and currd here resp

Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

On Thu, Jan 22, 2015 at 5:00 PM, Jan Beulich wrote: On 22.01.15 at 16:34, wrote: >> On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich wrote: >> On 18.01.15 at 16:17, wrote: --- a/xen/include/public/mem_event.h +++ b/xen/include/public/mem_event.h @@ -27,9 +27,15 @@ #ifn

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

On Thu, Jan 22, 2015 at 04:42:52PM +0100, Roger Pau Monné wrote: > El 22/01/15 a les 16.18, Elena Ufimtseva ha escrit: > > > > - jbeul...@suse.com wrote: > > > > On 22.01.15 at 12:37, wrote: > >>> El 22/01/15 a les 12.09, Jan Beulich ha escrit: > >>> On 22.01.15 at 11:59, wrote: > >

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On 22/01/15 16:04, Oleksandr Tyshchenko wrote: > > > On Thu, Jan 22, 2015 at 4:44 PM, Julien Grall > wrote: > Hi Julien, Hi Oleksandr, >> >> On 21/01/15 14:16, Iurii Konovalenko wrote: >> > diff --git a/xen/drivers/char/rcar2-uart.c > b/xen/drivers/char/rcar2-u

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

Oleksandr Dmytryshyn writes ("Re: [PATCH v5] sndif: add ABI for Para-virtual sound"): > On Thu, Jan 22, 2015 at 5:41 PM, Ian Jackson > wrote: > > So for example, much real hardware will have a headphone output and > > also built-in speakers, and a mic input and built-in microphone. > > > How is

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

Oleksandr Dmytryshyn writes ("Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound"): > On Thu, Jan 22, 2015 at 5:56 PM, Ian Jackson > wrote: > > Oleksandr Dmytryshyn writes ("Re: [Xen-devel] [PATCH v5] sndif: add ABI for > > Para-virtual sound"): > >> In my case this is about 3 pac

Re: [Xen-devel] [PATCH OSSTEST v2 12/18] Toolstack: Refactor migration support.

On Thu, 2015-01-22 at 15:19 +, Ian Campbell wrote: > On Thu, 2015-01-22 at 15:17 +, Ian Jackson wrote: > > Ian Campbell writes ("Re: [PATCH OSSTEST v2 12/18] Toolstack: Refactor > > migration support."): > > > On Tue, 2015-01-20 at 18:38 +, Ian Jackson wrote: > > > > Again, I think you

Re: [Xen-devel] [PATCH 2/3] grant-table: refactor grant copy to reduce duplicate code

>>> On 22.01.15 at 15:42, wrote: > On 22/01/15 14:24, Jan Beulich wrote: > On 20.01.15 at 19:19, wrote: >>> +static int gnttab_copy_buf(const struct gnttab_copy *op, >>> + struct gnttab_copy_buf *dest, >>> + const struct gnttab_copy_buf *src

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add new driver for R-Car Gen2 UART

On Thu, Jan 22, 2015 at 4:44 PM, Julien Grall wrote: > > Hi Iurii, Hi Julien, It's Oleksandr. Thank you for your comments. > > > On 21/01/15 14:16, Iurii Konovalenko wrote: > > diff --git a/xen/drivers/char/rcar2-uart.c b/xen/drivers/char/rcar2-uart.c > > +static void rcar2_uart_interrupt(int ir

Re: [Xen-devel] [PATCH 3/3] grant-table: defer releasing pages acquired in a grant copy

>>> On 22.01.15 at 15:39, wrote: > On 22/01/15 14:34, Jan Beulich wrote: > On 20.01.15 at 19:19, wrote: >>> Acquiring a page for the source or destination of a grant copy is an >>> expensive operation. A common use case is for two adjacent grant copy >>> ops to operate on either the same sou

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

On Thu, Jan 22, 2015 at 5:56 PM, Ian Jackson wrote: > Oleksandr Dmytryshyn writes ("Re: [Xen-devel] [PATCH v5] sndif: add ABI for > Para-virtual sound"): >> On Thu, Jan 22, 2015 at 5:39 PM, Roger Pau Monné >> wrote: >> > Also, how often are the sound packets sent, and which size do they have? >

Re: [Xen-devel] [RFC PATCH V2 1/8] xen/mem_event: Cleanup of mem_event structures

>>> On 22.01.15 at 16:34, wrote: > On Thu, Jan 22, 2015 at 4:00 PM, Jan Beulich wrote: > On 18.01.15 at 16:17, wrote: >>> --- a/xen/include/public/mem_event.h >>> +++ b/xen/include/public/mem_event.h >>> @@ -27,9 +27,15 @@ >>> #ifndef _XEN_PUBLIC_MEM_EVENT_H >>> #define _XEN_PUBLIC_MEM_EVE

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

On Thu, Jan 22, 2015 at 5:41 PM, Ian Jackson wrote: > Oleksandr Dmytryshyn writes ("[PATCH v5] sndif: add ABI for Para-virtual > sound"): >> This is ABI for the two halves of a Para-virtual >> sound driver to communicate with each to other. > ... >> + * Request open - open an pcm stream for playb

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

Oleksandr Dmytryshyn writes ("Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound"): > On Thu, Jan 22, 2015 at 5:39 PM, Roger Pau Monné wrote: > > Also, how often are the sound packets sent, and which size do they have? > > I'm mainly asking because I don't know if it would be more s

Re: [Xen-devel] [PATCH OSSTEST v5 00/13] support for ARM32 arndale and cubietruck platforms

On Thu, 2015-01-22 at 15:52 +, Ian Campbell wrote: > Pushing the ~1 to the output will force a test run, once that is done I > will push the osstest patches. Actually using the result will require me to push this along with the main series. 8<--- >From ba72d891c2d97991a4b00d8958883d17e4b

Re: [Xen-devel] [RFC PATCH V2 4/8] x86/hvm: rename hvm_memory_event_* functions to hvm_event_*

On 18/01/15 15:17, Tamas K Lengyel wrote: > The function names currently imply that these events are to be delivered via > the memory_event subsystem. However, the naming is confusing as these events > have nothing to do with actual memory events. Simply naming these functions > hvm_event_* more ac

Re: [Xen-devel] [PATCH OSSTEST v5 00/13] support for ARM32 arndale and cubietruck platforms

On Thu, 2015-01-22 at 10:56 +, Ian Campbell wrote: > I've managed to make a habit of forgetting to mention one important > point (including hitting send on this bit in reply to v4!) > > Both the cubietruck and the arndale are (for different reasons) not > supported by the 3.14 kernel which we

Re: [Xen-devel] Outstanding OSSTEST patch series

On Tue, 2015-01-20 at 15:07 +0100, Dario Faggioli wrote: > the one reorganizing scheduler jobs have received feedback already Ian has asked me to push this along with my osstest patches to support the new arm boards in the next couple of days. Accordingly I'm planning to pick up the patch from <2

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound

On Thu, Jan 22, 2015 at 5:39 PM, Roger Pau Monné wrote: > El 22/01/15 a les 16.19, Oleksandr Dmytryshyn ha escrit: > [...] >> +/* >> + * Description of the protocol between the frontend and the backend driver. >> + * >> + * The two halves of a Para-virtual sound driver communicates with >> + * eac

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

- jbeul...@suse.com wrote: > >>> On 22.01.15 at 16:11, wrote: > > - jbeul...@suse.com wrote: > >> A fundamental question is what business devices have to DMA their > >> own (or other devices') MMIO space. I could remotely see a need > >> for this for e.g. frame buffers, but I have diffic

Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

At 13:54 -0800 on 19 Jan (1421672054), Ed White wrote: > > Or: declare in the interface that the altp2ms are soft state that can > > be dropped on migration, with some suitable callback (#VE injection?) > > to the guest when an altp2m 'view' is not available. That depends on > > whether the in-gue

Re: [Xen-devel] [PATCH v3 3/3] xen: prevent access to HPET from Dom0

>>> On 22.01.15 at 16:19, wrote: > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -36,6 +36,7 @@ > #include /* for bzimage_parse */ > #include > #include > +#include /* for hpet_address */ Please drop the comment - with hpet_flags it's now stale > @@ -1495,6 +1

Re: [Xen-devel] [PATCH v3 2/3] xen/pvh: check permissions when adding MMIO regions

>>> On 22.01.15 at 16:19, wrote: > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -320,11 +320,24 @@ static __init void pvh_add_mem_mapping(struct domain > *d, unsigned long gfn, > { > unsigned long i; > p2m_access_t a; > +mfn_t omfn; > +p2m_type_t t

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions

El 22/01/15 a les 16.18, Elena Ufimtseva ha escrit: > > - jbeul...@suse.com wrote: > > On 22.01.15 at 12:37, wrote: >>> El 22/01/15 a les 12.09, Jan Beulich ha escrit: >>> On 22.01.15 at 11:59, wrote: > On 22/01/15 09:53, Jan Beulich wrote: > On 21.01.15 at 21:55, wrote

  1   2   3   >