On 2/5/2016 1:12 AM, George Dunlap wrote:
On 04/02/16 14:08, Jan Beulich wrote:
On 04.02.16 at 14:33, wrote:
Jan Beulich writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram_ranges."):
On 04.02.16 at 10:38, wrote:
So another question is, if value of this limit rea
On 2/5/2016 12:18 PM, Tian, Kevin wrote:
From: George Dunlap [mailto:george.dun...@citrix.com]
Sent: Friday, February 05, 2016 1:12 AM
On 04/02/16 14:08, Jan Beulich wrote:
On 04.02.16 at 14:33, wrote:
Jan Beulich writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram
Shuai, thank you very much for helping me push these patches!
And sorry for the delay due to my illness.
Now I'm back and will pick this up. :)
B.R.
Yu
On 12/15/2015 10:05 AM, Shuai Ruan wrote:
From: Yu Zhang ng the
XenGT leverages ioreq server to track and forward the accesses to
GP
On 12/21/2015 10:38 PM, Jan Beulich wrote:
On 15.12.15 at 03:05, wrote:
This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet
On 12/21/2015 10:45 PM, Jan Beulich wrote:
On 15.12.15 at 03:05, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -935,6 +935,9 @@ static void hvm_ioreq_server_free_rangesets(struct
hvm_ioreq_server *s,
rangeset_destroy(s->range[i]);
}
+static const char *io_r
On 1/6/2016 4:59 PM, Jan Beulich wrote:
On 31.12.15 at 10:33, wrote:
On 12/21/2015 10:45 PM, Jan Beulich wrote:
On 15.12.15 at 03:05, wrote:
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -48,8 +48,8 @@ struct hvm_ioreq_vcpu {
bool_t pendi
On 1/6/2016 5:58 PM, Jan Beulich wrote:
On 06.01.16 at 10:44, wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 06 January 2016 08:59
To: Zhang Yu
Cc: Andrew Cooper; Paul Durrant; Wei Liu; Ian Jackson; Stefano Stabellini;
Kevin Tian; zhiyuan...@intel.com;
o new hypercall
defined, only a new type is introduced.
Acked-by: Wei Liu
Acked-by: Ian Campbell
Reviewed-by: Kevin Tian
Signed-off-by: Shuai Ruan
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31
tools/libxc/xc_domain.c
nges - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zhang (3):
Refactor rangeset structure for better performance.
Differentiate IO/mem resources tracked by ioreq server
tools: introduce parameter max_ranges.
docs/man/xl.cfg.pod.5| 17 +
to
supposed to know the specific scenarios that necessitate this
configuration.
Signed-off-by: Yu Zhang
---
docs/man/xl.cfg.pod.5 | 17 +
tools/libxl/libxl_dom.c | 3 +++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 4
xen/arch
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Reviewed-by: Paul Durrant
Signed-off-by: Shuai Ruan
Signed-off-by: Yu Zhang
On 1/20/2016 11:14 AM, Tian, Kevin wrote:
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: Tuesday, January 19, 2016 11:19 PM
On Tue, 2016-01-19 at 15:04 +, Wei Liu wrote:
This patch doesn't seem to have been CCd to the tools maintainers, adding
Ian too, I think everyone else was
On 1/20/2016 11:58 AM, Tian, Kevin wrote:
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Wednesday, January 20, 2016 11:33 AM
As a feature this write-protection has nothing to be GPU virtualization
specific.
In the future the same mediated pass-through idea used in XenGT may be
On 1/20/2016 6:18 PM, Paul Durrant wrote:
-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: 20 January 2016 10:16
To: Kevin Tian; Yu, Zhang; Wei Liu; Paul Durrant
Cc: Keir (Xen.org); jbeul...@suse.com; Andrew Cooper; xen-
de...@lists.xen.org; Lv, Zhiyuan
o new hypercall
defined, only a new type is introduced.
Acked-by: Wei Liu
Acked-by: Ian Campbell
Reviewed-by: Kevin Tian
Reviewed-by: Paul Durrant
Signed-off-by: Shuai Ruan
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31
tools/libxc/xc_dom
> Take Paul Durrant's comments:
a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
b> Keep original routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Reviewed-by: Paul Durrant
Signed-off-by: Shuai Ruan
Signed-off-by: Yu Zhang
intel broadwell platforms,
the number of page tables concerned will be several thousand(normally
in this case, 8192 could be a big enough value). Users who set this
item explicitly are supposed to know the specific scenarios that
necessitate this configuration.
Signed-off-by: Yu Zhang
---
docs
Thank you, Jan.
On 1/22/2016 4:01 PM, Jan Beulich wrote:
On 22.01.16 at 04:20, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -940,6 +940,10 @@ static int hvm_ioreq_server_alloc_rangesets(struct
hvm_ioreq_server *s,
{
unsigned int i;
int rc;
+unsigned int
On 1/22/2016 7:43 PM, Jan Beulich wrote:
On 22.01.16 at 04:20, wrote:
@@ -2601,6 +2605,16 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct
domain *d,
type = (p->type == IOREQ_TYPE_PIO) ?
HVMOP_IO_RANGE_PORT : HVMOP_IO_RANGE_MEMORY;
addr = p->ad
On 1/26/2016 7:00 PM, Jan Beulich wrote:
On 26.01.16 at 08:32, wrote:
On 1/22/2016 4:01 PM, Jan Beulich wrote:
On 22.01.16 at 04:20, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -940,6 +940,10 @@ static int hvm_ioreq_server_alloc_rangesets(struct
hvm_ioreq_server *s,
On 1/26/2016 7:24 PM, Jan Beulich wrote:
On 26.01.16 at 08:59, wrote:
On 1/22/2016 7:43 PM, Jan Beulich wrote:
On 22.01.16 at 04:20, wrote:
@@ -2601,6 +2605,16 @@ struct hvm_ioreq_server
*hvm_select_ioreq_server(struct domain *d,
type = (p->type == IOREQ_TYPE_PIO) ?
On 1/26/2016 7:16 PM, David Vrabel wrote:
On 22/01/16 03:20, Yu Zhang wrote:
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -962,6 +962,24 @@ FIFO-based event channel ABI support up to 131,071 event
channels.
Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
On 1/27/2016 6:27 PM, Jan Beulich wrote:
On 27.01.16 at 08:01, wrote:
On 1/26/2016 7:00 PM, Jan Beulich wrote:
On 26.01.16 at 08:32, wrote:
On 1/22/2016 4:01 PM, Jan Beulich wrote:
On 22.01.16 at 04:20, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -940,6 +940,1
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the default value:
You are right. :) For XenGT, MAX_NR_IO_RANGES may only work under
limited conditions. Having it default to zero means XenGT users must
manually configure this option. Since we have plans to pus
On 1/27/2016 11:12 PM, Jan Beulich wrote:
On 27.01.16 at 15:56, wrote:
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the truncation issue:
I do not quite follow. Will this hurt if the value configured does
not exceed 4G? What about a type cast?
A typec
On 1/27/2016 11:58 PM, Jan Beulich wrote:
On 27.01.16 at 16:23, wrote:
On 1/27/2016 11:12 PM, Jan Beulich wrote:
On 27.01.16 at 15:56, wrote:
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the truncation issue:
I do not quite follow. Will this hurt
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Reviewed-by: Paul Durrant
Signed-off-by: Shuai Ruan
Signed-off-by: Yu Zhang
for XenGT, future cpu platforms which provide even more per-process
graphic translation tables.
Signed-off-by: Yu Zhang
---
docs/man/xl.cfg.pod.5 | 26 ++
tools/libxl/libxl.h | 5 +
tools/libxl/libxl_dom.c | 3 +++
tools/libxl/libxl_types.idl
o new hypercall
defined, only a new type is introduced.
Acked-by: Wei Liu
Acked-by: Ian Campbell
Reviewed-by: Kevin Tian
Reviewed-by: Paul Durrant
Signed-off-by: Shuai Ruan
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_dom
l routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zhang (3):
Refactor rangeset structure for better performance.
Differentiate IO/mem resources tracked by ioreq server
tools: introduce pa
]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 39 +++---
tools/libxc/xc_domain.c
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang
---
xen/common/rangeset.c | 82
ments:
a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
b> Keep original routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq serve
On 8/10/2015 4:26 PM, Wei Liu wrote:
On Mon, Aug 10, 2015 at 11:33:40AM +0800, Yu Zhang wrote:
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected
On 8/10/2015 6:57 PM, Paul Durrant wrote:
-Original Message-
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: 10 August 2015 11:56
To: Paul Durrant; Wei Liu; Yu Zhang
Cc: xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian Campbell;
Keir (Xen.org); jbeul
On 8/11/2015 4:25 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 11 August 2015 08:57
To: Paul Durrant; Andrew Cooper; Wei Liu
Cc: xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian Campbell;
Keir (Xen.org); jbeul
outine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zhang (2):
Differentiate IO/mem resources tracked by ioreq server
Refactor rangeset structure for better performance.
tools/libxc/include/xenc
]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_domain.c
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang
---
xen/common/rangeset.c | 82
On 8/13/2015 6:16 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 13 August 2015 11:06
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
On 8/13/2015 6:33 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 13 August 2015 11:06
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
Hi Paul,
On 8/13/2015 6:39 PM, Yu, Zhang wrote:
On 8/13/2015 6:16 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 13 August 2015 11:06
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano
Stabellini; Ian
Campbell; Wei Liu
On 8/14/2015 4:46 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 August 2015 08:41
To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew
mments:
a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
b> Keep original routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq ser
]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_domain.c
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang
---
xen/common/rangeset.c | 82
On 8/14/2015 9:51 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 August 2015 13:03
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
On 8/18/2015 9:25 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 17 August 2015 22:34
To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew
;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zhang (3):
Remove identical relationship between ioreq type and rangeset type.
Differentiate IO/mem resources tracked by ioreq server
Refactor rangeset structure for better pe
]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_domain.c
This patch uses HVMOP_IO_RANGE_XXX values rather than the raw ioreq
type to select the ioreq server, therefore the identical relationship
between ioreq type and rangeset type is no longer necessary.
Signed-off-by: Yu Zhang
---
xen/arch/x86/hvm/hvm.c | 16 +++-
1 file changed, 7
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang
Reviewed-by: Paul Durrant
---
xen/common/rangeset.c | 82
On 8/20/2015 12:16 AM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 August 2015 02:16
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew
This patch uses HVMOP_IO_RANGE_XXX values rather than the raw ioreq
type to select the ioreq server, therefore the identical relationship
between ioreq type and rangeset type is no longer necessary.
Signed-off-by: Yu Zhang
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/hvm.c | 16
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang
Reviewed-by: Paul Durrant
---
xen/common/rangeset.c | 82
er in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31
tools/libxc/xc_domain.c | 61
xen/arch/x86/hvm/hvm.c
dump the ranges in ioreq server;
b> Keep original routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zhang (3):
Remove identical relationship between ioreq type and rangeset type.
Differentiate IO/
On 8/21/2015 2:35 PM, Tian, Kevin wrote:
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Friday, August 21, 2015 11:31 AM
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in
er in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang
---
tools/libxc/include/xenctrl.h| 31
tools/libxc/xc_domain.c | 61
xen/arch/x86/hvm/hvm.c
doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang
Reviewed-by: Paul Durrant
---
xen/common/rangeset.c | 82
a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
b> Keep original routine names for hvm ioreq server;
c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.
Yu Zh
This patch uses HVMOP_IO_RANGE_XXX values rather than the raw ioreq
type to select the ioreq server, therefore the identical relationship
between ioreq type and rangeset type is no longer necessary.
Signed-off-by: Yu Zhang
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/hvm.c | 16
On 8/25/2015 5:40 PM, Wei Liu wrote:
On Sun, Aug 23, 2015 at 05:33:17PM +0800, Yu Zhang wrote:
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected
On 8/28/2015 4:38 PM, Jan Beulich wrote:
On 28.08.15 at 05:11, wrote:
To other maintainers, do you have any question or suggestion?
I certainly intend to get to reviewing these patches, but my originally
huge backlog hasn't shrunk enough yet.
Jan
Thanks for your reply, Jan. And I fully
On 12/2/2014 7:40 PM, Tim Deegan wrote:
At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
On 12/1/2014 8:13 PM, Tim Deegan wrote:
At 11:17 + on 01 Dec (1417429027), Jan Beulich wrote:
On 01.12.14 at 11:30, wrote:
During this bit of archaeology I realised that either this new
On 12/4/2014 5:36 PM, Tim Deegan wrote:
Hi,
At 17:01 +0800 on 04 Dec (1417708878), Yu, Zhang wrote:
I just noticed that in __hvm_copy()/__hvm_clear(), the grant types are
handled before the p2m_ram_ro - will return HVMCOPY_unhandleable. So if
p2m_is_discard_write() is supposed to replace the
them.
- Address various comments from Jan.
Yu Zhang (2):
Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
add a new p2m type - p2m_mmio_write_dm
xen/arch/x86/hvm/hvm.c | 25 ++---
xen/arch/x86/mm/p2m-ept.c | 1 +
xen/arch/x86/mm/p2m-pt.c| 1 +
xen
From: Yu Zhang
Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
cla
From: Yu Zhang
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
checks, with only difference on final policy of emulation vs. drop.
For p2m_ram_ro
On 12/5/2014 12:04 AM, Tim Deegan wrote:
Hi,
At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most cond
From: Yu Zhang
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
checks, with only difference on final policy of emulation vs. drop.
For p2m_ram_ro
From: Yu Zhang
Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
cla
as a special mmio range instead
of ram;
- Move macros to c file since only this file is using them.
- Address various comments from Jan.
Yu Zhang (2):
Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
add a new p2m type - p2m_mmio_write_dm
xen/arch/x86/hvm/hvm.c
Hi Tim & Jan,
Thank you very much for your review.
And could you please also help me about how to get an ACK? I'm not
sure what's the next action I need to take. :-)
B.R.
Yu
On 12/6/2014 11:55 AM, Yu Zhang wrote:
XenGT (Intel Graphics Virtualization technology, please
Hi all,
As you can see, we are pushing our XenGT patches to the upstream. One
feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
device model.
Here we may have 2 similar solutions:
1> Paul told me(and thank you, Paul :)) that there used to be a
hypercall, XENMEM_tr
On 12/9/2014 4:31 PM, Jan Beulich wrote:
On 09.12.14 at 03:02, wrote:
Thank you very much for your review.
And could you please also help me about how to get an ACK? I'm not
sure what's the next action I need to take. :-)
I don't think you need to take any action at this point. The
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, Paul.
Well, not exactly for this case. :)
In Xen
From: Yu Zhang
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
checks, with only difference on final policy of emulation vs. drop.
For p2m_ram_ro
from p2m_ram_wp to p2m_mmio_write_dm.
This means that we treat the pages as a special mmio range instead
of ram;
- Move macros to c file since only this file is using them.
- Address various comments from Jan.
Yu Zhang (2):
Add a new p2m type class - P2M_DISCARD_WRITE_TYPES
add a new p2m
From: Yu Zhang
Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
cla
Hi Wei,
This is Zhang Yu from Intel graphic virtualization team. Previously
in Xen hackathon, Paul and I mentioned that there're several patch
series for XenGT that need to be tracked on Xen 4.6.
Here, I'd like to confirm with you about these patchsets:
1> 16-byte MMIO emulation fix – ow
Hi Wei,
Thanks for your reply.
On 5/4/2015 5:44 PM, Wei Liu wrote:
(Thanks for trimming the CC list before hand)
On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote:
Hi Wei,
Hello.
This is Zhang Yu from Intel graphic virtualization team. Previously in Xen
hackathon, Paul and I
Thank you, Wei.
On 5/5/2015 5:12 PM, Wei Liu wrote:
On Mon, May 04, 2015 at 08:51:56PM +0800, Yu, Zhang wrote:
Hi Wei,
Thanks for your reply.
On 5/4/2015 5:44 PM, Wei Liu wrote:
(Thanks for trimming the CC list before hand)
On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote:
Hi Wei
s means that we treat the pages as a special mmio range instead
of ram.
- Move macros to c file since only this file is using them.
- Address various comments from Jan.
Signed-off-by: Yu Zhang
Signed-off-by: Wei Ye
---
xen/arch/x86/hvm/hvm.c | 13 ++---
xen/arch/x
On 11/28/2014 5:57 PM, Jan Beulich wrote:
On 28.11.14 at 08:59, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2838,7 +2838,8 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
* to the mmio handler.
*/
if ( (p2mt == p2m_mmio_dm) ||
-
On 12/1/2014 8:13 PM, Tim Deegan wrote:
At 11:17 + on 01 Dec (1417429027), Jan Beulich wrote:
On 01.12.14 at 11:30, wrote:
At 09:32 + on 01 Dec (1417422746), Jan Beulich wrote:
On 01.12.14 at 09:49, wrote:
To my understanding, pages with p2m_ram_ro are not supposed to be
modified
On 12/1/2014 8:31 PM, Jan Beulich wrote:
On 01.12.14 at 13:13, wrote:
At 11:17 + on 01 Dec (1417429027), Jan Beulich wrote:
On 01.12.14 at 11:30, wrote:
At 09:32 + on 01 Dec (1417422746), Jan Beulich wrote:
On 01.12.14 at 09:49, wrote:
To my understanding, pages with p2m_ram_ro
On 12/2/2014 7:40 PM, Tim Deegan wrote:
At 15:38 +0800 on 02 Dec (1417531126), Yu, Zhang wrote:
On 12/1/2014 8:13 PM, Tim Deegan wrote:
At 11:17 + on 01 Dec (1417429027), Jan Beulich wrote:
On 01.12.14 at 11:30, wrote:
During this bit of archaeology I realised that either this new
301 - 389 of 389 matches
Mail list logo
