On 10/03/16 20:48, Tamas K Lengyel wrote:
>
>
> On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap <mailto:george.dun...@citrix.com>> wrote:
>
> On 08/03/16 15:30, Malcolm Crossley wrote:
> > Nested hap code assumed implict bitmask semantics of the p2m_acce
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
---
xen/arch/x86/mm/hap/nested_hap.c | 2 +-
xen/include/xen/p2m-common.h
On 23/02/16 16:17, Jan Beulich wrote:
>>>> On 10.02.16 at 11:09, wrote:
>> % Xen PV IOMMU interface
>> % Malcolm Crossley <>
>> Paul Durrant <>
>> % Draft D
>>
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
> --
>
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
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
--
Cc: jbeul...@suse.com
Cc: k...@xen.org
Cc: t...@xen.org
Cc: andrew.coop...@citrix.com
Cc: xen-devel@lists.xen.org
---
xen/common
: Malcolm Crossley
--
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 | 100 ++
xen/include/asm-x86/m2b.h
Function does not need to handle shared EPT use of IOMMU as core code
already handles this.
Signed-off-by: Malcolm Crossley
--
Cc: kevin.t...@intel.com
Cc: feng...@intel.com
Cc: xen-devel@lists.xen.org
---
xen/drivers/passthrough/vtd/iommu.c | 31 +++
xen/drivers
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
--
Cc: k...@xen.org
Cc: jbeul...@suse.com
Cc
Signed-off-by: Malcolm Crossley
--
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| 2 ++
xen/common/Makefile
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
--
Cc: jbeul...@suse.com
Cc: xen-devel@lists.xen.org
---
xen/drivers/passthrough/iommu.c | 21 +
xen/include
interface which is mandated by the B2M interface itself.
Signed-off-by: Malcolm Crossley
--
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/common/pv_iommu.c | 269
% Xen PV IOMMU interface
% Malcolm Crossley <>
Paul Durrant <>
% Draft D
Introduction
Revision History
Version Date
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:
>>>> -
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
Move 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
nd to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley
Acked-by: Ian Campbell
--
Changes since v5:
- None
Changes since v4:
- Rename grant table rwlock wrappers and use grant table pointer as argument
Changes since v3:
- None
Changes sin
used with interrupts disabled.
Signed-off-by: Malcolm Crossley
--
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 stray hard tabs
- Added owner
they take an altp2m read lock
simultaneously with the main p2m lock.
Signed-off-by: Malcolm Crossley
Reviewed-by: George Dunlap
--
Changes since v5:
- None
Changes since v4:
- None
Changes since v3:
- None
Changes since v2
- Updated local percpu rwlock initialisation
---
xen/arch/x86/mm/mm-lo
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 from the
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
---
tools/misc/xenpm.c | 37
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
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
---
tools/misc/xenpm.c | 42
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 }
>&
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
they take an altp2m read lock
simultaneously with the main p2m lock.
Signed-off-by: Malcolm Crossley
--
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/arch/x86/mm/p2m.c
used with interrupts disabled.
Signed-off-by: Malcolm Crossley
--
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 field to percpu_rwlock_t for debug builds.
nd to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley
--
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 wrappers for taking percpu r
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 infrastructure
grant_table: convert grant
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/clearin
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
nd to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley
--
Changes since v2:
- Switched to using wrappers for taking percpu rwlock
- Added percpu structure pointer to percpu rwlock initialisation
- Added comment on removal of ASSERTS for grant
ercpu 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 rwlock to percpu rwlock
p2m: convert p2m rwlock to percpu rwlock
xen/arch/arm/mm.c
used with interrupts disabled.
Signed-off-by: Malcolm Crossley
--
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 which verify the correct g
they take an altp2m read lock
simultaneously with the main p2m lock.
Signed-off-by: Malcolm Crossley
--
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/asm-x86/mm.h | 2 +-
3 files ch
used with interrupts disabled.
Signed-off-by: Malcolm Crossley
--
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 instead of global
- Created sep
they take an altp2m read lock
simultaneously with the main p2m lock.
Signed-off-by: Malcolm Crossley
--
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/asm-x86/mm.h | 2 +-
3 files ch
nd to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley
--
Changes since v2:
- Switched to using wrappers for taking percpu rwlock
- Added percpu structure pointer to percpu rwlock initialisation
- Added comment on removal of ASSERTS for grant
vised 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/
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 +++-
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(-)
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 causes substantially
>> worse per
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:
>> --- a/xen/drivers/passthrough/vtd/quirks.c
>> +++ b/xen
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
>> e)
{
struct active_grant_entry *act;
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(&t->lock));
>
> Even if not covering all cases, I don't thin
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);
>> -write_lock(&l->loc
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
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 way the alive kernel
used with interrupts disabled.
Signed-off-by: Malcolm Crossley
--
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_rwlock_t type and added macr
nd to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley
--
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 table rwlock_t usage site
---
xen
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 bounci
they take an altp2m read lock
simultaneously with the main p2m lock.
Signed-off-by: Malcolm Crossley
---
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 deletions(-)
diff --git a/xen/arch/x
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
@@ -178,6 +178,10 @@ struct act
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
overhead
by only setting/clearing a per-cpu variable for usin
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 avoids locked compare swap opera
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:
>>>>&g
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, wrote:
>>>> On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote:
>>>>&
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
>>> object is a pointer to an 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 Beulich wrote:
> On 03.11.15 at 18:58, wrote:
>>>
> (XEN) Panic on CPU 0:
> (XEN) Assertion 'rw_is_locked(&t->lock)' failed at grant_table.c:215
> (XEN)
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)
>
>
> Thanks for your help.
>
>
ction.
The loop is optimised to only iterate over the per-cpu data of active readers
of the rwlock.
Signed-off-by: Malcolm Crossley
---
xen/common/spinlock.c| 32
xen/include/asm-arm/percpu.h | 5 +
xen/include/asm-x86/percpu.h | 6 ++
xen/includ
nd to confirm the overhead was dramatically reduced by the percpu rwlocks.
Signed-off-by: Malcolm Crossley
---
xen/arch/arm/mm.c | 5 ++-
xen/arch/x86/mm.c | 5 ++-
xen/common/grant_table.c | 100 ++
xen/include/xen/grant_table.h
sanitize_e820_map to use the full size of the allocated E820
array.
Signed-off-by: Malcolm Crossley
---
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/arch/x86/xen/setup.c
+++ b/arch/x86
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 = pow(2,(MAX_SOCKETS - (max(nr_iommus(), MAX_SOCKETS
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 implemented, ditto for pow.
>>
>> T
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 the outstanding tasklet
>>>
sion.
Malcolm
>
> Thanks
> 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.
>
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
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
---
xen/drivers/passthrough/vtd/iommu.c | 23 ---
1 file changed, 20 insertions(+), 3
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:
>>&g
version so 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 <>
Paul Durrant <>
% Draft C
Introduction
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
On 17/06/15 13:48, Yu, Zhang wrote:
> Hi Malcolm,
>
> Thank you very much for accommodate our XenGT requirement in your
> design. Following are some XenGT related questions. :)
>
> On 6/13/2015 12:43 AM, Malcolm Crossley wrote:
>> Hi All,
>&g
On 16/06/15 14:19, Jan Beulich wrote:
On 12.06.15 at 18:43, 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.
>
> "calling domain
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 <>
Paul Durrant <>
% Draft B
Introduction
Revi
On 08/06/15 08:42, Jan Beulich wrote:
On 07.06.15 at 08:23, 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, wrote:
> On Mon, Apr 13, 2015 at 01:51:06PM +0100, Jan
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 L
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, Ro
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 passthrough of a PCI device for an HVM guest, don't insert
>>> the device into xenstore, otherwise pciback attempts to us
On 30/04/15 16:12, Tim Deegan wrote:
> At 14:28 +0100 on 30 Apr (1430404125), David Vrabel wrote:
>> From: Malcolm Crossley
>>
>> Performance analysis of aggregate network throughput with many VMs
>> shows that performance is signficantly limited by contention o
On 24/04/15 10:50, Jan Beulich wrote:
On 24.04.15 at 11:09, wrote:
>> On 23/04/15 17:11, Jan Beulich wrote:
>> On 22.04.15 at 18:00, wrote:
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -60,6 +60,8 @@ struct grant_mapping {
u32 r
On 23/04/15 17:11, Jan Beulich wrote:
On 22.04.15 at 18:00, wrote:
>> static inline int
>> get_maptrack_handle(
>> struct grant_table *lgt)
>> {
>> +struct vcpu *v = current;
>> int i;
>> grant_handle_thandle;
>> struct grant_mappi
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;
>>>
On 19/02/15 14:28, Jan Beulich wrote:
On 19.02.15 at 14:01, 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.)
>>
>> On ho
On 19/02/15 14:21, Jan Beulich wrote:
On 19.02.15 at 14:08, 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 performance
>>>
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
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 do
s uncached.
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
diff -r dfb21287aac1 -r 4c9ba9c0
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
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, wrote:
>>> two translation paths in assigned case:
>>>
>>> 1. [direct CPU access from VM], with partitioned PCI aperture
>>> resource,
On 09/12/14 11:23, Jan Beulich wrote:
On 09.12.14 at 12:17, 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 the IOMMU in
On 09/12/14 10:37, Yu, Zhang wrote:
>
>
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is
>> using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
>> you really need raw mfn values?
> Thanks for your quick response,
On 12/11/14 10:11, Jan Beulich wrote:
On 12.11.14 at 11:01, 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 decodes to
>> MMI
On 12/11/14 09:24, Jan Beulich wrote:
On 12.11.14 at 02:37, 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 only having
94 matches
Mail list logo
