[Xen-devel] [linux-linus test] 113730: regressions - FAIL

flight 113730 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 113666

[Xen-devel] [ovmf test] 113739: all pass - PUSHED

flight 113739 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/113739/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ba30d5f0512196b1ee7b3d864f980e551da0ebf5 baseline version: ovmf

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

flight 113733 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/113733/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113492 Tests which did not succeed,

[Xen-devel] [xen-unstable test] 113724: regressions - FAIL

flight 113724 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113724/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 113387 Regressions

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 2:21 PM, Thomas Garnier wrote: > On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel > wrote: >> >> On 21 September 2017 at 08:59, Ingo Molnar wrote: >> > >> > ( Sorry about the delay in answering this. I

[Xen-devel] [ovmf bisection] complete build-i386

branch xen-unstable xenbranch xen-unstable job build-i386 testid xen-build Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced

Re: [Xen-devel] Booting signed xen.efi through shim

On Fri, Sep 22, 2017 at 02:25:46AM -0600, Jan Beulich wrote: > >>> On 22.09.17 at 00:46, wrote: > > One piece that I see still missing is the Xen command line parameters > > not being verified. It would be ideal to have the option to get that > > set during compile time as

Re: [Xen-devel] [PATCH v4 12/13] xen/pvcalls: implement release command

>> + */ >> +map->active.ring->in_error = -EBADF; >> +wake_up_interruptible(>active.inflight_conn_req); >> + >> +/* >> + * Wait until there are no more waiters on the mutexes. >> + * We know that no new waiters can be added

Re: [Xen-devel] [PATCH 01/27 v10] xen/arm: vpl011: Define common ring buffer helper functions in console.h

Adding Jan On Fri, 22 Sep 2017, Bhupinder Thakur wrote: > DEFINE_XEN_FLEX_RING(xencons) defines common helper functions such as > xencons_queued() to tell the current size of the ring buffer, > xencons_mask() to mask off the index, which are useful helper functions. > pl011 emulation code will

Re: [Xen-devel] [PATCH v4 12/13] xen/pvcalls: implement release command

> > +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata, > +struct sock_mapping *map) I just noticed: pvcalls_front_free_map() is referenced by patches 2 and 8. > +{ > + int i; > + > + unbind_from_irqhandler(map->active.irq, map); > + > +

Re: [Xen-devel] [PATCH v4 11/13] xen/pvcalls: implement poll command

> > +static unsigned int pvcalls_front_poll_passive(struct file *file, > +struct pvcalls_bedata *bedata, > +struct sock_mapping *map, > +poll_table *wait) > +{ > +

Re: [Xen-devel] [PATCH v4 10/13] xen/pvcalls: implement recvmsg

> > +static bool pvcalls_front_read_todo(struct sock_mapping *map) > +{ > + struct pvcalls_data_intf *intf = map->active.ring; > + RING_IDX cons, prod; > + int32_t error; > + > + cons = intf->in_cons; > + prod = intf->in_prod; > + error = intf->in_error; > + return

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

flight 113717 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/113717/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 113666

Re: [Xen-devel] [PATCH v4 09/13] xen/pvcalls: implement sendmsg

> +static bool pvcalls_front_write_todo(struct sock_mapping *map) > +{ > + struct pvcalls_data_intf *intf = map->active.ring; > + RING_IDX cons, prod, size = XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER); > + int32_t error; > + > + cons = intf->out_cons; > + prod = intf->out_prod; >

Re: [Xen-devel] [PATCH 06/27 v10] xen/arm: vpl011: Add a new domctl API to initialize vpl011

On Fri, 22 Sep 2017, Bhupinder Thakur wrote: > Add a new domctl API to initialize vpl011. It takes the GFN and console > backend domid as input and returns an event channel to be used for > sending and receiving events from Xen. > > Xen will communicate with xenconsole using GFN as the ring

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 09/22/17 11:57, Kees Cook wrote: > On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote: >> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64 >> has RIP-relative addressing there is no need for a dedicated PIC register. > > FWIW, since gcc 5, the PIC

Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy

On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote: > On 22/09/17 04:09, Christopher Clark wrote: > > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom > > wrote: > >> > >> On Thu, September 21, 2017, 10:39:52 AM, Roger Pau Monné wrote: > >> > >>> On Wed,

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

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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 09/22/17 09:32, Ingo Molnar wrote: > > BTW., I think things improved with ORC because with ORC we have RBP as an > extra > register and with PIE we lose RBX - so register pressure in code generation > is > lower. > We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64

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

flight 113711 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/113711/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113659 Tests

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote: > On 09/22/17 09:32, Ingo Molnar wrote: >> >> BTW., I think things improved with ORC because with ORC we have RBP as an >> extra >> register and with PIE we lose RBX - so register pressure in code generation >> is >> lower.

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote: > We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64 > has RIP-relative addressing there is no need for a dedicated PIC register. FWIW, since gcc 5, the PIC register isn't totally lost. It is now

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 08/21/17 07:28, Peter Zijlstra wrote: > > Ah, I see, this is large mode and that needs to use MOVABS to load 64bit > immediates. Still, small RIP relative should be able to live at any > point as long as everything lives inside the same 2G relative range, so > would still allow the goal of

[Xen-devel] [qemu-upstream-unstable baseline-only test] 72142: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 72142 qemu-upstream-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72142/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1)

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Sep 22, 2017 at 9:32 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote: >> > >> > ( Sorry about the delay in answering this. I could blame the delay on the >> > merge >> >

Re: [Xen-devel] [PATCH v3 1/3] python: Add binding for xs_fileno()

On Fri, Sep 22, 2017 at 05:21:12PM +0100, Euan Harris wrote: > xs_fileno() returns a file descriptor which receives events when Xenstore > watches fire. Exposing this in the Python bindings is a prerequisite > for writing event-driven clients in Python. > > Signed-off-by: Euan Harris

Re: [Xen-devel] [PATCH v9 09/10] xen: make grant resource limits per domain

On 22/09/17 17:15, Jan Beulich wrote: On 22.09.17 at 13:41, wrote: >> Instead of using the same global resource limits of grant tables (max. >> number of grant frames, max. number of maptrack frames) for all domains >> make these limits per domain. Set those per-domain

Re: [Xen-devel] [PATCH] VMX: PLATFORM_INFO MSR is r/o

On 22/09/17 10:07, Jan Beulich wrote: Therefore all write attempts should produce #GP, just like on real hardware. Signed-off-by: Jan Beulich Sergey has already posted a patch series to fix this. What is the benefit of this version?  As far as I can tell, it isn't as

[Xen-devel] [PATCH] Config.mk: update OVMF changeset

Signed-off-by: Anthony PERARD --- Config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Config.mk b/Config.mk index bba81bee7d..57d3e2bc44 100644 --- a/Config.mk +++ b/Config.mk @@ -272,7 +272,7 @@ QEMU_TRADITIONAL_URL ?=

[Xen-devel] [ovmf test] 113719: regressions - FAIL

flight 113719 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/113719/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 113647 build-i386-xsm

Re: [Xen-devel] [PATCH] VMX: PLATFORM_INFO MSR is r/o

On Fri, Sep 22, 2017 at 03:07:44AM -0600, Jan Beulich wrote: > Therefore all write attempts should produce #GP, just like on real > hardware. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -3138,10 +3138,7 @@ static

Re: [Xen-devel] [PATCH v6 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space

On Thu, Sep 21, 2017 at 02:36:25PM +0100, Wei Liu wrote: > On Tue, Sep 19, 2017 at 04:29:27PM +0100, Roger Pau Monne wrote: > > This functionality is going to reside in vpci.c (and the corresponding > > vpci.h header), and should be arch-agnostic. The handlers introduced > > in this patch setup

Re: [Xen-devel] Xen Porting Inquiry

On Fri, Sep 22, 2017 at 09:31:26AM -0700, t...@hughes.net wrote: > Hello, > > Who can I contact at Xen to obtain an estimate of the effort required to port > Xen to IBM's OpenPOWER 9 CPU? I would recommend you speak to IBM as they would be most qualified to answer that question.

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

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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote: > > > > ( Sorry about the delay in answering this. I could blame the delay on the > > merge > > window, but in reality I've been procrastinating this is due to the > >

[Xen-devel] [linux-4.9 test] 113706: trouble: broken/fail/pass

flight 113706 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/113706/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale broken Tests which are

[Xen-devel] Xen Porting Inquiry

Hello, Who can I contact at Xen to obtain an estimate of the effort required to port Xen to IBM's OpenPOWER 9 CPU? Kind regards, TCB ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 10/10] xen: add new Xen cpuid node for max address width info

On 22/09/17 16:47, Jan Beulich wrote: On 22.09.17 at 13:41, wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -929,6 +929,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, >> uint32_t leaf, >> res->b = v->vcpu_id; >> break; >>

[Xen-devel] [PATCH v2 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

Right now there is only a pvclock_pvti_cpu0_va() which is defined on kvmclock since: commit dac16fba6fc5 ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") The only user of this interface so far is kvm. This commit adds a setter function for the pvti page and moves

[Xen-devel] [PATCH v2 2/3] x86/xen/time: setup vcpu 0 time info page

In order to support pvclock vdso on xen we need to setup the time info page for vcpu 0 and register the page with Xen using the VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall will also forcefully update the pvti which will set some of the necessary flags for vdso. Afterwards we

[Xen-devel] [PATCH v2 0/3] x86/xen: pvclock vdso support

Hey, Sorry for the huge delay in following up this series. This take 2 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting Xen 4.8 which is required for vdso time related calls. In order to have it on, you need to have the hypervisor clocksource be TSC e.g. with the following boot

[Xen-devel] [PATCH v2 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

This file defines an ABI shared between guest and hypervisor(s) (KVM, Xen) and as such there should be an correspondent entry in MAINTAINERS file. Notice that there's already a text notice at the top of the header file, hence this commit simply enforces it more explicitly and have both peers

[Xen-devel] [PATCH v3 2/3] python: Extract registered watch search logic from xspy_read_watch()

When a watch fires, xspy_read_watch() checks whether the client has registered interest in the path which changed and, if so, returns the path and a client-supplied token. The binding for xs_check_watch() needs to do the same, so this patch extracts the search code into a separate function.

[Xen-devel] [PATCH v3 1/3] python: Add binding for xs_fileno()

xs_fileno() returns a file descriptor which receives events when Xenstore watches fire. Exposing this in the Python bindings is a prerequisite for writing event-driven clients in Python. Signed-off-by: Euan Harris Reviewed-by: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v3 3/3] python: Add binding for non-blocking xs_check_watch()

xs_check_watch() checks for watch notifications without blocking. Together with the binding for xs_fileno(), this makes it possible to write event-driven clients in Python. Signed-off-by: Euan Harris Reviewed-by: Wei Liu Acked-by: Marek

[Xen-devel] [PATCH v3 0/3] python: Add non-blocking Xenstore watch bindings

Expose xs_fileno() and xs_check_watch() to Python. These functions make it posible to write event-driven Xenstore clients in Python: #!/usr/bin/env python import xen.lowlevel.xs import sys import errno from select import select import time # Connect to XenStore and set

Re: [Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

On 22/09/17 16:47, George Dunlap wrote: On Fri, Aug 25, 2017 at 6:37 PM, Andrew Cooper wrote: On 25/08/17 17:43, George Dunlap wrote: You don't need __AFL_INIT if you have __AFL_LOOP. Signed-off-by: George Dunlap Really? Is that covered

Re: [Xen-devel] [PATCH v2 02/21] libxl: introduce a way to mark fields as deprecated in the idl

Roger Pau Monné writes ("Re: [PATCH v2 02/21] libxl: introduce a way to mark fields as deprecated in the idl"): > Thanks for the review. I've fixed all the other comments on the series > and started an osstest flight, my aim is to post a new version of the > series using the same deprecation idl

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

On 22/09/17 17:07, Wei Liu wrote: On Fri, Sep 22, 2017 at 10:00:20AM -0600, Jan Beulich wrote: On 22.09.17 at 17:56, wrote: On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote: On 14.09.17 at 14:58, wrote: They will be used by PV mm code

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

On Fri, Sep 22, 2017 at 10:00:20AM -0600, Jan Beulich wrote: > >>> On 22.09.17 at 17:56, wrote: > > On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote: > >> >>> On 14.09.17 at 14:58, wrote: > >> > They will be used by PV mm code and mm hypercall

Re: [Xen-devel] [PATCH v2 02/21] libxl: introduce a way to mark fields as deprecated in the idl

On Wed, Sep 20, 2017 at 04:46:16PM +0100, Ian Jackson wrote: > Roger Pau Monne writes ("[PATCH v2 02/21] libxl: introduce a way to mark > fields as deprecated in the idl"): > > The deprecation involves generating a function that copies the > > deprecated fields into it's new location if the new

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

>>> On 22.09.17 at 17:56, wrote: > On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote: >> >>> On 14.09.17 at 14:58, wrote: >> > They will be used by PV mm code and mm hypercall code, which is going >> > to be split into two files. >> >> Hmm,

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

On Fri, Sep 22, 2017 at 09:44:53AM -0600, Jan Beulich wrote: > >>> On 14.09.17 at 14:58, wrote: > > They will be used by PV mm code and mm hypercall code, which is going > > to be split into two files. > > Hmm, no, I think I'd prefer mod_lN_entry() and >

Re: [Xen-devel] [PATCH v5 17/23] x86/mm: export base_disallow_mask and l1 mask in asm-x86/mm.h

On Fri, Sep 22, 2017 at 07:52:13AM -0600, Jan Beulich wrote: > >>> On 14.09.17 at 14:58, wrote: > > The l1 mask needs to stay in x86/mm.c while l{2,3,4} masks are only > > needed by PV code. Both x86 common mm code and PV mm code use > > base_disallow_mask and l1 maks. > > >

Re: [Xen-devel] [PATCH v5 20/23] x86/mm: split out PV mm code to pv/mm.c

>>> On 14.09.17 at 14:58, wrote: > A load of functions are moved: > > 1. {get,put}_page_from_l{2,3,4}e As just indicated in reply to another patch, I'd really hope for these to stay together with mod_lN_entry(). Jan ___

Re: [Xen-devel] [PATCH v5 19/23] x86/mm: export get_page_light via asm-x86/mm.h

>>> On 14.09.17 at 14:58, wrote: > It is going to be needed by common x86 mm code and pv mm code. The sole callers are alloc_page_type() and __put_final_page_type(), and their respective code paths should be PV only. I'd also prefer if the compiler remained to be able to

Re: [Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

On Fri, Aug 25, 2017 at 6:37 PM, Andrew Cooper wrote: > On 25/08/17 17:43, George Dunlap wrote: >> You don't need __AFL_INIT if you have __AFL_LOOP. >> >> Signed-off-by: George Dunlap > > Really? Is that covered in any documentation? > > I

Re: [Xen-devel] [PATCH v5 18/23] x86/mm: export some stuff via local mm.h

>>> On 14.09.17 at 14:58, wrote: > They will be used by PV mm code and mm hypercall code, which is going > to be split into two files. Hmm, no, I think I'd prefer mod_lN_entry() and {get,put}_page_from_lNe() to stay in the same file (with the possible exception of

Re: [Xen-devel] [PATCH v9 07/10] xen: delay allocation of grant table sub structures

On 22/09/17 16:43, Jan Beulich wrote: On 22.09.17 at 13:41, wrote: >> Delay the allocation of the grant table sub structures in order to >> allow modifying parameters needed for sizing of these structures at a >> per domain basis. Allocate the structures and the table frames

Re: [Xen-devel] [PATCH v9 09/10] xen: make grant resource limits per domain

>>> On 22.09.17 at 13:41, wrote: > Instead of using the same global resource limits of grant tables (max. > number of grant frames, max. number of maptrack frames) for all domains > make these limits per domain. Set those per-domain limits in > grant_table_set_limits(). The

[Xen-devel] [libvirt test] 113708: tolerable all pass - PUSHED

flight 113708 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/113708/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113652 test-armhf-armhf-libvirt 14

Re: [Xen-devel] Booting signed xen.efi through shim

On Fri, Sep 22, 2017 at 2:25 AM, Jan Beulich wrote: On 22.09.17 at 00:46, wrote: >> One piece that I see still missing is the Xen command line parameters >> not being verified. It would be ideal to have the option to get that >> set during compile

[Xen-devel] [GIT PULL] xen: Fixes for rc2

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.14b-rc2-tag xen: Fixes for rc2 It contains a fix for a missing __init annotation and two cleanup patches. Thanks. Juergen arch/x86/xen/mmu_pv.c | 2 +-

Re: [Xen-devel] [PATCH v9 10/10] xen: add new Xen cpuid node for max address width info

>>> On 22.09.17 at 13:41, wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -929,6 +929,13 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, > uint32_t leaf, > res->b = v->vcpu_id; > break; > > +case 5: /* PV-specific parameters */

Re: [Xen-devel] [PATCH v9 07/10] xen: delay allocation of grant table sub structures

>>> On 22.09.17 at 13:41, wrote: > Delay the allocation of the grant table sub structures in order to > allow modifying parameters needed for sizing of these structures at a > per domain basis. Allocate the structures and the table frames only > from grant_table_set_limits()

Re: [Xen-devel] [PATCH v9 01/10] xen: add function for obtaining highest possible memory address

>>> On 22.09.17 at 13:41, wrote: > @@ -104,6 +104,8 @@ struct xen_sysctl_physinfo { > > /* XEN_SYSCTL_PHYSCAP_??? */ > uint32_t capabilities; > + > +uint64_t max_mfn; /* Largest possible MFN on this host */ > }; I'm sorry for not having noticed this earlier

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 9:24 PM, Markus Trippelsdorf wrote: > On 2017.09.21 at 14:21 -0700, Thomas Garnier wrote: >> On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel >> wrote: >> > >> > On 21 September 2017 at 08:59, Ingo Molnar

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

On Fri, Sep 22, 2017 at 08:24:20AM -0600, Jan Beulich wrote: > >>> On 22.09.17 at 16:07, wrote: > > On Fri, Sep 22, 2017 at 07:40:04AM -0600, Jan Beulich wrote: > >> Additionally could you add (half) a sentence regarding the > >> PGT_l*_page_table uses outside of PV specific

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

>>> On 22.09.17 at 16:07, wrote: > On Fri, Sep 22, 2017 at 07:40:04AM -0600, Jan Beulich wrote: >> Additionally could you add (half) a sentence regarding the >> PGT_l*_page_table uses outside of PV specific code, which I'm >> sure you have verified can't make it into the

[Xen-devel] [linux-linus test] 113703: regressions - FAIL

flight 113703 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113703/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 6 xen-install fail REGR. vs. 113666 Regressions which

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

On Fri, Sep 22, 2017 at 5:17 PM, Wei Liu wrote: > On Fri, Sep 22, 2017 at 05:00:44PM +0300, Oleksandr Grytsov wrote: >> On Fri, Sep 22, 2017 at 4:02 PM, Wei Liu wrote: >> > On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote: >> >> From:

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

On Fri, Sep 22, 2017 at 05:00:44PM +0300, Oleksandr Grytsov wrote: > On Fri, Sep 22, 2017 at 4:02 PM, Wei Liu wrote: > > On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote: > >> From: Oleksandr Grytsov > >> > >> As we have generic

Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

Hi Manish, On 11/09/17 22:33, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > The set is divided into two patches. First one calculates the size of IORT > while second one writes the IORT table itself. It would be good if you could give a quick introduction *why*

Re: [Xen-devel] [PATCH] custom parameter handling fixes

On 14/09/17 09:57, Jan Beulich wrote: The recent changes to their handling introduced a few false warnings, due to checks looking at the wrong string slot. While going through all those commits and looking for patterns similar to the "dom0_mem=" I've noticed this with, I also realized that there

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

On Fri, Sep 22, 2017 at 07:40:04AM -0600, Jan Beulich wrote: > >>> On 14.09.17 at 14:58, wrote: > > And move the declarations to pv/mm.h. The code will be moved later. > > > > The stubs contain BUG() because they aren't supposed to be called when > > PV is disabled. > > I'd

Re: [Xen-devel] [PATCH v4 04/11] livepatch/arm[32, 64]: Don't load and crash on livepatches loaded with wrong text alignment.

>>> On 21.09.17 at 00:31, wrote: > @@ -272,6 +271,16 @@ int arch_livepatch_perform(struct livepatch_elf *elf, > elf->name, symndx); > return -EINVAL; > } > +else if ( (type != R_ARM_ABS32 && type != R_ARM_REL32) /* Only check

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

On Fri, Sep 22, 2017 at 4:02 PM, Wei Liu wrote: > On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote: >> From: Oleksandr Grytsov >> >> As we have generic functions to get device list >> (libxl__device_list) no need to have callback

Re: [Xen-devel] [PATCH v5 17/23] x86/mm: export base_disallow_mask and l1 mask in asm-x86/mm.h

>>> On 14.09.17 at 14:58, wrote: > The l1 mask needs to stay in x86/mm.c while l{2,3,4} masks are only > needed by PV code. Both x86 common mm code and PV mm code use > base_disallow_mask and l1 maks. > > Export base_disallow_mask and l1 mask in asm-x86/mm.h. So that's

Re: [Xen-devel] ARM64:Porting xen to new hardware

On Fri, Sep 22, 2017 at 03:30:57PM +0530, bharat gohil wrote: > Hello Wilk, > > I had try 'console=hvc0' but no success. > > @Oleksandr: At this moment it is difficult to share any file of guest. > It would be helpful if anyone provide me general technique to debug dom0 > bringup issue. You can

Re: [Xen-devel] [PATCH v5 16/23] x86/mm: add pv prefix to {alloc, free}_page_type

>>> On 14.09.17 at 14:58, wrote: > And move the declarations to pv/mm.h. The code will be moved later. > > The stubs contain BUG() because they aren't supposed to be called when > PV is disabled. I'd prefer ASSERT_UNREACHABLE() - they return proper errors after all, and

Re: [Xen-devel] [PATCH v5 15/23] x86/mm: move declaration of new_guest_cr3 to local pv/mm.h

>>> On 14.09.17 at 14:58, wrote: > It is only used by PV. The code can only be moved together with other > PV mm code. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel

Re: [Xen-devel] [PATCH v5 14/23] x86/mm: move PV l4 table setup code

>>> On 14.09.17 at 14:58, wrote: > @@ -32,6 +33,14 @@ > #undef page_to_mfn > #define page_to_mfn(pg) _mfn(__page_to_mfn(pg)) > > +#ifndef NDEBUG > +static unsigned int __read_mostly root_pgt_pv_xen_slots > += ROOT_PAGETABLE_PV_XEN_SLOTS; > +static l4_pgentry_t

Re: [Xen-devel] [PATCH v9 05/10] xl: add global grant limit config items

On Fri, Sep 22, 2017 at 01:41:29PM +0200, Juergen Gross wrote: > Add xl.conf config items for default values of grant limits: > > max_grant_frames will set the default for the maximum number of grant > frames for a domain which will take effect if the domain's config file > doesn't specify a

Re: [Xen-devel] [PATCH v9 06/10] libxl: add libxl support for setting grant table resource limits

On Fri, Sep 22, 2017 at 01:41:30PM +0200, Juergen Gross wrote: > Add new domain config items for setting the limits for the maximum > numbers of grant table frames and maptrack frames of a domain. > > Signed-off-by: Juergen Gross > Acked-by: Ian Jackson

Re: [Xen-devel] [PATCH v9 04/10] libxl: add max possible mfn to libxl_physinfo

On Fri, Sep 22, 2017 at 01:41:28PM +0200, Juergen Gross wrote: > Add the maximum possible mfn of the host to the libxl_physinfo > data structure. > > Signed-off-by: Juergen Gross > Acked-by: Ian Jackson Acked-by: Wei Liu

Re: [Xen-devel] [PATCH v5 13/23] x86/mm: factor out pv_arch_init_memory

>>> On 14.09.17 at 14:58, wrote: > Move the split l4 setup code into the new function. It can then be > moved to pv/ in a later patch. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v5 12/23] x86/mm: move and rename map_ldt_shadow_page

>>> On 14.09.17 at 14:58, wrote: > Add pv prefix to it. Move it to pv/mm.c. Fix call sites. > > Take the chance to change v to curr and d to currd. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich

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

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

Re: [Xen-devel] [PATCH v5 10/23] x86/mm: split out descriptor table manipulation code

On Fri, Sep 22, 2017 at 07:07:29AM -0600, Jan Beulich wrote: > >>> On 14.09.17 at 14:58, wrote: > > Move the code to pv/descriptor-tables.c. Change u64 to uint64_t while > > moving. Use currd in do_update_descriptor. > > Hmm, so the "later" in patch 9 isn't in a future

Re: [Xen-devel] [PATCH v5 11/23] x86/mm: move compat descriptor table manipulation code

>>> On 14.09.17 at 14:58, wrote: > --- a/xen/arch/x86/pv/descriptor-tables.c > +++ b/xen/arch/x86/pv/descriptor-tables.c > @@ -181,6 +181,46 @@ long do_update_descriptor(uint64_t pa, uint64_t desc) > return ret; > } > > +int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint)

Re: [Xen-devel] [PATCH v5 10/23] x86/mm: split out descriptor table manipulation code

>>> On 14.09.17 at 14:58, wrote: > Move the code to pv/descriptor-tables.c. Change u64 to uint64_t while > moving. Use currd in do_update_descriptor. Hmm, so the "later" in patch 9 isn't in a future series, but here. Why couldn't the move and rename then be done in one step?

Re: [Xen-devel] [PATCH v5 09/23] x86/mm: add pv prefix to {set, destroy}_gdt

>>> On 14.09.17 at 14:58, wrote: > --- a/xen/include/asm-x86/pv/mm.h > +++ b/xen/include/asm-x86/pv/mm.h > @@ -25,14 +25,24 @@ > > int pv_ro_page_fault(unsigned long addr, struct cpu_user_regs *regs); > > +long pv_set_gdt(struct vcpu *d, unsigned long *frames, unsigned

Re: [Xen-devel] [PATCH v1] libxl: remove list callback from device framework

On Fri, Sep 22, 2017 at 03:28:55PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > As we have generic functions to get device list > (libxl__device_list) no need to have callback in > the framework. To resolve issue when XS entry > doesn't match device

Re: [Xen-devel] [PATCH v5 08/23] x86/mm: split out pv grant table code

>>> On 14.09.17 at 14:58, wrote: > Move the code to pv/grant_table.c. Nothing needs to be done with > regard to headers. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel

Re: [Xen-devel] [PATCH v5 07/23] x86/mm: move map_guest_l1e to pv/mm.c

>>> On 14.09.17 at 14:58, wrote: > And export the function via pv/mm.h. > > Signed-off-by: Wei Liu I'm not overly happy with the function becoming non-static, but I can see that it'll be better to move grant table stuff and update-va- mapping into

Re: [Xen-devel] [PATCH v5 06/23] x86/mm: remove the now unused inclusion of pv/emulate.h

>>> On 14.09.17 at 14:58, wrote: > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 05/23] x86/mm: move ro page fault emulation code

>>> On 14.09.17 at 14:58, wrote: > --- /dev/null > +++ b/xen/include/asm-x86/pv/mm.h > @@ -0,0 +1,38 @@ > +/* > + * asm-x86/pv/mm.h > + * > + * Memory management interfaces for PV guests > + * > + * Copyright (C) 2017 Wei Liu > + * > + * This program is

Re: [Xen-devel] [PATCH v5 04/23] x86/mm: move {un, }adjust_guest_l*e to pv/mm.h

>>> On 14.09.17 at 14:58, wrote: > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 03/23] x86/mm: move update_intpte to pv/mm.h

>>> On 14.09.17 at 14:58, wrote: > --- a/xen/arch/x86/pv/mm.h > +++ b/xen/arch/x86/pv/mm.h > @@ -18,4 +18,69 @@ static inline l1_pgentry_t guest_get_eff_l1e(unsigned long > linear) > return l1e; > } > > +/* > + * PTE updates can be done with ordinary writes except: >

[Xen-devel] [PATCH v1] libxl: provide typedefs for device framework functions

From: Oleksandr Grytsov Resend Oleksandr Grytsov (1): libxl: remove list callback from device framework tools/libxl/libxl_checkpoint_device.c | 4 ++-- tools/libxl/libxl_colo_save.c | 2 +- tools/libxl/libxl_device.c| 4 ++--

  1   2   3   >