[Xen-devel] [linux-3.18 test] 112857: trouble: blocked/broken/fail/pass

flight 112857 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112857/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

[Xen-devel] [PATCH v8] VT-d: use correct BDF for VF to search VT-d unit

When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under the scope of the same VT-d unit as the 'Physical Function'. A 'Physical Function' can be a 'Traditional Function' or an ARI 'Extended Function'. And furthermore, 'Extended Functions' on an endpoint are under the scope

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

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

Re: [Xen-devel] [PATCH V2 9/25] tools/libxl: build DMAR table for a guest with one virtual VTD

On 2017年08月24日 19:08, Wei Liu wrote: If add dmar table for hvmlite, we should combine dmar table with other > >> ACPI table and populate into acpi_modules[2]. This is how hvmlite add > >> other ACPI tables in libxl__dom_load_acpi(). > >> >>> > > >>> > > Sure, that sounds

[Xen-devel] [xen-unstable test] 112855: regressions - trouble: blocked/broken/fail/pass

flight 112855 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112855/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 7 reboot fail REGR. vs. 112809

Re: [Xen-devel] [PATCH QEMU v4] xen/pt: allow QEMU to request MSI unmasking at bind time

On Thu, 24 Aug 2017, Roger Pau Monne wrote: > When a MSI interrupt is bound to a guest using > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is > left masked by default. > > This causes problems with guests that first configure interrupts and > clean the per-entry MSIX table

[Xen-devel] [xen-4.5-testing test] 112854: tolerable FAIL - PUSHED

flight 112854 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/112854/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112800 test-amd64-amd64-xl-rtds 7

[Xen-devel] [linux-linus test] 112853: regressions - trouble: blocked/broken/fail/pass

flight 112853 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112853/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 10 debian-install fail REGR. vs. 110515

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

On Thu, 24 Aug 2017 14:13:38 -0700 Thomas Garnier wrote: > With the fix for function tracing, the hackbench results have an > average of +0.8 to +1.4% (from +8% to +10% before). With a default > configuration, the numbers are closer to 0.8%. Wow, an empty fentry function

Re: [Xen-devel] [stage1-xen (RFC) PATCH 07/10] .circleci/config.yml: Add

On Thu, 24 Aug 2017, Rajiv Ranganath wrote: > On Thu, Aug 24 2017 at 05:54:05 AM, Stefano Stabellini > wrote: > > On Mon, 21 Aug 2017, Rajiv Ranganath wrote: > >> From: Rajiv M Ranganath > > > > Does .circleci need to be in the top directory

[Xen-devel] [libvirt test] 112856: tolerable trouble: blocked/broken/pass - PUSHED

flight 112856 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112856/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1

[Xen-devel] [xen-4.7-testing baseline-only test] 72014: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 72014 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72014/ 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 Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote: > > My original performance testing was done with an Ubuntu generic > configuration. This configuration has the CONFIG_FUNCTION_TRACER > option which was incompatible with PIE. The tracer failed to replace > the

Re: [Xen-devel] [PATCH 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

On 8/23/2017 5:20 PM, Konrad Rzeszutek Wilk wrote: ..snip.. Acked-by: Roger Pau Monné Forgot to add, this needs to be backported to stable branches, so: Annie, could you resend the patch with the tags and an update to the description to me please? Done Thanks Annie

[Xen-devel] [PATCH v2 1/1] xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

In xen_blkif_disconnect, before checking inflight I/O, following code stops the blkback thread, if (ring->xenblkd) { kthread_stop(ring->xenblkd); wake_up(>shutdown_wq); } If there is inflight I/O in any non-last queue, blkback returns -EBUSY directly, and above code would not be

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

On Thu, Aug 17, 2017 at 7:10 AM, Thomas Garnier wrote: > > On Thu, Aug 17, 2017 at 1:09 AM, Ingo Molnar wrote: > > > > > > * Thomas Garnier wrote: > > > > > > > -model=small/medium assume you are on the low 32-bit. It generates > > > >

Re: [Xen-devel] [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges

On Thu, Aug 24, 2017 at 9:39 AM, Christoph Hellwig wrote: > On Thu, Aug 24, 2017 at 09:31:17AM -0700, Dan Williams wrote: >> External agent is a DMA device, or a hypervisor like Xen. In the DMA >> case perhaps we can use the fcntl lease mechanism, I'll investigate. >> In the Xen case

Re: [Xen-devel] [PATCH v2 1/4] xen: credit2: implement utilization cap

On 8/18/17 4:50 PM, Dario Faggioli wrote: @@ -474,6 +586,12 @@ static inline struct csched2_runqueue_data *c2rqd(const struct scheduler *ops, return _priv(ops)->rqd[c2r(cpu)]; } +/* Does the domain of this vCPU have a cap? */ +static inline bool has_cap(const struct csched2_vcpu

Re: [Xen-devel] [PATCH v2] common/vm_event: Initialize vm_event lists on domain creation

On Thu, Aug 24, 2017 at 9:24 AM, Jan Beulich wrote: On 24.08.17 at 17:17, wrote: >> On Jo, 2017-08-24 at 07:24 -0600, Jan Beulich wrote: >>> > @@ -500,6 +519,9 @@ bool_t vm_event_check_ring(struct >>> > vm_event_domain *ved) >>> > int

Re: [Xen-devel] [PATCH v2] common/vm_event: Initialize vm_event lists on domain creation

On Thu, Aug 24, 2017 at 5:48 AM, Alexandru Isaila wrote: > The patch splits the vm_event into three structures:vm_event_share, > vm_event_paging, vm_event_monitor. The allocation for the > structure is moved to vm_event_enable so that it can be > allocated/init when

[Xen-devel] [xen-4.6-testing baseline-only test] 72013: regressions - FAIL

This run is configured for baseline tests only. flight 72013 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72013/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 7 xen-boot

[Xen-devel] [PATCH 2/3] gnttab: Drop the frame parameter from get_paged_frame()

It is redundant with the *page parameter. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim

[Xen-devel] [PATCH 3/3] gnttab: Drop the frame field from struct gnttab_copy_buf

It is redundant with *page. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan

[Xen-devel] [PATCH 0/3] gnttab: Further XSA-226 cleanup

Andrew Cooper (3): gnttab: Drop the frame parameter from acquire_grant_for_copy() gnttab: Drop the frame parameter from get_paged_frame() gnttab: Drop the frame field from struct gnttab_copy_buf xen/common/grant_table.c | 80 ++-- 1 file changed,

[Xen-devel] [PATCH 1/3] gnttab: Drop the frame parameter from acquire_grant_for_copy()

It is redundant with the *page parameter. Rename the grant_frame parameter to indicate that it is local, and highlight the correctness of the change. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 24/08/17 18:45, Juergen Gross wrote: > On 24/08/17 17:16, Andrew Cooper wrote: >> On 24/08/17 16:01, Juergen Gross wrote: >>> On 24/08/17 16:50, Andrew Cooper wrote: This patch was originally a workaround for XSA-226. Since then, transitive grants are believed to be functioning

[Xen-devel] [xen-4.9-testing test] 112850: regressions - trouble: blocked/broken/fail/pass

flight 112850 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/112850/ 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. 112820

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 24/08/17 17:16, Andrew Cooper wrote: > On 24/08/17 16:01, Juergen Gross wrote: >> On 24/08/17 16:50, Andrew Cooper wrote: >>> This patch was originally a workaround for XSA-226. Since then, transitive >>> grants are believed to be functioning properly, and the defaults have >>> changed >>>

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

On 21/08/17 21:27, Volodymyr Babchuk wrote: This feature indicates that hypervisor is compatible with ARM SMC calling convention. Hypervisor will not inject an undefined instruction exception if an invalid SMC function were called and will not crash a domain if an invlalid HVC functions were

Re: [Xen-devel] [PATCH v4 11/11] arm: enable XENFEAT_ARM_SMCCC_supported feature

On 22/08/17 08:29, Jan Beulich wrote: On 21.08.17 at 22:27, wrote: As Xen now supports SMCCC, we can enable this feature to tell guests that it is safe to call generic SMCs and HVCs. I think this and patch 10 should be folded. +1. Signed-off-by: Volodymyr

Re: [Xen-devel] [PATCH v4 08/11] arm: PSCI: use definitions provided by asm/smccc.h

Hi Volodymyr, On 21/08/17 21:27, Volodymyr Babchuk wrote: smccc.h provides definitions to construct SMC call function number according to SMCCC. We don't need multiple definitions for one thing, and definitions in smccc.h are more generic than ones used in psci.h. So psci.h will only provide

[Xen-devel] [xen-unstable-smoke test] 112861: tolerable trouble: broken/pass - PUSHED

flight 112861 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112861/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2

Re: [Xen-devel] [PATCH v2 REPOST 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

On Tue, Aug 22, 2017 at 03:51:05PM +0100, Paul Durrant wrote: > A subsequent patch will introduce a new scheme to allow an emulator to > map IOREQ server pages directly from Xen rather than the guest P2M. > > This patch lays the groundwork for that change by deferring mapping of > gfns until

Re: [Xen-devel] [PATCH v2 REPOST 10/12] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

On Tue, Aug 22, 2017 at 03:51:04PM +0100, Paul Durrant wrote: > This patch adjusts the IOREQ server code to use type-safe gfn_t values > where possible. No functional change. Oh, forget my comment on the previous patch then. Thanks. > Signed-off-by: Paul Durrant

Re: [Xen-devel] [PATCH v2 REPOST 09/12] x86/hvm/ioreq: simplify code and use consistent naming

On Tue, Aug 22, 2017 at 03:51:03PM +0100, Paul Durrant wrote: > This patch re-works much of the IOREQ server initialization and teardown > code: > > - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through > to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called >

Re: [Xen-devel] [PATCH v4 07/11] arm: traps: handle PSCI calls inside `vsmc.c`

Hi Volodymyr, On 21/08/17 21:27, Volodymyr Babchuk wrote: PSCI is part of HVC/SMC interface, so it should be handled in appropriate place: `vsmc.c`. This patch just moves PSCI handler calls from `traps.c` to `vsmc.c`. Older PSCI 0.1 uses SMC function identifiers in range that is resereved for

Re: [Xen-devel] [PATCH v4 06/11] arm: smccc: handle SMCs according to SMCCC

Hi Volodymyr, On 21/08/17 21:27, Volodymyr Babchuk wrote: SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. SMCCC states that both HVC and SMC are valid conduits to call to different firmware functions. Thus, for example, PSCI calls can be made both by SMC or HVC. Also

Re: [Xen-devel] [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges

On Thu, Aug 24, 2017 at 09:31:17AM -0700, Dan Williams wrote: > External agent is a DMA device, or a hypervisor like Xen. In the DMA > case perhaps we can use the fcntl lease mechanism, I'll investigate. > In the Xen case it actually would need to use fiemap() to discover the > physical addresses

Re: [Xen-devel] [PATCH v2 REPOST 02/12] x86/mm: allow a privileged PV domain to map guest mfns

On Tue, Aug 22, 2017 at 03:50:56PM +0100, Paul Durrant wrote: > In the case where a PV domain is mapping guest resources then it needs make > the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest > domid, so that the passed in gmfn values are correctly treated as mfns > rather

Re: [Xen-devel] [PATCH v2 REPOST 08/12] x86/hvm/ioreq: move is_default into struct hvm_ioreq_server

> -Original Message- > From: Roger Pau Monne > Sent: 24 August 2017 17:22 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Andrew Cooper > ; Jan Beulich > Subject: Re: [Xen-devel] [PATCH v2 REPOST 08/12]

Re: [Xen-devel] [PATCH v6 4/5] fs, xfs: introduce MAP_DIRECT for creating block-map-atomic file ranges

[ adding Xen ] On Thu, Aug 24, 2017 at 9:11 AM, Christoph Hellwig wrote: > I still can't make any sense of this description. What is an external > agent? Userspace obviously can't ever see a change in the extent > map, so it can't be meant. External agent is a DMA device, or a

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()

On 24/08/17 17:33, Jan Beulich wrote: On 23.08.17 at 19:33, wrote: >> @@ -163,20 +163,24 @@ void __init cmdline_parse(const char *cmdline) >> #endif >> } >> >> -int __init parse_bool(const char *s) >> +int __init parse_bool(const char *s, const char *e) >> { >> -if

Re: [Xen-devel] [PATCH v4 19/53] xen/arch/x86/psr.c: let custom parameter parsing routines return errno

On 24/08/17 17:35, Jan Beulich wrote: On 23.08.17 at 19:34, wrote: >> --- a/xen/arch/x86/psr.c >> +++ b/xen/arch/x86/psr.c >> @@ -418,50 +418,66 @@ static const struct feat_props l2_cat_props = { >> .write_msr = l2_cat_write_msr, >> }; >> >> -static void __init

Re: [Xen-devel] [PATCH v2 REPOST 08/12] x86/hvm/ioreq: move is_default into struct hvm_ioreq_server

On Tue, Aug 22, 2017 at 03:51:02PM +0100, Paul Durrant wrote: > Legacy emulators use the 'default' IOREQ server which has slightly > different semantics than other, explicitly created, IOREQ servers. > > Because of this, most of the initialization and teardown code needs to > know whether the

Re: [Xen-devel] [PATCH v2 REPOST 07/12] x86/hvm/ioreq: use bool rather than bool_t

On Tue, Aug 22, 2017 at 03:51:01PM +0100, Paul Durrant wrote: > This patch changes use of bool_t to bool in the IOREQ server code. It also > fixes an incorrect indentation in a continuation line. > > This patch is purely cosmetic. No semantic or functional change. > > Signed-off-by: Paul Durrant

Re: [Xen-devel] [PATCH 2/5] xen: move XENMAPSPACE_grant_table code into grant_table.c

Hello, I was expecting to be CCed on this patch. On 21/08/17 19:05, Juergen Gross wrote: The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly identical. Move the code into a function in grant_table.c and add an architecture dependant hook to handle the differences. This at

Re: [Xen-devel] [PATCH v2 REPOST 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

> -Original Message- > From: Roger Pau Monne > Sent: 24 August 2017 17:03 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Wei Liu ; Ian > Jackson > Subject: Re: [Xen-devel] [PATCH v2 REPOST 05/12]

Re: [Xen-devel] [PATCH v2 REPOST 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

On Tue, Aug 22, 2017 at 03:51:00PM +0100, Paul Durrant wrote: > Since IOREQ servers are only relevant to HVM guests and all the names in > question unequivocally refer to guest frame numbers, name them all .*gfn > to avoid any confusion. > > This patch is purely cosmetic. No semantic or

Re: [Xen-devel] [PATCH v2] x86: enable RCU based table free

On Thu, Aug 24, 2017 at 05:27:21PM +0200, Vitaly Kuznetsov wrote: > Do you think adding something like > > /* > * While x86 architecture in general requires an IPI to perform TLB > * shootdown, enablement code for several hypervisors overrides > * .flush_tlb_others hook in pv_mmu_ops and

Re: [Xen-devel] [PATCH v2 REPOST 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

On Tue, Aug 22, 2017 at 03:50:59PM +0100, Paul Durrant wrote: > A previous patch added support for priv-mapping guest resources directly > (rather than having to foreign-map, which requires P2M modification for > HVM guests). > > This patch makes use of the new API to seed the guest grant table

Re: [Xen-devel] [PATCH v2 REPOST 04/12] tools/libxenforeignmemory: add support for resource mapping

> -Original Message- > From: Roger Pau Monne > Sent: 24 August 2017 16:53 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Wei Liu ; Ian > Jackson > Subject: Re: [Xen-devel] [PATCH v2 REPOST 04/12] >

Re: [Xen-devel] [PATCH v2 REPOST 04/12] tools/libxenforeignmemory: add support for resource mapping

On Tue, Aug 22, 2017 at 03:50:58PM +0100, Paul Durrant wrote: > diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h > b/tools/libs/foreignmemory/include/xenforeignmemory.h > index f4814c390f..e56eb3c4d4 100644 > --- a/tools/libs/foreignmemory/include/xenforeignmemory.h > +++

Re: [Xen-devel] [PATCH v5 01/11] x86/pci: introduce hvm_pci_decode_addr

>>> On 14.08.17 at 16:28, wrote: > --- a/xen/arch/x86/hvm/io.c > +++ b/xen/arch/x86/hvm/io.c > @@ -256,6 +256,25 @@ void register_g2m_portio_handler(struct domain *d) > handler->ops = _portio_ops; > } > > +unsigned int hvm_pci_decode_addr(unsigned int cf8, unsigned

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()

On 23/08/17 18:33, Juergen Gross wrote: > Add a parameter to parse_bool() to specify the end of the to be > parsed string. Specifying it as NULL will preserve the current > behavior to parse until the end of the input string, while passing > a non-NULL pointer will specify the first character

Re: [Xen-devel] [PATCH v4 19/53] xen/arch/x86/psr.c: let custom parameter parsing routines return errno

>>> On 23.08.17 at 19:34, wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -418,50 +418,66 @@ static const struct feat_props l2_cat_props = { > .write_msr = l2_cat_write_msr, > }; > > -static void __init parse_psr_bool(char *s, char *value, char *feature,

Re: [Xen-devel] [PATCH v4 01/53] xen: add an optional string end parameter to parse_bool()

>>> On 23.08.17 at 19:33, wrote: > @@ -163,20 +163,24 @@ void __init cmdline_parse(const char *cmdline) > #endif > } > > -int __init parse_bool(const char *s) > +int __init parse_bool(const char *s, const char *e) > { > -if ( !strcmp("no", s) || > -

Re: [Xen-devel] [PATCH XEN v4] x86/pt: add a MSI unmask flag to XEN_DOMCTL_bind_pt_irq

>>> On 24.08.17 at 17:07, wrote: > The flag is part of the gflags, and should be used to request the > unmask of a MSI interrupt once it's bound. > > This is required for the device model in order to be capable of > binding MSIX interrupts that have the entry mask bit

Re: [Xen-devel] [PATCH v2] x86: enable RCU based table free

Peter Zijlstra writes: > On Thu, Aug 24, 2017 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: > >> diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h >> index c7797307fc2b..d43a7fcafee9 100644 >> --- a/arch/x86/include/asm/tlb.h >> +++

Re: [Xen-devel] [PATCH v4 12/31] x86/mm: split out readonly MMIO emulation code

On 24/08/17 16:16, Jan Beulich wrote: On 17.08.17 at 16:44, wrote: >> Move the code to pv/emul-mmio-op.c. Fix coding style issues while >> moving. >> >> Note that mmio_ro_emulated_write is needed by both PV and HVM, so it >> is left in x86/mm.c. >> >> Signed-off-by: Wei

Re: [Xen-devel] [PATCH v2] common/vm_event: Initialize vm_event lists on domain creation

>>> On 24.08.17 at 17:17, wrote: > On Jo, 2017-08-24 at 07:24 -0600, Jan Beulich wrote: >> > @@ -500,6 +519,9 @@ bool_t vm_event_check_ring(struct >> > vm_event_domain *ved) >> > int __vm_event_claim_slot(struct domain *d, struct vm_event_domain >> > *ved, >> >

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

>>> On 24.08.17 at 17:13, wrote: > On 24/08/17 17:04, Jan Beulich wrote: > On 24.08.17 at 16:48, wrote: >>> How would the guest know whether using v2 grants is no disadvantage? >> >> As said - it's always going to be a disadvantage. Even if controlling >>

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 24/08/17 16:01, Juergen Gross wrote: > On 24/08/17 16:50, Andrew Cooper wrote: >> This patch was originally a workaround for XSA-226. Since then, transitive >> grants are believed to be functioning properly, and the defaults have changed >> appropriately. >> >> However, for those people who

Re: [Xen-devel] [PATCH v2] common/vm_event: Initialize vm_event lists on domain creation

On Jo, 2017-08-24 at 07:24 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 24.08.17 at 13:48, wrote: > > The patch splits the vm_event into three structures:vm_event_share, > > vm_event_paging, vm_event_monitor. The allocation for the > > structure is moved to

Re: [Xen-devel] [PATCH v4 12/31] x86/mm: split out readonly MMIO emulation code

>>> On 17.08.17 at 16:44, wrote: > Move the code to pv/emul-mmio-op.c. Fix coding style issues while > moving. > > Note that mmio_ro_emulated_write is needed by both PV and HVM, so it > is left in x86/mm.c. > > Signed-off-by: Wei Liu > --- >

Re: [Xen-devel] [PATCH v4 11/31] x86/mm: split out writable pagetable emulation code

>>> On 17.08.17 at 16:44, wrote: > Move the code to pv/emul-ptwr-op.c. Fix coding style issues while > moving the code. > > Rename ptwr_emulated_read to pv_emul_ptwr_read and export it via > pv/mm.h because it is needed by other emulation code. If other emulated code uses

Re: [Xen-devel] [PATCH 4/5] xen: support different gnttab_max_frames for grant v1 and v2

On 24/08/17 17:01, Jan Beulich wrote: On 24.08.17 at 16:54, wrote: >> OTOH I think there should be a default especially on huge hosts >> allowing to use v2 grants without reducing the number of allowed >> grants, which doesn't need adding another parameter to the domain >>

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

On 24/08/17 17:04, Jan Beulich wrote: On 24.08.17 at 16:48, wrote: >> On 24/08/17 16:28, Jan Beulich wrote: >> On 21.08.17 at 20:05, wrote: Today a guest can get the maximum grant table frame number for the currently selected grant table

[Xen-devel] [PATCH v4] x86/pt: fix binding of MSIX entries already unmasked

Hello, The following two patches fix an issue where a MSIX interrupt bound to a guest when the MSIX entry is already unmasked would be left masked, and thus the guest would not receive any interrupts from the device. This is fixed by adding a new flag to the gflags field used in

[Xen-devel] [PATCH XEN v4] x86/pt: add a MSI unmask flag to XEN_DOMCTL_bind_pt_irq

The flag is part of the gflags, and should be used to request the unmask of a MSI interrupt once it's bound. This is required for the device model in order to be capable of binding MSIX interrupts that have the entry mask bit already unset at bind time. Without this fix the interrupts would be

[Xen-devel] [PATCH QEMU v4] xen/pt: allow QEMU to request MSI unmasking at bind time

When a MSI interrupt is bound to a guest using xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is left masked by default. This causes problems with guests that first configure interrupts and clean the per-entry MSIX table mask bit and afterwards enable MSIX globally. In such

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

>>> On 24.08.17 at 16:48, wrote: > On 24/08/17 16:28, Jan Beulich wrote: > On 21.08.17 at 20:05, wrote: >>> Today a guest can get the maximum grant table frame number for the >>> currently selected grant table interface version (1 or 2) only. Add >>> a new

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

On 24/08/17 16:48, Juergen Gross wrote: > On 24/08/17 16:28, Jan Beulich wrote: > On 21.08.17 at 20:05, wrote: >>> Today a guest can get the maximum grant table frame number for the >>> currently selected grant table interface version (1 or 2) only. Add >>> a new grant table

Re: [Xen-devel] [PATCH 4/5] xen: support different gnttab_max_frames for grant v1 and v2

>>> On 24.08.17 at 16:54, wrote: > OTOH I think there should be a default especially on huge hosts > allowing to use v2 grants without reducing the number of allowed > grants, which doesn't need adding another parameter to the domain > config. Or do you want the tools to always

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 24/08/17 16:50, Andrew Cooper wrote: > This patch was originally a workaround for XSA-226. Since then, transitive > grants are believed to be functioning properly, and the defaults have changed > appropriately. > > However, for those people who chose to use the workaround (especially from an

Re: [Xen-devel] [PATCH v4 05/11] arm: add SMCCC protocol definitions.

Hi Volodymyr, Title: No need for the full stop. On 21/08/17 21:27, Volodymyr Babchuk wrote: This patch adds generic definitions used in ARM SMC call convention. Those definitions was taken from linux header arm-smccc.h, extended and formatted according to XEN coding style. They can be used by

Re: [Xen-devel] [PATCH v4 10/31] x86/mm: move {un, }adjust_guest_* to pv/mm.h

>>> On 17.08.17 at 16:44, wrote: > Those macros will soon be used in different files. They are PV > specific so move them to pv/mm.h. Same comment here regarding where to move them. Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v4 09/31] x86/mm: rename and move update_intpte

>>> On 17.08.17 at 16:44, wrote: > That function is only used by PV guests supporting code, add pv_ > prefix. Is any code outside of x86/pv/ going to need access to it? I hope not, in which case it shouldn't be exposed via include/asm-x86/pv/mm.h, but via a private header in

Re: [Xen-devel] [PATCH v4 08/31] x86/mm: export get_page_from_mfn

>>> On 17.08.17 at 16:44, wrote: > It will be used by different files later, so export it via > asm-x86/mm.h. This is a pretty thin wrapper - wouldn't be better to make it a static inline? Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 4/5] xen: support different gnttab_max_frames for grant v1 and v2

On 24/08/17 16:21, Jan Beulich wrote: On 21.08.17 at 20:05, wrote: >> The number of grants a domain can setup is limited by the maximum >> number of grant frames it is allowed to use. Today the limit is the >> same regardless whether the domain uses grant v1 or v2. Using v2

Re: [Xen-devel] [PATCH v4 07/31] x86/mm: move and rename guest_get_eff{, kern}_l1e

>>> On 17.08.17 at 16:44, wrote: > Move them to pv/mm.c and rename them to pv_get_guest_eff_{,kern}_l1e. > Export them via pv/mm.h. I think these should remain static inlines. If either is really needed by more than one C file, it may be best to move it/them to a private

[Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

This patch was originally a workaround for XSA-226. Since then, transitive grants are believed to be functioning properly, and the defaults have changed appropriately. However, for those people who chose to use the workaround (especially from an attack surface mitigation point of view), retain

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

On 24/08/17 16:28, Jan Beulich wrote: On 21.08.17 at 20:05, wrote: >> Today a guest can get the maximum grant table frame number for the >> currently selected grant table interface version (1 or 2) only. Add >> a new grant table operation to get the limits of both variants

Re: [Xen-devel] [PATCH v4 04/11] arm: processor.h: add definition for immediate value mask

Hi Volodymyr, Title: It is a too generic, you may want to rename to: "Define HVC/SMC immediate mask" On 21/08/17 21:27, Volodymyr Babchuk wrote: This patch adds definition HSR_XXC_IMM_MASK. It can be used to extract s/adds definition/define/ immediate value for trapped HVC32, HVC64,

Re: [Xen-devel] [PATCH v4 02/11] arm: traps: check if SMC was conditional before handling it

Hi Volodymyr, On 21/08/17 21:27, Volodymyr Babchuk wrote: Trapped SMC instruction can fail condition check on ARMv8 arhcitecture s/arhcitecture/architecture/ (ARM DDI 0487B.a page D7-2271). So we need to check if condition was meet. Signed-off-by: Volodymyr Babchuk

Re: [Xen-devel] [PATCH QEMU v2] xen/pt: allow QEMU to request MSI unmasking at bind time

On Thu, Aug 24, 2017 at 07:09:08AM -0600, Jan Beulich wrote: > >>> On 24.08.17 at 14:19, wrote: > > When a MSI interrupt is bound to a guest using > > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is > > left masked by default. > > > > This causes problems

Re: [Xen-devel] [PATCH v4 01/11] arm: traps: use generic register accessors in the PSCI code

Hi Volodymyr, On 21/08/17 21:27, Volodymyr Babchuk wrote: There are standard functions set_user_reg() and get_user_reg(). We can use them in PSCI_SET_RESULT()/PSCI_ARG() macroses instead of relying on s/macroses/macros/ I think. CONFIG_ARM_64 definition. Signed-off-by: Volodymyr Babchuk

Re: [Xen-devel] [PATCH v2] x86: enable RCU based table free

On Thu, Aug 24, 2017 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: > diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h > index c7797307fc2b..d43a7fcafee9 100644 > --- a/arch/x86/include/asm/tlb.h > +++ b/arch/x86/include/asm/tlb.h > @@ -15,4 +15,9 @@ > > #include > >

Re: [Xen-devel] [PATCH 4/6] xsm: flask: change the interface and default policy for xsm_map_gmfn_foregin

On 08/24/2017 08:39 AM, Jan Beulich wrote: On 24.08.17 at 13:33, wrote: Hi Jan, 2017-08-24 14:37 GMT+08:00 Jan Beulich : On 24.08.17 at 02:51, wrote: 2017-08-23 17:55 GMT+08:00 Jan Beulich : On 22.08.17 at

Re: [Xen-devel] [PATCH v4 49/53] xen: add hypercall for setting parameters at runtime

On Wed, Aug 23, 2017 at 07:34:42PM +0200, Juergen Gross wrote: > Add a sysctl hypercall to support setting parameters similar to > command line parameters, but at runtime. The parameters to set are > specified as a string, just like the boot parameters. > > Cc: Daniel De Graaf

Re: [Xen-devel] [PATCH 3/5] xen: clean up grant_table.h

On 24/08/17 16:17, Jan Beulich wrote: On 21.08.17 at 20:05, wrote: >> @@ -118,6 +154,18 @@ struct grant_mapping { >> uint32_t pad; /* round size to a power of 2 */ >> }; >> >> +/* Number of grant table frames. Caller must hold d's grant table lock. */ >>

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

>>> On 21.08.17 at 20:05, wrote: > Today a guest can get the maximum grant table frame number for the > currently selected grant table interface version (1 or 2) only. Add > a new grant table operation to get the limits of both variants in > order to give the guest an opportunity

Re: [Xen-devel] [PATCH v4 40/53] xen: check parameter validity when parsing command line

On Wed, Aug 23, 2017 at 07:34:33PM +0200, Juergen Gross wrote: > Where possible check validity of parameters in _cmdline_parse() and > issue a warning message in case of an error detected. > > In order to make sure a custom parameter parsing function really > returns a value (error or success),

Re: [Xen-devel] [PATCH V2 1/25] DOMCTL: Introduce new DOMCTL commands for vIOMMU support

On Thu, Aug 24, 2017 at 03:03:49PM +0100, Julien Grall wrote: > Hi, > > On 23/08/17 15:05, Roger Pau Monné wrote: > > On Wed, Aug 23, 2017 at 11:19:01AM +0100, Julien Grall wrote: > > > Hi Roger, > > > > > > On 23/08/17 08:22, Roger Pau Monné wrote: > > > > On Wed, Aug 23, 2017 at 02:06:17PM

[Xen-devel] [xen-4.7-testing test] 112851: tolerable trouble: blocked/broken/fail/pass - PUSHED

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

Re: [Xen-devel] [PATCH 4/5] xen: support different gnttab_max_frames for grant v1 and v2

>>> On 21.08.17 at 20:05, wrote: > The number of grants a domain can setup is limited by the maximum > number of grant frames it is allowed to use. Today the limit is the > same regardless whether the domain uses grant v1 or v2. Using v2 > will therefor be a disadvantage for the

Re: [Xen-devel] [PATCH XEN v2] x86/pt: add a MSI unmask flag to XEN_DOMCTL_bind_pt_irq

On Thu, Aug 24, 2017 at 07:04:55AM -0600, Jan Beulich wrote: > >>> On 24.08.17 at 14:19, wrote: > > @@ -438,6 +439,20 @@ int pt_irq_create_bind( > > pi_update_irte(vcpu ? >arch.hvm_vmx.pi_desc : NULL, > > info, pirq_dpci->gmsi.gvec);

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

On Thu, Aug 24, 2017 at 02:14:57PM +0100, Andrew Cooper wrote: > This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___

Re: [Xen-devel] [PATCH 1/3] x86/mm: Replace opencoded forms of l?e_{get, from}_page()

On Thu, Aug 24, 2017 at 02:14:55PM +0100, Andrew Cooper wrote: > No functional change (confirmed by diffing the disassembly). > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing

Re: [Xen-devel] [PATCH 2/3] x86/mm: Replace opencoded forms of map_l?t_from_l?e()

On Thu, Aug 24, 2017 at 02:14:56PM +0100, Andrew Cooper wrote: > No functional change (confirmed by diffing the disassembly). > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

At 14:14 +0100 on 24 Aug (1503584097), Andrew Cooper wrote: > This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. > > Signed-off-by: Andrew Cooper Acked-by: Tim Deegan ___ Xen-devel

  1   2   3   >