flight 44369 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44369/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44349
build-armhf
> -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 Beulich; 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 Beuli
On Wed, Apr 27, 2016 at 5:22 PM, Jim Fehlig wrote:
> On 04/27/2016 01:38 AM, Roger Pau Monné wrote:
>> On Tue, Apr 26, 2016 at 10:35:31PM -0600, Jim Fehlig wrote:
>>> qemu commit 91a097e7 forbids specifying the cache mode for empty
>>> drives. Attempting to create a domain with an empty qdisk cdro
On Wed, Apr 27, 2016 at 6:17 PM, tutu sky wrote:
>
> yeah, I do familiar with nested virtualization. but using xen in xen has less
> performance vs using xen in vmware, so i decided using vmware.
So you'd rather hard-crash your development box quickly than
successfully debug your guest OS a litt
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 4.7.0. And there will be no
pages with type p2m_mmio_write_dm, therefore HVMOP_get_mem_type will
never get the old type - HVM
On Wed, Apr 27, 2016 at 7:03 PM, Martin Cerveny wrote:
>
>
> On Wed, 27 Apr 2016, Fabio Fantoni wrote:
>
>> Il 27/04/2016 13:26, George Dunlap ha scritto:
>>>
>>> On 27/04/16 12:02, Fabio Fantoni wrote:
Hi, I took a look at the new pvusb hotplug code in libxl to try to add
also hotp
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 4.7.
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 4.7.0. And there will be no
pages with type p2m_mmio_write_dm, therefore HVMOP_get_mem_type will
never get the old type - HVM
On Wed, Apr 27, 2016 at 8:38 PM, Martin Cerveny wrote:
> Hello.
>
> I have problem with multiple ioreq_servers
> server 1 (emulates VGA) and server 2 (qemu).
>
> Emulation VGA server maps VGA PIO registers (3c0-3cf, 3b4-3b5 ...)
> Qemu maps "all" PIO space (0-)
> (ref:
> http://xenbits.xen.org
On Thu, Apr 28, 2016 at 3:37 AM, Big Strong wrote:
> There is a #VE exception defined in p2086 of Intel Software Development
> Manual, however, no definition of exception handler is availble in Xen 4.6.
> Should I define the handler by myself by modifying the source code of xen,
> or is there a wa
On 28/04/16 09:53, George Dunlap wrote:
> On Thu, Apr 28, 2016 at 3:37 AM, Big Strong wrote:
>> There is a #VE exception defined in p2086 of Intel Software Development
>> Manual, however, no definition of exception handler is availble in Xen 4.6.
>> Should I define the handler by myself by modifyi
Please don't cross-post unless you need to. These are coding
questions, so xen-devel is the right place to ask this.
On Thu, Apr 28, 2016 at 7:58 AM, Zhang, Chunyu wrote:
>
> hi all
>
> i have two question about ballon.
>
> 1.
> cfg:
> memory=4096
> maxmem=4096
>
> no pod was set , no
On Thu, Apr 28, 2016 at 05:08:50AM +, Ni, Ruiyu wrote:
>
>
> Regards,
> Ray
>
> >-Original Message-
> >From: Laszlo Ersek [mailto:ler...@redhat.com]
> >Sent: Wednesday, April 27, 2016 6:44 PM
> >To: Ni, Ruiyu ; Gary Lin
> >Cc: edk2-de...@lists.01.org ; Xen Devel
> >; Kinney, Michae
On Thu, Apr 28, 2016 at 09:27:30AM +0100, George Dunlap wrote:
> On Wed, Apr 27, 2016 at 5:22 PM, Jim Fehlig wrote:
> > On 04/27/2016 01:38 AM, Roger Pau Monné wrote:
> >> On Tue, Apr 26, 2016 at 10:35:31PM -0600, Jim Fehlig wrote:
> >>> qemu commit 91a097e7 forbids specifying the cache mode for e
These were found as "secondary" issues while trying to get REP MOVS
to guest MSI-X tables to properly work (the changes needed for that
one will constitute a second series about to be submitted).
1: fix emulation re-issue check
2: fix forwarding of internally cached requests (part 2)
Signed-off-b
flight 93041 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93041/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 878
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 28 April 2016 09:30
> To: xen-devel@lists.xen.org
> Cc: zhiyuan...@intel.com; Jan Beulich; Andrew Cooper; George Dunlap; Paul
> Durrant; Wei Liu
> Subject: [PATCH for 4.7] Remove HVMMEM_mmio_write_dm from the
Commit 96ae556569 ("x86/HVM: fix forwarding of internally cached
requests") wasn't quite complete: hvmemul_do_io() also needs to
propagate up the clipped count. (I really should have re-tested the
forward port resulting in the earlier change, instead of relying on the
testing done on the older vers
?: has lower precedence than !=, hence parentheses are required here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -134,7 +134,7 @@ static int hvmemul_do_io(
p = vio->io_req;
/* Verify the emulation request has been correctly
1: add further checks to snoop logic
2: also snoop qword writes
3: also snoop REP MOVS
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 28/04/16 10:12, Gary Lin wrote:
> On Thu, Apr 28, 2016 at 05:08:50AM +, Ni, Ruiyu wrote:
>>
>> Regards,
>> Ray
>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Wednesday, April 27, 2016 6:44 PM
>>> To: Ni, Ruiyu ; Gary Lin
>>> Cc: edk2-de...@list
On 28/04/16 10:32, Jan Beulich wrote:
> ?: has lower precedence than !=, hence parentheses are required here.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 27.04.16 at 18:36, wrote:
> On Wed, Apr 27, 2016 at 03:27:27AM -0600, Jan Beulich wrote:
>> >>> On 25.04.16 at 17:35, wrote:
>> > @@ -33,9 +36,43 @@ config.h: xen_hello_world_func.o
>> > xen_hello_world.o: xen_hello_world_func.o
>> >
>> > .PHONY: $(XSPLICE)
>> > -$(XSPLICE): config.h x
> -Original Message-
> From: George Dunlap
> Sent: 28 April 2016 09:51
> To: Martin Cerveny
> Cc: xen-de...@lists.xensource.com; Paolo Bonzini; Paul Durrant
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
>
> On Wed, Apr 27, 2016 at 8:38 PM, Martin Cerveny
msixtbl_range(), as any other MMIO ->check() handlers, may get called
with other than the base address of an access - avoid the snoop logic
considering those.
Also avoid considering vCPU-s not blocked in the hypervisor in
msixtbl_pt_register(), just to be on the safe side.
Signed-off-by: Jan Beul
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 10:33
> To: xen-devel
> Cc: Paul Durrant; Wei Liu
> Subject: [PATCH 2/2] x86/HVM: fix forwarding of internally cached requests
> (part 2)
>
> Commit 96ae556569 ("x86/HVM: fix forwarding of internally
Signed-off-by: Roger Pau Monné
---
Config.mk | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Config.mk b/Config.mk
index 9b097c9..67b26dd 100644
--- a/Config.mk
+++ b/Config.mk
@@ -45,6 +45,12 @@ DESTDIR ?= /
# Allow phony attribute to be listed as dependency rather than fake targe
... the high half of which may be a write to the Vector Control field.
This gets things in sync again with msixtbl_write().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -336,6 +336,7 @@ out:
static int msixtbl_range(struct vcpu *v, unsigned long addr
... as at least certain versions of Windows use such to update the
MSI-X table. However, to not overly complicate the logic for now
- only EFLAGS.DF=0 is being handled,
- only updates not crossing MSI-X table entry boundaries are handled.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
Hello,
On 27/04/16 23:53, Suriyan Ramasami wrote:
How can I check which core is currently active?
Judging by this link on big.LITTLE architecture:
http://forum.odroid.com/viewtopic.php?f=65&t=2580
result of: cat /proc/cpuinfo | grep "CPU part" is
CPU par
>>> On 28.04.16 at 11:35, wrote:
> 1: add further checks to snoop logic
> 2: also snoop qword writes
> 3: also snoop REP MOVS
>
> Signed-off-by: Jan Beulich
Wei,
I've only now realized that I should have Cc-ed you on this series (all
intended for 4.7).
Jan
__
On Wed, Apr 27, 2016 at 08:49:23PM -0600, Jim Fehlig wrote:
> On 04/27/2016 04:22 PM, Andrew Cooper wrote:
> > On 27/04/2016 22:58, Jim Fehlig wrote:
> >> On 04/25/2016 05:26 AM, osstest service owner wrote:
> >>> flight 92667 libvirt real [real]
> >>> http://logs.test-lab.xenproject.org/osstest/lo
On 28/04/16 10:33, Jan Beulich wrote:
> Commit 96ae556569 ("x86/HVM: fix forwarding of internally cached
> requests") wasn't quite complete: hvmemul_do_io() also needs to
> propagate up the clipped count. (I really should have re-tested the
> forward port resulting in the earlier change, instead of
>>> On 28.04.16 at 09:14, wrote:
>> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
>> Sent: 28 April 2016 03:47
>> Besides, do you think it acceptable we just replace p2m_mmio_write_dm
>> with p2m_ioreq_server in next version, or should we remove this p2m
>> type and define p2m_ioreq_server w
On 28/04/16 10:54, Wei Liu wrote:
> On Wed, Apr 27, 2016 at 08:49:23PM -0600, Jim Fehlig wrote:
>> On 04/27/2016 04:22 PM, Andrew Cooper wrote:
>>> On 27/04/2016 22:58, Jim Fehlig wrote:
On 04/25/2016 05:26 AM, osstest service owner wrote:
> flight 92667 libvirt real [real]
> http://lo
hi george
>Please don't cross-post unless you need to. These are coding
>questions, so xen-devel is the right place to ask this.
>
>On Thu, Apr 28, 2016 at 7:58 AM, Zhang, Chunyu wrote:
>>
>> hi all
>>
>> i have two question about ballon.
>>
>> 1.
>> cfg:
>> memory=4096
>> maxmem=4096
>
>>> On 28.04.16 at 11:48, wrote:
> Signed-off-by: Roger Pau Monné
> ---
> Config.mk | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Config.mk b/Config.mk
> index 9b097c9..67b26dd 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -45,6 +45,12 @@ DESTDIR ?= /
> # Allow phony att
>>> On 27.04.16 at 18:06, wrote:
> Clarify the meaning of nested maintainership.
>
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Apr 28, 2016 at 04:09:46AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 11:48, wrote:
> > Signed-off-by: Roger Pau Monné
> > ---
> > Config.mk | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Config.mk b/Config.mk
> > index 9b097c9..67b26dd 100644
> > --- a/Config.
On Wed, Apr 27, 2016 at 11:22:37PM +0100, Andrew Cooper wrote:
> On 27/04/2016 22:58, Jim Fehlig wrote:
> > On 04/25/2016 05:26 AM, osstest service owner wrote:
> >> flight 92667 libvirt real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/92667/
> >>
> >> Regressions :-(
> >>
> >> Tes
On Thu, Apr 28, 2016 at 04:09:46AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 11:48, wrote:
> > Signed-off-by: Roger Pau Monné
> > ---
> > Config.mk | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Config.mk b/Config.mk
> > index 9b097c9..67b26dd 100644
> > --- a/Config.
On 28/04/16 10:49, Jan Beulich wrote:
> msixtbl_range(), as any other MMIO ->check() handlers, may get called
> with other than the base address of an access - avoid the snoop logic
> considering those.
>
> Also avoid considering vCPU-s not blocked in the hypervisor in
> msixtbl_pt_register(), just
>>> 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)
> [HVMMEM_ram_rw] = p2m_ram_rw,
> [HVMMEM_ram_ro] = p2m_ram_ro,
> [HVMMEM_mmio_dm] = p2m_mmio_dm,
> -[HVMMEM_mmio_writ
On Thu, Apr 28, 2016 at 03:51:40AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 11:35, wrote:
> > 1: add further checks to snoop logic
> > 2: also snoop qword writes
> > 3: also snoop REP MOVS
> >
> > Signed-off-by: Jan Beulich
>
> Wei,
>
> I've only now realized that I should have Cc-ed you
On Wed, Apr 27, 2016 at 05:06:27PM +0100, George Dunlap wrote:
> Clarify the meaning of nested maintainership.
>
> Signed-off-by: George Dunlap
> ---
> We had a discussion about the meaning of nested maintainership at the
> recent Xen Hackathon. The notes of that meeting can be found on this
> l
On Thu, Apr 28, 2016 at 03:21:23AM -0600, Jan Beulich wrote:
> These were found as "secondary" issues while trying to get REP MOVS
> to guest MSI-X tables to properly work (the changes needed for that
> one will constitute a second series about to be submitted).
>
> 1: fix emulation re-issue check
On 28/04/16 10:49, Jan Beulich wrote:
> ... the high half of which may be a write to the Vector Control field.
> This gets things in sync again with msixtbl_write().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
On 28/04/16 07:39, Peng Fan wrote:
Hi Julien,
Hello Peng,
On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote:
Hi Julien,
On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall wrote:
Hello Peng,
On 27/04/2016 03:02, Peng Fan wrote:
On Tue, Apr 26, 2016 at 04:30:03PM +0200, Edgar E
On 28/04/16 10:50, Jan Beulich wrote:
> ... as at least certain versions of Windows use such to update the
> MSI-X table. However, to not overly complicate the logic for now
> - only EFLAGS.DF=0 is being handled,
> - only updates not crossing MSI-X table entry boundaries are handled.
>
> Signed-off
On 04/28/16 07:08, Ni, Ruiyu wrote:
Do you know whether Xen passes the PCI device resource
information to firmware?
>>
>> I don't think so, no.
>>
>> But, given that the previous PciHostBridgeDxe driver was working on Xen,
>> can we perhaps emulate that behavior in
>> "OvmfPkg/Library/P
On 27/04/16 16:48, Tamas K Lengyel wrote:
> Don't propagate altp2m changes from ept_set_entry for memshare as memshare
> already has the lock. We call altp2m propagate changes once memshare
> successfully finishes. Allow the hostp2m entries to be of type
> p2m_ram_shared when applying mem_access. A
>>> On 27.04.16 at 16:42, wrote:
> The current test performed in order to check if the assembler supports
> certain instructions doesn't take into account the value of AFLAGS, which
> when using clang contains the option that disables the integrated assembler
> due to the lack of features.
>
> As
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 11:23
> To: Yu Zhang
> Cc: Andrew Cooper; Paul Durrant; Wei Liu; George Dunlap;
> zhiyuan...@intel.com; xen-devel@lists.xen.org
> Subject: Re: [PATCH for 4.7] Remove HVMMEM_mmio_write_dm from the
> pub
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)
>> [HVMMEM_ram_rw] = p2m_ram_rw,
>> [HVMMEM_ram_ro] = p2m_ram_ro,
>> [HVMMEM_mmio_dm] = p
On 28/04/16 09:29, 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 4.7.0. And there will be no
> pages with type p2m_mmio_write_dm, therefore HVMOP_get
>>> On 28.04.16 at 12:34, wrote:
> On 28/04/16 10:50, Jan Beulich wrote:
>> ... as at least certain versions of Windows use such to update the
>> MSI-X table. However, to not overly complicate the logic for now
>> - only EFLAGS.DF=0 is being handled,
>> - only updates not crossing MSI-X table entr
Got it. Thanks for the replying.
2016-04-28 17:03 GMT+08:00 Andrew Cooper :
> On 28/04/16 09:53, George Dunlap wrote:
> > On Thu, Apr 28, 2016 at 3:37 AM, Big Strong wrote:
> >> There is a #VE exception defined in p2086 of Intel Software Development
> >> Manual, however, no definition of excepti
hi Geoge,
I don't get your meaning. would you please repeat your question for me in order
to understand it?
Thanks and regards.
From: dunl...@gmail.com on behalf of George Dunlap
Sent: Thursday, April 28, 2016 8:32 AM
To: tutu sky
Cc: Dario Faggioli; J
On Thu, Apr 28, 2016 at 04:29:57PM +0800, 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 4.7.0. And there will be no
> pages with type p2m_mmio_write_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 10:50
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant
> Subject: [PATCH 2/3] x86/vMSI-X: also snoop qword writes
>
> ... the high half of which may be a write to the Vector Control field.
> This get
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 10:49
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant
> Subject: [PATCH 1/3] x86/vMSI-X: add further checks to snoop logic
>
> msixtbl_range(), as any other MMIO ->check() handlers, may get called
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 11:03
> To: Paul Durrant
> Cc: Andrew Cooper; George Dunlap; Wei Liu; JunNakajima; Kevin Tian;
> Zhiyuan Lv; Zhang Yu; xen-devel@lists.xen.org; Keir (Xen.org); Tim (Xen.org)
> Subject: RE: [Xen-devel]
On Tue, Apr 26, 2016 at 09:38:45AM -0500, Doug Goldstein wrote:
> When building debug use -Og as the optimization level if its available,
> otherwise retain the use of -O0. -Og has been added by GCC to enable all
> optimizations that to not affect debugging while retaining full
> debugability.
>
>
>>> 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)
>>> [HVMMEM_ram_rw] = p2m_ram_rw,
>>> [HVMMEM_ram_ro] = p2m_ram_r
>>> On 27.04.16 at 21:26, wrote:
> The implementation does not actually do any patching.
>
> It just adds the framework for doing the hypercalls,
> keeping track of ELF payloads, and the basic operations:
> - query which payloads exist,
> - query for specific payloads,
> - check*1, apply*1, re
Hello.
On Thu, 28 Apr 2016, Paul Durrant wrote:
-Original Message-
From: George Dunlap
Sent: 28 April 2016 09:51
To: Martin Cerveny
Cc: xen-de...@lists.xensource.com; Paolo Bonzini; Paul Durrant
Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
(Xen4.6.1)
On Wed, Apr 27
>>> On 27.04.16 at 21:27, wrote:
> From: Ross Lagerwall
>
> Add Elf routines and data structures in preparation for loading an
> xSplice payload.
>
> We make an assumption that the max number of sections an ELF payload
> can have is 64. We can in future make this be dependent on the
> names of
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 10:50
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant
> Subject: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>
> ... as at least certain versions of Windows use such to update the
> MSI-X table. How
>>> On 27.04.16 at 21:27, wrote:
> From: Ross Lagerwall
>
> Add support for loading xsplice payloads. This is somewhat similar to
> the Linux kernel module loader, implementing the following steps:
> - Verify the elf file.
> - Parse the elf file.
> - Allocate a region of memory mapped within a f
On Wed, Apr 27, 2016 at 06:03:54PM +0100, George Dunlap wrote:
> On 26/04/16 14:44, Wei Liu wrote:
> > Hi all
> >
> > I spent some time this morning to work out the details of xen.git build
> > system.
> >
> > * How build system works at the moment?
> > 1. Stubdom.mk.in and Tools.mk.in define F
> -Original Message-
> From: Martin Cerveny [mailto:mar...@c-home.cz]
> Sent: 28 April 2016 12:17
> To: Paul Durrant
> Cc: George Dunlap; Martin Cerveny; xen-de...@lists.xensource.com; Paolo
> Bonzini
> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
>
> Hell
>>> On 27.04.16 at 21:27, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/test/Makefile
> @@ -0,0 +1,42 @@
> +include $(XEN_ROOT)/Config.mk
> +
> +CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
> +CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
> +
>>> On 27.04.16 at 21:27, wrote:
> --- a/xen/arch/x86/test/Makefile
> +++ b/xen/arch/x86/test/Makefile
> @@ -6,17 +6,20 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{
> print "0x"$$2}')
> .PHONY: default
>
> XSPLICE := xen_hello_world.xsplice
> +XSPLICE_BYE := xen_bye_world.xspl
>>> On 27.04.16 at 21:27, wrote:
> --- a/xen/arch/x86/test/Makefile
> +++ b/xen/arch/x86/test/Makefile
> @@ -7,15 +7,18 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{
> print "0x"$$2}')
>
> XSPLICE := xen_hello_world.xsplice
> XSPLICE_BYE := xen_bye_world.xsplice
> +XSPLICE_REPL
>>> On 28.04.16 at 13:17, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 April 2016 10:50
>> @@ -366,7 +367,22 @@ static int msixtbl_range(struct vcpu *v,
>> ((addr & (PCI_MSIX_ENTRY_SIZE - 1)) ==
>>PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET) &&
>>
Jan informed me on IRC that this series is ready to go in (with minor
adjustments). I also went through this series briefly and was satisfied
with it, so:
Release-acked-by: Wei Liu
Feel free to stick that to later versions as well.
Thanks everyone!
Wei.
___
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 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 the point of going through
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 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
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 12:44
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel
> Subject: RE: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>
> >>> On 28.04.16 at 13:17, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.co
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 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 28.04.16 at 12:42, wrote:
On 28/04/16 11:22, Jan Beulich wrote:
On 28.04.16 at
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 28.04.16 at 12:42,
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 28
>>> On 28.04.16 at 14:00, wrote:
>
> 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 a
>>> On 28.04.16 at 13:58, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 April 2016 12:44
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-devel
>> Subject: RE: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>>
>> >>> On 28.04.16 at 13:17, wrote:
>> >
>>> On 28.04.16 at 14:06, 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 Beul
>>> 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 go in as is, I just inquired
because
On Thu, Apr 28, 2016 at 06:34:48AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 14:06, 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 admi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 April 2016 13:31
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel
> Subject: RE: [PATCH 3/3] x86/vMSI-X: also snoop REP MOVS
>
> >>> On 28.04.16 at 13:58, wrote:
> >> -Original Message-
> >> From: Jan
On 25/04/16 12:18, Stefano Stabellini wrote:
> From: Jan Beulich
>
> For vtsc=1 PV guests, rdtsc is trapped and calculated from get_s_time()
> using gtime_to_gtsc. Similarly the tsc_timestamp, part of struct
> vcpu_time_info, is calculated from stime_local_stamp using
> gtime_to_gtsc.
>
> However
On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote:
>
>
>On 28/04/16 07:39, Peng Fan wrote:
>>Hi Julien,
>
>Hello Peng,
>
>>On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote:
>>>Hi Julien,
>>>On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall wrote:
Hello Peng,
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
Hello,
On 28/04/16 13:56, Peng Fan wrote:
On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote:
On 28/04/16 07:39, Peng Fan wrote:
Hi Julien,
Hello Peng,
On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote:
Hi Julien,
On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall w
> Xen is not ready for big.LITTLE, so I would highly recommend you to
> disable either all the Cortex-A15 or Cortex-A7.
> For your information, I am planning to send a patch to park any CPUs
> whose MIDR is not matching the boot CPU one.
> Julien Grall
Ok,
I decided to use A15s... How can I
flight 93056 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
Hello Julien,
Thank you for the advice. I do have a follow up question.
On Thu, Apr 28, 2016 at 2:50 AM, Julien Grall wrote:
> Hello,
>
> On 27/04/16 23:53, Suriyan Ramasami wrote:
>
> How can I check which core is currently active?
>> Judging by this link on big.LITTLE archi
Hi Julien,
Sorry for the late reply.
I have ported the basic framework to make it work. It
can be built and boot, but still in the early stage (lots
of functions are there but empty). The code on my github
(https://github.com/baozich/mini-os) is the latest version
(though there have been a long t
Hi Julien
Can you also CC minios-devel@ in the future for relevant discussions?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
1 - 100 of 165 matches
Mail list logo
