At 13:33 -0400 on 23 Jun (1435066410), Lengyel, Tamas wrote:
> That's indeed sad. I'm actively using the sharing system in my tools and
> have a couple branches laying around for improving it, like batch
> memsharing for example to support flash-cloning. Now that it's orphaned,
> how would I go abo
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:
clear_identit
>>> On 24.06.15 at 09:26, wrote:
>> This would need to go into patch 2; I wonder whether folding that
>
> Yes.
>
>> and this one wouldn't be warranted, avoiding the former adding
>
> Are you saying to fold patch #2 and patch #3? But shouldn't we always
> define a new and then use that in pract
>>> On 23.06.15 at 18:32, 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 course if you
don't mi
>>> On 24.06.15 at 04:34, wrote:
> On 06/23/2015 08:30 AM, Jan Beulich wrote:
> On 22.06.15 at 18:37, wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -1444,6 +1444,9 @@ const struct hvm_function_table * __init
>>> start_svm(void)
>>> svm_function_
>>> On 24.06.15 at 04:53, 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 ( is_pvh_dom
>>> On 24.06.15 at 05:05, wrote:
> On 06/23/2015 09:38 AM, Jan Beulich wrote:
> On 20.06.15 at 05:09, 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 )
>>> return rc;
>>>
>>> -
flight 58844 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58844/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 11 guest-start fail like 58829
test-amd64-i386-libvirt-xsm
On Tue, 2015-06-23 at 12:44 -0600, Jim Fehlig wrote:
> On 06/18/2015 10:02 AM, Ian Campbell wrote:
> > On Thu, 2015-06-18 at 16:18 +0100, Ian Campbell wrote:
> >> On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote:
> >>> The "No response from client ..." appear only on armhf as far as I can
>
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
Reviewed-by: Andrew C
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:
> test-armhf-armhf-xl-
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 th
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, wrote:
> > > On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote:
> > >> >>> On 17.06.15 at 12:26, wrote:
> > >> > Jan Beulich writes ("stable trees (was:
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
This is fine as far as it goes but I wonder if perhaps
docs/README.{remus,co
Hi everyone,
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:
vmx_vmexit_handler(EXIT_REASON_EPT_VIOLATION)
->ept_handle_violation
->
Hi,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index f1a087e..da73cf5 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -115,6 +115,8 @@ struct arch_domain
> #endif
> } vgic
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:
> vmx_vmexit_handler(EXIT_REASON
>>> On 23.06.15 at 12:39, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -540,6 +540,115 @@ static int hvmemul_virtual_to_linear(
> return X86EMUL_EXCEPTION;
> }
>
> +static int hvmemul_phys_mmio_access(
> +paddr_t gpa, unsigned int size, uint8_t dir,
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
On 22/06/15 19:56, Ed White wrote:
> As implemented here, only supported on platforms with VMX HAP.
>
> By default this functionality is force-disabled, it can be enabled
> by specifying altp2m=1 on the Xen command line.
>
> Signed-off-by: Ed White
> ---
> docs/misc/xen-command-line.markdown | 7
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 and
> the max mem can get out of sync, this is because the call the
> xc_domain_setmaxmem is not tied in any way to the xenstore transaction
> which controls updates to th
On 24/06/15 09:47, 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 w
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 == merlo
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 install,
>>
>> fxsave trigger the follo
>>> On 24.06.15 at 11:06, 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 lake-frog. Looking
El 23/06/15 a les 12.55, Stefano Stabellini ha escrit:
> On Mon, 22 Jun 2015, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jun 22, 2015 at 06:55:12PM +0100, Stefano Stabellini wrote:
>>> Hi Roger,
>>>
>>> given that this patch series is actually using the Xen "hvm" builder, I
>>> take that all the PVH c
On Mon, 2015-06-22 at 17:31 +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> This is based on DraftF version
> http://xenbits.xen.org/people/ianc/vits/draftF.pdf
I had some local edits due to comments made on IRC and in response to
questions you asked while implementing etc. It's
>>> On 24.06.15 at 11:47, 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).
> - Convert the rest of xc_dom_*loaders in order to use the physical
>
On 22/06/15 19:56, Ed White wrote:
> Add the basic data structures needed to support alternate p2m's and
> the functions to initialise them and tear them down.
>
> Although Intel hardware can handle 512 EPTP's per hardware thread
> concurrently, only 10 per domain are supported in this patch for
>
>>> On 24.06.15 at 11:44, wrote:
> On 22/06/15 19:56, Ed White wrote:
>> @@ -6474,6 +6481,11 @@ enum hvm_intblk nhvm_interrupt_blocked(struct vcpu *v)
>> return hvm_funcs.nhvm_intr_blocked(v);
>> }
>>
>> +bool_t hvm_altp2m_supported()
>> +{
>> +return hvm_funcs.altp2m_supported;
>> +}
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: W
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
tools/include/xen-sys/NetBSDRump/evtchn.
Signed-off-by: Wei Liu
---
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) += xc_linux.c xc_linux_os
> -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 a
El 24/06/15 a les 12.05, Jan Beulich ha escrit:
On 24.06.15 at 11:47, 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).
>> - Convert the r
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 24.06.15 at 12:06, wrote:
> On 22/06/15 19:56, Ed White wrote:
>> @@ -498,6 +498,24 @@ int hap_enable(struct domain *d, u32 mode)
>> goto out;
>> }
>>
>> +/* Init alternate p2m data */
>> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
>
> Please use
>>> On 24.06.15 at 12:10, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 June 2015 10:38
>> >>> On 23.06.15 at 12:39, wrote:
>> > --- a/xen/arch/x86/hvm/emulate.c
>> > +++ b/xen/arch/x86/hvm/emulate.c
>> > @@ -540,6 +540,115 @@ static int hvmemul_virtual_to_linear(
>> > r
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
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)
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Add Virtual ITS command processing support to Virtual ITS driver
>
> Signed-off-by: Vijaya Kumar K
> ---
> xen/arch/arm/gic-v3-its.c |7 +
> xen/arch/arm/vgic-v3-its.c | 393
>
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
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
>>> On 24.06.15 at 11:14, 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:
> vmx_vmexit_handler(EXIT_REASON_EPT_VIO
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 encou
On 24/06/15 11:29, Andrew Cooper wrote:
> 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 @@ struc
...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 g
The check is done at the wrong point (since it is irrelevant if the
I/O is to be handled by the hypervisor) and its functionality can be
covered by returning X86EMUL_UNHANDLEABLE from hvm_send_assist_req()
instead.
This patch also removes the domain_crash() call from
hvm_send_assist_req(). Returni
The is_mmio parameter can be inferred from the ioreq type.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/e
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
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c |2 +
xen/ar
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
m
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
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hpet.c |7 ---
xen/arch/x86/hvm/intercept.c
The struct just contains three methods and no data, so the name
hvm_mmio_ops more accurately reflects its content. A subsequent patch
introduces a new structure which more accurately warrants the name
hvm_mmio_handler so doing the rename in this purely cosmetic patch avoids
conflating functional an
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 Dur
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 X
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 i
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
build-i386-rumpuserxe
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Add APIs to add devices to RB-tree, assign and remove
> devices to domain.
>
> Signed-off-by: Vijaya Kumar K
> ---
> xen/arch/arm/gic-v3-its.c | 246
> -
> xen/i
On 06/24/2015 03:57 AM, Jan Beulich wrote:
On 24.06.15 at 04:53, 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;
...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 ca
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
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulat
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
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/a
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
Cc: Keir Fraser
Cc: J
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 inl
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
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew
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
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c| 50 ++
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 i
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
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, 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
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
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 132
>
El 24/06/15 a les 13.52, Boris Ostrovsky ha escrit:
> 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, wrote:
What needs to be done (ordered by priority):
- Clean up the patches, this patch series was do
Hi,
my qemu integrated pvUSB backend is now running stable enough to do
some basic performance measurements. I've passed a memory-stick with
about 90MB of data on it to a pv-domU. Then I read all the data on
it with tar and looked how long this would take (elapsed time):
in dom0:
>>> On 23.06.15 at 12:39, 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 patches will unif
>>> On 24.06.15 at 13:42, wrote:
> On 06/24/2015 03:57 AM, Jan Beulich wrote:
> On 24.06.15 at 04:53, 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, wrote:
> 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 dow
On Wed, 2015-06-24 at 10:38 +0100, Ian Campbell wrote:
> Adding Boris+Suravee+Aravind (AMD/SVM maintainers), Dario (NUMA) and Jim
> +Anthony (libvirt) to the CC.
> Supposing that the NUMA oddities might be what is exposing this issue I
> tried an adhoc run on the merlot machines where I specified
>>> On 24.06.15 at 13:24, 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 callers know how (
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]
> > > > h
>>> On 24.06.15 at 14:29, wrote:
> On Wed, 2015-06-24 at 10:38 +0100, Ian Campbell wrote:
>> The memory info
>> Jun 23 15:56:27.749008 (XEN) Memory location of each domain:
>> Jun 23 15:56:27.756965 (XEN) Domain 0 (total: 131072):
>> Jun 23 15:56:27.756983 (XEN) Node 0: 126905
>> Jun 23 15:56:
On 22/06/15 19:56, Ed White wrote:
> From: Ravi Sahita
>
> Signed-off-by: Ravi Sahita
> ---
> xen/arch/x86/hvm/emulate.c | 13 +++--
> xen/arch/x86/hvm/vmx/vmx.c | 30 ++
> xen/arch/x86/x86_emulate/x86_emulate.c | 8
> xen/arc
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 failing
.string8 is only supported by gas 2.19 and newer.
Signed-off-by: Jan Beulich
--- 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
- .L\@s1: .strin
> -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, wrote:
> > This patch s
> -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 a
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, Roge
> On 24 Jun 2015, at 12:48, Stefano Stabellini
> 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 problem about channel,
On Mon, Jun 22, 2015 at 6:47 PM, Jan Beulich wrote:
On 22.06.15 at 14:01, 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 generic_fls64(__u64 x)
>> # endif
>> #end
>>> On 24.06.15 at 13:24, 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, unsigned long a
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
>>> On 24.06.15 at 14:59, wrote:
>> -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
On Wed, 24 Jun 2015, Dave Scott wrote:
> > On 24 Jun 2015, at 12:48, Stefano Stabellini
> > 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 We
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: 24 June 2015 14:08
> To: Paul Durrant
> Cc: Andrew Cooper; Keir (Xen.org); xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v4 07/17] x86
[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, wrote:
> > On Wed, 2015-06-24 at 10:38 +0100, Ian Campbell wrote:
> >> The memory info
> >> Jun 23 15:56:27.749008 (XEN) Memory location
On 22/06/15 19:56, Ed White wrote:
> The existing ept_set_entry() and ept_get_entry() routines are extended
> to optionally set/get suppress_ve and renamed. New ept_set_entry() and
> ept_get_entry() routines are provided as wrappers, where set preserves
> suppress_ve for an existing entry and sets
On 22/06/15 19:56, Ed White wrote:
> Add a flag to indicate that a memory event occurred in an alternate p2m
> and a field containing the p2m index. Allow the response to switch to
> a different p2m using the same flag and field.
>
> Modify p2m_access_check() to handle alternate p2m's.
>
> Signed-o
On 24/06/15 13:56, Jan Beulich wrote:
> .string8 is only supported by gas 2.19 and newer.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- 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: u
>>> On 24.06.15 at 15:05, wrote:
> On Mon, Jun 22, 2015 at 6:47 PM, Jan Beulich wrote:
> On 22.06.15 at 14:01, wrote:
>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -117,6 +117,14 @@ static inline int generic_fls64(__u64 x)
>>> # endif
>>> #endif
>>>
>>> +stat
>>> On 24.06.15 at 15:14, wrote:
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Jan Beulich
>> Sent: 24 June 2015 14:08
>> >>> On 24.06.15 at 13:24, wrote:
>> > --- a/xen/include/asm-x86/hvm/io.h
>> > +++ b/xen/include/asm-x86/hvm/io.h
>> > @@ -
On Wed, 24 Jun 2015, Roger Pau Monné wrote:
> El 23/06/15 a les 12.55, Stefano Stabellini ha escrit:
> > On Mon, 22 Jun 2015, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Jun 22, 2015 at 06:55:12PM +0100, Stefano Stabellini wrote:
> >>> Hi Roger,
> >>>
> >>> given that this patch series is actually us
>>> On 24.06.15 at 15:15, wrote:
> [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, wrote:
>> > On Wed, 2015-06-24 at 10:38 +0100, Ian Campbell wrote:
>> >> The memory info
>> >
1 - 100 of 322 matches
Mail list logo
