Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

On 10/03/16 20:48, Tamas K Lengyel wrote: > > > On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap <george.dun...@citrix.com > <mailto:george.dun...@citrix.com>> wrote: > > On 08/03/16 15:30, Malcolm Crossley wrote: > > Nested hap code assumed implict b

[Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

p2m_access users assuming bitmask semantics, instead restore the previous enum order and make it explict that bitmask semantics are to be preserved for the read, write and execute access types. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- xen/arch/x86/mm/hap/nested_hap.

[Xen-devel] Xen PV IOMMU interface draft D

% Xen PV IOMMU interface % Malcolm Crossley <<malcolm.cross...@citrix.com>> Paul Durrant <<paul.durr...@citrix.com>> % Draft D Introduction Revision History Versi

Re: [Xen-devel] [RFC PATCH 1/7] common/pv-iommu: Add stub hypercall for PV-IOMMU

I forgot to CC xen-devel for the cover letter for this series. You can access the cover letter in the xen-devel archives here: http://lists.xen.org/archives/html/xen-devel/2016-02/msg01441.html On 10/02/16 10:10, Malcolm Crossley wrote: > Signed-off-by: Malcolm Crossley <malcolm

[Xen-devel] [RFC PATCH 0/7] Implement Xen PV-IOMMU interface

in order to keep performance parity with current out of tree mechanisms to obtain BFNs for foreign guest owned memory. The pre map mechanism is not a weakening of the current security model of Xen and is only allowed when the hardware domain is allowed relaxed IOMMU mappings. Malcolm Crossley (7

[Xen-devel] [RFC PATCH 6/7] common/pv-iommu: Add foreign ops to PV-IOMMU interface

interface which is mandated by the B2M interface itself. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: dgde...@tycho.nsa.gov Cc: jbeul...@suse.com Cc: ian.campb...@citrix.com Cc: k...@xen.org Cc: t...@xen.org Cc: andrew.coop...@citrix.com Cc: xen-devel@lists.xen.org --

[Xen-devel] [RFC PATCH 5/7] x86/m2b: Add a tracking structure for mfn to bfn mappings per page

destroy to ensure malicious guests do not cause memory To aid emulators tracking state, with asynchronous domain destruction, an ioreq is issued to all affected emulators for each m2b mapping being removed. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: k...@xen.

[Xen-devel] [RFC PATCH 4/7] common/pv-iommu: Add query, map and unmap ops

Implement above ops according to PV-IOMMU design draft D. Currently restricted to hardware domains only due to RFC status. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: jbeul...@suse.com Cc: k...@xen.org Cc: t...@xen.org Cc: andrew.coop...@citrix.com Cc: xen

[Xen-devel] [RFC PATCH 7/7] common/pv-iommu: Allow hardware_domain to pre IOMMU map foreign memory

-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: k...@xen.org Cc: jbeul...@suse.com Cc: andrew.coop...@citrix.com Cc: george.dun...@eu.citrix.com Cc: xen-devel@lists.xen.org --- xen/arch/x86/mm/m2b.c | 2 + xen/common/pv_iommu.c

[Xen-devel] [RFC PATCH 1/7] common/pv-iommu: Add stub hypercall for PV-IOMMU

Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: jbeul...@suse.com Cc: andrew.coop...@citrix.com Cc: ian.campb...@citrix.com Cc: k...@xen.org Cc: t...@xen.org Cc: xen-devel@lists.xen.org --- xen/arch/x86/x86_64/compat/entry.S | 2 ++ xen/arch/x86/x86_64/entry.S

[Xen-devel] [RFC PATCH 2/7] iommu: add iommu_lookup_page to lookup guest gfn for a particular IOMMU mapping

If IOMMU driver does not implement lookup_page function then it returns -ENOMEM. Returns 0 on success and any other value on failure. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: jbeul...@suse.com Cc: xen-devel@lists.xen.org --- xen/drivers/passthrough/iommu.

[Xen-devel] [RFC PATCH 3/7] VT-d: Add iommu_lookup_page support

Function does not need to handle shared EPT use of IOMMU as core code already handles this. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Cc: kevin.t...@intel.com Cc: feng...@intel.com Cc: xen-devel@lists.xen.org --- xen/drivers/passthrough/vtd/iommu.

[Xen-devel] [PATCHv6 3/3] p2m: convert p2m rwlock to percpu rwlock

if they take an altp2m read lock simultaneously with the main p2m lock. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> Reviewed-by: George Dunlap <george.dun...@citrix.com> -- Changes since v5: - None Changes since v4: - None Changes since v3: - None Changes since v2 - U

[Xen-devel] [PATCHv6 2/3] grant_table: convert grant table rwlock to percpu rwlock

and to confirm the overhead was dramatically reduced by the percpu rwlocks. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> Acked-by: Ian Campbell <ian.campb...@citrix.com> -- Changes since v5: - None Changes since v4: - Rename grant table rwlock wrappers and use grant t

[Xen-devel] [PATCHv6 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

with interrupts disabled. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v5: - Fix compilation on ARM Changes since v4: - Use static inlines for the percpu_owner check Changes since v3: - Fix the ASSERTS for the percpu_owner check Changes since v2: - Remove

[Xen-devel] [PATCHv6 0/3] Implement per-cpu reader-writer locks

percpu rwlock barrier from global to per lock - Move write lock cpumask variable to a percpu variable - Add macros to help initialise and use percpu rwlocks - Updated IO benchmark results to cover revised locking implementation Malcolm Crossley (3): rwlock: Add per-cpu reader-writer lock

Re: [Xen-devel] [PATCHv6 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

On 22/01/16 13:54, Ian Campbell wrote: > On Fri, 2016-01-22 at 13:41 +0000, Malcolm Crossley wrote: >> >> Changes since v5: >> - Fix compilation on ARM > > This was the removal of some spurious "&", I think? Yeah, I forgot to keep the macro's in sync.

Re: [Xen-devel] [PATCHv6 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

On 22/01/16 14:22, Ian Campbell wrote: > On Fri, 2016-01-22 at 14:16 +0000, Malcolm Crossley wrote: >> On 22/01/16 13:54, Ian Campbell wrote: >>> On Fri, 2016-01-22 at 13:41 +, Malcolm Crossley wrote: >>>> >>>> Changes since v5: >>>>

Re: [Xen-devel] [PATCHv5 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

On 11/01/16 15:06, Malcolm Crossley wrote: > On 22/12/15 11:56, George Dunlap wrote: >> On 18/12/15 16:08, Malcolm Crossley wrote: >>> >>> + >>> +#ifndef NDEBUG >>> +#define PERCPU_RW_LOCK_UNLOCKED(owner) { RW_LOCK_UNLOCKED, 0, owner } >&

[Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

The average is calculated over the period of time from the last xenpm report of the average CPU frequency. Reporting the average CPU frequency helps confirm the level of turbo boost being achieved per CPU. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- tools/misc/xenpm.

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

On 19/01/16 11:06, Ian Campbell wrote: > On Tue, 2016-01-19 at 10:50 +0000, Malcolm Crossley wrote: >> The average is calculated over the period of time from the last >> xenpm report of the average CPU frequency. >> >> Reporting the average CPU frequency helps confirm

[Xen-devel] [PATCHv2] xenpm: Add option to report average CPU frequency

The average is calculated over the period of time from the last xenpm report of the average CPU frequency. Reporting the average CPU frequency helps confirm the level of turbo boost being achieved per CPU. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- tools/misc/xenpm.

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

On 19/01/16 11:35, Ian Campbell wrote: > On Tue, 2016-01-19 at 11:10 +0000, Malcolm Crossley wrote: >> On 19/01/16 11:06, Ian Campbell wrote: >>> On Tue, 2016-01-19 at 10:50 +, Malcolm Crossley wrote: >>>> The average is calculated over the period of time f

Re: [Xen-devel] [PATCHv5 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

On 22/12/15 11:56, George Dunlap wrote: > On 18/12/15 16:08, Malcolm Crossley wrote: >> >> + >> +#ifndef NDEBUG >> +#define PERCPU_RW_LOCK_UNLOCKED(owner) { RW_LOCK_UNLOCKED, 0, owner } >> +static inline void _percpu_rwlock_owner_ch

[Xen-devel] [PATCHv4 2/3] grant_table: convert grant table rwlock to percpu rwlock

and to confirm the overhead was dramatically reduced by the percpu rwlocks. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v2: - Switched to using wrappers for taking percpu rwlock - Added percpu structure pointer to percpu rwlock initialisation - Added comment on r

[Xen-devel] [PATCHv4 3/3] p2m: convert p2m rwlock to percpu rwlock

if they take an altp2m read lock simultaneously with the main p2m lock. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v2 - Updated local percpu rwlock initialisation --- xen/arch/x86/mm/mm-locks.h | 12 +++- xen/arch/x86/mm/p2m.c | 1 + xen/include/a

[Xen-devel] [PATCHv4 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

with interrupts disabled. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v3: - Fix the ASSERTS for the percpu_owner check Changes since v2: - Remove stray hard tabs - Added owner field to percpu_rwlock_t for debug builds. This allows for ASSERTs to be added

Re: [Xen-devel] [PATCHv3 0/3] Implement per-cpu reader-writer locks

I didn't spot the percpu rwlock owner ASSERT being the wrong way round. Please review version 4 of the series. Sorry for the noise. On 17/12/15 12:52, Malcolm Crossley wrote: > This patch series adds per-cpu reader-writer locks as a generic lock > implementation and then converts the grant

Re: [Xen-devel] [PATCHv3 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

I didn't spot the percpu rwlock owner ASSERT being the wrong way round. Please review version 4 of the series. Sorry for the noise. On 17/12/15 12:52, Malcolm Crossley wrote: > Per-cpu read-write locks allow for the fast path read case to have > low overhead by only setting/clearing a p

[Xen-devel] [PATCHv5 3/3] p2m: convert p2m rwlock to percpu rwlock

if they take an altp2m read lock simultaneously with the main p2m lock. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v4: - None Changes since v3: - None Changes since v2 - Updated local percpu rwlock initialisation --- xen/arch/x86/mm/mm-locks.h | 12 +++

[Xen-devel] [PATCHv5 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

with interrupts disabled. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v4: - Use static inlines for the percpu_owner check Changes since v3: - Fix the ASSERTS for the percpu_owner check Changes since v2: - Remove stray hard tabs - Added owner

[Xen-devel] [PATCHv5 2/3] grant_table: convert grant table rwlock to percpu rwlock

and to confirm the overhead was dramatically reduced by the percpu rwlocks. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v4: - Rename grant table rwlock wrappers and use grant table pointer as argument Changes since v3: - None Changes since v2: - Switched to using wr

[Xen-devel] [PATCHv5 0/3] Implement per-cpu reader-writer locks

- Move write lock cpumask variable to a percpu variable - Add macros to help initialise and use percpu rwlocks - Updated IO benchmark results to cover revised locking implementation Malcolm Crossley (3): rwlock: Add per-cpu reader-writer lock infrastructure grant_table: convert grant table

[Xen-devel] [PATCHv3 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

with interrupts disabled. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v2: - Remove stray hard tabs Changes since v1: - Removed restriction on taking two or more different percpu rw locks simultaneously - Moved fast-path/slow-path barrier to be per lock i

[Xen-devel] [PATCHv3 0/3] Implement per-cpu reader-writer locks

locking implementation Malcolm Crossley (3): rwlock: Add per-cpu reader-writer lock infrastructure grant_table: convert grant table rwlock to percpu rwlock p2m: convert p2m rwlock to percpu rwlock xen/arch/arm/mm.c | 4 +- xen/arch/x86/mm.c | 4 +- xen/arch/x86/mm/mm

[Xen-devel] [PATCHv3 2/3] grant_table: convert grant table rwlock to percpu rwlock

and to confirm the overhead was dramatically reduced by the percpu rwlocks. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v2: - Switched to using wrappers for taking percpu rwlock - Added percpu structure pointer to percpu rwlock initialisation - Added comment on r

[Xen-devel] [PATCHv3 3/3] p2m: convert p2m rwlock to percpu rwlock

if they take an altp2m read lock simultaneously with the main p2m lock. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v2 - Updated local percpu rwlock initialisation --- xen/arch/x86/mm/mm-locks.h | 12 +++- xen/arch/x86/mm/p2m.c | 1 + xen/include/a

[Xen-devel] [PATCH] x86: Make printks consistent in hvm_set_callback_via function

The printks in the switch statement do not match the dprintk used immediately before the switch statement. This leads to confusing messages being printed to the Xen console log on non-debug versions of Xen. --- xen/arch/x86/hvm/irq.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-)

[Xen-devel] [PATCH] x86: Make debug output consistent in hvm_set_callback_via

The unconditional printks in the switch statement of the hvm_set_callback_via function results in Xen log spam in non debug versions of Xen. The printks are for debug output only so conditionally compile the entire switch statement on debug versions of Xen only. --- xen/arch/x86/hvm/irq.c | 4

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

On 26/11/15 13:46, Jan Beulich wrote: On 25.11.15 at 11:28, wrote: >> The problem is that SandyBridge IOMMUs advertise 2M support and do >> function with it, but cannot cache 2MB translations in the IOTLBs. >> >> As a result, attempting to use 2M translations

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

On 25/11/15 15:38, Jan Beulich wrote: On 25.11.15 at 16:13, wrote: >> On 25/11/15 10:49, Jan Beulich wrote: >> On 25.11.15 at 11:28, wrote: On 24/11/15 17:41, Jan Beulich wrote: On 24.11.15 at 18:17, wrote: >> ---

Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

On 24/11/15 18:30, George Dunlap wrote: > On 24/11/15 18:16, George Dunlap wrote: >> On 20/11/15 16:03, Malcolm Crossley wrote: >>> This patch series adds per-cpu reader-writer locks as a generic lock >>> implementation and then converts the grant table and p2m rw

Re: [Xen-devel] [PATCHv2 3/3] p2m: convert grant table rwlock to percpu rwlock

On 25/11/15 12:38, Jan Beulich wrote: On 20.11.15 at 17:03, wrote: >> @@ -115,7 +117,7 @@ static inline void _mm_write_lock(mm_rwlock_t *l, const >> char *func, int level) >> if ( !mm_write_locked_by_me(l) ) >> { >> __check_lock_level(level);

Re: [Xen-devel] [PATCHv2 2/3] grant_table: convert grant table rwlock to percpu rwlock

On 25/11/15 12:35, Jan Beulich wrote: On 20.11.15 at 17:03, wrote: >> @@ -208,8 +210,6 @@ active_entry_acquire(struct grant_table *t, grant_ref_t >> e) >> { >> struct active_grant_entry *act; >> >> -ASSERT(rw_is_locked(>lock)); > > Even if not

Re: [Xen-devel] [PATCHv2 2/3] grant_table: convert grant table rwlock to percpu rwlock

On 25/11/15 13:53, Jan Beulich wrote: On 25.11.15 at 14:43, wrote: >> On 25/11/15 12:35, Jan Beulich wrote: >> On 20.11.15 at 17:03, wrote: @@ -208,8 +210,6 @@ active_entry_acquire(struct grant_table *t, grant_ref_t

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 08:59, Jan Beulich wrote: On 24.11.15 at 07:55, wrote: >> What about: >> >> 4) Instead of relying on the kernel maintained p2m list for m2p >>conversion use the hypervisor maintained m2p list which should be >>available in the dump as well. This is the

[Xen-devel] [PATCHv2 1/3] rwlock: Add per-cpu reader-writer locks

with interrupts disabled. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v1: - Removed restriction on taking two or more different percpu rw locks simultaneously - Moved fast-path/slow-path barrier to be per lock instead of global - Created seperate percpu_rw

[Xen-devel] [PATCHv2 2/3] grant_table: convert grant table rwlock to percpu rwlock

and to confirm the overhead was dramatically reduced by the percpu rwlocks. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> -- Changes since v1: - Used new macros provided in updated percpu rwlock v2 patch - Converted grant table rwlock_t to percpu_rwlock_t - Patched a missed grant

[Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

This patch series adds per-cpu reader-writer locks as a generic lock implementation and then converts the grant table and p2m rwlocks to use the percpu rwlocks, in order to improve multi-socket host performance. CPU profiling has revealed the rwlocks themselves suffer from severe cache line

[Xen-devel] [PATCHv2 3/3] p2m: convert grant table rwlock to percpu rwlock

if they take an altp2m read lock simultaneously with the main p2m lock. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- xen/arch/x86/mm/mm-locks.h | 12 +++- xen/arch/x86/mm/p2m.c | 1 + xen/include/asm-x86/mm.h | 2 +- 3 files changed, 9 insertions(+), 6 del

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 20:02, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper wrote: >> On 17/11/15 17:04, Jan Beulich wrote: >> On 03.11.15 at 18:58, wrote: --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c

Re: [Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

On 18/11/15 14:15, Jan Beulich wrote: On 18.11.15 at 14:49, wrote: >> On 17/11/15 17:00, Jan Beulich wrote: >> On 03.11.15 at 18:58, wrote: Per-cpu read-write locks allow for the fast path read case to have low

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 12:07, Ian Campbell wrote: > On Wed, 2015-11-18 at 11:56 +0000, Malcolm Crossley wrote: >> On 18/11/15 11:50, Ian Campbell wrote: >>> On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote: >>>> On 18/11/15 10:54, Jan Beulich wrote: >>>

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 10:54, Jan Beulich wrote: On 18.11.15 at 11:36, wrote: >> On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote: >>> On 17/11/15 17:39, Jan Beulich wrote: >>> On 17.11.15 at 18:30, wrote: > On 17/11/15 17:04, Jan

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 11:41, Jan Beulich wrote: On 18.11.15 at 12:23, wrote: >> On 18/11/15 10:54, Jan Beulich wrote: >>> That's not how I understood it, the rwlock isn't per-pCPU (at least not >>> in what this patch does - it remains a per-domain one). The per-pCPU >>>

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 11:50, Ian Campbell wrote: > On Wed, 2015-11-18 at 11:23 +0000, Malcolm Crossley wrote: >> On 18/11/15 10:54, Jan Beulich wrote: >>>>>> On 18.11.15 at 11:36, <ian.campb...@citrix.com> wrote: >>>> On Tue, 2015-11-17 at 17:53 +, Andr

Re: [Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

On 17/11/15 17:00, Jan Beulich wrote: On 03.11.15 at 18:58, wrote: >> Per-cpu read-write locks allow for the fast path read case to have low >> overhead >> by only setting/clearing a per-cpu variable for using the read lock. >> The per-cpu read fast path also

Re: [Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

> (XEN) Assertion 'rw_is_locked(>lock)' failed at grant_table.c:215 > (XEN) > (XEN) > (XEN) Manual reset required ('noreboot' specified) > > > Thanks for your help. > > On 11/03/2015 12:58 PM, Malcolm Crossley wrote: >>

[Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

and to confirm the overhead was dramatically reduced by the percpu rwlocks. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- xen/arch/arm/mm.c | 5 ++- xen/arch/x86/mm.c | 5 ++- xen/common/grant_table.c | 100 ++---

[Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

. The loop is optimised to only iterate over the per-cpu data of active readers of the rwlock. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- xen/common/spinlock.c| 32 xen/include/asm-arm/percpu.h | 5 + xen/include/asm-x86/pe

[Xen-devel] [PATCH] x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

sanitize_e820_map to use the full size of the allocated E820 array. Signed-off-by: Malcolm Crossley <malcolm.cross...@citrix.com> --- arch/x86/xen/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index f5ef674..415a55f 100644 --- a/ar

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

On 11/09/15 12:11, Jan Beulich wrote: On 11.09.15 at 12:28, wrote: >> On 11/09/15 10:17, Jan Beulich wrote: >> On 11.09.15 at 02:59, wrote: If you want a formula I would do: #define MAX_SOCKETS 8 max_pfns =

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

On 11/09/15 10:17, Jan Beulich wrote: On 11.09.15 at 02:59, wrote: >> If you want a formula I would do: >> >> #define MAX_SOCKETS 8 >> >> max_pfns = pow(2,(MAX_SOCKETS - (max(nr_iommus(), MAX_SOCKETS * 64; >> >> Where nr_iommus would have to be somehow

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

On 09/09/15 15:50, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote: > On 09.09.15 at 16:20, wrote: >>> Perhaps the solution is remove the first printk(s) and just have them >>> once the operation has completed? That may fix

Re: [Xen-devel] [PATCH for 4.6] VT-d: Create IOMMU mappings for RMRR regions if shared EPT is not being used

Tiejun On 8/26/2015 11:49 PM, Malcolm Crossley wrote: Add RMRR 1:1 IOMMU mappings to IOMMU page tables if EPT page table are not being shared with the IOMMU. This is a regression in behaviour versus Xen 4.5. Signed-off-by: Malcolm Crossley malcolm.cross...@citrix.com --- xen/drivers

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote: On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote: On 8/25/2015 8:19 AM, Tamas K Lengyel wrote: Hi everyone, I saw some people passingly mention this on the list before but just in case it has been missed, my serial is also being

[Xen-devel] [PATCH for 4.6] VT-d: Create IOMMU mappings for RMRR regions if shared EPT is not being used

Add RMRR 1:1 IOMMU mappings to IOMMU page tables if EPT page table are not being shared with the IOMMU. This is a regression in behaviour versus Xen 4.5. Signed-off-by: Malcolm Crossley malcolm.cross...@citrix.com --- xen/drivers/passthrough/vtd/iommu.c | 23 --- 1 file

Re: [Xen-devel] Xen PV IOMMU interface draft C

On 29/06/15 15:52, Ian Campbell wrote: On Mon, 2015-06-29 at 10:40 -0400, Konrad Rzeszutek Wilk wrote: On Fri, Jun 26, 2015 at 12:03:44PM +0100, Ian Campbell wrote: +ARM devs. On Fri, 2015-06-26 at 11:23 +0100, Malcolm Crossley wrote: Hi All, I had a chat with Malcolm about

[Xen-devel] Xen PV IOMMU interface draft C

please provide feedback on any major design problems/concerns. The pandoc markdown format of the document is provided below to allow for easier inline comments: % Xen PV IOMMU interface % Malcolm Crossley malcolm.cross...@citrix.com Paul Durrant paul.durr...@citrix.com % Draft C Introduction

Re: [Xen-devel] [PATCH v2] libxl: Add AHCI support for upstream qemu

On 25/06/15 12:15, Fabio Fantoni wrote: Il 25/06/2015 12:21, Ian Campbell ha scritto: On Tue, 2015-06-23 at 11:15 +0200, Fabio Fantoni wrote: Usage: ahci=0|1 (default=0) I think a global rather than per disk option is OK (I can't think why a user would want to mix and match) but maybe we

Re: [Xen-devel] [RFC] Xen PV IOMMU interface draft B

On 16/06/15 14:19, Jan Beulich wrote: On 12.06.15 at 18:43, malcolm.cross...@citrix.com wrote: IOMMUOP_query_caps -- This subop queries the runtime capabilities of the PV-IOMMU interface for the specific called domain. This subop uses `struct pv_iommu_op` directly.

[Xen-devel] [RFC] Xen PV IOMMU interface draft B

Address mapping/lookup for Mediated pass-through emulators. The pandoc markdown format of the document is provided below to allow for easier inline comments: % Xen PV IOMMU interface % Malcolm Crossley malcolm.cross...@citrix.com Paul Durrant paul.durr...@citrix.com % Draft B Introduction

Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register

On 08/06/15 08:42, Jan Beulich wrote: On 07.06.15 at 08:23, m...@redhat.com wrote: On Mon, Apr 20, 2015 at 04:32:12PM +0200, Michael S. Tsirkin wrote: On Mon, Apr 20, 2015 at 03:08:09PM +0100, Jan Beulich wrote: On 20.04.15 at 15:43, m...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:51:06PM

Re: [Xen-devel] [PATCH] libxl: Don't insert PCI device into xenstore for HVM guests

On 01/06/15 18:55, Konrad Rzeszutek Wilk wrote: On Mon, Jun 01, 2015 at 05:03:14PM +0100, Malcolm Crossley wrote: On 01/06/15 16:43, Ross Lagerwall wrote: On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote: On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote: When doing

Re: [Xen-devel] [PATCH] libxl: Don't insert PCI device into xenstore for HVM guests

On 02/06/15 15:34, Konrad Rzeszutek Wilk wrote: On Tue, Jun 02, 2015 at 11:06:26AM +0100, Malcolm Crossley wrote: On 01/06/15 18:55, Konrad Rzeszutek Wilk wrote: On Mon, Jun 01, 2015 at 05:03:14PM +0100, Malcolm Crossley wrote: On 01/06/15 16:43, Ross Lagerwall wrote: On 06/01/2015 04:26 PM

Re: [Xen-devel] [PATCHv7 3/3] gnttab: use per-VCPU maptrack free lists

On 30/04/15 16:12, Tim Deegan wrote: At 14:28 +0100 on 30 Apr (1430404125), David Vrabel wrote: From: Malcolm Crossley malcolm.cross...@citrix.com Performance analysis of aggregate network throughput with many VMs shows that performance is signficantly limited by contention on the maptrack

Re: [Xen-devel] [PATCHv6 5/5] gnttab: use per-VCPU maptrack free lists

On 23/04/15 17:11, Jan Beulich wrote: On 22.04.15 at 18:00, david.vra...@citrix.com wrote: static inline int get_maptrack_handle( struct grant_table *lgt) { +struct vcpu *v = current; int i; grant_handle_thandle; struct

Re: [Xen-devel] [PATCHv6 5/5] gnttab: use per-VCPU maptrack free lists

On 24/04/15 10:50, Jan Beulich wrote: On 24.04.15 at 11:09, malcolm.cross...@citrix.com wrote: On 23/04/15 17:11, Jan Beulich wrote: On 22.04.15 at 18:00, david.vra...@citrix.com wrote: --- a/xen/include/xen/grant_table.h +++ b/xen/include/xen/grant_table.h @@ -60,6 +60,8 @@ struct

Re: [Xen-devel] [PATCH RFC] tcp: Allow sk_wmem_alloc to exceed sysctl_tcp_limit_output_bytes

On 13/04/15 15:05, Eric Dumazet wrote: On Mon, 2015-04-13 at 14:46 +0100, David Vrabel wrote: And the proof-of-concept patch for idea (b) I used was: @@ -552,6 +552,8 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) goto drop; } +

Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct

On 19/02/15 11:08, Roger Pau Monné wrote: El 19/02/15 a les 3.05, Bob Liu ha escrit: On 02/19/2015 02:08 AM, Felipe Franciosi wrote: -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: 18 February 2015 17:38 To: Roger Pau Monne Cc: Bob Liu;

Re: [Xen-devel] serious performance regression in Xen 4.2.4 and 4.2.5

On 19/02/15 11:08, Andreas Kinzler wrote: Hello Xen developers, since we use Xen for our production systems, I run many tests on Xen (stability/performance). One test now uncovered a serious performance regression when updating from Xen 4.2.3 to 4.2.x (with x=4). To reproduce run a domU

[Xen-devel] [PATCH] [XEN-4.2] hvmloader: Workaround uncached P2M mappings being created when relocating RAM

. This patch sets the default MTRR to be write back before relocating the RAM and restores the default MTRR after relocating the RAM. The patch was designed to be be minimally invasive so it could be backported easily. Signed-off-by: Malcolm Crossley malcolm.cross...@citrix.com diff -r

Re: [Xen-devel] [PATCH] [XEN-4.2] hvmloader: Workaround uncached P2M mappings being created when relocating RAM

On 19/02/15 13:01, Malcolm Crossley wrote: Upstream commit 1c84d046735102e02d2df454ab07f14ac51f235d (XSA-60 fix) Stopped tracking of setting/unsetting of uncached mode in an HVM guest. (This was later fixed by the EPT misconfig changes in Xen 4.5.) This issue affects any Xen with XSA-60 fixes

Re: [Xen-devel] [PATCH] [XEN-4.2] hvmloader: Workaround uncached P2M mappings being created when relocating RAM

On 19/02/15 14:28, Jan Beulich wrote: On 19.02.15 at 14:01, malcolm.cross...@citrix.com wrote: Upstream commit 1c84d046735102e02d2df454ab07f14ac51f235d (XSA-60 fix) Stopped tracking of setting/unsetting of uncached mode in an HVM guest. (This was later fixed by the EPT misconfig changes in Xen

Re: [Xen-devel] serious performance regression in Xen 4.2.4 and 4.2.5

On 19/02/15 14:21, Jan Beulich wrote: On 19.02.15 at 14:08, malcolm.cross...@citrix.com wrote: On 19/02/15 11:08, Andreas Kinzler wrote: Hello Xen developers, since we use Xen for our production systems, I run many tests on Xen (stability/performance). One test now uncovered a serious

Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

On 10/12/14 09:51, Tian, Kevin wrote: From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Wednesday, December 10, 2014 5:17 PM On 10.12.14 at 09:47, kevin.t...@intel.com wrote: two translation paths in assigned case: 1. [direct CPU access from VM], with partitioned PCI aperture resource,

Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

On 09/12/14 11:23, Jan Beulich wrote: On 09.12.14 at 12:17, paul.durr...@citrix.com wrote: I think we want be able to avoid setting up a PTE in the MMU since it's not needed in most (or perhaps all?) cases. With shared page tables, there's no way to do one without the other. Interestingly

Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64 addresses are bogus)

On 12/11/14 09:24, Jan Beulich wrote: On 12.11.14 at 02:37, konrad.w...@oracle.com wrote: When we PCI insert an device, the BARs are not set at all - and hence the Linux kernel is the one that tries to set the BARs in. The reason it cannot fit the device in the MMIO region is due to the _CRS

Re: [Xen-devel] PCI passthrough (pci-attach) to HVM guests bug (BAR64 addresses are bogus)

On 12/11/14 10:11, Jan Beulich wrote: On 12.11.14 at 11:01, malcolm.cross...@citrix.com wrote: As for the CRS regions: These typically describe the BIOS set limits in hardware configuration for the MMIO hole itself. On single socket systems anything which isn't RAM or another predefined region