[Xen-devel] Completing a modprobe on xen-netback.ko

Hi, Sorry for the blank email previously. I am trying to modify netback.c in the Linux Kernel and Observe the changes. I've cloned the latest Linux Kernel with Git, checked out version 4.7.0 and compiled it with the config options listed here:

[Xen-devel] Completing a modprobe on xen-netback.ko

Hi, ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 100993: tolerable FAIL - PUSHED

flight 100993 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100993/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966 test-amd64-amd64-xl-rtds

Re: [Xen-devel] [for-4.8][PATCH v2 14/23] xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry

On Thu, 15 Sep 2016, Julien Grall wrote: > The function p2m_cache_flush can be re-implemented using the generic > function p2m_get_entry by iterating over the range and using the mapping > order given by the callee. > > As the current implementation, no preemption is implemented, although > the

Re: [Xen-devel] [for-4.8][PATCH v2 12/23] xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookup

On Thu, 15 Sep 2016, Julien Grall wrote: > Currently, for a given GFN, the function __p2m_lookup will only return > the associated MFN and the p2m type of the mapping. > > In some case we need the order of the mapping and the memaccess > permission. Rather than providing a separate function for

Re: [Xen-devel] [for-4.8][PATCH v2 11/23] xen/arm: p2m: Introduce p2m_get_root_pointer and use it in __p2m_lookup

On Thu, 15 Sep 2016, Julien Grall wrote: > Mapping the root table is always done the same way. To avoid duplicating > the code in a later patch, move the code in a separate helper. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini >

Re: [Xen-devel] [for-4.8][PATCH v2 09/23] xen/arm: p2m: Change the type of level_shifts from paddr_t to uint8_t

On Thu, 15 Sep 2016, Julien Grall wrote: > The level shift can be encoded with 8-bit. So it is not necessary to > use paddr_t (i.e 64-bit). > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > Changes in v2: > - Use

Re: [Xen-devel] [for-4.8][PATCH v2 07/23] xen/arm: traps: Check the P2M before injecting a data/instruction abort

On Thu, 15 Sep 2016, Julien Grall wrote: > A data/instruction abort may have occurred if another CPU was playing > with the stage-2 page table when following the break-before-make > sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly > the fault to the guest, we need to check

Re: [Xen-devel] [for-4.8][PATCH v2 06/23] xen/arm: traps: Move MMIO emulation code in a separate helper

On Thu, 15 Sep 2016, Julien Grall wrote: > Currently, a stage-2 fault translation will likely access an emulated > region. All the checks are pre-sanitity check for MMIO emulation. > > A follow-up patch will handle a new case that could lead to a stage-2 > translation. To improve the clarity of

Re: [Xen-devel] [for-4.8][PATCH v2 05/23] xen/arm: p2m: Add a back pointer to domain in p2m_domain

On Thu, 15 Sep 2016, Julien Grall wrote: > The back pointer will be usefult later to get the domain when we only > have the p2m in hand. > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > Changes in v2: > - Patch

[Xen-devel] [xen-unstable test] 100992: tolerable FAIL - PUSHED

flight 100992 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100992/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100982 test-armhf-armhf-xl-vhd

[Xen-devel] boot-wrapped xen image barfs with overlapped sections

Hi, all, I have been following the instructions at https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation to build xen for arm64. When I tried to use the latest kernel instead of v3.13 as suggested, I failed when building boot-wrapped image. See below.

[Xen-devel] [seabios baseline-only test] 67723: tolerable FAIL

This run is configured for baseline tests only. flight 67723 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67723/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop

[Xen-devel] stack size limit issues with xen + qemu + rbd

I have spent some time investigating a case where qemu is failing to register xenstore watches for a PV guest once I enable vfb (and thereby triggering the creation of a qemu instance). The qemu logs show something along the lines of: xen be core: xen be core: xen be: watching backend path

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote: > Currently ELF end of image address is calculated using first line from > "nm -nr xen/xen-syms" output. However, today usually it contains random > symbol address not related to end of image in any way. So, it looks Weird. The -n

[Xen-devel] [qemu-mainline test] 100989: trouble: broken/fail/pass

flight 100989 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100989/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 3 host-install(3)broken REGR. vs.

[Xen-devel] [xen-unstable baseline-only test] 67721: regressions - FAIL

This run is configured for baseline tests only. flight 67721 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67721/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 15

[Xen-devel] [PATCH v4] vm_event: Implement ARM SMC events

The ARM SMC instructions are already configured to trap to Xen by default. In this patch we allow a user-space process in a privileged domain to receive notification of when such event happens through the vm_event subsystem by introducing the PRIVILEGED_CALL type. The intended use-case for this

[Xen-devel] [xen-unstable-smoke test] 100991: tolerable all pass - PUSHED

flight 100991 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100991/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c >> index 39a05fd..cf58fd5 100644 >> --- a/xen/arch/arm/traps.c >> +++ b/xen/arch/arm/traps.c >> @@ -41,6 +41,7 @@ >> #include >> #include >> #include >> +#include >> >> #include "decode.h" >> #include "vtimer.h" >> @@ -2527,6

Re: [Xen-devel] [PATCH v4 08/16] livepatch: Move test-cases to their own sub-directory in test.

On Fri, Sep 16, 2016 at 12:38:20PM -0400, Konrad Rzeszutek Wilk wrote: > So they can be shared with ARM64 (but not yet, so they > are only built on x86). > > No functional change. > > We also need to tweak the MAINTAINERS and .gitignore file. > > Also we need to update SUBDIRS to include the

[Xen-devel] [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

Certain platforms, such as ARM [32|64] add extra mapping symbols such as $x (for ARM64 instructions), or more interesting to this patch: $t (for Thumb instructions). These symbols are suppose to help the final linker to make any adjustments (such as add an veneer). But more importantly - we do not

[Xen-devel] [PATCH v4 06/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

Those symbols are used to help final linkers to replace insn. The ARM ELF specification mandates that they are present to denote the start of certain CPU features. There are two variants of it - short and long format. Either way - we can ignore these symbols. Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH v4 12/16] bug/x86/arm: Align bug_frames sections.

Most of the WARN_ON or BUG_ON sections are properly aligned on x86. However on ARM and on x86 assembler the macros don't include any aligment information - hence they end up being the default byte granularity. On ARM32 it is paramount that the aligment is word-size (4) otherwise if one tries to

[Xen-devel] [PATCH v4 04/16] livepatch: Initial ARM64 support.

As compared to x86 the va of the hypervisor .text is locked down - we cannot modify the running pagetables to have the .ro flag unset. We borrow the same idea that alternative patching has - which is to vmap the entire .text region and use the alternative virtual address for patching. Since we

[Xen-devel] [PATCH v4 09/16] livepatch: tests: Make them compile under ARM64

We need to two things: 1) Wrap the platform-specific objcopy parameters in defines The input and output parameters for $(OBJCOPY) are different based on the platforms. As such provide them in the OBJCOPY_MAGIC define and use that. 2) The alternative is a bit different and there are no

[Xen-devel] [PATCH v4 15/16] livepatch: arm[32, 64], x86: NOP test-case

The test-case is quite simple - we NOP the 'xen_minor_version'. The amount of NOPs depends on the architecture. On x86 the function is 11 bytes long: 55 push %rbp <- NOP 48 89 e5mov%rsp,%rbp <- NOP b8 04 00 00 00 mov$0x4,%eax

[Xen-devel] [PATCH v4 16/16] livepatch: In xen_nop test-case remove the .bss and .data sections

As they are not needed for the livepatch to work. Also this allows us to properly test: "livepatch: Disallow applying after an revert" as the livepatch will now only have the minimalistic sections: Section Headers: [Nr] Name Type Address Offset Size

[Xen-devel] [PATCH v4 05/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

If the distance is too great we are in trouble - as our relocation distance can surely be clipped, or still have a valid width - but cause an overflow of distance. On various architectures the maximum displacement for a unconditional branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while

[Xen-devel] [PATCH v4 08/16] livepatch: Move test-cases to their own sub-directory in test.

So they can be shared with ARM64 (but not yet, so they are only built on x86). No functional change. We also need to tweak the MAINTAINERS and .gitignore file. Also we need to update SUBDIRS to include the new 'test' directory so 'cscope' can show the example livepatches. Acked-by: Jan Beulich

[Xen-devel] [PATCH v4 01/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]

x86 implements all of them by default - and we just add two extra HAS_ variables to be declared in autoconf.h. ARM 64 only has alternative while ARM 32 has none of them. And while at it change the livepatch common code that would benefit from this. Suggested-by: Julien Grall

[Xen-devel] [PATCH v4 14/16] livepatch, arm[32|64]: Share arch_livepatch_revert_jmp

It is exactly the same in both platforms. No functional change. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Julien Grall Cc: Stefano Stabellini v3: New submission. v4: s/arch_livepatch_insn_len/livepatch_insn_len/

[Xen-devel] [PATCH v4 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

To use as a common way of testing alternative patching for livepatches. Both architectures have this FEATURE and the test-cases can piggyback on that. Suggested-by: Julien Grall Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Julien Grall

[Xen-devel] [PATCH v4] Livepatch for ARM 64 and 32.

Hey! Since v3: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg01127.html] - Addressed Jan's comment (most are renaming) - Addressed Julien's and Jan's idea of HAS_ALTERNATIVE - Addressed Julien's review comments of "arm: poison initmem when it is freed." v2:

[Xen-devel] [PATCH v4 13/16] livepatch: Initial ARM32 support.

The patch piggybacks on: livepatch: Initial ARM64 support, which brings up all of the neccessary livepatch infrastructure pieces in. This patch adds three major pieces: 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which means the adddendum had to be extracted from within the

[Xen-devel] [PATCH v4 02/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

If the payload had the sections mentioned but the hypervisor did not support some of them (say on ARM the .ex_table) - instead of ignoring them - it should forbid loading of such payload. Reviewed-by: Julien Grall Signed-off-by: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v4 03/16] arm: poison initmem when it is freed.

The current byte sequence is '0xcc' which makes sense on x86, but on ARM it is: stclgt 12, cr12, [ip], {204} ; 0xcc Picking something more ARM applicable such as: efefefefsvc 0x00efefef Creates a nice crash if one executes that code: (XEN) CPU1: Unexpected Trap:

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 09/16/2016 11:22 AM, Lars Kurth wrote: > > On 16/09/2016 13:41, "Boris Ostrovsky" wrote: > >> On 09/16/2016 02:45 AM, Jan Beulich wrote: > And then there's the question of whether excluding things from the > build, but having them present in the sources

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote: > Hi Edgar, > > On 07/09/2016 08:56, Edgar E. Iglesias wrote: > >From: "Edgar E. Iglesias" > > > >Add support for describing normal non-cacheable memory. > > > >Signed-off-by: Edgar E. Iglesias

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

On 09/16/16 18:37, Tamas K Lengyel wrote: > Since this breaks compilation of existing clients, I think we should > increment some macro to alow for compile-time switching (maybe > VM_EVENT_INTERFACE_VERSION?). >>> >>> I'm not sure I follow - this is a Xen

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

On Fri, 2016-09-16 at 10:49 +0800, Wei Yang wrote: > On Wed, Sep 14, 2016 at 06:18:48PM +0200, Dario Faggioli wrote: > > On Wed, 2016-09-14 at 18:44 +0800, Wei Yang wrote: > > If the system is not overbooked, it's a bit strange that the > > scheduler > > is the bottleneck. > I looked at the

Re: [Xen-devel] [PATCH v3 5/6] xen/arm: domain_build: Plumb for different mapping attributes

On Fri, Sep 16, 2016 at 04:31:20PM +0200, Julien Grall wrote: > Hi Edgar, > > On 07/09/2016 08:56, Edgar E. Iglesias wrote: > >From: "Edgar E. Iglesias" > > > >Add plumbing for passing around mapping attributes. This > >is in preparation to allow us to differentiate

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

On Fri, Sep 16, 2016 at 12:50 AM, Thomas Gleixner wrote: > On Thu, 15 Sep 2016, Kyle Huey wrote: > > First of all, please add a cover letter [PATCH 0/N] to your patch series > and send it with something which provides proper mail threading. > See: git-send-email, quilt I did

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

On Fri, Sep 16, 2016 at 04:34:36PM +0200, Julien Grall wrote: > Hi Edgar, > > On 07/09/2016 08:56, Edgar E. Iglesias wrote: > >From: "Edgar E. Iglesias" > > > >Add support for describing normal non-cacheable memory. > > I am a bit confused, you introduced this new p2m

Re: [Xen-devel] [PATCH] x86/Intel: hide CPUID faulting capability from guests

On Thu, Sep 15, 2016 at 11:32 PM, Jan Beulich wrote: > We don't currently emulate it, so guests should not be misguided to > believe they can (try to) use it. > > For now, simply return zero to guests for platform MSR reads, and only > accept (by discarding) writes of zero. If

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

On Fri, Sep 16, 2016 at 7:54 AM, Julien Grall wrote: > Hi Tamas, > > On 15/09/2016 20:24, Tamas K Lengyel wrote: >> >> The ARM SMC instructions are already configured to trap to Xen by default. >> In >> this patch we allow a user-space process in a privileged domain to

Re: [Xen-devel] [PATCH v3 4/6] xen/device-tree: Make dt_match_node match props

On Fri, Sep 16, 2016 at 04:28:20PM +0200, Julien Grall wrote: > Hi Edgar, > > On 07/09/2016 08:56, Edgar E. Iglesias wrote: > >From: "Edgar E. Iglesias" > > > >Make dt_match_node match for existing properties. > >We only search for the existence of the properties, not

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

On Fri, Sep 16, 2016 at 1:21 AM, Razvan Cojocaru wrote: > On 09/15/16 20:08, Razvan Cojocaru wrote: >> On 09/15/16 19:36, Tamas K Lengyel wrote: >>> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru >>> wrote: On 09/13/2016 09:12 PM,

[Xen-devel] [seabios test] 100987: tolerable FAIL - PUSHED

flight 100987 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/100987/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100898

Re: [Xen-devel] [PATCH v3 2/6] xen/arm: Rename and generalize un/map_regions_rw_cache

On Fri, Sep 16, 2016 at 04:24:17PM +0200, Julien Grall wrote: > Hi Edgar, > > On 07/09/2016 08:56, Edgar E. Iglesias wrote: > >From: "Edgar E. Iglesias" > > > >Rename and generalize un/map_regions_rw_cache into > >un/map_regions_p2mt. The new functions take the mapping

[Xen-devel] [PATCH v6 2/6] livepatch: Add limit of 2MB to payload .bss sections.

The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793 "xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the size of the binary at 2MB. We follow that in capping the size of the .BSSes to be at maximum 2MB. Reviewed-by: Ross Lagerwall Signed-off-by:

[Xen-devel] [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.

The NOP functionality will NOP any of the code at the 'old_addr' or at 'name' if the 'new_addr' is zero. The purpose of this is to NOP out calls, such as: e8 <4-bytes-offset> (5 byte insn), or on ARM a 4 byte insn for branching. We need the EIP of where we need to the NOP, and that can be

[Xen-devel] [PATCH v6 4/6] livepach: Add .livepatch.hooks functions and test-case

From: Ross Lagerwall Add hook functions which run during patch apply and patch revert. Hook functions are used by livepatch payloads to manipulate data structures during patching, etc. One use case is the XSA91. As Martin mentions it: "If we have shadow variables, we

[Xen-devel] [PATCH v6] Livepatch fixes and general features for Xen4.8.

Hey! Since v5:[https://lists.xen.org/archives/html/xen-devel/2016-09/msg01114.html] - Acted on the review comments. - Replaced "livepatch/docs: Document .bss not being cleared, and .data potentially having changed values" with "livepatch: Disallow applying after an revert" - Added two

[Xen-devel] [PATCH v6 6/6] livepatch/tests: Move the .name value to .rodata

Right now the contents of 'name' are all located in the .data section. We want them in the .rodata section so change the type to have const on them. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Andrew Cooper Cc: Jan Beulich

[Xen-devel] [PATCH v6 5/6] livepatch/tests: Make .livepatch.depends be read-only

As currently during the injection of the build-id it ends up being marked as AW. We want it to be read-only. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Andrew Cooper Cc: Jan Beulich v6: New submission. ---

[Xen-devel] [PATCH v6 1/6] livepatch: Disallow applying after an revert

On general this is unhealthy - as the payload's .bss (definitly) or .data (maybe) will be modified once the payload is running. Doing an revert and then re-applying the payload with a non-pristine .bss or .data can lead to unforseen consequences (.bss are assumed to always contain zero value but

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 16/09/2016 13:41, "Boris Ostrovsky" wrote: >On 09/16/2016 02:45 AM, Jan Beulich wrote: >> And then there's the question of whether excluding things from the build, but having them present in the sources actually helps. >>> The main reason for this whole

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote: > Hi Edgar, Hi Julien, Thanks for the review! > On 07/09/2016 08:56, Edgar E. Iglesias wrote: > >From: "Edgar E. Iglesias" > > > >Add support for describing normal non-cacheable memory. > > >

Re: [Xen-devel] [PATCH RFC 5/6] xen/arm: Add function to query IRQ 'ownership'.

On Mon, Sep 05, 2016 at 06:14:00AM -0400, Kyle Temkin wrote: > From: "Kyle J. Temkin" > > The addition of new IRQ-related platform hooks now allow platforms to > perform platform-specific interrupt logic; allowing e.g. virtualization > of platform-specific interrupt

Re: [Xen-devel] [PATCH RFC 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing.

On Mon, Sep 05, 2016 at 06:13:59AM -0400, Kyle Temkin wrote: > From: "Kyle J. Temkin" > > Tegra devices have a legacy interrupt controller (lic, or ictlr) that > must be programmed in parallel with their primary GIC. For all intents > and purposes, we treat this devices

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

On 16/09/2016 16:35, Konrad Rzeszutek Wilk wrote: On Fri, Sep 16, 2016 at 03:45:12PM +0200, Julien Grall wrote: On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote: On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote: Hi Konrad, On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

On Fri, Sep 16, 2016 at 03:45:12PM +0200, Julien Grall wrote: > > > On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote: > > > Hi Konrad, > > > > > > On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: > > > > v2:

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

Hi Edgar, On 07/09/2016 08:56, Edgar E. Iglesias wrote: From: "Edgar E. Iglesias" Add support for describing normal non-cacheable memory. I am a bit confused, you introduced this new p2m type but I don't see any usage of it in this series. Is it expected?

Re: [Xen-devel] [PATCH v3 5/6] xen/arm: domain_build: Plumb for different mapping attributes

Hi Edgar, On 07/09/2016 08:56, Edgar E. Iglesias wrote: From: "Edgar E. Iglesias" Add plumbing for passing around mapping attributes. This is in preparation to allow us to differentiate the attributes for specific device nodes. We still use the same DEVICE mappings

Re: [Xen-devel] [PATCH v3 4/6] xen/device-tree: Make dt_match_node match props

Hi Edgar, On 07/09/2016 08:56, Edgar E. Iglesias wrote: From: "Edgar E. Iglesias" Make dt_match_node match for existing properties. We only search for the existence of the properties, not for specific values. Signed-off-by: Edgar E. Iglesias

Re: [Xen-devel] [PATCH v3 2/6] xen/arm: Rename and generalize un/map_regions_rw_cache

Hi Edgar, On 07/09/2016 08:56, Edgar E. Iglesias wrote: From: "Edgar E. Iglesias" Rename and generalize un/map_regions_rw_cache into un/map_regions_p2mt. The new functions take the mapping attributes as an argument. No functional change. Signed-off-by: Edgar E.

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

Hi Edgar, On 07/09/2016 08:56, Edgar E. Iglesias wrote: From: "Edgar E. Iglesias" Add support for describing normal non-cacheable memory. Signed-off-by: Edgar E. Iglesias --- xen/arch/arm/p2m.c | 18 ++

[Xen-devel] [qemu-mainline test] 100984: regressions - FAIL

flight 100984 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100984/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 100966

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

Hi Tamas, On 15/09/2016 20:24, Tamas K Lengyel wrote: The ARM SMC instructions are already configured to trap to Xen by default. In this patch we allow a user-space process in a privileged domain to receive notification of when such event happens through the vm_event subsystem by introducing

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote: On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote: Hi Konrad, On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last] - Addressed the two outstanding concerns: CPU

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote: > Hi Konrad, > > On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: > > v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last] > > - Addressed the two outstanding concerns: CPU bit feature to test > > alternative > >

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

Hi Konrad, On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last] - Addressed the two outstanding concerns: CPU bit feature to test alternative test-case, and errata #843419 on some Cortex-A53 I am a bit confused. I haven't

Re: [Xen-devel] [PATCH v3 05/18] arm: poison initmem when it is freed.

Hi Konrad, On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: The current byte sequence is '0xcc' which makes sense on x86, but on ARM it is: stclgt 12, cr12, [ip], {204} ; 0xcc Picking something more ARM applicable such as: efefefefsvc 0x00efefef Whilst I

[Xen-devel] [distros-debian-jessie test] 67722: tolerable FAIL

flight 67722 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67722/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-startfail like 67680 Tests which did

Re: [Xen-devel] [PATCH v3 03/18] arm/x86: change [modify, destroy]_xen_mappings to return error

Hi Konrad, On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: The implementation on x86 always returns zero, but other platforms may return error values. Reviewed-by: Andrew Cooper Suggested-by: Julien Grall Signed-off-by: Konrad Rzeszutek Wilk

[Xen-devel] First set of Xen Project Developer Summit Videos are available

Hi all, the first batch of Xen Project Developer Summit Videos are available. There are a few videos missing, which have some issues that still need to be fixed, but that shouldn't take too long. You can see what is uploaded and available t

Re: [Xen-devel] [PATCH v3 02/18] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

Hi Konrad, On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote: If the payload had the sections mentioned but the hypervisor did not support some of them (say on ARM the .ex_table) - instead of ignoring them - it should forbid loading of such payload. Signed-off-by: Konrad Rzeszutek Wilk

[Xen-devel] [xen-unstable test] 100982: tolerable FAIL

flight 100982 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100982/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail in 100973 pass in 100982 test-armhf-armhf-xl-vhd 9

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 09/16/2016 02:45 AM, Jan Beulich wrote: > >>> And then there's the question of whether excluding things from the >>> build, but having them present in the sources actually helps. >> The main reason for this whole relicensing debacle is to prevent non-GPL >> binaries from linking against GPL

Re: [Xen-devel] [PATCH V3] xen/arm: arm64: Update the Image header

Hello Peng, On 12/09/2016 11:43, Peng Fan wrote: According to Linux Kernel, Documentation/arm64/booting.txt " When image_size is zero, a bootloader should attempt to keep as much memory as possible free for use by the kernel immediately after the end of the kernel image. The amount of space

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

>>> On 14.09.16 at 10:23, wrote: > Starting from the beginning it looks that there are "soft" limits enforced > in BIOS early boot code looking for usable low memory region. Hight limit > is set at 640 KiB and low at 256 KiB. This means that if a value from a given >

Re: [Xen-devel] [PATCH v4 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

> What is the scenario that you would want toolstack to set such flag? > > Shouldn't hypervisor always set the flag when the guest is never > unpaused and always clear / ignore that flag if the guest is ever > unpaused? If that's all is needed, why does toolstack need to get > involved? You are

Re: [Xen-devel] [PATCH v2] xen-netback: fix error handling on netback_probe()

On Thu, Sep 15, 2016 at 05:10:46PM +0200, Filipe Manco wrote: > In case of error during netback_probe() (e.g. an entry missing on the > xenstore) netback_remove() is called on the new device, which will set > the device backend state to XenbusStateClosed by calling > set_backend_state(). However,

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

On Fri, Sep 16, 2016 at 10:51:18AM +0200, Juergen Groß wrote: > On 09/15/2016 05:38 PM, Wei Liu wrote: > >On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote: > >>Add HVM usb passthrough support to libxl by using qemu's capability > >>to emulate standard USB controllers. > >> > >>A USB

[Xen-devel] [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

Small packet loss is reported on complex multi host network configurations including tunnels, NAT, ... My investigation led me to the following check in netback which drops packets: if (unlikely(txreq.size < ETH_HLEN)) { netdev_err(queue->vif->dev,

Re: [Xen-devel] [PATCH v4 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

On Fri, Sep 16, 2016 at 03:47:23AM -0700, Dongli Zhang wrote: > > > +/* > > > + * MEMF_no_tlbflush can be set only during vm creation phase when > > > + * is_ever_unpaused is still false before this domain gets unpaused > > > for > > > + * the first time. > > > + */ > > > +

Re: [Xen-devel] [PATCH v4 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

> > +/* > > + * MEMF_no_tlbflush can be set only during vm creation phase when > > + * is_ever_unpaused is still false before this domain gets unpaused for > > + * the first time. > > + */ > > +if ( unlikely(!d->is_ever_unpaused) ) > > +a->memflags |=

Re: [Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, 15 Sep 2016, Kyle Huey wrote: Please use proper prefixes for your patch: git-log arch/x86/kernel/cpu/scattered.c will give you the hint: x86/cpufeature: Move some of the scattered feature bits to x86_capability x86/cpufeature: Correct spelling of the HWP_NOTIFY flag and make the

Re: [Xen-devel] [PATCH] x86/Intel: hide CPUID faulting capability from guests

>>> On 16.09.16 at 11:46, wrote: > On 16/09/16 07:32, Jan Beulich wrote: >> We don't currently emulate it, so guests should not be misguided to >> believe they can (try to) use it. >> >> For now, simply return zero to guests for platform MSR reads, and only >> accept

Re: [Xen-devel] [PATCH] x86/Intel: hide CPUID faulting capability from guests

On 16/09/16 07:32, Jan Beulich wrote: We don't currently emulate it, so guests should not be misguided to believe they can (try to) use it. For now, simply return zero to guests for platform MSR reads, and only accept (by discarding) writes of zero. If ever there will be bits we can safely

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

On 09/15/2016 05:38 PM, Wei Liu wrote: On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote: Add HVM usb passthrough support to libxl by using qemu's capability to emulate standard USB controllers. A USB controller is added via qmp command to the emulated hardware when a usbctrl

[Xen-devel] [libvirt test] 100980: regressions - FAIL

flight 100980 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/100980/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100962 Tests which did not

[Xen-devel] [qemu-mainline test] 100975: regressions - FAIL

flight 100975 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100975/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100966 Regressions

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

On Thu, 15 Sep 2016, Kyle Huey wrote: First of all, please add a cover letter [PATCH 0/N] to your patch series and send it with something which provides proper mail threading. See: git-send-email, quilt > arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for > now. Rename

Re: [Xen-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

On Wed, Sep 14, Stefano Stabellini wrote: > The doc says: > > "If VMDP was configured to control just NIC devices it would write the > value 0x1 to offset 0x8. If VMDP was configured to control just storage > devices it would write the value 0x2 to offset 0x8." > > So 0x1 to 0x8 to unplug NICs,

Re: [Xen-devel] [PATCH v2 1/2] xen_platform: unplug also SCSI disks

On Wed, Sep 14, Stefano Stabellini wrote: > Written like this, the code will unplug any Xen SCSI disks together with > Xen IDE disks when the guest writes "1" to ioport `0x10`. I am sorry to > be pedantic, but the recent changes introduced to > docs/misc/hvm-emulated-unplug.markdown do not cover

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

On 09/15/16 21:24, Tamas K Lengyel wrote: > The ARM SMC instructions are already configured to trap to Xen by default. In > this patch we allow a user-space process in a privileged domain to receive > notification of when such event happens through the vm_event subsystem by > introducing the

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

On 09/15/16 20:08, Razvan Cojocaru wrote: > On 09/15/16 19:36, Tamas K Lengyel wrote: >> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru >> wrote: >>> On 09/13/2016 09:12 PM, Tamas K Lengyel wrote: When emulating instructions the emulator maintains a small i-cache

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

>>> On 15.09.16 at 18:40, wrote: > On 09/15/2016 12:05 PM, Jan Beulich wrote > >>> Maybe even without changes to mk_dsdt.c >> But isn't that the critical part? > > Not necessarily since we'd use --gpl option only for > dsdt_anycpu_qemu_xen, dsdt_anycpu and

  1   2   >