[Xen-devel] [xen-unstable-smoke test] 99736: regressions - FAIL

flight 99736 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99736/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 99707 Tests

[Xen-devel] [xen-unstable-smoke test] 99732: regressions - FAIL

flight 99732 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99732/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 99707 Tests

Re: [Xen-devel] [PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

On Tue, Jul 26, 2016 at 01:19:35PM +0800, Bob Liu wrote: > Two places didn't get updated when 64KB page granularity was introduced, this > patch fix them. > > Signed-off-by: Bob Liu > Acked-by: Roger Pau Monné Could you rebase this on

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

> > > Sadly not. The debug symbols need to be specific to the exact binary > > > you booted. > > > > > > Any change in the compilation will result in the translation being > > > useless. What addr2line is doing is saying "which specific bit of > > > source code did the compiler/linker end up

Re: [Xen-devel] pci passthrough kills qemu-xen

On Mon, Jul 25, 2016 at 11:56:40AM +0200, Olaf Hering wrote: > I'm trying to assing a PCIe network card to a HVM guest on an Dell > Optiplex 980. This works with qemu-xen-traditional, but fails with > qemu-xen. I tried staging-4.4 and staging-4.7, both with xenlinux based > SLE12 dom0 kernel and

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 05:28 PM, li...@ssl-mail.com wrote: > 123 unsigned long long size = md->num_pages << > EFI_PAGE_SHIFT; If I'm reading it right, that originated in this pull DateMon, 16 May 2016 16:43:11 +0200 FromIngo Molnar <> Subject [GIT PULL] EFI

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 11:36 AM, li...@ssl-mail.com wrote: > On Wed, Jul 27, 2016, at 11:28 AM, Andrew Cooper wrote: > > > I'm not sure if that's good enough. > > > > Sadly not. The debug symbols need to be specific to the exact binary > > you booted. > > > > Any change in the compilation

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 28/07/2016 00:46, Rafael J. Wysocki wrote: > On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote: >> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki >> wrote: >>> The STAO definition document: >>> >>>

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki wrote: > > > > The STAO definition document: > > > > http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf > > > > requires as to "operate as

[Xen-devel] Integration of xen vTPM in Openstack cloud

Hello, I saw in an earlier xen-devel conversation that there were some efforts going on to integrate xen vTPM in to the Openstack cloud so that Openstack managed VM's can work with Xen vTPM. I'd like to know if this was

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki wrote: > > The STAO definition document: > > http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf > > requires as to "operate as if that device does not exist", quite literally. Well, first off,

Re: [Xen-devel] [PATCH 04/19] xen: Move evtchn functions to xen_pvdev.c

On 07/25/2016 07:53 AM, Anthony PERARD wrote: > On Sun, Jul 10, 2016 at 02:47:35PM +0300, Emil Condrea wrote: >> The name of the functions moved: >> * xen_be_evtchn_event >> * xen_be_unbind_evtchn >> * xen_be_send_notify >> >> Signed-off-by: Emil Condrea >> --- >>

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/27/2016 10:24 PM, Roger Pau Monné wrote: > On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote: >> >> On 07/27/2016 06:59 PM, Roger Pau Monné wrote: >>> On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: >>> [...] +static ssize_t dynamic_reconfig_device(struct blkfront_info

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On Wednesday, July 27, 2016 07:57:34 PM Andrew Cooper wrote: > On 27/07/16 19:42, Linus Torvalds wrote: > > On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote: > >> Shannon Zhao (16): > >> Xen: ACPI: Hide UART used by Xen > > So this caused a trivial conflict. No

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Tue, Jul 26, 2016 at 12:30:14AM +0900, Masami Hiramatsu wrote: > On Fri, 22 Jul 2016 14:24:41 -0700 > "Luis R. Rodriguez" wrote: > > > +/** > > + * LINKTABLE_RUN_ALL - iterate and run through all entries on a linker > > table > > + * > > + * @tbl: linker table > > + *

Re: [Xen-devel] [RFC v3 13/13] kprobes: port blacklist kprobes to linker table

On Tue, Jul 26, 2016 at 12:27:22AM +0900, Masami Hiramatsu wrote: > On Fri, 22 Jul 2016 14:24:47 -0700 > "Luis R. Rodriguez" wrote: > > > kprobe makes use of two sections, the one dealing with the actual > > kprobes was recently ported using the standard section range API. > >

Re: [Xen-devel] [RFC v3 10/13] jump_label: port __jump_table to linker tables

On Fri, Jul 22, 2016 at 05:55:35PM -0500, Josh Poimboeuf wrote: > On Sat, Jul 23, 2016 at 12:26:54AM +0200, Luis R. Rodriguez wrote: > > On Fri, Jul 22, 2016 at 04:49:45PM -0500, Josh Poimboeuf wrote: > > > On Fri, Jul 22, 2016 at 02:24:44PM -0700, Luis R. Rodriguez wrote: > > > > diff --git

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

On Mon, Jul 25, 2016 at 10:32:29PM +0900, Masami Hiramatsu wrote: > Hi Luis, > > On Fri, 22 Jul 2016 14:24:34 -0700 > "Luis R. Rodriguez" wrote: > > > This RFC v3 builds off the last RFC v2 series [0] for adding linker tables. > > The largest amount of work here was to take

Re: [Xen-devel] [RFC v3 12/13] kprobes: port .kprobes.text to section range

On Tue, Jul 26, 2016 at 12:19:58AM +0900, Masami Hiramatsu wrote: > On Fri, 22 Jul 2016 14:24:46 -0700 > "Luis R. Rodriguez" wrote: > > > kprobe makes use of two custom sections, each custom section > > is folded into one of the standard Linux sections types as follows, > > it

[Xen-devel] [xen-unstable-smoke test] 99729: regressions - FAIL

flight 99729 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99729/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 99707 Tests

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

On 27/07/2016 18:55, Stefano Stabellini wrote: On Wed, 27 Jul 2016, Julien Grall wrote: Hi, On 20/07/16 17:10, Julien Grall wrote: Currently, mfn_to_p2m_entry is relying on the caller to provide the correct memory attribute and will deduce the sharability based on it. Some of the callers,

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

Hi Stefano, On 27/07/2016 19:25, Stefano Stabellini wrote: On Wed, 27 Jul 2016, Julien Grall wrote: Hi Stefano, On 26/07/16 23:28, Stefano Stabellini wrote: On Wed, 20 Jul 2016, Julien Grall wrote: @@ -411,7 +411,7 @@ static int p2m_create_table(struct domain *d, lpae_t *entry, if (

Re: [Xen-devel] [xen-unstable-smoke test] 99722: regressions - FAIL

On 27/07/2016 20:51, osstest service owner wrote: > flight 99722 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/99722/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

[Xen-devel] [PATCH] libxl: compilation warning fix for arm & aarch64

From: Chris Patterson GCC 6 will warn on unused static const variables in c modules: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00847.html When compiling with LIBXL_HAVE_NO_SUSPEND_RESUME set (arm & aarch64), the compiler emits the following errors:

[Xen-devel] [xen-unstable-smoke test] 99722: regressions - FAIL

flight 99722 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99722/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 99707 Tests

Re: [Xen-devel] OVMF very slow on AMD

On 07/27/2016 07:35 AM, Anthony PERARD wrote: > On Wed, Jul 27, 2016 at 12:08:04PM +0100, Anthony PERARD wrote: >> I can try to describe how OVMF is setting up the memory. > From the start of the day: > setup gdt > cr0 = 0x4023 I think this is slightly odd, with bit 30 (cache disable) set.

Re: [Xen-devel] [PATCH v3 0/9] xen/arm: Support SPIs routing

Committed, thank you. On Wed, 27 Jul 2016, Julien Grall wrote: > Hello all, > > Currently, Xen does not route SPIs to DOM0 when ACPI is inuse after > the functionality has been reverted in Xen 4.7 by commit 909bd14. > > In the previous approach, the SPIs was routed when DOM0 was writing into >

Re: [Xen-devel] [PATCH v3 7/9] xen/arm: Allow DOM0 to set the IRQ type

On Wed, 27 Jul 2016, Julien Grall wrote: > The function route_irq_to_guest mandates the IRQ type, stored in > desc->arch.type, to be valid. However, in case of ACPI, these > information is not part of the static tables. Therefore Xen needs to > rely on DOM0 to provide a valid type based on the

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 27/07/16 19:42, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote: >> Shannon Zhao (16): >> Xen: ACPI: Hide UART used by Xen > So this caused a trivial conflict. No biggie, it wasn't bad and the > patch was acked by Rafael. However, looking

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote: > > Shannon Zhao (16): > Xen: ACPI: Hide UART used by Xen So this caused a trivial conflict. No biggie, it wasn't bad and the patch was acked by Rafael. However, looking at it made me somewhat unhappy. Should the

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 11:28 AM, Andrew Cooper wrote: > > I'm not sure if that's good enough. > > Sadly not. The debug symbols need to be specific to the exact binary > you booted. > > Any change in the compilation will result in the translation being > useless. What addr2line is doing is

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On 27/07/16 18:56, Andrew Cooper wrote: > On 27/07/16 17:54, li...@ssl-mail.com wrote: >> >> On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote: >>> This looks suspiciously like the issue which was fixed by c/s >>> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when >>>

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On 27/07/16 19:22, li...@ssl-mail.com wrote: > > On Wed, Jul 27, 2016, at 09:56 AM, Andrew Cooper wrote: Failing that, can you find out exactly where the kernel crashed? You need to manually decode 81f6374c with the debug symbols. >>> Sure can try. I'm gonna have to read-up on

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

On Wed, 27 Jul 2016, Julien Grall wrote: > Hi Stefano, > > On 26/07/16 23:28, Stefano Stabellini wrote: > > On Wed, 20 Jul 2016, Julien Grall wrote: > > > @@ -411,7 +411,7 @@ static int p2m_create_table(struct domain *d, lpae_t > > > *entry, > > > if ( splitting ) > > > { > > >

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 09:56 AM, Andrew Cooper wrote: > >> Failing that, can you find out exactly where the kernel crashed? You > >> need to manually decode 81f6374c with the debug symbols. > > Sure can try. I'm gonna have to read-up on how . Atm no clue. > > addr2line -e

[Xen-devel] [PATCH 1/2] x86/mm: Avoid NULL dereference when checking altp2m's for shareability

Coverity identifies that __get_gfn_type_access() unconditionally writes to its type parameter under a number of circumstances. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap

[Xen-devel] [PATCH 2/2] x86/mm: Annotate gfn_get_* helpers as requiring non-NULL parameters

Introduce and use the nonnull attribute to help the compiler catch NULL parameters being passed to function which require their parameters not to be NULL. Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness from immediate callers, so propagate the attributes out to all helpers.

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

Hi Stefano, On 27/07/16 18:56, Stefano Stabellini wrote: On Wed, 27 Jul 2016, Julien Grall wrote: On 26/07/16 23:44, Stefano Stabellini wrote: On Wed, 20 Jul 2016, Julien Grall wrote: Currently, the check in get_page_from_gfn is using a blacklist. This is very fragile because we may forgot

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

On Wed, 27 Jul 2016, Julien Grall wrote: > On 26/07/16 23:44, Stefano Stabellini wrote: > > On Wed, 20 Jul 2016, Julien Grall wrote: > > > Currently, the check in get_page_from_gfn is using a blacklist. This is > > > very fragile because we may forgot to update the check when a new p2m > > > type

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

On Wed, 27 Jul 2016, Julien Grall wrote: > Hi, > > On 20/07/16 17:10, Julien Grall wrote: > > Currently, mfn_to_p2m_entry is relying on the caller to provide the > > correct memory attribute and will deduce the sharability based on it. > > > > Some of the callers, such as p2m_create_table, are

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

On 27/07/16 18:28, Sergej Proskurin wrote: Hi Julien, Hello Sergej, Please reply to all (or at least CC me) when answering to xen-devel. Otherwise your mail may be missed or the answer may be delayed because I filter any mail where I am not the recipients (a lot of people do this on the

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

Hi Julien, On 07/27/2016 07:09 PM, Julien Grall wrote: > Translating a VA to a IPA is expensive. Currently, Xen is assuming that > HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened > during a translation table walk of a first stage translation (i.e S1PTW > is set). > >

Re: [Xen-devel] [PATCH 16/22] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

Hi, On 20/07/16 17:10, Julien Grall wrote: The field vttbr holds the base address of the translation table for guest. Its value will depends on how the p2m has been initialized and will only be used by the code code. So move the field from arch_domain to p2m_domain. This will also ease the

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

Hi, On 20/07/16 17:10, Julien Grall wrote: Currently, mfn_to_p2m_entry is relying on the caller to provide the correct memory attribute and will deduce the sharability based on it. Some of the callers, such as p2m_create_table, are using same memory attribute regardless the underlying p2m

[Xen-devel] [PATCH v2 0/6] xen/arm: Simplify do_trap_*_abort_guest

Hello all, The current data/instruction abort paths contain unnecessary code and translate to often a VA to a IPA. This series aim to simplify this path. Now that the register HPFAR_EL2 is read in some case that can be affected by the erratum 834220 on Cortex-A57, we need to implement a

[Xen-devel] [PATCH v2 6/6] xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround

The ARM erratum applies to certain revisions of Cortex-A57. The processor may report a Stage 2 translation fault as the result of Stage 1 fault for load crossing a page boundary when there is a permission fault or device memory fault at stage 1 and a translation fault at Stage 2. So Xen needs to

[Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

Translating a VA to a IPA is expensive. Currently, Xen is assuming that HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened during a translation table walk of a first stage translation (i.e S1PTW is set). However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is

[Xen-devel] [PATCH v2 3/6] xen/arm: Use check_workaround to handle the erratum 766422

Currently, Xen is accessing the stored MIDR everytime it has to check whether the processor is affected by the erratum 766422. This could take advantage of the new capability bitfields to detect whether the processor is affected at boot time. With this patch, the number of instructions to check

[Xen-devel] [PATCH v2 2/6] xen/arm: Provide macros to help creating workaround helpers

Workarounds may require to execute a different path when the platform is affected by the associated erratum. Furthermore, this may need to be called in the common code. To avoid too much intrusion/overhead, the workaround helpers need to be a nop on architecture which will never have the

[Xen-devel] [PATCH v2 4/6] xen/arm: traps: MMIO should only be emulated for fault translation

The function do_trap_data_abort_guest assumes that a stage-2 data abort can only be taken for a translation fault or permission fault today. Whilst this is true today, it might not be in the future. Rather than emulating the MMIO for any fault other than the permission one, print a warning

[Xen-devel] [PATCH v2 1/6] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

The fault status we care are in the form xx where xx is the lookup level that gave the fault. We can simplify the code by masking the 2 least significant bits. Signed-off-by: Julien Grall --- The switch has not been replaced by a simple if because more case

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On 27/07/16 17:54, li...@ssl-mail.com wrote: > > On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote: >> This looks suspiciously like the issue which was fixed by c/s >> d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when >> setting early page table entries", but that fix

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote: > This looks suspiciously like the issue which was fixed by c/s > d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when > setting early page table entries", but that fix is present in Linux 4.7.0 > > Can you check to see

[Xen-devel] [PATCH v6 3/7] xen/arm: Detect silicon revision and set cap bits accordingly

After each CPU has been started, we iterate through a list of CPU errata to detect CPUs which need from hypervisor code patches. For each bug there is a function which checks if that a particular CPU is affected. This needs to be done on every CPU to cover heterogenous systems properly. If a

[Xen-devel] [PATCH v6 1/7] xen/arm: Introduce alternative runtime patching

Some of the processor erratum will require to modify code sequence. As those modifications may impact the performance, they should only be enabled on affected cores. Furthermore, Xen may also want to take advantage of new hardware features coming up with v8.1 and v8.2. This patch adds an

[Xen-devel] [PATCH v6 6/7] xen/arm: arm64: Add cortex-A57 erratum 832075 workaround

The ARM erratum 832075 applies to certain revisions of Cortex-A57, one of the workarounds is to change device loads into using load-acquire semantics. Use the alternative framework to enable the workaround only on affected cores. Whilst a guest could trigger the deadlock, it can be broken when

[Xen-devel] [PATCH v6 7/7] xen/arm: traps: Don't inject a fault if the translation VA -> IPA fails

Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c), a Stage 1 translation error has priority over a Stage 2 translation error. Therefore gva_to_ipa can only fail if another vCPU is playing with the page table. Rather than injecting a custom fault, replay the instruction

[Xen-devel] [PATCH v6 5/7] xen/arm: arm64: Add Cortex-A53 cache errata workaround

The ARM errata 819472, 827319 and 824069 define the same workaround for these hardware issues in certain Cortex-A53 parts. The cache instructions "dc cvac" and "dc cvau" need to be upgraded to "dc civac". Use the alternative framework to replace those instructions only on affected cores. Whilst

[Xen-devel] [PATCH v6 0/7] xen/arm: Introduce alternative runtime patching on ARM64

Hello, Some of the processor errata will require to modify code sequence. As those modifications may impact the performance, they should only be enabled on affected cores. Furthermore, Xen may also want to take advantage of new hardware features coming up with v8.1 and v8.2. The first part of

[Xen-devel] [PATCH v6 4/7] xen/arm: Document the errata implemented in Xen

The new document will help to keep track of each erratum Xen is able to handle. The text is based on the Linux doc in Documents/arm64/silicon-errata.txt. Also list the current errata that Xen is aware of. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On 27/07/16 17:21, li...@ssl-mail.com wrote: > [0.00] DMI: Supermicro X10SAT/X10SAT, BIOS 3.0 05/26/2015 > [0.00] Hypervisor detected: Xen > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 08:50 AM, Andrew Cooper wrote: > This disassembles to > > callq *0x8(%rax) > > and %rax looks like an implausible value for a function pointer. This > particular issue is definitely an EFI firmware issue. With all the reference to & around EFI I kinda figured ... >

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: Detect silicon revision and set cap bits accordingly

Hi Konrad, On 22/07/16 15:24, Konrad Rzeszutek Wilk wrote: On Wed, Jul 20, 2016 at 04:25:56PM +0100, Julien Grall wrote: diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h new file mode 100644 index 000..fe93beb --- /dev/null +++

[Xen-devel] Xen Security Advisory 184 (CVE-2016-5403) - virtio: unbounded memory allocation issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-5403 / XSA-184 version 2 virtio: unbounded memory allocation issue UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On 27/07/16 00:32, li...@ssl-mail.com wrote: > I'm running Xen-4.7.0_08-452 + linux kernel 4.7.0-4.g89a2ada-default on > X86_64 UEFI hardware. > > If I boot without Xen hypervisor enabled it boots fine. > > If I boot with Xen enabled it PANICs: > > (XEN) [2016-07-26 22:05:33]

Re: [Xen-devel] [PATCH] xsm: don't require configuring tools to build xen xsm blob

Hi Wei, On 25/07/16 16:22, Wei Liu wrote: Starting from 08cffe66 ("xsm: add a default policy to .init.data") we can attach a xsm policy blob to hypervisor. To build that policy blob now hypervisor build system needs to enter tools directory. The expectation for hypervisor and tools build

Re: [Xen-devel] [oxenstored]Guest users could get the VM count and domids on the host

On Tue, Jul 12, 2016 at 4:35 AM, Sunguodong wrote: > Hi all, > > I found a problem in oxenstored, which may be a security issue: > Guest users could get the VM count and domids on the host by a sniffing > method. > > You can reproduce it like this: > (1) Create a VM, e.g.

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote: > > On 07/27/2016 06:59 PM, Roger Pau Monné wrote: > > On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: > > [...] > >> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, > >> ssize_t count) > >> +{ > >> + /* > >>

[Xen-devel] [PATCH v3 3/9] xen/arm: gic: split set_irq_properties

The callback set_irq_properties will configure the GIC for a specific IRQ with the type and the priority. In a follow-up patch, Xen will configure the type and the priority at different stage of the routing. So split it in 2 separate callbacks. At the same time, move the ASSERT to check the

[Xen-devel] [PATCH v3 2/9] xen/arm: gic: Do not configure affinity during routing

The affinity of a guest IRQ is set every time the guest enable it (see vgic_enable_irqs). It is not necessary to set the affinity when the IRQ is routed to the guest because Xen will never receive the IRQ until it hass been enabled by the guest. To keep gic_route_irq_to_{xen,guest} behaving the

[Xen-devel] [PATCH v3 8/9] xen/arm: acpi: route all unused IRQs to DOM0

It is not possible to know which IRQs will be used by DOM0 when ACPI is inuse. The approach implemented by this patch, will route all unused IRQs to DOM0 before it has booted. The number of IRQs routed is based on the maximum SPIs supported by the hardware (up to ~1000). However, some of them

[Xen-devel] [PATCH v3 5/9] xen/arm: gic: Document how gic_set_irq_type should be called

Changing the value of Int_config is UNPREDICTABLE when the corresponding interrupt is not disabled. The driver is assuming the interrupt will be disabled by the caller of gic_set_irq_type. Add an ASSERT to ensure it. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini

[Xen-devel] [PATCH v3 6/9] Revert "xen/arm: warn the user that we cannot route SPIs to Dom0 on ACPI"

This reverts commit f91c84edebe67296e4051af055dbf0adafb13a37. SPI routing for ACPI support will be added in a follow-up patch. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v3: - Fix typo in Stefano's e-mail

[Xen-devel] [PATCH v3 9/9] xen/arm: Fix coding style and update comment in acpi_route_spis

The comment was not correctly indented. Also the preferred name for the initial domain is "hardware domain" and not "dom0, so replace it. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v3: - Add Stefano's

[Xen-devel] [PATCH v3 7/9] xen/arm: Allow DOM0 to set the IRQ type

The function route_irq_to_guest mandates the IRQ type, stored in desc->arch.type, to be valid. However, in case of ACPI, these information is not part of the static tables. Therefore Xen needs to rely on DOM0 to provide a valid type based on the firmware tables. A new helper,

[Xen-devel] [PATCH v3 4/9] xen/arm: gic: set_type: Pass the type in parameter rather than in desc->arch.type

A follow-up patch will not store the type in desc->arch.type. Also, the callback prototype is more logical. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v3: - Add Stefano's reviewed-by Changes in v2:

[Xen-devel] [PATCH v3 0/9] xen/arm: Support SPIs routing

Hello all, Currently, Xen does not route SPIs to DOM0 when ACPI is inuse after the functionality has been reverted in Xen 4.7 by commit 909bd14. In the previous approach, the SPIs was routed when DOM0 was writing into ISENABLER. However, this has resulted to deadlock (see more details in [1]) as

[Xen-devel] [PATCH v3 1/9] xen/arm: gic: Consolidate the IRQ affinity set in a single place

The code to set the IRQ affinity is duplicated: once in gicv{2,3}_set_properties and the other is gicv{2,3}_irq_set_affinity. Remove the code from gicv{2,3}_set_properties and call directly the affinity set helper from the common code. Signed-off-by: Julien Grall

[Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.8-rc0-tag xen: features and fixes for 4.8-rc0 - - ACPI support for guests on ARM platforms. - - Generic steal time support for arm

Re: [Xen-devel] [PATCH v2 0/9] xen/arm: Support SPIs routing

On 14/07/16 19:17, Shanker Donthineni wrote: Hi Julien, Hello Shanker, Tested-by: Shanker Donthineni I have tested this patchset on Qualcomm Technologies QDF2XXX server platform without any issue. Thank you for testing this series on your platform. I have added

Re: [Xen-devel] [PATCH 0/6] libxl: extend device type framework

Series pushed to staging. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF very slow on AMD

On Wed, Jul 27, 2016 at 12:08:04PM +0100, Anthony PERARD wrote: > I can try to describe how OVMF is setting up the memory. From the start of the day: setup gdt cr0 = 0x4023 jump to 32bit cr4 = 0x640 setup page tables: page directory attributes: (PAGE_ACCESSED + PAGE_READ_WRITE +

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/27/2016 06:59 PM, Roger Pau Monné wrote: > On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: > [...] >> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, ssize_t >> count) >> +{ >> +/* >> + * Prevent new requests even to software request queue. >> + */

Re: [Xen-devel] OVMF very slow on AMD

On Fri, Jul 15, 2016 at 11:22:45AM -0400, Boris Ostrovsky wrote: > On 07/15/2016 09:48 AM, Konrad Rzeszutek Wilk wrote: > > On Thu, Jul 14, 2016 at 04:53:07PM +0100, Anthony PERARD wrote: > >> Hi, > >> > >> I've been investigating why OVMF is very slow in a Xen guest on an AMD > >> host. This, I

Re: [Xen-devel] [PATCH] xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo

On Fri, Jul 15, 2016 at 5:57 PM, Andrew Cooper wrote: > This allows a toolstack to identify whether a running domain is using hardware > assisted paging or not. > > The appropriate tests differ by architecture, so introduce > arch_get_domain_info(). ARM unconditionally

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: [...] > +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, ssize_t > count) > +{ > + /* > + * Prevent new requests even to software request queue. > + */ > + blk_mq_freeze_queue(info->rq); > + > + /* >

Re: [Xen-devel] [PATCH v2 2/3] xen-blkfront: introduce blkif_set_queue_limits()

On Tue, Jul 26, 2016 at 01:19:36PM +0800, Bob Liu wrote: > blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not > as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits > with initial correct values. > > Signed-off-by: Bob Liu

[Xen-devel] VM save/restore on Xen ARM

Hello Chenxiao, You mentioned that you were working on save/restore for Xen ARM on the hikey board a couple of months [1]. I am wondering if you are still working on? If so, do you have any plan to upstream it? Regards, [1]

Re: [Xen-devel] [PATCH 18/22] xen/arm: p2m: Rework the context switch to another VTTBR in flush_tlb_domain

Hi Stefano, On 27/07/16 02:12, Stefano Stabellini wrote: On Wed, 20 Jul 2016, Julien Grall wrote: The current implementation of flush_tlb_domain is relying on the domain to have a single p2m. With the upcoming feature altp2m, a single domain may have different p2m. So we would need to switch

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On Wed, Jul 27, 2016 at 05:12:22PM +0800, Bob Liu wrote: > > On 07/27/2016 04:07 PM, Roger Pau Monné wrote: > ..[snip].. > >> @@ -2443,6 +2674,22 @@ static void blkfront_connect(struct blkfront_info > >> *info) > >>return; > >>} > >> > >> + err =

Re: [Xen-devel] [PATCH 16/22] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

Hi Stefano, On 27/07/16 01:57, Stefano Stabellini wrote: On Wed, 20 Jul 2016, Julien Grall wrote: The field vttbr holds the base address of the translation table for guest. Its value will depends on how the p2m has been initialized and will only be used by the code code.

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

On 27/07/16 10:01, George Dunlap wrote: > On 26/07/16 23:43, Andrew Cooper wrote: >> On 26/07/2016 16:49, George Dunlap wrote: >>> On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel >>> wrote: On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

On 26/07/16 23:44, Stefano Stabellini wrote: On Wed, 20 Jul 2016, Julien Grall wrote: Currently, the check in get_page_from_gfn is using a blacklist. This is very fragile because we may forgot to update the check when a new p2m type is added. To avoid any possible issue, use a whitelist. All

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

Hi Stefano, On 26/07/16 23:28, Stefano Stabellini wrote: On Wed, 20 Jul 2016, Julien Grall wrote: @@ -411,7 +411,7 @@ static int p2m_create_table(struct domain *d, lpae_t *entry, if ( splitting ) { p2m_type_t t = entry->p2m.type; -unsigned long base_pfn =

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

> -Original Message- [snip] > > > > Also, I'm not sure this is correct, if blkfront sees the "Closing" state on > > blkback it will try to close the frontend and destroy the block device (see > > blkfront_closing), and this should be avoided. You should call > > blkfront_resume as soon as

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/27/2016 04:07 PM, Roger Pau Monné wrote: ..[snip].. >> @@ -2443,6 +2674,22 @@ static void blkfront_connect(struct blkfront_info >> *info) >> return; >> } >> >> +err = device_create_file(>xbdev->dev, >> _attr_max_ring_page_order); >> +if (err) >> +

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

Stefano Stabellini writes: > On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote: >> David Vrabel writes: >> >> > On 26/07/16 13:30, Vitaly Kuznetsov wrote: >> >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >> >> particular, when

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

On 26/07/16 23:43, Andrew Cooper wrote: > On 26/07/2016 16:49, George Dunlap wrote: >> On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel >> wrote: >>> On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap >>> wrote: On Wed, Jul 20, 2016 at 7:01

Re: [Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

Hello, Thanks for the fixes. On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount of segments. > *

[Xen-devel] [distros-debian-squeeze test] 66838: tolerable trouble: blocked/broken

flight 66838 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66838/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 66621 build-armhf

  1   2   >