On April 19, 2016 2:51pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> > However the existing panic() is going to be eliminated, so we must
> > propagate the IOMMU Device-TLB flush er
flight 44343 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44343/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 44321
build-armhf
Hi Wei,
This patch has all the required acks now. Can you consider it for 4.7?
It's a signficant scalability improvement (see the cover letter for
details).
v7 has been in XenServer's upcoming release for a while now so it has
been tested with many guests and many life cycle operations, includi
flight 91987 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91987/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 9 debian-install fail in 91935 pass in 91987
test-amd64-amd64-xl-credit2 19 g
flight 92004 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 91479
build-i386-libvirt
On April 19, 2016 2:33pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > The propagation value from IOMMU flush interfaces may be positive,
> > which indicates callers need to flush cache, not one of faliures.
> >
> > when the propagation value is positive,
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 19 April 2016 05:51
> To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun
> Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen-devel@lists.xen.org;
> Keir (Xen.org); Tim (Xen.org)
> Subject: RE: [Xen-devel] [
On Mon, Apr 18, 2016 at 09:26:17AM +0100, Doug Goldstein wrote:
> On 4/15/16 10:29 AM, Roger Pau Monné wrote:
> > On Fri, Apr 15, 2016 at 10:19:49AM +0100, Wei Liu wrote:
> >> On Thu, Apr 14, 2016 at 06:51:04PM +0200, Roger Pau Monné wrote:
> >>> Hello,
> >>>
> >>> I would like to request an update
On April 19, 2016 2:58pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> > However the existing panic() is going to be eliminated, so we must
> > propagate the IOMMU Device-TLB flush er
On 4/18/16 12:20 PM, Lars Kurth wrote:
> Hi all,
>
> I took notes as much as I could. CC'ed the people who participated most. If I
> missed/misrepresented something, please add to the discussion. I know that
> George for example took some extra notes in the one or other area.
>
> Regards
> Lars
On 4/18/2016 11:57 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 April 2016 11:45
To: George Dunlap; Paul Durrant; xen-devel@lists.xen.org
Cc: Jan Beulich; Kevin Tian; Andrew Cooper; Lv, Zhiyuan; Tim (Xen.org);
jun.nakaj...@intel
On 4/19/2016 12:50 PM, Tian, Kevin wrote:
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Thursday, April 14, 2016 5:57 PM
And with all three bits now possibly being clear, aren't we risking the
entries to be mis-treated as not-present ones?
Hah. You got me. Thanks! :)
Now I realiz
> -Original Message-
[snip]
> >> Does any other maintainers have any suggestions?
> >
> > Note that it is a requirement that an ioreq server be disabled before VM
> suspend. That means ioreq server pages essentially have to go back to
> ram_rw semantics.
> >
> >Paul
> >
>
> OK. So it s
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 10:15
> To: Kevin Tian; Jan Beulich; Paul Durrant; Nakajima, Jun
> Cc: Keir (Xen.org); George Dunlap; Andrew Cooper; Tim (Xen.org); xen-
> de...@lists.xen.org; Lv, Zhiyuan
> Subject: Re: [Xen-de
On 4/19/2016 12:37 PM, Tian, Kevin wrote:
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: Thursday, April 14, 2016 6:45 PM
On 4/11/2016 7:15 PM, Yu, Zhang wrote:
On 4/8/2016 7:01 PM, George Dunlap wrote:
On 08/04/16 11:10, Yu, Zhang wrote:
[snip]
BTW, I noticed your reply has no
On 4/19/2016 4:46 PM, Paul Durrant wrote:
-Original Message-
From: Tian, Kevin [mailto:kevin.t...@intel.com]
Sent: 19 April 2016 05:51
To: Yu, Zhang; Jan Beulich; Paul Durrant; Nakajima, Jun
Cc: Andrew Cooper; George Dunlap; Lv, Zhiyuan; xen-devel@lists.xen.org;
Keir (Xen.org); Tim (Xen
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 10:27
> To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun
> Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen-
> de...@lists.xen.org; Lv, Zhiyuan
> Subject: Re: [Xen-de
On 4/19/2016 5:21 PM, Paul Durrant wrote:
-Original Message-
[snip]
Does any other maintainers have any suggestions?
Note that it is a requirement that an ioreq server be disabled before VM
suspend. That means ioreq server pages essentially have to go back to
ram_rw semantics.
On 4/19/2016 5:40 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 10:27
To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun
Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen-
de...@lists.xen.org;
On 19/04/16 10:02, Doug Goldstein wrote:
On 4/18/16 12:20 PM, Lars Kurth wrote:
Hi all,
I took notes as much as I could. CC'ed the people who participated most. If I
missed/misrepresented something, please add to the discussion. I know that
George for example took some extra notes in the one
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 10:49
> To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun
> Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen-
> de...@lists.xen.org; Lv, Zhiyuan
> Subject: Re: [Xen-de
On 4/19/2016 6:01 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 10:49
To: Paul Durrant; Kevin Tian; Jan Beulich; Nakajima, Jun
Cc: Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George Dunlap; xen-
de...@lists.xen.org;
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 10:44
> To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org
> Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan;
> jun.nakaj...@intel.com
> Subject: Re: [Xen-devel] [PA
On Mon, Apr 18, 2016 at 10:33:46AM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 04/18/16 9:50 AM >>>
> >On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
> >> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
> >>
Dear Community members,
you may remember the following e-mail called "Call for nominations for new
Hypervisor subproject maintainers and committers" (also see
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03459.html)
I am now pleased to confirm the following people as
== New
flight 91992 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91992/
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
= Topics Discussed =
- Clarifying ACKing rules and conventions
- ACK on Xen and Linux have different meaning : or do they?
- Patches sent by a maintainer (with no ACK from another maintainer)
- Explain tooling / working patterns which make it easier for contributors see
whether a patch made it in
Restartable driver domains and dom0
---
Jeurgen: See XenSummit presentation.
- Xenstore Domain (bits missing in libxl)
- Looking at driver domains next.
One domain per backend or several backends in one domain.
Drivers crash -> restart driver domains while guests
On 04/18/2016 07:45 PM, Jan Beulich wrote:
Razvan Cojocaru 04/18/16 2:40 PM >>>
>> On 04/14/2016 07:08 PM, Jan Beulich wrote:
>> Razvan Cojocaru 04/14/16 5:45 PM >>>
On 04/14/2016 06:40 PM, Jan Beulich wrote:
> To be honest, just having remembered that we do the write back for l
flight 91991 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91991/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 91846
Regressions which are regarded as
On 4/19/2016 12:58 AM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
Beulich
Sent: 18 April 2016 17:47
To: Paul Durrant
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 12:03
> To: Paul Durrant; Jan Beulich; Wei Liu
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> Dunlap; xen-devel@lists.xen.org; zhiyuan...@intel.com;
> jun.nakaj...@inte
On 4/19/2016 6:05 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 10:44
To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org
Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan;
jun.nakaj...@intel.
On 4/19/2016 7:15 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 12:03
To: Paul Durrant; Jan Beulich; Wei Liu
Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
Dunlap; xen-devel@lists.xen.org; zhiyuan
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 12:18
> To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org
> Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan;
> jun.nakaj...@intel.com
> Subject: Re: [Xen-devel] [PA
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 April 2016 12:39
> To: Paul Durrant; Jan Beulich; Wei Liu
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> Dunlap; xen-devel@lists.xen.org; zhiyuan...@intel.com;
> jun.nakaj...@inte
On 4/19/2016 7:47 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 19 April 2016 12:18
To: Paul Durrant; George Dunlap; xen-devel@lists.xen.org
Cc: Kevin Tian; Jan Beulich; Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan;
jun.nakaj...@intel.
Hi Wei Liu
On 15 April 2016 at 17:47, Wei Liu wrote:
> On Wed, Apr 13, 2016 at 05:45:27PM +0800, Fu Wei wrote:
>> Hi Julien,
>>
>> On 8 April 2016 at 23:19, Julien Grall wrote:
>> > Hi Wei,
>> >
>> > On 08/04/16 15:58, Wei Liu wrote:
>> >>
>> >> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien G
On Mon, 18 Apr 2016, Doug Goldstein wrote:
> On 3/14/16 5:55 PM, Anthony PERARD wrote:
> > ... into the firmware directory, along with hvmloader.
> >
> > Signed-off-by: Anthony PERARD
> > ---
> > Change in V4:
> > - remove install of acpi dsdt table
> >
> > Change in V3:
> > - do not check if RO
flight 92003 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684
build-i386
On April 19, 2016 2:46pm, Tian, Kevin wrote:
> > From: Quan Xu
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > While grant table is unmapping, the domain (with the exception of the
>
> unmapping -> unmapped.
>
A slightly different take, IMO the hypercall is not returned, so it is DOING.
> >
This run is configured for baseline tests only.
flight 44344 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 10 guest-start
On 18.04.2016 10:17, Julien Grall wrote:
On 16/04/2016 18:39, Dirk Behme wrote:
Hi Julien,
Hi Dirk,
On 06.04.2016 12:48, Julien Grall wrote:
On 04/04/2016 16:44, Dirk Behme wrote:
Hi Julien,
I'm using
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boo
On Tue, Apr 19, 2016 at 08:32:17PM +0800, Fu Wei wrote:
> Hi Wei Liu
>
> On 15 April 2016 at 17:47, Wei Liu wrote:
> > On Wed, Apr 13, 2016 at 05:45:27PM +0800, Fu Wei wrote:
> >> Hi Julien,
> >>
> >> On 8 April 2016 at 23:19, Julien Grall wrote:
> >> > Hi Wei,
> >> >
> >> > On 08/04/16 15:58, W
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.
Signed-off-by: Doug Goldstein
---
tools/Rules.mk | 3 ++-
1 file changed,
>>> Razvan Cojocaru 04/19/16 1:01 PM >>>
>I think this might be because the LOCK prefix should guarantee that the
>instruction that follows it has exclusive use of shared memory (for both
>reads and writes) but I might be misreading the docs:
LOCK definitely has no effect on other than the instru
>>> "Yu, Zhang" 04/19/16 1:46 PM >>>
>On 4/19/2016 7:15 PM, Paul Durrant wrote:
>> I talked to Wei earlier and he is happy to give a freeze exception to this
>> change.
>
>Great! I really obliged. :)
>BTW, Does some form of application need to be submitted? I'm not
>familiar with the procedure.
flight 92027 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92027/
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
c/s 75f9455e "tools/libxc: Calculate xstate cpuid leaf from guest information"
incorrectly inverted the shift and mask when using X86_XSS_MASK. Luckily, the
mask is currently zero, avoiding incorrect calculations.
While adjusting this, use an explcit uint32_t cast rather than masking against
0xff
On Tue, Apr 19, 2016 at 06:27:05PM +0100, Andrew Cooper wrote:
> c/s 75f9455e "tools/libxc: Calculate xstate cpuid leaf from guest information"
> incorrectly inverted the shift and mask when using X86_XSS_MASK. Luckily, the
> mask is currently zero, avoiding incorrect calculations.
>
> While adju
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/xen/arch/arm/Makefile
>+++ b/xen/arch/arm/Makefile
>@@ -57,6 +57,8 @@ ifeq ($(CONFIG_ARM_64),y)
>ln -sf $(notdir $@) ../../$(notdir $@).efi
>endif
>
>+tests:
I think this should be phony just like ...
>--- a/xen/arch/x86/Makefile
flight 92005 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92005/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
test-amd64-amd64-xl-c
flight 92026 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 91987
Regressions which a
flight 92057 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92057/
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
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/test/xen_hello_world.c
>+++ b/xen/arch/x86/test/xen_hello_world.c
>@@ -10,11 +10,14 @@
>static char hello_world_patch_this_fnc[] = "xen_extra_version";
>extern const char *xen_hello_world(void);
>
>+/* External symbol. */
>+ext
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>NEW CODE:
>
>To make that work we add three tables:
Why three? Two (or a single one with element pairs) ought to be sufficient:
Afaict you could just have (symbol-address,symbol-offset) pairs which you
then sort and search by name (using symbols_ex
flight 92036 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92036/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 88172
test-amd64-amd64-xl-qemuu-win7-amd
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>@@ -331,16 +332,23 @@ static char *pointer(char *str, char *end, const char
>**fmt_ptr,
>{
>unsigned long sym_size, sym_offset;
>char namebuf[KSYM_NAME_LEN+1];
>+bool_t payload = 0;
I don't see the point of this var
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>+bool_t is_patch(const void *ptr)
>+{
>+struct payload *data;
You guess it: const.
>+/*
>+ * No locking since this list is only ever changed during apply or revert
>+ * context.
>+ */
What if you crash while applying or revert
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>@@ -48,19 +49,23 @@ static void __init swap_ex(void *a, void *b, int size)
>}
>#endif
>
>-void __init sort_exception_tables(void)
>+void __INIT sort_exception_table(struct exception_table_entry *start,
>+ struct exception_ta
Could anyone have a look at this patch?
Thanks,
Zhigang
On 03/11/2016 03:18 PM, Zhigang Wang wrote:
> xentop will segmentation fault in this case:
>
> # ip link set eth1 down
> # ip link set eth1 name ETH
> # xentop
>
> This patch will let xentop to handle all uppercase network interface
flight 92074 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92074/
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
flight 92071 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92071/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91987
test-amd64-amd64-xl-rtds
This run is configured for baseline tests only.
flight 44345 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44345/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail
flight 92097 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92097/
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
flight 92111 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92111/
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
On April 19, 2016 2:44pm, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > If IOMMU mapping and unmapping failed, the domain (with the exception
> > of the hardware domain) is crashed, treated as a fatal error. Rollback
> > can be lighter weight.
>
> What d
> From: Xu, Quan
> Sent: Tuesday, April 19, 2016 9:28 PM
>
> On April 19, 2016 2:46pm, Tian, Kevin wrote:
> > > From: Quan Xu
> > > Sent: Monday, April 18, 2016 10:00 PM
> > >
> > > While grant table is unmapping, the domain (with the exception of the
> >
> > unmapping -> unmapped.
> >
>
> A sli
> From: Xu, Quan
> Sent: Wednesday, April 20, 2016 1:27 PM
>
> On April 19, 2016 2:44pm, Tian, Kevin wrote:
> > > From: Xu, Quan
> > > Sent: Monday, April 18, 2016 10:00 PM
> > >
> > > If IOMMU mapping and unmapping failed, the domain (with the exception
> > > of the hardware domain) is crashed,
>>> "Xu, Quan" 04/20/16 7:29 AM >>>
>I am still not sure whether we really need throw out error message for each
>IOMMU mapping or not.
>If yes, I will throw out error message for each IOMMU mapping in next v3.
Ideally not, if it's a batch that it failing, The question just is whether at
the po
flight 92126 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92126/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 91479
build-i386-libvirt
wed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Acked-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
commit ef5d5641f5f35f64a7f150bb3593dae0c08f236d
Merge: bb97bfd a49923d
Author: Peter Maydell
Date: Tue Apr 19 12:10:30 2016 +0100
Merge remote-tracking branch &
On April 20, 2016 2:12pm, wrote:
> >>> "Xu, Quan" 04/20/16 7:29 AM >>>
> Ideally not, if it's a batch that it failing, The question just is whether at
> the point
> you issue the error message you can know another got already emitted. In no
> case must this lead to spamming of the console origin
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/Makefile
>+++ b/xen/arch/x86/Makefile
>@@ -6,7 +6,11 @@ subdir-y += mm
>subdir-$(CONFIG_XENOPROF) += oprofile
>subdir-y += x86_64
>
>+ifdef CONFIG_XSPLICE
>+obj-y += alternative.o
>+else
>obj-bin-y += alternative.init.o
>+endi
74 matches
Mail list logo
