Hi George,
Thanks a lot for your thorough review. :)
On 3/22/2016 7:31 PM, George Dunlap wrote:
On Wed, Mar 16, 2016 at 12:21 PM, Yu Zhang wrote:
For clarity this patch breaks the code to set/get memory types out
of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type().
Also, for
On 3/22/2016 10:15 PM, George Dunlap wrote:
On 16/03/16 12:21, Yu Zhang wrote:
Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restricts
Thanks, Jan.
On 3/23/2016 5:22 PM, Jan Beulich wrote:
On 22.03.16 at 18:51, wrote:
From: George Dunlap [mailto:george.dun...@citrix.com]
Sent: 22 March 2016 17:27
There's not much documentation in the code about how this is expected to
be used.
For instance, having separate flags seems to imp
s with HAP enabled;
3> Code corrections according to George Dunlap's comments;
4> Comments added according to George Dunlap's comments.
Yu Zhang (3):
x86/ioreq server: Add new functions to get/set memory types.
x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
intentional functional change in this patch.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 284 +++--
1 file changed, 159 insertions(+), 125 deletions(-)
diff --git a/xen
.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc: Tim Deegan
---
xen/arch/x86/hvm/hvm.c | 10 +-
xen/arch/x86/mm/p2m-ept.c | 2 +-
xen/arch/x86/mm/p2m-pt.c
steps should be the backend driver
first claims its ownership of guest ram pages with p2m_ioreq_server
type, and then sets the memory type to p2m_ioreq_server for specified
guest ram pages.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Coope
Thanks, Tim.
On 4/4/2016 4:25 PM, Tim Deegan wrote:
At 18:53 +0800 on 31 Mar (1459450418), Yu Zhang wrote:
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
Thanks for your advices and good questions. :)
On 4/7/2016 1:13 AM, George Dunlap wrote:
On Thu, Mar 31, 2016 at 11:53 AM, Yu Zhang wrote:
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with
On 4/8/2016 9:33 PM, Andrew Cooper wrote:
On 31/03/16 11:53, Yu Zhang wrote:
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify
On 4/9/2016 6:28 AM, Jan Beulich wrote:
On 31.03.16 at 12:53, wrote:
+static int mem_write(const struct hvm_io_handler *handler,
+ uint64_t addr,
+ uint32_t size,
+ uint64_t data)
+{
+struct domain *currd = current->domain;
+
On 4/8/2016 7:01 PM, George Dunlap wrote:
On 08/04/16 11:10, Yu, Zhang wrote:
[snip]
BTW, I noticed your reply has not be CCed to mailing list, and I also
wonder if we should raise this last question in community?
Oops -- that was a mistake on my part. :-) I appreciate the
discretion
On 4/12/2016 12:31 AM, Jan Beulich wrote:
On 11.04.16 at 13:14, wrote:
On 4/9/2016 6:28 AM, Jan Beulich wrote:
On 31.03.16 at 12:53, wrote:
@@ -168,13 +226,72 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-
On 4/12/2016 11:08 PM, Jan Beulich wrote:
"Yu, Zhang" 04/12/16 11:47 AM >>>
On 4/12/2016 12:31 AM, Jan Beulich wrote:
On 11.04.16 at 13:14, wrote:
On 4/9/2016 6:28 AM, Jan Beulich wrote:
On 31.03.16 at 12:53, wrote:
+if ( s->id == id )
+
On 4/11/2016 7:15 PM, Yu, Zhang wrote:
On 4/8/2016 7:01 PM, George Dunlap wrote:
On 08/04/16 11:10, Yu, Zhang wrote:
[snip]
BTW, I noticed your reply has not be CCed to mailing list, and I also
wonder if we should raise this last question in community?
Oops -- that was a mistake on my part
On 4/18/2016 11:57 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 April 2016 11:45
To: George Dunlap; Paul Durrant; xen-devel@lists.xen.org
Cc: Jan Beulich; Kevin Tian; Andrew Cooper; Lv, Zhiyuan; Tim (Xen.org);
jun.nakaj
On 4/19/2016 12:50 PM, Tian, Kevin wrote:
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Thursday, April 14, 2016 5:57 PM
And with all three bits now possibly being clear, aren't we risking the
entries to be mis-treated as not-present ones?
Hah. You got me. Thanks! :)
On 4/19/2016 12:37 PM, Tian, Kevin wrote:
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Thursday, April 14, 2016 6:45 PM
On 4/11/2016 7:15 PM, Yu, Zhang wrote:
On 4/8/2016 7:01 PM, George Dunlap wrote:
On 08/04/16 11:10, Yu, Zhang wrote:
[snip]
BTW, I noticed your reply has
On 4/19/2016 4:46 PM, Paul Durrant wrote:
-Original Message-
From: Tian, Kevin [mailto:kevin.t...@intel.com]
Sent: 19 April 2016 05:51
To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun
Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen-devel@lists.xen.org;
Keir (Xen.org); Tim
On 4/19/2016 5:21 PM, Paul Durrant wrote:
-Original Message-
[snip]
Does any other maintainers have any suggestions?
Note that it is a requirement that an ioreq server be disabled before VM
suspend. That means ioreq server pages essentially have to go back to
ram_rw semantics.
On 4/19/2016 5:40 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 10:27
To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun
Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen-
de...@lists.xen.org
On 4/19/2016 6:01 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 10:49
To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun
Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen-
de...@lists.xen.org
On 4/19/2016 12:58 AM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
Beulich
Sent: 18 April 2016 17:47
To: Paul Durrant
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org
On 4/19/2016 6:05 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 10:44
To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org
Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan;
jun.nakaj
On 4/19/2016 7:15 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 12:03
To: Paul Durrant; Jan Beulich; Wei Liu
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org
On 4/19/2016 7:47 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 12:18
To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org
Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan;
jun.nakaj
maintainers,
Thanks for the discussion and sorry for my delayed reply...
On 4/21/2016 12:52 AM, Jan Beulich wrote:
George Dunlap 04/20/16 6:30 PM >>>
On Wed, Apr 20, 2016 at 4:02 PM, George Dunlap wrote:
On 19/04/16 12:02, Yu, Zhang wrote:
So I suppose the only place we need c
t 4:02 PM, George Dunlap
wrote:
On 19/04/16 12:02, Yu, Zhang wrote:
So I suppose the only place we need change for this patch is
for hvmmem_type_t, which should be defined like this?
typedef enum {
HVMMEM_ram_rw, /* Normal read/write guest RAM */
HVMMEM_ram_ro,
Thank you, George.
On 4/20/2016 10:50 PM, George Dunlap wrote:
On Tue, Apr 19, 2016 at 12:59 PM, Yu, Zhang wrote:
So what about the VM suspend case you mentioned above? Will that trigger
the unmapping of ioreq server? Could the device model also take the role
to change the p2m type back in
On 4/21/2016 12:30 AM, Paul Durrant wrote:
-Original Message-
From: George Dunlap
Sent: 20 April 2016 16:38
To: Paul Durrant
Cc: Yu, Zhang; Kevin Tian; jun.nakaj...@intel.com; Andrew Cooper; Tim
(Xen.org); xen-devel@lists.xen.org; Lv, Zhiyuan; Jan Beulich
Subject: Re: [Xen-devel
On 4/21/2016 9:31 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 21 April 2016 13:25
To: George Dunlap; Paul Durrant; Jan Beulich; Wei Liu
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); xen-
de...@lists.xen.org
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Tim Deegan
---
xen/arch/x86/hvm/emulate.c | 32 --
xen/arch/x86/hvm/hvm.c
mem type
interfaces;
- Add George's Reviewed-by and Acked-by from Tim & Andrew.
changes in v2:
- According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
Acked-by: And
intentional functional change in this patch.
changes in v3:
- Add Andrew's Acked-by and George's Reviewed-by.
changes in v2:
- According to George Dunlap's comments, follow the "set rc /
do something / goto out" pattern in hvmop_get_mem_type().
Signed-off-by: Paul Durrant
. Now this new
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly.
Yu Zhang (3):
x86/ioreq server
On 4/25/2016 10:01 PM, Paul Durrant wrote:
-Original Message-
From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
George Dunlap
Sent: 25 April 2016 14:39
To: Yu Zhang
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Paul
On 4/25/2016 11:29 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 25 April 2016 16:22
To: Paul Durrant; George Dunlap
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan
On 4/25/2016 11:38 PM, Jan Beulich wrote:
On 25.04.16 at 17:29, wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 25 April 2016 16:22
To: Paul Durrant; George Dunlap
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew
On 4/26/2016 12:15 AM, George Dunlap wrote:
On 25/04/16 16:53, Yu, Zhang wrote:
On 4/25/2016 11:38 PM, Jan Beulich wrote:
On 25.04.16 at 17:29, wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 25 April 2016 16:22
To: Paul Durrant; George Dunlap
On 4/26/2016 1:01 AM, Paul Durrant wrote:
-Original Message-
From: George Dunlap [mailto:george.dun...@citrix.com]
Sent: 25 April 2016 17:16
To: Yu, Zhang; Jan Beulich; Paul Durrant
Cc: Andrew Cooper; Wei Liu; Jun Nakajima; Kevin Tian; Zhiyuan Lv; xen-
de...@lists.xen.org; Keir
On 4/26/2016 6:53 PM, Wei Liu wrote:
Hi Yu
On Mon, Apr 25, 2016 at 06:35:39PM +0800, Yu Zhang wrote:
For clarity this patch breaks the code to set/get memory types out
of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type().
Also, for clarity, checks for whether a memory type
On 4/27/2016 10:42 PM, Paul Durrant wrote:
-Original Message-
From: George Dunlap
Sent: 27 April 2016 15:13
To: Paul Durrant
Cc: Yu, Zhang; Jan Beulich; Kevin Tian; Wei Liu; Andrew Cooper; Tim
(Xen.org); xen-devel@lists.xen.org; Zhiyuan Lv; Jun Nakajima; Keir (Xen.org)
Subject: Re
On 4/28/2016 3:14 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 28 April 2016 03:47
To: Paul Durrant; George Dunlap
Cc: Kevin Tian; Wei Liu; Jun Nakajima; Andrew Cooper; Tim (Xen.org); xen-
de...@lists.xen.org; Zhiyuan Lv; Jan
- HVMMEM_mmio_write_dm.
New approaches to write protect guest ram pages will be provided in
future patches.
Signed-off-by: Yu Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Paul Durrant
Cc: Wei Liu
---
xen/arch/x86/hvm/hvm.c | 7 +++
xen/include/public/hvm
Sorry, please ignore this patch due to incorrect header.
Will send another one.
On 4/28/2016 4:21 PM, Yu Zhang wrote:
HVMMEM_mmio_write_dm is removed for new xen interface versions, and
is replaced with type HVMMEM_unused. Attempts to set a page to this
type will return -EINVAL in xen after
- HVMMEM_mmio_write_dm.
New approaches to write protect guest ram pages will be provided in
future patches.
Signed-off-by: Yu Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Paul Durrant
Cc: Wei Liu
---
xen/arch/x86/hvm/hvm.c | 7 +++
xen/include/public/hvm
Thanks Jan. And I admire your rigorous thought. :)
On 4/28/2016 6:57 PM, Jan Beulich wrote:
On 28.04.16 at 12:42, wrote:
On 28/04/16 11:22, Jan Beulich wrote:
On 28.04.16 at 10:29, wrote:
@@ -5529,7 +5527,7 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
On 4/28/2016 7:52 PM, Jan Beulich wrote:
On 28.04.16 at 13:40, wrote:
On 4/28/2016 6:57 PM, Jan Beulich wrote:
On 28.04.16 at 12:42, wrote:
That might have been slightly cleaner; but we're going to have to put it
back as soon as the development window opens anyway, so I don't really
see th
On 4/28/2016 8:06 PM, Wei Liu wrote:
On Thu, Apr 28, 2016 at 01:00:57PM +0100, Andrew Cooper wrote:
On 28/04/16 12:59, Wei Liu wrote:
On Thu, Apr 28, 2016 at 07:40:45PM +0800, Yu, Zhang wrote:
Thanks Jan. And I admire your rigorous thought. :)
On 4/28/2016 6:57 PM, Jan Beulich wrote:
On
On 4/28/2016 8:39 PM, Jan Beulich wrote:
On 28.04.16 at 14:12, wrote:
I'm still confused why do we need this, especially at such critical
moment. IIUC HVMMEM type is used to get/set mem type, why would someone
define a HVMMEM type but not use it here?
Who knows. And as said - the patch can
.
Patches following up will add the related HVMOP handling code which
map/unmap type p2m_ioreq_server to/from an ioreq server.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
Acked-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Kevin Tian
Cc
. Now this new
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly.
Yu Zhang (3):
x86/ioreq server
both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
are only supported for HVMs with HAP enabled.
Also note that only after one ioreq server claims its ownership
of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
be allowed.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
-
intentional functional change in this patch.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Reviewed-by: George Dunlap
Acked-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
changes in v4:
- According to Wei Liu's comments, change the format of the commit
message.
changes
Hi Jan,
I saw that commit 8c14e5f provides emulations for UMIP affected
instructions. But realized that xen does not have logic to expose UMIP
feature to guests - you have sent out one in
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html
to emulate the cpuid leaf, b
On 4/19/2017 5:18 PM, Jan Beulich wrote:
On 19.04.17 at 10:48, wrote:
I saw that commit 8c14e5f provides emulations for UMIP affected
instructions. But realized that xen does not have logic to expose UMIP
feature to guests - you have sent out one in
https://lists.xenproject.org/archives/h
On 4/19/2017 5:59 PM, Andrew Cooper wrote:
On 19/04/17 10:48, Yu Zhang wrote:
On 4/19/2017 5:18 PM, Jan Beulich wrote:
On 19.04.17 at 10:48, wrote:
I saw that commit 8c14e5f provides emulations for UMIP affected
instructions. But realized that xen does not have logic to expose UMIP
On 4/19/2017 7:19 PM, Jan Beulich wrote:
On 19.04.17 at 11:48, wrote:
On 4/19/2017 5:18 PM, Jan Beulich wrote:
On 19.04.17 at 10:48, wrote:
I saw that commit 8c14e5f provides emulations for UMIP affected
instructions. But realized that xen does not have logic to expose UMIP
feature to
On 4/19/2017 9:34 PM, Jan Beulich wrote:
On 19.04.17 at 13:44, wrote:
On 4/19/2017 7:19 PM, Jan Beulich wrote:
On 19.04.17 at 11:48, wrote:
Does hypervisor need to differentiate dom0 kernel and its
user space?
If we want to para-virtualize the feature, then yes. Otherwise
we can't assume
On 4/19/2017 10:09 PM, Andrew Cooper wrote:
On 19/04/17 15:07, Jan Beulich wrote:
On 19.04.17 at 15:58, wrote:
On 19/04/17 14:50, Yu Zhang wrote:
On 4/19/2017 9:34 PM, Jan Beulich wrote:
On 19.04.17 at 13:44, wrote:
On 4/19/2017 7:19 PM, Jan Beulich wrote:
On 19.04.17 at 11:48, wrote
On 4/20/2017 5:47 PM, Jan Beulich wrote:
On 20.04.17 at 09:15, wrote:
And back to the schedule of this feature, are you working on it? Or any
specific plan?
Well, the HVM side is basically ready (as said, the single hunk needed
to support UMIP when hardware supports it could be easily split
On 4/20/2017 6:01 PM, Jan Beulich wrote:
On 20.04.17 at 11:53, wrote:
On 4/20/2017 5:47 PM, Jan Beulich wrote:
On 20.04.17 at 09:15, wrote:
And back to the schedule of this feature, are you working on it? Or any
specific plan?
Well, the HVM side is basically ready (as said, the single hun
On 4/20/2017 6:23 PM, Andrew Cooper wrote:
On 20/04/17 11:10, Yu Zhang wrote:
On 4/20/2017 6:01 PM, Jan Beulich wrote:
On 20.04.17 at 11:53, wrote:
On 4/20/2017 5:47 PM, Jan Beulich wrote:
On 20.04.17 at 09:15, wrote:
And back to the schedule of this feature, are you working on it?
Or
On 4/28/2017 3:45 PM, Zhang, Xiong Y wrote:
I found this patch couldn't work, the reason is inline. And need propose to
fix this.
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 7e0da81..d72b7bd 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -384,15 +384,5
On 5/8/2017 7:12 PM, George Dunlap wrote:
On 08/05/17 11:52, Zhang, Xiong Y wrote:
On 06.05.17 at 03:51, wrote:
On 05.05.17 at 05:52, wrote:
'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
outstanding p2m_ioreq_server entries")' will call
p2m_change_entry_type_global() which
On 5/10/2017 12:29 AM, Jan Beulich wrote:
On 05.04.17 at 10:59, wrote:
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -411,14 +411,17 @@ static int dm_op(domid_t domid,
while ( read_atomic(&p2m->ioreq.entry_count) &&
first_gfn <= p2m->max_mapped
face to support XenGT (v7)
- XEN-43
- Yu Zhang
- Paul Durrant
I think this is either done or obsolete now. Not sure which.
CCed Yu Zhang to tell which one.
Thanks, Julien. This is done now. :)
Yu
Cheers,
___
Xen-devel mailing
On 8/22/2017 8:44 PM, Julien Grall wrote:
Hi,
On 22/08/17 11:22, Yu Zhang wrote:
On 8/21/2017 6:15 PM, Julien Grall wrote:
Hi Paul,
On 21/08/17 11:11, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
Julien Grall
Sent
-off-by: Yi Zhang
Signed-off-by: Yu Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/mm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a20fdca..9c9afa1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
On 11/9/2017 5:19 PM, Jan Beulich wrote:
On 09.11.17 at 16:29, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4844,9 +4844,10 @@ int map_pages_to_xen(
{
unsigned long base_mfn;
-pl1e = l2e_to_l1e(*pl2e);
if ( lo
` with the lock will fix this race condition.
Signed-off-by: Min He
Signed-off-by: Yi Zhang
Signed-off-by: Yu Zhang
Oh, one more thing: Is it really the case that all three of you
contributed to the patch? We don't use the Linux model of
everyone through whose hands a patch passes adding a
.
Otherwise, the paging structure may be freed more than once, if
the same routine is invoked simultaneously on different CPUs.
Signed-off-by: Yu Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/mm.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/xen
lock, and checking the PSE flag of the `pl2e`.
Note: PSE flag of `pl3e` is also checked before its re-consolidation,
for the same reason we do for `pl2e` - we cannot presume the contents
of the target superpage.
Signed-off-by: Min He
Signed-off-by: Yi Zhang
Signed-off-by: Yu Zhang
---
Cc: Jan
On 11/10/2017 5:57 PM, Jan Beulich wrote:
On 10.11.17 at 08:18, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5097,6 +5097,17 @@ int modify_xen_mappings(unsigned long s, unsigned long
e, unsigned int nf)
*/
if ( (nf & _PAGE_PRESENT) || ((v != e) && (
On 11/10/2017 5:49 PM, Jan Beulich wrote:
On 10.11.17 at 08:18, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4844,9 +4844,19 @@ int map_pages_to_xen(
{
unsigned long base_mfn;
-pl1e = l2e_to_l1e(*pl2e);
if ( l
On 11/13/2017 5:31 PM, Jan Beulich wrote:
On 10.11.17 at 15:05, wrote:
On 11/10/2017 5:49 PM, Jan Beulich wrote:
I'm not certain this is important enough a fix to consider for 4.10,
and you seem to think it's good enough if this gets applied only
after the tree would be branched, as you didn
,
for the corresponding L2/L3 entry.
Signed-off-by: Min He
Signed-off-by: Yi Zhang
Signed-off-by: Yu Zhang
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes in v3:
According to comments from Jan Beulich:
- use local variable instead of dereference pointer to pte to check flag.
- also chec
reference a superpage.
Therefore the logic to enumerate the L1/L2 page table and to
reset the corresponding L2/L3 PTE need to be protected with
spinlock. And the _PAGE_PRESENT and _PAGE_PSE flags need be
checked after the lock is obtained.
Signed-off-by: Yu Zhang
---
Cc: Jan Beulich
Cc: Andrew
o_xen(), modify_xen_mappings() etc. To fix this, this
patch will
check the _PAGE_PRESENT and _PAGE_PSE flags, after the spinlock is
obtained,
for the corresponding L2/L3 entry.
Signed-off-by: Min He
Signed-off-by: Yi Zhang
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
Please try to have a cover l
On 7/17/2017 6:53 PM, Juergen Gross wrote:
Hey,
I took a few notes at the 5-level-paging session at the summit.
I hope there isn't any major stuff missing...
Participants (at least naming the active ones): Andrew Cooper,
Jan Beulich, Yu Zhang and myself (the list is just from my m
On 7/20/2017 6:42 PM, Andrew Cooper wrote:
On 20/07/17 11:10, Yu Zhang wrote:
On 7/17/2017 6:53 PM, Juergen Gross wrote:
Hey,
I took a few notes at the 5-level-paging session at the summit.
I hope there isn't any major stuff missing...
Participants (at least naming the active
On 7/20/2017 7:24 PM, Andrew Cooper wrote:
On 20/07/17 11:36, Yu Zhang wrote:
On 7/20/2017 6:42 PM, Andrew Cooper wrote:
On 20/07/17 11:10, Yu Zhang wrote:
On 7/17/2017 6:53 PM, Juergen Gross wrote:
Hey,
I took a few notes at the 5-level-paging session at the summit.
I hope there
On 8/15/2017 6:28 PM, Andrew Cooper wrote:
On 15/08/17 04:18, Boqun Feng (Intel) wrote:
Add a "umip" test for the User-Model Instruction Prevention. The test
simply tries to run sgdt/sidt/sldt/str/smsw in guest user-mode with
CR4_UMIP = 1.
Signed-off-by: Boqun Feng (Intel)
Reviewed-by: Andr
On 3/23/2017 4:57 PM, Jan Beulich wrote:
On 23.03.17 at 04:23, wrote:
On 3/22/2017 10:21 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
---
xen/arch/x86/hvm/dm.c| 37 ++--
xen/arch/x86/hvm/emulate.c | 65 ---
xen
On 3/23/2017 5:00 PM, Jan Beulich wrote:
On 23.03.17 at 04:23, wrote:
On 3/22/2017 10:29 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -949,6 +949,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d,
ioservid_t
On 3/23/2017 5:02 PM, Jan Beulich wrote:
On 23.03.17 at 04:23, wrote:
On 3/22/2017 10:39 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -385,16 +385,51 @@ static int dm_op(domid_t domid,
case XEN_DMOP_map_mem_type_t
On 3/24/2017 5:26 PM, Tian, Kevin wrote:
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Wednesday, March 22, 2017 6:13 PM
On 3/22/2017 3:49 PM, Tian, Kevin wrote:
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Tuesday, March 21, 2017 10:53 AM
A new DMOP
On 3/24/2017 6:19 PM, Jan Beulich wrote:
On 24.03.17 at 10:05, wrote:
On 3/23/2017 4:57 PM, Jan Beulich wrote:
On 23.03.17 at 04:23, wrote:
On 3/22/2017 10:21 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
@@ -177,8 +178,64 @@ static int hvmemul_do_io(
break;
ca
On 3/24/2017 6:37 PM, Jan Beulich wrote:
On 24.03.17 at 10:05, wrote:
On 3/23/2017 5:00 PM, Jan Beulich wrote:
On 23.03.17 at 04:23, wrote:
On 3/22/2017 10:29 PM, Jan Beulich wrote:
On 21.03.17 at 03:52, wrote:
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -949,6 +949
On 3/24/2017 5:37 PM, Tian, Kevin wrote:
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Wednesday, March 22, 2017 6:12 PM
On 3/22/2017 4:10 PM, Tian, Kevin wrote:
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Tuesday, March 21, 2017 10:53 AM
After an ioreq server has
led.
b> only after one ioreq server claims its ownership of p2m_ioreq_server,
will the p2m type change to p2m_ioreq_server be allowed.
c> this patch shall be accepted together with the following ones in
this series.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
server X, This wrapper shall be updated when such change
is made.
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/devicemodel/core.c | 25 +
tools/libs/devicemodel/include/xendevicemodel.h | 18
. Now this new
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly.
Yu Zhang (6):
x86/ioreq server
). Later, a per-event channel
lock was introduced in commit de6acb7, to send events. So we do not
need to worry about the deadlock issue.
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
changes in v4:
- According to comments from Jan
p2m table. The core reason is our current
implementation of p2m_change_entry_type_global() lacks information
to resync p2m_ioreq_server entries correctly if global_logdirty is
on.
Signed-off-by: Yu Zhang
Reviewed-by: Paul Durrant
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Geo
because both reads and writes will go to the device mode.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
changes in v4:
- Added "Reviewed-by: Jan Beulich " with one comment
change in hvm
mapped. And
since the sweeping of p2m table could be time consuming, it is done
with hypercall continuation.
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
changes in v3:
- According to comments from Paul: use mar_nr, instead of
On 4/3/2017 5:28 PM, Wei Liu wrote:
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 02 April 2017 13:24
To: xen-devel@lists.xen.org
Cc: zhiyuan...@intel.com; Paul Durrant ; Ian
Jackson ; Wei Liu
On 4/3/2017 10:36 PM, Jan Beulich wrote:
So this produces the same -EINVAL as the earlier check in context
above. I think it would be nice if neither did - -EINUSE for the first
(which we don't have, so -EOPNOTSUPP would seem the second
bets option there) and -EBUSY for the second would seem mo
we need to guarantee
the p2m table is clean before another ioreq server is mapped. And
since the sweeping of p2m table could be time consuming, it is done
with hypercall continuation.
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
albeit I think ...
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen
1 - 100 of 389 matches
Mail list logo
