On 05/07/15 08:47, lidonglin wrote:
> Dear all：
> New issue：
> Guest BSOD and restart when using OVMF to boot and install windows8
> 64bit OS(which owns more than 4G memmory)。
> My environment as below:
> xen 4.5.0
> qemu 2.2.1
> ovmf git clone from git://xenbits.xen.org/ovmf.git (comm
Hello,
El 06/05/15 a les 19.10, Michael Dexter ha escrit:
> On 5/6/15 9:50 AM, Andrew Cooper wrote:
>> Are you using a full debug Xen?
>
> I have been working with binary packages and I will assume it has not
> been built with any debug options. Roger can elaborate on this.
It's a build of Xen 4
El 07/05/15 a les 8.36, Jan Beulich ha escrit:
Michael Dexter 05/06/15 6:29 PM >>>
>> I have been working with Roger Pau Monné to bring FreeBSD Dom0 support
>> to a production-ready state but we appear to have hit an IOMMU issue.
>>
>> Hardware: Lenovo ThinkPad T420 i7-2640M CPU @ 2.80GHz wi
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, May 06, 2015 7:37 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com;
> Hu,
> Robert
> Subject: Re: [OSSTEST Nested PATCH v9 7/9] Add new scrip
Cc Andrew cooper
Sorry I missed your address...
On 05/07/2015 02:37 PM, Yang Hongyang wrote:
This patchset implement the Remus support for Migration v2 but without
memory compressing.
PATCH 1-5: Some refactor and prepare work.
PATCH 6-7: The main Remus loop implement.
PATCH 8: Fix for Remus.
On Wed, May 06, 2015 at 07:08:44AM +, Olaf Hering wrote:
> The current base directory /var/xen for domU dumps will be patched to
> /var/lib/xen by most distros. Provide a configure option to avoid
> patching the source.
>
> If the option is not specified the default remains /var/xen/dump.
>
>
On 5/7/15 12:27 AM, Roger Pau Monné wrote:
Michael can probably elaborate on this, but if I'm not mistaken he can
use X on the Dom0 without problems, but when he launches a guest all
those IOMMU faults start showing up. Then if the guest is created
without X running everything works as expected (
On Wed, May 06, George Dunlap wrote:
> On Fri, Apr 24, 2015 at 11:25 AM, Olaf Hering wrote:
> > Replace all private variables in Makefiles with automake variables.
> > This series is based on 92ff75384bce7a11e27fbfaf0c531e88dd1ab4c7.
>
> Why?
Thanks for your reply. The rationale comes from the
On Thu, May 07, Wei Liu wrote:
> On Wed, May 06, 2015 at 07:08:44AM +, Olaf Hering wrote:
> > The current base directory /var/xen for domU dumps will be patched to
> > /var/lib/xen by most distros. Provide a configure option to avoid
> > patching the source.
> > If the option is not specifie
On Thu, May 07, 2015 at 10:10:51AM +0200, Olaf Hering wrote:
> On Thu, May 07, Wei Liu wrote:
>
> > On Wed, May 06, 2015 at 07:08:44AM +, Olaf Hering wrote:
> > > The current base directory /var/xen for domU dumps will be patched to
> > > /var/lib/xen by most distros. Provide a configure optio
On Wed, May 06, Wei Liu wrote:
> On Wed, May 06, 2015 at 10:58:11AM +0200, Olaf Hering wrote:
> > On Wed, May 06, Olaf Hering wrote:
> >
> > > Since libvirtd runs forever there is very little code to undo most
> > > things. But I will see if there is any unload function, did not actively
> > > lo
On 06/05/15 19:56, Julien Grall wrote:
His email address is bouncing from more than a month.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Zoltan Kiss
---
I've heard he left Huawei.
Yes, he left indeed.
---
MAINTAINERS | 1 -
1 file changed, 1 d
On Thu, May 07, Zoltan Kiss wrote:
> Yes, he left indeed.
> > M: Zoltan Kiss
What about you? ;-)
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Upcoming changes for vscsi will use libxlutil.so to prepare the
configuration for libxl. The helpers needs a xlu struct for logging.
Provide one and reuse the existing output as log target.
Signed-off-by: Olaf Hering
Cc: Jim Fehlig
---
v2:
- call xlu_cfg_destroy, unconditionally
- fix cpp ind
I'm still working there, but as a Linaro assignee for LNG. Julian's last
mail fell through unfortunately, sorry about that.
Zoli
On 07/05/15 09:25, Olaf Hering wrote:
On Thu, May 07, Zoltan Kiss wrote:
Yes, he left indeed.
M:Zoltan Kiss
What about you? ;-)
Olaf
_
Hi Julien,
On 5 May 2015 at 19:22, Julien Grall wrote:
> Hi Pranav,
>
> On 29/04/15 10:38, Pranavkumar Sawargaonkar wrote:
>> In old X-Gene Storm firmware and DT, secure mode addresses have been
>> mentioned in GICv2 node. In this case maintenance interrupt is used
>> instead of EOI HW method.
>>
Looks good at first glance, let me try it on a board.
On 06/05/15 19:52, Julien Grall wrote:
The GIC hip04 driver was differring from GICv2. I suspect that some of
the changes in the common GIC code make boot fail on hip04. Although, I
don't have a platform to check so it has been only build tes
I just git clone ovmf from official edk2 git repo ang git latest qemu 2.3.50.
But the issue still exists. Besides, I find windows server 2012 has the same
BSOD issue but windows 8.1 works normally.
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: 2015年5月7日 15:03
Handle NULL pointer passed to xlu_cfg_destroy. libvirt calls it in its
libxlDriverConfigDispose function. If the XLU_Config was not initialized
yet for some reason a crash would occour on cleanup.
Avoid the crash just like libxl_ctx_free and xtl_logger_destroy do when
called from the same context.
On Thu, May 07, 2015 at 10:20:23AM +0200, Olaf Hering wrote:
> On Wed, May 06, Wei Liu wrote:
>
> > On Wed, May 06, 2015 at 10:58:11AM +0200, Olaf Hering wrote:
> > > On Wed, May 06, Olaf Hering wrote:
> > >
> > > > Since libvirtd runs forever there is very little code to undo most
> > > > things
flight 53023 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/53023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR.
vs. 36755
test-am
HVM guests which do not include PV drivers will not shutdown after a
simple "xl shutdown". Add a runvar to indicate that the guest will
shutdown in response to an ACPI power event and apply this to the win7
and winxp test jobs.
Tested with:
test-amd64-amd64-xl-qemuu-winxpsp3
test-amd64-amd
On Fri, Apr 24, 2015 at 03:59:32PM +0100, Jan Beulich wrote:
> >>> On 23.04.15 at 11:55, wrote:
> > struct psr_cmt *__read_mostly psr_cmt;
> > +
> > +static unsigned long __read_mostly * cat_socket_init_bitmap;
> > +static unsigned long __read_mostly * cat_socket_enable_bitmap;
> > +static struct
On Wed, 2015-05-06 at 17:02 +0100, Stefano Stabellini wrote:
> On Wed, 6 May 2015, Ian Campbell wrote:
> > On Wed, 2015-05-06 at 15:43 +0100, Stefano Stabellini wrote:
> > [...]
> > > +echo >>config ENABLED_COMPONENTS=\\"seabios ovmf xen qemu
> > > qemu_traditional libvirt\\"
> > [...]
> > > +
On Thu, 2015-05-07 at 07:42 +, Pang, LongtaoX wrote:
[...]
> Thanks for trying, I tried it in my environment, a reboot is not required now.
> I think this bug happened just because I have used '
> Debian-7.6.0-amd64-DVD-1.iso ' as installing L1's guest OS before,
> it did required a reboot an
On Thu, 2015-05-07 at 10:10 +0200, Olaf Hering wrote:
> On Thu, May 07, Wei Liu wrote:
>
> > On Wed, May 06, 2015 at 07:08:44AM +, Olaf Hering wrote:
> > > The current base directory /var/xen for domU dumps will be patched to
> > > /var/lib/xen by most distros. Provide a configure option to av
On Thu, May 07, 2015 at 08:54:26AM +, Olaf Hering wrote:
> Handle NULL pointer passed to xlu_cfg_destroy. libvirt calls it in its
> libxlDriverConfigDispose function. If the XLU_Config was not initialized
> yet for some reason a crash would occour on cleanup.
> Avoid the crash just like libxl_c
On Thu, 2015-05-07 at 09:02 +0200, Laszlo Ersek wrote:
> (Plus, you are cloning a git repo that may or may not be
> identical to the (semi-)official edk2 git repo.)
FWIW git://xenbits.xen.org/ovmf.git is a direct descendant of the
https://github.com/tianocore/edk2.git (which I hope is the
(semi-)o
On 07/05/15 08:04, Hongyang Yang wrote:
> Cc Andrew cooper
>
> Sorry I missed your address...
No worries. You have managed a far faster turnaround on this than I
have with libxl migration v2!
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Thu, 7 May 2015, Ian Campbell wrote:
> On Wed, 2015-05-06 at 17:02 +0100, Stefano Stabellini wrote:
> > On Wed, 6 May 2015, Ian Campbell wrote:
> > > On Wed, 2015-05-06 at 15:43 +0100, Stefano Stabellini wrote:
> > > [...]
> > > > +echo >>config ENABLED_COMPONENTS=\\"seabios ovmf xen qemu
>
On Thu, 2015-05-07 at 09:52 +0100, Zoltan Kiss wrote:
> Looks good at first glance, let me try it on a board.
>
> On 06/05/15 19:52, Julien Grall wrote:
[...]
> > I'm concerned to see a newly driver (pushed last march) already orphan.
> > Does Huawei still plan to maintain this driver?
I share Ju
flight 53718 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/53718/
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
On Thu, 2015-05-07 at 10:31 +0100, Stefano Stabellini wrote:
> On Thu, 7 May 2015, Ian Campbell wrote:
> > On Wed, 2015-05-06 at 17:02 +0100, Stefano Stabellini wrote:
> > > On Wed, 6 May 2015, Ian Campbell wrote:
> > > > On Wed, 2015-05-06 at 15:43 +0100, Stefano Stabellini wrote:
> > > > [...]
>
On Thu, 2015-05-07 at 14:19 +0530, Pranavkumar Sawargaonkar wrote:
> Hi Julien,
>
> On 5 May 2015 at 19:22, Julien Grall wrote:
> > Hi Pranav,
> >
> > On 29/04/15 10:38, Pranavkumar Sawargaonkar wrote:
> >> In old X-Gene Storm firmware and DT, secure mode addresses have been
> >> mentioned in GIC
At 11:53 +0100 on 05 May (1430826812), Andrew Cooper wrote:
> On 05/05/15 11:25, Paul Durrant wrote:
> > There are actually very few HVM parameters that a guest needs to read
> > and even fewer that a guest needs to write. Use white-lists to specify
> > those parameters and also ensre that, by defa
On 07/05/15 07:37, Yang Hongyang wrote:
> Move the memory allocation before the concrete live/nolive save
> in order to avoid the free/alloc memory loop when using Remus.
>
> Signed-off-by: Yang Hongyang
> ---
> tools/libxc/xc_sr_save.c | 53
> +++-
>
Hi Zoltan,
On 07/05/2015 09:21, Zoltan Kiss wrote:
On 06/05/15 19:56, Julien Grall wrote:
His email address is bouncing from more than a month.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Zoltan Kiss
---
I've heard he left Huawei.
Yes, he left ind
On 07/05/15 07:37, Yang Hongyang wrote:
> introduce bitmap_set() to set the entire bitmap.
> in send_all_pages(), set the entire bitmap and call send_some_pages().
>
> Signed-off-by: Yang Hongyang
Ah - I see now why you unconditionally allocated the to_send bitmap.
I suppose it is probably bette
On Thu, 2015-05-07 at 10:07 +0100, Ian Campbell wrote:
> HVM guests which do not include PV drivers will not shutdown after a
> simple "xl shutdown". Add a runvar to indicate that the guest will
> shutdown in response to an ACPI power event and apply this to the win7
> and winxp test jobs.
>
> Tes
On 07/05/15 10:52, Julien Grall wrote:
Hi Zoltan,
On 07/05/2015 09:21, Zoltan Kiss wrote:
On 06/05/15 19:56, Julien Grall wrote:
His email address is bouncing from more than a month.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Zoltan Kiss
---
I'v
On 07/05/15 07:37, Yang Hongyang wrote:
> Move record handle codes into a function process_record().
> It will be used multiple times by Remus.
> No functional change.
>
> Signed-off-by: Yang Hongyang
Reviewed-by: Andrew Cooper
___
Xen-devel mailing
At 16:31 +0100 on 05 May (1430843498), Jan Beulich wrote:
> >>> On 05.05.15 at 17:17, wrote:
> > At 16:10 +0100 on 05 May (1430842206), Jan Beulich wrote:
> >> From what I
> >> can tell (and assuming other code works correctly) the fact that
> >> arch_iommu_populate_page_table() sets d->need_iommu
On 07/05/15 07:37, Yang Hongyang wrote:
> Set the hvm param HVM_PARAM_IDENT_PT second time will fail.
> So defer the setting of HVM_PARAM_IDENT_PT.
>
> Signed-off-by: Yang Hongyang
I would argue that this is a Xen bug, not a migration bug. There is
nothing conceptually wrong with setting this pa
Having xenalyze in the source tree makes it much easier to keep private
debug code in hypervisor and xenalyze in sync. It helped alot while
debugging the root cause for commit 607e8494c42397fb249191904066cace6ac9a880.
changes between v1 and v2:
- move to tools/xentrace/xenalyze
- drop patch whic
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/xenalyze.c | 73 ++
1 file changed, 66 insertions(+), 7 deletions(-)
diff --git a/tools/xentrace/xenalyze/xenalyze.c
b/tools/xentrac
Result of "sed -i 's@[[:blank:]]\+$@@' tools/xentrace/xenalyze/xenalyze.c"
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/xenalyze.c | 350 ++---
1 file changed, 175 insertions(+), 175
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze/xenalyze.c
b/tools/xentrace/xenalyze/xenalyze.c
index 5f0757b..51a
Since xenalyze is now upstream its Open Source and part of the given
release.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/xenalyze.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/xentrace/xenalyze/xenal
To match the hypervisor default which was introduced in
9da0c5b63933b9912e3903190601661813954d0d, bump the limit.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/analyze.h | 2 +-
1 file changed, 1 insertion(+), 1 del
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze/xenalyze.c
b/tools/xentrace/xenalyze/xenalyze.c
index 51a2d1d..58e
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze/xenalyze.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/xentrace/xenalyze/xenalyze.c
b/tools/xentrace/xenalyze/xenalyze.c
index 58e8456..0566d00 100644
--
On 07/05/15 07:37, Yang Hongyang wrote:
> Split read/handle qemu info. The receiving of qemu info
> should be done while we receive the migration stream,
> handle_qemu will be called when the stream complete.
> Otherwise, it will break Remus because read_record()
> won't read qemu info and stream_c
Hi,
At 16:54 +0100 on 05 May (1430844841), Jan Beulich wrote:
> So comparing current and new schemes things would go
>
> OLD NEW
> 4.6-unstable5.0-unstable (or 5.0.0)
> 4.6.0-rc1 5.0.1 (-rc1)
> ... .
On 07/05/15 07:37, Yang Hongyang wrote:
> X86_PV_INFO can be sent multiple times under Remus
>
> Signed-off-by: Yang Hongyang
X86_PV_INFO cannot be sent multiple times. If any information in it
were to change, the receiving side would have no choice other than to
abort the restore.
I think this
At 17:38 +0100 on 05 May (1430847486), Lars Kurth wrote:
> Hi all,
>
> one piece of feedback we got at the last and this Hackathon, was that the
> name for the event is really misleading. Although some Hacking goes on, in
> reality the event is really more of an Architecture, Design and Deployme
Hi Ian,
On 7 May 2015 at 15:11, Ian Campbell wrote:
> On Thu, 2015-05-07 at 14:19 +0530, Pranavkumar Sawargaonkar wrote:
>> Hi Julien,
>>
>> On 5 May 2015 at 19:22, Julien Grall wrote:
>> > Hi Pranav,
>> >
>> > On 29/04/15 10:38, Pranavkumar Sawargaonkar wrote:
>> >> In old X-Gene Storm firmware
On 05/07/15 11:29, Ian Campbell wrote:
> On Thu, 2015-05-07 at 09:02 +0200, Laszlo Ersek wrote:
>> (Plus, you are cloning a git repo that may or may not be
>> identical to the (semi-)official edk2 git repo.)
>
> FWIW git://xenbits.xen.org/ovmf.git is a direct descendant of the
> https://github.com
>>> On 07.05.15 at 11:08, wrote:
> On Fri, Apr 24, 2015 at 03:59:32PM +0100, Jan Beulich wrote:
>> >>> On 23.04.15 at 11:55, wrote:
>> > struct psr_cmt *__read_mostly psr_cmt;
>> > +
>> > +static unsigned long __read_mostly * cat_socket_init_bitmap;
>> > +static unsigned long __read_mostly * cat
>>> On 07.05.15 at 09:27, wrote:
> El 07/05/15 a les 8.36, Jan Beulich ha escrit:
> Michael Dexter 05/06/15 6:29 PM >>>
>>> I have been working with Roger Pau Monné to bring FreeBSD Dom0 support
>>> to a production-ready state but we appear to have hit an IOMMU issue.
>>>
>>> Hardware: Lenov
Hi Pranav,
On 07/05/15 12:12, Pranavkumar Sawargaonkar wrote:
> On 7 May 2015 at 15:11, Ian Campbell wrote:
>> On Thu, 2015-05-07 at 14:19 +0530, Pranavkumar Sawargaonkar wrote:
>>> Hi Julien,
>>>
>>> On 5 May 2015 at 19:22, Julien Grall wrote:
Hi Pranav,
On 29/04/15 10:38, Pranav
>>> On 07.05.15 at 10:05, wrote:
> On 5/7/15 12:27 AM, Roger Pau Monné wrote:
>> Michael can probably elaborate on this, but if I'm not mistaken he can
>> use X on the Dom0 without problems, but when he launches a guest all
>> those IOMMU faults start showing up. Then if the guest is created
>> wi
On Thu, 2015-05-07 at 12:00 +0100, Tim Deegan wrote:
> At 17:38 +0100 on 05 May (1430847486), Lars Kurth wrote:
> > The current proposal is to Rename the Xen Project Hackathons to either
> > a) Xen Project Architecture & Design Summit,
> > b) or Xen Project Design Summit
>
> IMO (b) is a better
flight 53039 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/53039/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 52702
test-amd64-amd64-xl-cr
Hi,
On 07/05/15 10:32, Ian Campbell wrote:
On Thu, 2015-05-07 at 09:52 +0100, Zoltan Kiss wrote:
Looks good at first glance, let me try it on a board.
On 06/05/15 19:52, Julien Grall wrote:
[...]
I'm concerned to see a newly driver (pushed last march) already orphan.
Does Huawei still plan t
Handing INVALID_GFN to functions like hd->platform_ops->map_page()
just can't do any good, and the ioreq server code results in such pages
being on the list of ones owned by a guest.
While - as suggested by Tim - we should use get_gfn()/put_gfn() there
to eliminate races, we really can't due to ho
>>> On 06.05.15 at 17:10, wrote:
> In fact, before this change, if bringing up or tearing down a
> CPU fails with -EBUSY, we BUG_ON() and never get to see what
> CPU caused the problem.
>
> Signed-off-by: Dario Faggioli
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Keir Fraser
> ---
> xen/comm
On 07/05/15 13:59, Jan Beulich wrote:
> Handing INVALID_GFN to functions like hd->platform_ops->map_page()
> just can't do any good, and the ioreq server code results in such pages
> being on the list of ones owned by a guest.
>
> While - as suggested by Tim - we should use get_gfn()/put_gfn() ther
On 05/07/2015 05:48 PM, Andrew Cooper wrote:
On 07/05/15 07:37, Yang Hongyang wrote:
Move the memory allocation before the concrete live/nolive save
in order to avoid the free/alloc memory loop when using Remus.
Signed-off-by: Yang Hongyang
---
tools/libxc/xc_sr_save.c | 53 +++
At 14:18 +0200 on 07 May (1431008321), Dario Faggioli wrote:
> On Thu, 2015-05-07 at 12:00 +0100, Tim Deegan wrote:
> > At 17:38 +0100 on 05 May (1430847486), Lars Kurth wrote:
>
> > > The current proposal is to Rename the Xen Project Hackathons to either
> > > a) Xen Project Architecture & Design
On 05/07/2015 06:08 PM, Andrew Cooper wrote:
On 07/05/15 07:37, Yang Hongyang wrote:
introduce bitmap_set() to set the entire bitmap.
in send_all_pages(), set the entire bitmap and call send_some_pages().
Signed-off-by: Yang Hongyang
Ah - I see now why you unconditionally allocated the to_
>>> On 07.05.15 at 15:13, wrote:
> On 07/05/15 13:59, Jan Beulich wrote:
>> @@ -729,12 +733,15 @@ int amd_iommu_unmap_page(struct domain *
>> * we might need a deeper page table for lager gfn now */
>> if ( is_hvm_domain(d) )
>> {
>> -if ( update_paging_mode(d, gfn) )
>> +
On 06/05/2015 19:14, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 05/07/2015 06:48 PM, Andrew Cooper wrote:
On 07/05/15 07:37, Yang Hongyang wrote:
Split read/handle qemu info. The receiving of qemu info
should be done while we receive the migration stream,
handle_qemu will be called when the stream complete.
Otherwise, it will break Remus because read_re
On Thu, 2015-05-07 at 21:42 +0800, Hongyang Yang wrote:
>
> On 05/07/2015 05:48 PM, Andrew Cooper wrote:
> > On 07/05/15 07:37, Yang Hongyang wrote:
> >> Move the memory allocation before the concrete live/nolive save
> >> in order to avoid the free/alloc memory loop when using Remus.
> >>
> >> Si
On 07/05/15 14:42, Hongyang Yang wrote:
>
>
> On 05/07/2015 05:48 PM, Andrew Cooper wrote:
>> On 07/05/15 07:37, Yang Hongyang wrote:
>>> Move the memory allocation before the concrete live/nolive save
>>> in order to avoid the free/alloc memory loop when using Remus.
>>>
>>> Signed-off-by: Yang Ho
>>> On 07.05.15 at 12:11, wrote:
> On 07/05/15 10:52, Julien Grall wrote:
>> On 07/05/2015 09:21, Zoltan Kiss wrote:
>>> On 06/05/15 19:56, Julien Grall wrote:
His email address is bouncing from more than a month.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc: Keir Fras
>>> On 06.05.15 at 19:21, wrote:
> Removed Nathan Studer and added Josh Whitehead.
Nathan,
could you confirm the removal please?
Jan
> Signed-off-by: Robert VanVossen
> ---
> MAINTAINERS |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
Ian Campbell writes ("Re: [GIT PULL OSSTEST] Merge up changes from Cambridge
instance."):
> Driving error on git request-pull, the correct branch name is:
> git://xenbits.xen.org/people/ianc/osstest.git from-cambridge/2015-05-05
I have just pushed this to colo pretest.
In an hour or so I will
On 05/05/2015 12:44 AM, 蒋雄伟(蒋冲) wrote:
> In /xen/arch/x86/oprofile/op_counter.h there is a definition
>
> #define OP_MAX_COUNTER 8
>
> As far as I know , the number of counter equals the number of events. As
> all we know that the number of events is more than 8.
> So my question is : Is it th
On 07/05/15 15:14, Jan Beulich wrote:
On 07.05.15 at 12:11, wrote:
On 07/05/15 10:52, Julien Grall wrote:
On 07/05/2015 09:21, Zoltan Kiss wrote:
On 06/05/15 19:56, Julien Grall wrote:
His email address is bouncing from more than a month.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc:
Changes in this iteration include the addition of a non-contiguous allocator
that's used in shadow_track_dirty_vram and hap_track_dirty_vram in order to
allocate the temporary dirty bitmap.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen
The allocator uses independent calls to alloc_heap_pages in order to get the
desired amount of memory and then maps all the independent physical
addresses into a contiguous virtual address space.
In order to keep track of this regions a red-black tree is used.
Signed-off-by: Roger Pau Monné
Cc:
Just like it's done for shadow_track_dirty_vram allocate the temporary
buffer using non-contiguous memory.
Signed-off-by: Roger Pau Monné
Cc: Tim Deegan
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/mm/hap/hap.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/
Modify shadow_track_dirty_vram to use a local buffer and then flush to the
guest without the paging_lock held. This is modeled after
hap_track_dirty_vram.
Signed-off-by: Roger Pau Monné
Cc: Tim Deegan
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v3:
- Use the newly introduced alloc_xen
When the caller of paging_log_dirty_op is a hvm guest Xen would choke when
trying to copy the dirty bitmap to the guest because the paging lock is
already held.
Fix this by independently mapping each page of the guest bitmap as needed
without the paging lock held.
Signed-off-by: Roger Pau Monné
Hi Jan,
On 07/05/15 15:14, Jan Beulich wrote:
On 07.05.15 at 12:11, wrote:
>> On 07/05/15 10:52, Julien Grall wrote:
>>> On 07/05/2015 09:21, Zoltan Kiss wrote:
On 06/05/15 19:56, Julien Grall wrote:
> His email address is bouncing from more than a month.
>
> Signed-off-by:
On Thu, May 7, 2015 at 10:15 AM, Jan Beulich wrote:
On 06.05.15 at 19:21, wrote:
>> Removed Nathan Studer and added Josh Whitehead.
>
> Nathan,
>
> could you confirm the removal please?
Confirmed, and if you need a more formal ack...
>
> Jan
>
>> Signed-off-by: Robert VanVossen
Acked-by
>>> On 07.05.15 at 16:31, wrote:
> On 07/05/15 15:14, Jan Beulich wrote:
>> Now the question of course is - is that really what we want to do?
>> I.e. is it known that he no longer wants to be a maintainer of this
>> code (or cannot be)? The mail address having become stale
>> doesn't necessarily
This version include splitting changes into separate patches, specially
those that also affect PV guests.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
This port is used by PM1a and should not be accessed directly by Dom0. This
also premits trapping 2 and 4 byte accesses to 0xcf8, which need to be
handled by the hypervisor.
Also, since admin_io_okay is now a wrapper around ioports_access_permitted
remove it.
Signed-off-by: Roger Pau Monné
Cc: J
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: Sur
Previously this was done ad-hoc in admin_io_okay.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain_build.c | 3 +++
xen/arch/x86/traps.c| 4
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/domain_build.c b/xen/arc
On 05/07/2015 06:35 PM, Andrew Cooper wrote:
On 07/05/15 07:37, Yang Hongyang wrote:
Set the hvm param HVM_PARAM_IDENT_PT second time will fail.
So defer the setting of HVM_PARAM_IDENT_PT.
Signed-off-by: Yang Hongyang
I would argue that this is a Xen bug, not a migration bug. There is
not
On 05/07/2015 06:58 PM, Andrew Cooper wrote:
On 07/05/15 07:37, Yang Hongyang wrote:
X86_PV_INFO can be sent multiple times under Remus
Signed-off-by: Yang Hongyang
X86_PV_INFO cannot be sent multiple times. If any information in it
were to change, the receiving side would have no choice
On 05/07/2015 05:31 PM, Andrew Cooper wrote:
On 07/05/15 08:04, Hongyang Yang wrote:
Cc Andrew cooper
Sorry I missed your address...
No worries. You have managed a far faster turnaround on this than I
have with libxl migration v2!
Thank you for the more faster review!
~Andrew
.
--
>>> On 07.05.15 at 16:54, wrote:
> Since a PVH hardware domain has access to the physical hardware create a
> custom more permissive IO bitmap. The permissions set on the bitmap are
> populated based on the contents of the ioports rangeset.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Be
>>> On 07.05.15 at 16:54, wrote:
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -1548,6 +1549,8 @@ int __init construct_dom0(
> rc |= ioports_deny_access(d, pmtmr_iop
At 16:29 +0200 on 07 May (1431016173), Roger Pau Monne wrote:
> The allocator uses independent calls to alloc_heap_pages in order to get the
> desired amount of memory and then maps all the independent physical
> addresses into a contiguous virtual address space.
>
> In order to keep track of this
>>> On 07.05.15 at 16:54, wrote:
> This port is used by PM1a and should not be accessed directly by Dom0.
I don't think this is unconditionally PM1a - that should be read out
of the FADT if at all. I also don't think port CF9 universally serves
as the port to do reboots. I.e. I don't think this s
On 05/07/2015 11:10 AM, Michal Suchanek wrote:
Hello,
it appears the Linus master tree fails to build on ARM with XEN enabled.
Since commit 2b953a5e9 xen: Suspend ticks on all CPUs during suspend
provides the suspend function only for x86 this is not surprising.
I currently don't use XEN yet
1 - 100 of 172 matches
Mail list logo
