-Original Message-
From: Meng Xu [mailto:xumengpa...@gmail.com]
Sent: Wednesday, June 24, 2015 2:16 PM
To: Wu, Feng
Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
Cooper; Jan Beulich; Zhang, Yang Z
Subject: Re: [Xen-devel] [v3 01/15] Vt-d
Note actually we just need p2m_remove_page() to unmap these mapping on
both ept and vt-d sides, and guest_physmap_remove_page is really a
wrapper of p2m_remove_page().
And I agree with Tim regarding the desire to avoid code duplication.
Yet that's no reason to do it asymmetrically:
On 06/16/2015 06:56 PM, Ian Campbell wrote:
On Mon, 2015-06-08 at 11:45 +0800, Yang Hongyang wrote:
add colo readme, refer to
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
This is fine as far as it goes but I wonder if perhaps
Hi Feng,
One minor thing:
+Important Definitions
+==
+There are some changes to IRTE and posted-interrupt descriptor after
+VT-d PI is introduced:
+IRTE:
It seems that you forgot to define IRTE. :-)
I guess it stands for Interrupt Remapping Table Entry? (Probably I'm wrong.
On 22/06/15 19:56, Ed White wrote:
Currently, neither is enabled globally but may be enabled on a per-VCPU
basis by the altp2m code.
Remove the check for EPTE bit 63 == zero in ept_split_super_page(), as
that bit is now hardware-defined.
Signed-off-by: Ed White edmund.h.wh...@intel.com
On 06/24/2015 12:14 PM, Fanhenglong wrote:
I want to debug the procedure of windows os install with windbg,
windbg executes instruction(fxsave) after the blank vm is started and
before guest iso start to install,
fxsave trigger the following code path:
On 24.06.15 at 03:11, tiejun.c...@intel.com wrote:
On 2015/6/23 18:12, Jan Beulich wrote:
On 23.06.15 at 11:57, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1839,7 +1839,7 @@ static int rmrr_identity_mapping(struct
On Wed, 2015-06-24 at 06:03 +, osstest service user wrote:
flight 58849 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On Tue, 2015-06-23 at 19:50 +0100, Wei Liu wrote:
On Tue, Jun 23, 2015 at 05:38:17PM +0100, Ian Campbell wrote:
On Tue, 2015-06-23 at 17:32 +0100, Wei Liu wrote:
On Tue, Jun 23, 2015 at 03:58:32PM +0100, Ian Campbell wrote:
There is an issue in libxl_set_memory_target whereby the target
On Fri, 2015-06-19 at 12:07 +0100, Ian Campbell wrote:
On Fri, 2015-06-19 at 10:51 +0100, Jan Beulich wrote:
On 18.06.15 at 16:22, ian.campb...@citrix.com wrote:
On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote:
On 17.06.15 at 12:26, ian.jack...@eu.citrix.com wrote:
Jan Beulich
On 24.06.15 at 05:05, boris.ostrov...@oracle.com wrote:
On 06/23/2015 09:38 AM, Jan Beulich wrote:
On 20.06.15 at 05:09, boris.ostrov...@oracle.com wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2652,7 +2652,7 @@ int vcpu_destroy_pagetables(struct vcpu *v)
if ( rc )
On 24.06.15 at 04:53, boris.ostrov...@oracle.com wrote:
On 06/23/2015 09:22 AM, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,12 +2320,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
v-arch.hvm_vcpu.inject_trap.vector = -1;
if (
On 23.06.15 at 18:32, paul.durr...@citrix.com wrote:
Ok. If you believe it's the right thing to do, I'm happy to drop this patch
out of the series. I'll send v4 tomorrow.
Perhaps worth waiting a little for further review comments (fwiw I
didn't get to look at 5 and onwards so far)? But of
flight 58849 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 58830
Tests which did
Xen's build system has a target for rump kernel called NetBSDRump. We
want to build libxc against rump kernel, so we need to copy NetBSD's
evtchn.h and privcmd.h to NetBSDRump. These copies is not very likely to
diverge from NetBSD's copies, but we don't preclude such possibility.
Signed-off-by:
I have upstreamed a privcmd driver for rump kernel. That driver has the same
semantics as the NetBSD one so we can just use xc_netbsd for rump kernel.
Wei.
Wei Liu (2):
NetBSDRump: provide evtchn.h and privcmd.h
libxc: use xc_netbsd.c for rump kernel
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 55782c8..153b79e 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -48,6 +48,7 @@ CTRL_SRCS-$(CONFIG_Linux) +=
On Wed, Jun 24, 2015 at 10:31:57AM +0100, Andrew Cooper wrote:
On 24/06/15 10:25, Razvan Cojocaru wrote:
On 06/24/2015 12:14 PM, Fanhenglong wrote:
I want to debug the procedure of windows os install with windbg,
windbg executes instruction(fxsave) after the blank vm is started and
...and error handling
NOTE: A straight reversion was not possible because of subsequent changes
in the code so this at least partially a manual reversion.
By limiting hvmemul_do_io_addr() to reps falling within the pages on which
a reference has already been taken, we can guarantee that
By removing the HVMIO_dispatched state and making all pending emulations
(i.e. all those not handled by the hypervisor) use HVMIO_awating_completion,
various code-paths can be simplified.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich
On Mon, Jun 22, 2015 at 6:47 PM, Jan Beulich jbeul...@suse.com wrote:
On 22.06.15 at 14:01, vijay.kil...@gmail.com wrote:
First of all, please Cc _all_ relevant maintainers.
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -117,6 +117,14 @@ static inline int
On 06/24/2015 12:31 PM, Andrew Cooper wrote:
On 24/06/15 10:25, Razvan Cojocaru wrote:
On 06/24/2015 12:14 PM, Fanhenglong wrote:
I want to debug the procedure of windows os install with windbg,
windbg executes instruction(fxsave) after the blank vm is started and
before guest iso start to
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add APIs to add devices to RB-tree, assign and remove
devices to domain.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c |
Hi Wang,
I don't know the answer, so I CCed xen-devel (the Xen development list)
and a few people that I think will be able to help.
Cheers,
Stefano
On Wed, 24 Jun 2015, Wang Xu wrote:
A problem about channel, where do I found the channel name in the guest, In
the document, it says I could
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 24 June 2015 13:16
To: Paul Durrant
Cc: xen-de...@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v4 00/17] x86/hvm: I/O emulation cleanup
and fix
On 24.06.15 at 13:24, paul.durr...@citrix.com wrote:
.string8 is only supported by gas 2.19 and newer.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/include/asm-x86/bug.h
+++ b/xen/include/asm-x86/bug.h
@@ -79,7 +79,7 @@ extern const struct bug_frame __start_bu
.L\@ud: ud2a
.pushsection .rodata.str1, aMS, @progbits, 1
-
El 24/06/15 a les 13.11, Roger Pau Monné ha escrit:
El 22/06/15 a les 16.48, Roger Pau Monné ha escrit:
El 22/06/15 a les 12.09, George Dunlap ha escrit:
On 06/22/2015 10:59 AM, Roger Pau Monné wrote:
El 22/06/15 a les 11.08, George Dunlap ha escrit:
On 06/19/2015 09:58 AM, Roger Pau Monne
On 24 Jun 2015, at 12:48, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
Hi Wang,
I don't know the answer, so I CCed xen-devel (the Xen development list)
and a few people that I think will be able to help.
Cheers,
Stefano
On Wed, 24 Jun 2015, Wang Xu wrote:
A
El 24/06/15 a les 12.10, Wei Liu ha escrit:
+#define IOCTL_PRIVCMD_MMAP \
+_IOW('P', 2, privcmd_mmap_t)
+#define IOCTL_PRIVCMD_MMAPBATCH\
+_IOW('P', 3, privcmd_mmapbatch_t)
FWIW you could have gotten away with just implementing
IOCTL_PRIVCMD_MMAPBATCH, this is
On 22/06/15 19:56, Ed White wrote:
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 3d8f4dc..a1529c0 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -118,6 +118,13 @@ struct nestedvcpu {
#define vcpu_nestedhvm(v)
El 22/06/15 a les 16.48, Roger Pau Monné ha escrit:
El 22/06/15 a les 12.09, George Dunlap ha escrit:
On 06/22/2015 10:59 AM, Roger Pau Monné wrote:
El 22/06/15 a les 11.08, George Dunlap ha escrit:
On 06/19/2015 09:58 AM, Roger Pau Monne wrote:
This is not needed, neither encouraged.
...in hvmemul_read/write()
Add hvmemul_phys_mmio_access() and hvmemul_linear_mmio_access() functions
to reduce code duplication.
NOTE: This patch also introduces a change in 'chunking' around a page
boundary. Previously (for example) an 8 byte access at the last
byte of a page would
On 06/24/2015 06:14 AM, Roger Pau Monné wrote:
El 24/06/15 a les 12.05, Jan Beulich ha escrit:
On 24.06.15 at 11:47, roger@citrix.com wrote:
What needs to be done (ordered by priority):
- Clean up the patches, this patch series was done in less than a week.
- Finish the boot ABI (this
On 06/24/2015 02:02 PM, Roger Pau Monné wrote:
El 24/06/15 a les 13.11, Roger Pau Monné ha escrit:
El 22/06/15 a les 16.48, Roger Pau Monné ha escrit:
El 22/06/15 a les 12.09, George Dunlap ha escrit:
On 06/22/2015 10:59 AM, Roger Pau Monné wrote:
El 22/06/15 a les 11.08, George Dunlap ha
On 22/06/15 19:56, Ed White wrote:
In preparation for selectively enabling #VE in a later patch, set
suppress #VE on all EPTE's.
Suppress #VE should always be the default condition for two reasons:
it is generally not safe to deliver #VE into a guest unless that guest
has been modified to
flight 58871 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
Use an ioreq_t rather than open coded state, size, dir and data fields
in struct hvm_vcpu_io. This also allows PIO completion to be handled
similarly to MMIO completion by re-issuing the handle_pio() call.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan
Emulation request status is already covered by STATE_IOREQ_XXX values so
just use those. The mapping is:
HVMIO_none- STATE_IOREQ_NONE
HVMIO_awaiting_completion - STATE_IOREQ_READY
HVMIO_completed - STATE_IORESP_READY
Signed-off-by: Paul Durrant paul.durr...@citrix.com
By removing the calls in hvmemul_do_io() (which is replaced by a single
assignment) and hvm_complete_assist_request() (which is replaced by a
call to process_portio_intercept() with a suitable set of ops) then
hvm_io_assist() can be moved into hvm.c and made static (and hence be a
candidate for
The state of in-flight I/O and how its completion will be handled are
logically separate and conflating the two makes the code unnecessarily
confusing.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper
The code in hvmemul_do_io() that tracks large reads or writes, to avoid
re-issue of component I/O, is defeated by accesses across a page boundary
because it uses physical address. The code is also only relevant to memory
mapped I/O to or from a buffer.
This patch re-factors the code and moves it
If memory mapped I/O is 'chunked' then the I/O must be re-emulated,
otherwise only the first chunk will be processed. This patch makes
sure all I/O from a buffer is re-emulated regardless of whether it
is a read or a write.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser
On Tue, 2015-06-23 at 14:38 +0100, Ian Campbell wrote:
On Tue, 2015-06-23 at 12:15 +0100, Anthony PERARD wrote:
On Mon, Jun 08, 2015 at 10:22:28AM +0100, Ian Campbell wrote:
On Mon, 2015-06-08 at 04:37 +, osstest service user wrote:
flight 58119 libvirt real [real]
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 24 June 2015 13:34
To: Paul Durrant
Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
Subject: Re: [PATCH v4 04/17] x86/hvm: remove multiple open coded
'chunking' loops
On 24.06.15 at 13:24,
El 24/06/15 a les 12.05, Jan Beulich ha escrit:
On 24.06.15 at 11:47, roger@citrix.com wrote:
What needs to be done (ordered by priority):
- Clean up the patches, this patch series was done in less than a week.
- Finish the boot ABI (this would also be needed for PVH anyway).
-
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Virtual ITS command processing support to Virtual ITS driver
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c |7 +
On Wed, Jun 24, 2015 at 12:22:46PM +0200, Roger Pau Monné wrote:
El 24/06/15 a les 12.10, Wei Liu ha escrit:
+#define IOCTL_PRIVCMD_MMAP \
+_IOW('P', 2, privcmd_mmap_t)
+#define IOCTL_PRIVCMD_MMAPBATCH\
+_IOW('P', 3, privcmd_mmapbatch_t)
FWIW you could
The implementation of mmio and portio intercepts is unnecessarily different.
This leads to much code duplication. This patch unifies much of the
intercept handling, leaving only distinct handlers for stdvga mmio and dpci
portio. Subsequent patches will unify those handlers.
Signed-off-by: Paul
Currently hvmemul_do_io() handles paging for I/O to/from a guest address
inline. This causes every exit point to have to execute:
if ( ram_page )
put_page(ram_page);
This patch introduces wrapper hvmemul_do_io_addr() and
hvmemul_do_io_buffer() functions. The latter is used for I/O to/from a
It's clear from the following check in hvmemul_rep_movs:
if ( sp2mt == p2m_mmio_direct || dp2mt == p2m_mmio_direct ||
(sp2mt == p2m_mmio_dm dp2mt == p2m_mmio_dm) )
return X86EMUL_UNHANDLEABLE;
that mmio - mmio copy is not handled. This means the code in the
stdvga mmio
The is_mmio parameter can be inferred from the ioreq type.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
---
xen/arch/x86/hvm/emulate.c |7 ---
1 file changed, 4
This patch re-works the dpci portio intercepts so that they can be unified
with standard portio handling thereby removing a substantial amount of
code duplication.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper
This patch series re-works much of the code involved in emulation of port
and memory mapped I/O for HVM guests.
The code has become very convoluted and, at least by inspection, certain
emulations will apparently malfunction.
The series is broken down into 17 patches (which are also available in
When memory mapped I/O is range checked by internal handlers, the length
of the access should be taken into account.
Signed-off-by: Paul Durrant paul.durr...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
---
On 06/24/2015 03:57 AM, Jan Beulich wrote:
On 24.06.15 at 04:53, boris.ostrov...@oracle.com wrote:
On 06/23/2015 09:22 AM, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,12 +2320,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
On 24.06.15 at 13:24, paul.durr...@citrix.com wrote:
+static int hvmemul_phys_mmio_access(
+paddr_t gpa, unsigned int size, uint8_t dir, uint8_t **buffer)
As much as the earlier offset you returned via indirection to the
caller was unnecessary, the indirection here seems pointless too.
All
On 22/06/15 19:56, Ed White wrote:
From: Ravi Sahita ravi.sah...@intel.com
Signed-off-by: Ravi Sahita ravi.sah...@intel.com
---
xen/arch/x86/hvm/emulate.c | 13 +++--
xen/arch/x86/hvm/vmx/vmx.c | 30 ++
Adding Boris+Suravee+Aravind (AMD/SVM maintainers), Dario (NUMA) and Jim
+Anthony (libvirt) to the CC.
TL;DR osstest is exposing issues running on AMD Opteron(tm) Processor
6376 in at least a couple of test cases. It would be good if someone
from AMD could have a look.
The systems here ==
On 24.06.15 at 11:06, ian.campb...@citrix.com wrote:
After that baseline I ran a few tests of just the windows + qemuu stuff:
http://xenbits.xen.org/people/ianc/tmp/adhoc/37619/
was allowing free reign on the machines and was mostly successful, apart
from the windows-install failure on
flight 58845 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58845/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are
On 24.06.15 at 13:24, paul.durr...@citrix.com wrote:
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -498,10 +498,11 @@ static int hpet_write(
return X86EMUL_OKAY;
}
-static int hpet_range(struct vcpu *v, unsigned long addr)
+static int hpet_range(struct vcpu *v,
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 24 June 2015 10:38
To: Paul Durrant
Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
Subject: Re: [PATCH v3 05/18] x86/hvm: remove multiple open coded
'chunking' loops
On 23.06.15 at 12:39,
On 24.06.15 at 11:14, fanhengl...@huawei.com wrote:
I want to debug the procedure of windows os install with windbg,
windbg executes instruction(fxsave) after the blank vm is started and before
guest iso start to install,
fxsave trigger the following code path:
On 22/06/15 19:56, Ed White wrote:
Implement and hook up the code to enable VMX support of VMFUNC and #VE.
VMFUNC leaf 0 (EPTP switching) emulation is added in a later patch.
Signed-off-by: Ed White edmund.h.wh...@intel.com
---
xen/arch/x86/hvm/vmx/vmx.c | 132
On 23.06.15 at 12:39, paul.durr...@citrix.com wrote:
The implementation of mmio and portio intercepts is unnecessarily different.
This leads to much code duplication. This patch unifies much of the
intercept handling, leaving only distinct handlers for stdvga mmio and dpci
portio. Subsequent
On Wed, 24 Jun 2015, Dave Scott wrote:
On 24 Jun 2015, at 12:48, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
Hi Wang,
I don't know the answer, so I CCed xen-devel (the Xen development list)
and a few people that I think will be able to help.
Cheers,
Stefano
Hello everyone,
I would like to try the vTPM feature, but I'm having some issues. Basically, I
followed the steps explained in
https://mhsamsal.wordpress.com/2013/12/05/configuring-virtual-tpm-vtpm-for-xen-4-3-guest-virtual-machines/
I'm running Ubuntu 14.04 as Dom0 on a Dell optiplex-9020.
On Wed, 24 Jun 2015 16:26:44 -0400
Elena Ufimtseva elena.ufimts...@oracle.com wrote:
On Wed, Jun 24, 2015 at 07:24:18PM +0100, Andrew Cooper wrote:
On 24/06/15 08:49, Jan Beulich wrote:
On 24.06.15 at 04:34, boris.ostrov...@oracle.com wrote:
On 06/23/2015 08:30 AM, Jan Beulich wrote:
Thanks for the help and support guys. I'll need some time to get a proper
understanding of how it is incorporated in Linux kernel and what all
interfaces are built on top of it. Once I'm comfortable with that and xen's
credit_scheduler, for starting, I'll come up with a design doc and share
with
On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but
flight 58851 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs.
On Wed, Jun 24, 2015 at 07:24:18PM +0100, Andrew Cooper wrote:
On 24/06/15 08:49, Jan Beulich wrote:
On 24.06.15 at 04:34, boris.ostrov...@oracle.com wrote:
On 06/23/2015 08:30 AM, Jan Beulich wrote:
On 22.06.15 at 18:37, elena.ufimts...@oracle.com wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
On Wed, Jun 24, 2015 at 12:43 PM, Ed White edmund.h.wh...@intel.com wrote:
On 06/24/2015 06:37 AM, Razvan Cojocaru wrote:
On 06/24/2015 04:32 PM, Lengyel, Tamas wrote:
On Wed, Jun 24, 2015 at 1:39 AM, Razvan Cojocaru
rcojoc...@bitdefender.com mailto:rcojoc...@bitdefender.com wrote:
On 06/24/2015 03:45 PM, Lengyel, Tamas wrote:
On Wed, Jun 24, 2015 at 6:02 PM, Ed White edmund.h.wh...@intel.com wrote:
On 06/24/2015 02:34 PM, Lengyel, Tamas wrote:
Hi Ed,
I tried the system using memsharing and I collected the following crash
log. In this test I ran memsharing on all
On 06/23/2015 11:18 AM, Jan Beulich wrote:
... as being identical to is_pv_32bit_vcpu() after the x86-32 removal.
In a few cases this includes an additional is_pv_32bit_vcpu() -
is_pv_32bit_domain() conversion.
Signed-off-by: Jan Beulich jbeul...@suse.com
We have
struct arch_domain
{
...
On Wed, Jun 24, 2015 at 3:05 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis
On 06/24/2015 05:47 AM, Andrew Cooper wrote:
+case EXIT_REASON_VMFUNC:
+if ( vmx_vmfunc_intercept(regs) == X86EMUL_OKAY )
This is currently an unconditional failure, and I don't see subsequent
patches which alter vmx_vmfunc_intercept(). Shouldn't
vmx_vmfunc_intercept() switch
On 06/24/2015 02:34 PM, Lengyel, Tamas wrote:
Hi Ed,
I tried the system using memsharing and I collected the following crash
log. In this test I ran memsharing on all pages of the domain before
activating altp2m and creating the view. Afterwards I used my updated
xen-access to create a copy
On Wed, Jun 24, 2015 at 6:02 PM, Ed White edmund.h.wh...@intel.com wrote:
On 06/24/2015 02:34 PM, Lengyel, Tamas wrote:
Hi Ed,
I tried the system using memsharing and I collected the following crash
log. In this test I ran memsharing on all pages of the domain before
activating altp2m
[Moving most people to Bcc, as this is indeed unrelated to the original
topic]
On Wed, 2015-06-24 at 13:41 +0100, Jan Beulich wrote:
On 24.06.15 at 14:29, dario.faggi...@citrix.com wrote:
On Wed, 2015-06-24 at 10:38 +0100, Ian Campbell wrote:
The memory info
Jun 23 15:56:27.749008 (XEN)
On 24.06.15 at 15:34, paul.durr...@citrix.com wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 24 June 2015 14:25
To: Paul Durrant
Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
Subject: RE: [Xen-devel] [PATCH v4 07/17] x86/hvm: add
On 22/06/15 19:56, Ed White wrote:
This set of patches adds support to hvm domains for EPTP switching by creating
multiple copies of the host p2m (currently limited to 10 copies).
The primary use of this capability is expected to be in scenarios where access
to memory needs to be monitored
On 22.06.15 at 20:56, edmund.h.wh...@intel.com wrote:
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -210,6 +210,14 @@ struct hvm_function_table {
uint32_t *ecx, uint32_t *edx);
void (*enable_msr_exit_interception)(struct
Signed-off-by: Rob Hoes rob.h...@citrix.com
---
tools/libxl/libxl.c | 12 ++--
tools/libxl/libxl_device.c | 6 +++---
tools/libxl/libxl_qmp.c | 4 +++-
tools/libxl/libxl_types.idl | 22 +-
4 files changed, 33 insertions(+), 11 deletions(-)
diff --git
Signed-off-by: Rob Hoes rob.h...@citrix.com
---
tools/libxl/libxl_device.c | 1 +
tools/libxl/libxl_types.idl | 3 +++
2 files changed, 4 insertions(+)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 93bb41e..56c6e2e 100644
--- a/tools/libxl/libxl_device.c
+++
Signed-off-by: Rob Hoes rob.h...@citrix.com
---
tools/libxl/libxl_types.idl | 41 +
1 file changed, 41 insertions(+)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 65d479f..6dc18fa 100644
--- a/tools/libxl/libxl_types.idl
+++
Signed-off-by: Rob Hoes rob.h...@citrix.com
---
tools/libxl/libxl_types.idl | 8
tools/libxl/libxl_xshelp.c | 14 +++---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6dc18fa..e9b3477 100644
---
On 22/06/15 19:56, Ed White wrote:
Signed-off-by: Ed White edmund.h.wh...@intel.com
---
xen/arch/x86/hvm/hvm.c | 216
xen/include/public/hvm/hvm_op.h | 69 +
2 files changed, 285 insertions(+)
diff --git
On 24.06.15 at 13:24, paul.durr...@citrix.com wrote:
@@ -424,8 +427,17 @@ static void stdvga_mem_writeb(uint64_t addr, uint32_t
val)
}
}
-static void stdvga_mem_write(uint64_t addr, uint64_t data, uint64_t size)
+static int stdvga_mem_write(struct vcpu *v, unsigned long addr,
+
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 24 June 2015 14:59
To: Paul Durrant
Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
Subject: Re: [PATCH v4 09/17] x86/hvm: unify stdvga mmio intercept with
standard mmio intercept
On 24.06.15
On Wed, 24 Jun 2015, Ian Campbell wrote:
On Wed, 2015-06-24 at 06:03 +, osstest service user wrote:
flight 58849 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests
flight 58847 xen-4.1-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 27396
Regressions
On 22.06.15 at 20:56, edmund.h.wh...@intel.com wrote:
@@ -1826,6 +1827,20 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
vmx_vmcs_exit(v);
}
+static bool_t vmx_vcpu_emulate_vmfunc(struct cpu_user_regs *regs)
+{
+bool_t rc = 0;
+
+if ( !cpu_has_vmx_vmfunc
Windows 8.0 iso can't install in uefi mode,
I have to use windbg to get more debug information,
So using xen in this case
发件人: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
发送时间: 2015年6月24日 17:26
收件人: Fanhenglong; xen-devel@lists.xen.org
抄送: Liuqiming (John); Yanqiangjun; Huangpeng
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
On Thu, Jun 25, 2015 at 09:38:01AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2015-06-24 at 15:29 -0700, Luis R. Rodriguez wrote:
Nope but at least what made me squint at this being a possible
feature was that in practice when reviewing all of the kernels
pending device drivers using
On Wed, 2015-06-24 at 17:58 -0700, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
OK thanks I'll proceed with these patches then.
As for user mappings,
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a)
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take
1 - 100 of 216 matches
Mail list logo
