Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output

On Tue, Oct 17, 2017 at 02:44:29PM +0100, Dave Martin wrote: > arch/arm/kernel/debug.S: > > ENTRY(printascii) > addruart_current r3, r1, r2 > b 2f > 1: waituart r2, r3 > senduart r1, r3 > busyuart r2, r3 >

Re: [Xen-devel] [PATCH 25/44] arm: implement ->mapping_error

BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote: > +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr) > +{ > + if (dev->archdata.dmabounce) > + return 0; I'm not convinced that we need this check here: dev->archdata.dmabounce =

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

rrors if you try to build > with > - * -ffreestanding and include 'stdint.h' (such as when you include > 'arm_neon.h' > - * in order to use NEON intrinsics) > - * > - * As the typedefs for these types in 'stdint.h' are based on builtin defines > - * supplied by GCC, we can tweak

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote: > Please, do not remove the email subject when you reply. I restore it to > ease the thread follow-up. I mentioned it to David, and he says it's because the long list of recipients is breaking his mailer. I've already posed the

Re: [Xen-devel] [PATCH v2 1/7] arm: put types.h in uapi

On Mon, Jan 09, 2017 at 12:33:02PM +0100, Arnd Bergmann wrote: > On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote: > > > > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h > > index a53cdb8f068c..c48fee3d7b3b 100644 > > --- a/arch/arm/include/asm/types.h >

Re: [Xen-devel] [PATCH v2 7/7] uapi: export all headers under uapi directories

On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: > diff --git a/arch/arm/include/uapi/asm/Kbuild > b/arch/arm/include/uapi/asm/Kbuild > index 46a76cd6acb6..607f702c2d62 100644 > --- a/arch/arm/include/uapi/asm/Kbuild > +++ b/arch/arm/include/uapi/asm/Kbuild > @@ -1,23 +1,6 @@ > #

Re: [Xen-devel] [PATCH 1/1] sched: provide common cpu_relax_yield definition

nclude/asm/processor.h| 2 -- > arch/x86/um/asm/processor.h | 1 - > arch/xtensa/include/asm/processor.h | 1 - > include/linux/sched.h | 4 > 33 files changed, 5 insertions(+), 38 deletions(-) > > diff --git a/arch/alpha/include/asm/process

Re: [Xen-devel] [GIT PULL v2 1/5] processor.h: introduce cpu_relax_yield

On Tue, Nov 15, 2016 at 02:19:53PM +0100, Christian Borntraeger wrote: > On 11/15/2016 01:30 PM, Russell King - ARM Linux wrote: > > On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote: > >> For spinning loops people do often use barrier() or cpu_rela

Re: [Xen-devel] [GIT PULL v2 1/5] processor.h: introduce cpu_relax_yield

. By default this is the same as cpu_relax on all architectures. Rather than having to update all these architectures in this way, can't we put in some linux/*.h header something like: #ifndef cpu_relax_yield #define cpu_relax_yield() cpu_relax() #endif so only those architectures that need to do something n

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

On 2016-09-05 13:43, Jan Beulich wrote: On 05.09.16 at 13:19, wrote: On 2016-09-05 12:25, Jan Beulich wrote: Anyway - with you quite clearly having used HAP before, I can't see how this commit would matter for you at all. In case you want to double check you could try

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

On 2016-09-05 12:25, Jan Beulich wrote: On 05.09.16 at 12:02, wrote: On 2016-09-05 11:46, Jan Beulich wrote: On 05.09.16 at 11:20, wrote: Hmm it seems my thread was kind of hijacked and i was dropped from the CC. I had some time and bisected the

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

paddr=0x220 memsz=0x109000 (XEN) [2016-09-05 09:06:59.832] elf_parse_binary: phdr: paddr=0x2309000 memsz=0x18ea8 (XEN) [2016-09-05 09:06:59.842] elf_parse_binary: phdr: paddr=0x2322000 memsz=0x2de000 (XEN) [2016-09-05 09:06:59.851] elf_parse_binary: memory: 0x1000000 -> 0x260 (XEN) [201

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

On 2016-08-25 23:18, li...@eikelenboom.it wrote: On 2016-08-25 22:34, Doug Goldstein wrote: On 8/25/16 4:21 PM, li...@eikelenboom.it wrote: Today i tried to switch some of my HVM guests (qemu-xen) from booting of a kernel *inside* the guest, to a dom0 supplied kernel, which is described as

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

On 2016-08-25 22:34, Doug Goldstein wrote: On 8/25/16 4:21 PM, li...@eikelenboom.it wrote: Today i tried to switch some of my HVM guests (qemu-xen) from booting of a kernel *inside* the guest, to a dom0 supplied kernel, which is described as "Direct Kernel Boot" here:

[Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

Today i tried to switch some of my HVM guests (qemu-xen) from booting of a kernel *inside* the guest, to a dom0 supplied kernel, which is described as "Direct Kernel Boot" here: https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html : Direct Kernel Boot Direct kernel boot allows

Re: [Xen-devel] [PATCH v05 54/72] include/uapi/xen/privcmd.h: fix compilation in userspace

On Mon, Aug 22, 2016 at 08:33:11PM +0200, Mikko Rapeli wrote: > xen/interface/xen.h is not exported from kernel headers so remove the > dependency and provide needed defines for domid_t and xen_pfn_t if they > are not already defined by some other e.g. Xen specific headers. I'm confused. How did

Re: [Xen-devel] Xen-unstable 4.8: Host crash when shutting down guest with pci device passed through using MSI-X interrupts.

On 2016-07-18 22:57, Andrew Cooper wrote: On 18/07/2016 20:26, Sander Eikelenboom wrote: Monday, July 18, 2016, 7:48:20 PM, you wrote: On 18/07/16 11:21, li...@eikelenboom.it wrote: Hi Jan, It seems that since your patch series starting with commit: 2016-06-22 x86/vMSI-X: defer intercept

[Xen-devel] Xen-unstable 4.8: Host crash when shutting down guest with pci device passed through using MSI-X interrupts.

Hi Jan, It seems that since your patch series starting with commit: 2016-06-22 x86/vMSI-X: defer intercept handler registration 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798 The shutdown of a guest which has a PCI device passed through which uses MSI-X interrupts causes a host crash, see the splat

[Xen-devel] [PATCH v2] xen: x86: remove duplicated IA32_FEATURE_CONTROL MSR macro

From: Kai Huang Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR macro. The new one has better naming convention, so remove the old as a duplication. Also move the macros of bit

[Xen-devel] [PATCH] xen: x86: remove duplicated IA32_FEATURE_CONTROL MSR macro

From: Kai Huang Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR macro. The new one has better naming convention, so remove the old as duplication and replace the relevant code

[Xen-devel] [PATCH] xen: x86: remove duplicated MSR_IA32_FEATURE_CONTROL definition

From: Kai Huang MSR_IA32_FEATURE_CONTROL was introduced in below commit. Actually this MSR has already been defined as IA32_FEATURE_CONTROL_MSR. Remove it as a duplication. Also introduce a new macro for SGX_ENABLE bit in this MSR for better code and further use. The

[Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

Hi, Just tested latest xen-unstable 4.8 (xen_changeset git:d337764), but one of the latest commits seems to have broken boot of HVM guests (using qemu-xen) previous build with xen_changeset git:6e908ee worked fine. -- Sander (XEN) [2016-06-14 22:47:36.827] HVM19 save: CPU (XEN) [2016-06-14

Re: [Xen-devel] [PATCH 2/4] ARM: dma-mapping: Constify attrs passed to internal functions

On Tue, May 24, 2016 at 08:28:08AM +0200, Krzysztof Kozlowski wrote: > Some of the non-exported functions do not modify passed dma_attrs so the > pointer can point to const data. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Russell King

Re: [Xen-devel] [RFC v2 7/7] kprobes: port to linker table

On Fri, Feb 19, 2016 at 05:45:59AM -0800, Luis R. Rodriguez wrote: > kprobe makes use of two custom sections: > > type name beginend > init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist > text .kprobes.text

Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote: > On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > > > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrot

Re: [Xen-devel] [PATCH 1/3] checkpatch.pl: add missing memory barriers

On Mon, Jan 04, 2016 at 08:07:40AM -0800, Joe Perches wrote: > On Mon, 2016-01-04 at 13:36 +0200, Michael S. Tsirkin wrote: > > + my $all_barriers = join('|', (@barriers, @smp_barriers)); > > + > > + if ($line =~ /\b($all_barriers)\(/) { > > It would be better to use

Re: [Xen-devel] [PATCH v2 08/32] arm: reuse asm-generic/barrier.h

On Thu, Dec 31, 2015 at 09:06:46PM +0200, Michael S. Tsirkin wrote: > On arm smp_store_mb, read_barrier_depends, smp_read_barrier_depends, > smp_store_release, smp_load_acquire, smp_mb__before_atomic and > smp_mb__after_atomic match the asm-generic variants exactly. Drop the > local definitions

Re: [Xen-devel] [PATCH v2 17/32] arm: define __smp_xxx

On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for arm, > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > This reduces the amount of arch-specific boiler-plate code. >

Re: [Xen-devel] [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote: > The code builds, but of course it could not actually run on CPU_V6. But > the use case for me is building drivers/xen/grant-table.c, which can > only run on CPU_V7 anyway, so it is not a problem. What I'm concerned about in

Re: [Xen-devel] [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

On Tue, Dec 22, 2015 at 02:17:17PM +, Stefano Stabellini wrote: > Hello Russell, > > Would you please consider this patch for the next merge window? It > is a very old patch (March 2014) which has been left over. This patch has some obvious problems... > diff --git a/arch/arm/Kconfig

Re: [Xen-devel] [PATCH v11 3/5] arm: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops

On Fri, Nov 20, 2015 at 02:40:31PM +, Stefano Stabellini wrote: > On Fri, 20 Nov 2015, Christopher Covington wrote: > > Hi Stefano, > > > > On 11/20/2015 09:31 AM, Stefano Stabellini wrote: > > > On Tue, 10 Nov 2015, Stefano Stabellini wrote: > > >> On Thu, 5 Nov 2015, Stefano Stabellini

Re: [Xen-devel] [PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

On Mon, Sep 14, 2015 at 10:36:55AM +0100, Stefano Stabellini wrote: > On Fri, 11 Sep 2015, Russell King - ARM Linux wrote: > > If you'd like your ack on it, please send one, I can still do that. > > Acked-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com> Sorry, that

Re: [Xen-devel] [PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

On Fri, Sep 11, 2015 at 06:36:05PM +0100, Julien Grall wrote: > On 11/09/15 18:32, Julien Grall wrote: > > On 11/09/15 18:00, Russell King - ARM Linux wrote: > >> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote: > >>> + /* > >>> + * Privcmd

Re: [Xen-devel] [PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote: > + /* > + * Privcmd calls are issued by the userspace. We need to allow the > + * kernel to access the userspace memory before issuing the hypercall. > + */ > + uaccess_enable r4 > + > + /* r4 is loaded now

Re: [Xen-devel] [PATCH v2] arm/xen: Enable user access to the kernel before issuing a privcmd call

On Fri, Sep 11, 2015 at 06:56:50PM +0100, Stefano Stabellini wrote: > On Fri, 11 Sep 2015, Russell King - ARM Linux wrote: > > On Fri, Sep 11, 2015 at 06:36:05PM +0100, Julien Grall wrote: > > > On 11/09/15 18:32, Julien Grall wrote: > > > > On 11/09/15 18:00,

Re: [Xen-devel] [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call

On Fri, Sep 11, 2015 at 03:45:29PM +0100, Julien Grall wrote: > Looking to the uaccess_save macro: > > .macro uaccess_save, tmp > #ifdef CONFIG_CPU_SW_DOMAIN_PAN > mrc p15, 0, \tmp, c3, c0, 0 > str \tmp, [sp, #S_FRAME_SIZE] > #endif > .endm > > > It's

Re: [Xen-devel] [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call

On Fri, Sep 11, 2015 at 03:56:38PM +0100, Julien Grall wrote: > Well, we can't assume that the function will be called with uaccess > disabled. Please explain your reasoning. The reason copy_from_user() et.al. need to save and restore the DACR is because the DACR may be in one of two states on

Re: [Xen-devel] [PATCHv1] xen/events/fifo: Handle linked events when closing a PIRQ port

/events_fifo.c b/drivers/xen/events/events_fifo.c index 6df8aac..149e1e9 100644 --- a/drivers/xen/events/events_fifo.c +++ b/drivers/xen/events/events_fifo.c @@ -40,6 +40,7 @@ #include linux/smp.h #include linux/percpu.h #include linux/cpu.h +#include linux/slab.h #include asm/sync_bitops.h

[Xen-devel] Linux 4.2-rc5:

Hi Ross, On my dom0 with a linux 4.2-rc5 kernel i encoutered the splat below. It's probably related to your patch that went in just for 4.2-rc5: xen/events/fifo: Handle linked events when closing a port -- Sander [ 49.020173] [ cut here ] [ 49.020187] WARNING: CPU

[Xen-devel] Xen-unstable + Linux 4.2-rc4: GPF RIP: e030:[ffffffff8110ea98] [ffffffff8110ea98] detach_if_pending+0x18/0x80

Hi, Running on Xen testing a 4.2-rc4 kernel it got the crash below. Could this be related to the changes in 3bb475a3446facd0425d3f2fe7e85bf03c5c6c05 ? It crashes dom0 when i put some strain onto the network + bridge. -- Sander [ 2108.078763] general protection fault: [#1] SMP [

Re: [Xen-devel] xen-unstabel + linux 4.2: MMIO emulation failed: d23v0 64bit @ 0010:ffffffff814e2b1c - 66 89 02 48 8d 55 c0 48 89 5d c0 44 89 65 c8 e8

On 2015-07-27 16:07, Andrew Cooper wrote: On 24/07/15 19:56, li...@eikelenboom.it wrote: Hi All, On my AMD system running xen-unstable (last commit: ), after a few restarts of a HVM guest with pci-passthrough i got these on shutdown of the guest: (never seen this before, so it should be

[Xen-devel] xen-unstabel + linux 4.2: MMIO emulation failed: d23v0 64bit @ 0010:ffffffff814e2b1c - 66 89 02 48 8d 55 c0 48 89 5d c0 44 89 65 c8 e8

Hi All, On my AMD system running xen-unstable (last commit: ), after a few restarts of a HVM guest with pci-passthrough i got these on shutdown of the guest: (never seen this before, so it should be something triggered by a recent commit) -- Sander (probably lost before but that's

[Xen-devel] traps.c:3227: GPF (0000): ffff82d080194a4d - ffff82d080239d85 and other dom0 induced log messages

Hi Jan / David, On the other thread you asked about some messages in xl-dmesg, over time there are more that come from a kernel booting. (mind you that there can be some changes in Kconfigs between the kernels i have used.) 3.16 was clean this is what xl-dmesg gained on log message that seem

Re: [Xen-devel] Xen-unstable: pci-passthrough of device using MSI-X interrupts not working after commit x86/MSI: track host and guest masking separately

On 2015-06-26 17:22, Jan Beulich wrote: On 26.06.15 at 17:04, jbeul...@suse.com wrote: On 26.06.15 at 15:38, li...@eikelenboom.it wrote: On 2015-06-26 14:41, Jan Beulich wrote: On 26.06.15 at 13:02, li...@eikelenboom.it wrote: Strange, i don't see *any* of your printk's being hit ... (xl

Re: [Xen-devel] Xen-unstable: pci-passthrough of device using MSI-X interrupts not working after commit x86/MSI: track host and guest masking separately

immediately know whether there's an option to make a guest become a normal HVM one again. Jan Hmm i had to read up on the difference .. http://wiki.xen.org/wiki/Virtualization_Spectrum#Paravirtualizing_little_by_little:_PVHVM_mode But doesn't it almost always do that on linux guests (since most

Re: [Xen-devel] Xen-unstable: pci-passthrough of device using MSI-X interrupts not working after commit x86/MSI: track host and guest masking separately

(XEN) [2015-06-26 10:41:32.803] elf_xen_parse_note: GUEST_OS = linux (XEN) [2015-06-26 10:41:32.812] elf_xen_parse_note: GUEST_VERSION = 2.6 (XEN) [2015-06-26 10:41:32.821] elf_xen_parse_note: XEN_VERSION = xen-3.0 (XEN) [2015-06-26 10:41:32.830] elf_xen_parse_note: VIRT_BASE = 0x8000

Re: [Xen-devel] Xen-unstable: pci-passthrough of device using MSI-X interrupts not working after commit x86/MSI: track host and guest masking separately

On 2015-06-25 15:37, Jan Beulich wrote: On 25.06.15 at 15:16, li...@eikelenboom.it wrote: Thursday, June 25, 2015, 2:40:18 PM, you wrote: Hmm, no, this Capabilities: [90] MSI-X: Enable+ Count=8 Masked- Vector table: BAR=0 offset=1000 PBA: BAR=0

Re: [Xen-devel] [Patch v2 08/14] genirq: Introduce helper function irq_data_get_affinity_mask()

(irq_data_get_affinity_mask(d), affinity); return ret; } diff --git a/include/linux/irq.h b/include/linux/irq.h index 43581e166298..2eb82257aaee 100644 --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -650,6 +650,18 @@ static inline int irq_data_get_node(struct irq_data *d

Re: [Xen-devel] [PATCHv6 1/3] arm: make __get_user() work for 8 byte values

On Fri, Mar 06, 2015 at 12:58:33PM +, David Vrabel wrote: diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h index ce0786e..d8f535b 100644 --- a/arch/arm/include/asm/uaccess.h +++ b/arch/arm/include/asm/uaccess.h @@ -306,6 +306,7 @@ do {

Re: [Xen-devel] [PATCH v9 05/13] arm: introduce is_device_dma_coherent

On Thu, Nov 20, 2014 at 10:39:32AM +, Stefano Stabellini wrote: On Thu, 20 Nov 2014, Russell King - ARM Linux wrote: On Tue, Nov 18, 2014 at 04:49:21PM +, Stefano Stabellini wrote: ping? Sending something which wants my attention _To:_ me is always a good idea :) I'll keep

Re: [Xen-devel] [PATCH v9 05/13] arm: introduce is_device_dma_coherent

On Tue, Nov 18, 2014 at 04:49:21PM +, Stefano Stabellini wrote: ping? Sending something which wants my attention _To:_ me is always a good idea :) The patch is fine in itself, but I have a niggle about the is_device_dma_coherent() - provided this is only used in architecture specific code,