On 20.12.2016 18:43, Eduardo Habkost wrote:
> This moves the KVM and Xen files to the an accel/ subdir.
>
> Instead of moving the *-stubs.c file to accel/ as-is, I tried to
> move most of the stub code to libqemustub.a. This way the obj-y
> logic for accel/ is simpler: obj-y includes accel/ only i
When Xen apicv is enabled, wall clock time is faster on Windows7-32
guest with high payload (with 2vCPU, captured from xentrace, in
high payload, the count of IPI interrupt increases rapidly between
these vCPUs).
If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pen
On December 21, 2016 10:30 AM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Tuesday, December 20, 2016 9:12 PM
>>
>> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> >> Sent: Friday, December 16, 2016 5
On 12/20/16 2:16 PM, Andrew Cooper wrote:
> On 20/12/2016 20:06, Doug Goldstein wrote:
>> On 12/20/16 1:46 PM, Alistair Francis wrote:
>>> Signed-off-by: Alistair Francis
>>> ---
>>> Config.mk | 2 +-
>>> tools/blktap2/drivers/Makefile | 1 -
>>> tools/libxl/Makefile
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Tuesday, December 20, 2016 5:39 PM
>
> On December 20, 2016 4:32 PM, Jan Beulich wrote:
> On 20.12.16 at 06:54, wrote:
> >> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Tuesday, December 20, 2016 9:12 PM
>
> On December 20, 2016 1:37 PM, Tian, Kevin wrote:
> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> >> Sent: Friday, December 16, 2016 5:40 PM
> >I suppose you've verified this new version, b
Hi,
I really want to know when the ept (extended page table) for domain U is
initialized and comes into use in xen. I already know the do_domctl() function
can create domain U by handling the hypercall XEN_DOMCTL_createdomain. It
actually initialize some data structures of ept such as default memo
On Tue, 20 Dec 2016, Eduardo Habkost wrote:
> This moves the KVM and Xen files to the an accel/ subdir.
>
> Instead of moving the *-stubs.c file to accel/ as-is, I tried to
> move most of the stub code to libqemustub.a. This way the obj-y
> logic for accel/ is simpler: obj-y includes accel/ only i
On Tue, Dec 20, 2016 at 12:16 PM, Andrew Cooper
wrote:
> On 20/12/2016 20:06, Doug Goldstein wrote:
>> On 12/20/16 1:46 PM, Alistair Francis wrote:
>>> Signed-off-by: Alistair Francis
>>> ---
>>> Config.mk | 2 +-
>>> tools/blktap2/drivers/Makefile | 1 -
>>> tools/libxl/Mak
On Tue, 20 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 01:47, wrote:
> > ## Design Phase
> >
> > The first step toward acceptance of a new PV protocol is to write a
> > design document and send it to xen-devel. It should cover the xenstore
> > handshake mechanism, the ABI, how the protocol
On Tue, 20 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 00:39, wrote:
> > On Wed, 14 Dec 2016, Jiandi An wrote:
> >> Xen currently does not handle mapping mmio regions specified in standard
> > static ACPI tables such as BERT, TPM2, GT block, IORT, HEST, etc. There
> > has
> > been some i
On Tue, 20 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 00:01, wrote:
> > This is actually not an ARM specific question, so changing the subject
> > and CC'ing more people.
> >
> > On Wed, 14 Dec 2016, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Dec 13, 2016 at 07:14:27PM -0600, Jiandi An wrot
On Tue, 20 Dec 2016, Julien Grall wrote:
> Hi Jiandi,
>
> On 20/12/2016 07:31, Jiandi An wrote:
> > On 12/19/16 07:11, Julien Grall wrote:
> > >
> > >
> > > On 19/12/2016 13:20, Jaggi, Manish wrote:
> > > > > On 16/12/2016 15:49, Julien Grall wrote:
> > > > > > On 14/12/16 08:00, Jiandi An wrote
On Tue, 20 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 20/12/2016 00:54, Stefano Stabellini wrote:
> > On Mon, 19 Dec 2016, Julien Grall wrote:
> > > On 16/12/2016 15:49, Julien Grall wrote:
> > > > On 14/12/16 08:00, Jiandi An wrote:
> > > > > Xen currently doesn't map ECAM space specified
On Tue, 20 Dec 2016, Bhupinder Thakur wrote:
> Hi Stefano,
>
> Thanks for a detailed explanation. I have some queries.
>
> > Let me explain how the PV console protocol and drivers work, because
> > they are a bit unusual. The first PV console is advertised via
> > hvm_params. The guest calls:
> >
This run is configured for baseline tests only.
flight 68248 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68248/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install f
On Tue, Dec 20, 2016 at 01:53:21PM -0800, Eric Dumazet wrote:
> On Tue, 2016-12-20 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 20, 2016 at 05:44:06PM +, Roger Pau Monné wrote:
> > > On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Dec 20, 2
On Tue, 2016-12-20 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2016 at 05:44:06PM +, Roger Pau Monné wrote:
> > On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> > > > To make the code
flight 103764 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737
test-amd64-amd64-qemu
On Tue, 20 Dec 2016, Christoffer Dall wrote:
> Hi Stefano,
>
> On Mon, Dec 19, 2016 at 12:24:18PM -0800, Stefano Stabellini wrote:
> > On Mon, 19 Dec 2016, Christoffer Dall wrote:
> > > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> > > > (CC rest maintainers for event channel que
flight 68247 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68247/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail blocked
in 68215
test-a
flight 103767 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103767/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-i386 3 host-install(3) broken in 103752 pass in
103767
test-amd64-i386-xl-qemuu-o
On Tue, 20 Dec 2016, Stefano Stabellini wrote:
> On Tue, 20 Dec 2016, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 19/12/2016 21:24, Stefano Stabellini wrote:
> > > On Mon, 19 Dec 2016, Christoffer Dall wrote:
> > > > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> > > > > (CC re
On 20/12/2016 20:06, Doug Goldstein wrote:
> On 12/20/16 1:46 PM, Alistair Francis wrote:
>> Signed-off-by: Alistair Francis
>> ---
>> Config.mk | 2 +-
>> tools/blktap2/drivers/Makefile | 1 -
>> tools/libxl/Makefile | 2 +-
>> tools/xentrace/Makefile| 2 --
On 12/20/16 1:46 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> Config.mk | 2 +-
> tools/blktap2/drivers/Makefile | 1 -
> tools/libxl/Makefile | 2 +-
> tools/xentrace/Makefile| 2 --
> 4 files changed, 2 insertions(+), 5 deletions(-
On Tue, Dec 20, 2016 at 11:53 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 20, 2016 at 11:46:55AM -0800, Alistair Francis wrote:
>> This patch series is a list of build issues that appeared when
>> buildling Xen 4.8.0 in buildroot. Hopefully some of them can be
>
> Is there an corresponding patc
On Tue, Dec 20, 2016 at 11:46:55AM -0800, Alistair Francis wrote:
> This patch series is a list of build issues that appeared when
> buildling Xen 4.8.0 in buildroot. Hopefully some of them can be
Is there an corresponding patch in buildroot for using Xen?
Thank you for reposting!
> accepted ups
On 12/20/16 1:46 PM, Alistair Francis wrote:
> To avoid build errors relating to missing delcarations of ssize_t add
declarations
> the appripriote header file to atomic.h.
appropriate
>
> Signed-off-by: Alistair Francis
> ---
> tools/blktap2/include/atomicio.h | 2 ++
> 1 file changed, 2 in
On Tue, 20 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 19/12/2016 21:24, Stefano Stabellini wrote:
> > On Mon, 19 Dec 2016, Christoffer Dall wrote:
> > > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> > > > (CC rest maintainers for event channel questions)
> > > >
> > > >
On Tue, Dec 20, 2016 at 11:46:59AM -0800, Alistair Francis wrote:
> To avoid build errors relating to missing delcarations of ssize_t add
> the appripriote header file to atomic.h.
appropiate.
>
> Signed-off-by: Alistair Francis
> ---
> tools/blktap2/include/atomicio.h | 2 ++
> 1 file changed
On 12/20/16 1:46 PM, Alistair Francis wrote:
> The unsued variable 'struct stat stats' causes build errors in some
> situations. As it isn't used just remove it.
>
> Signed-off-by: Alistair Francis
> ---
> tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --
On 12/20/16 1:46 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> config/StdGNU.mk | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> index 6be8233..a6cdd82 100644
> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -35,6 +35
This patch series is a list of build issues that appeared when
buildling Xen 4.8.0 in buildroot. Hopefully some of them can be
accepted upstream to help others who are trying to build Xen in
the future.
V2:
- Remove the #include path changes
- It turns out this only applies to musl (although
Signed-off-by: Alistair Francis
---
config/StdGNU.mk | 3 +++
1 file changed, 3 insertions(+)
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 6be8233..a6cdd82 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -35,6 +35,9 @@ UTIL_LIBS = -lutil
SONAME_LDFLAG = -soname
SHLIB_LDFLAGS
To avoid build errors related to missing file 'sys/sysctl.h' by removing
the #include statement.
Signed-off-by: Alistair Francis
---
tools/blktap2/drivers/block-remus.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/blktap2/drivers/block-remus.c
b/tools/blktap2/drivers/block-remus.c
i
The unsued variable 'struct stat stats' causes build errors in some
situations. As it isn't used just remove it.
Signed-off-by: Alistair Francis
---
tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/blktap2/vhd/lib/libvhd-journal.c
b/tools/blktap2/v
To avoid build errors relating to missing delcarations of ssize_t add
the appripriote header file to atomic.h.
Signed-off-by: Alistair Francis
---
tools/blktap2/include/atomicio.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/blktap2/include/atomicio.h b/tools/blktap2/include/atomi
Signed-off-by: Alistair Francis
---
Config.mk | 2 +-
tools/blktap2/drivers/Makefile | 1 -
tools/libxl/Makefile | 2 +-
tools/xentrace/Makefile| 2 --
4 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/Config.mk b/Config.mk
index 3ec7367..e3cda8
On Tue, 20 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 20/12/2016 00:22, Stefano Stabellini wrote:
> > On Mon, 19 Dec 2016, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 19/12/2016 23:30, Stefano Stabellini wrote:
> > > > On Mon, 19 Dec 2016, Julien Grall wrote:
> > > > > > > 2) We
Commit d6ac8e22c7c5 ("acpi/x86: define ACPI IO registers for
PVH guests") broke ARM64 build of mk_dsdt.c due to introduction
of XEN_ACPI_CPU_MAP[_LEN] macros that are needed only for x86
guests.
We could fix the build by dealing specifically with those macros
but since post-MADT code is not execut
On 12/20/16 18:43, Eduardo Habkost wrote:
This moves the KVM and Xen files to the an accel/ subdir.
I hope that it won't last long until we also get acceleration
for Windows and macOS. Those HAXM files will have to be moved
as well.
Regards,
Stefan
__
Commit d6ac8e22c7c5 ("acpi/x86: define ACPI IO registers for
PVH guests") broke ARM64 build of mk_dsdt.c due to introduction
of XEN_ACPI_CPU_MAP[_LEN] macros that are needed only for x86
guests.
We could fix the build by dealing specifically with those macros
but since post-MADT code is not execut
This is only required to avoid a lock inversion between the repo lock
and database table locks, but we have no explicit database table locks
any more.
We do not want to hold the repo lock for an extended period,
particularly when we are running a database retry loop.
In practice, currently, cs-bi
This is supposed to represent success. But now that _need_retry is
only called within a HandleError hook, we know there has been a
failure.
Retry such failures, in the hope that they are stochastic. If they
aren't, we will fail eventually when we run out of retries.
Signed-off-by: Ian Jackson
We have here:
* Two patches to improve mg-schema-test-database a bit.
* Fixes to cs-bisection-step, to survive and give right answers
on db retry.
* An attempt at a workarounds for a strange DBD::Pg behaviour.
The workaround seems to WFM in my ad-hoc tests and I propose to deploy
it in the h
We are going to want to reorganise this. As prep work, break the $dbh
state checking (and the corresponding comment) into a separate sub.
No functional changel.
(There is still an anomaly: need_retry passes it $dbh_tests, not the
$dbh it got from the caller. This will go away shortly.)
Signed-
If we previously searched for builds to reuse, trust our previous
answers. We will only have seen data from committed transactions and
we will only have looked at jobs in completed flights, which won't
have changed.
So any previously reuseable build is still reuseable. (Unless its
stash check fa
There are only two call sites and neither trashes $@ right now.
We are going to use a more exception-friendly style.
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.
The initial value (at creation time) of a sequence appears in the
schema, but is not of any consequence. To avoid the schema diff check
failing in databases created in a slightly different way, it is
necessary to copy the actual original initial sequence value for each
sequence.
Replace the seque
It appears that sometimes, $dbh->state could be overwritten before
$mjobdb->need_retry got to run. $dbh->err and $@ would still be
right. I have not been able to explain this; I suspect that there is
something exciting going on in the eval exception trapping.
To try to isolate the problem, I dev
%jobs_created is used for memoisation while populating the destination
flight. We need to reset it when we restart flight construction,
because those jobs were created in the discarded transaction.
Otherwise we could create a flight with missing jobs.
Signed-off-by: Ian Jackson
---
cs-bisectio
Otherwise it takes effect for the rest of the script, which is not
what is wanted ! As it happens, there are no accesses to the real db
after this point, so this bug is latent.
Signed-off-by: Ian Jackson
---
mg-schema-test-database | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
d
flight 103765 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 9 debian-install fail REGR. vs. 103407
test-amd64-amd6
On Tue, Dec 20, 2016 at 08:00:27PM +0200, Andrii Anisov wrote:
> Sorry for the mess,
>
> I mean the xen-swiotlb issue on renesas board:
Can you make sure to CC me on it (since I am the maintainer of that code).
>
> > Bosch: problem with xen-swiotlb. It does not work properly on renesas
> board.
flight 103766 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 3 host-install(3)broken REGR. vs. 103479
test-amd64-i386-libvirt
Hello Boris,
This patch is breaking compilation of mk_dsdt on ARM64 (see below).
Boris can you please send a patch to fix this?
In the future, please make sure that mk_dsdt at least build for all the
targeted architectures.
mk_dsdt.c: In function 'main':
mk_dsdt.c:249:9: error: 'XEN_ACPI_CP
Hi Andrii,
On 20/12/2016 19:00, Andrii Anisov wrote:
Sorry for the mess,
I mean the xen-swiotlb issue on renesas board:
Bosch: problem with xen-swiotlb. It does not work properly on renesas
board.
Stefano: please report the error on the ML
ACTION: Bosch to send a bug report regarding xen-s
Sorry for the mess,
I mean the xen-swiotlb issue on renesas board:
> Bosch: problem with xen-swiotlb. It does not work properly on renesas
board.
> Stefano: please report the error on the ML
>
> ACTION: Bosch to send a bug report regarding xen-swiotlb
--
*Andrii Anisov*
*Lead Systems Engine
On Mon, Dec 19, 2016 at 7:53 PM, Doug Goldstein wrote:
> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>>> Signed-off-by: Alistair Francis
>>
>>
>> Why?
>
> *adjusts his distro maintainer hat* It's considered really bad form
On Tue, Dec 20, 2016 at 9:21 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 20, 2016 at 11:02:15AM -0600, Doug Goldstein wrote:
>> On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
>> > On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
>> >> On 12/17/16 9:51 AM, Konrad Rzeszutek Wil
On Tue, Dec 20, 2016 at 05:44:06PM +, Roger Pau Monné wrote:
> On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> > > To make the code clearer, use rb_entry() instead of container_of() to
> > > deal with rbt
On Mon, Dec 19, 2016 at 8:00 PM, Doug Goldstein wrote:
> On 12/19/16 12:01 PM, Alistair Francis wrote:
>> On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote:
To avoid this build error with newer build systems:
Move xen stubs to stubs/ so they are handled automatically by
libqemustub.a.
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: xen-de...@lists.xensource.com
Cc: Paolo Bonzini
Signed-off-by: Eduardo Habkost
---
Makefile.target | 2 --
xen-hvm-stub.c => stubs/xen-hvm.c | 0
xen-co
Julien, Stefano,
Are there any updates about:
ACTION: Bosch to send a bug report regarding xen-swiotlb
Edgar: IOMMU could not be used by the guest (Stage-1). This would be useful
to implement driver in userspace.
Julien: When will it be required?
Edgar: It is a trend
Any mailing th
On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> > To make the code clearer, use rb_entry() instead of container_of() to
> > deal with rbtree.
>
> That is OK but I think 'container_of' is more clear.
>
> Roger
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: xen-de...@lists.xensource.com
Signed-off-by: Eduardo Habkost
---
Makefile.target| 4 +---
xen-common.c => accel/xen-common.c | 0
xen-hvm.c => accel/xen-hvm.c | 0
xen-mapcache.c => accel/xen-mapcache.c | 0
MAI
This moves the KVM and Xen files to the an accel/ subdir.
Instead of moving the *-stubs.c file to accel/ as-is, I tried to
move most of the stub code to libqemustub.a. This way the obj-y
logic for accel/ is simpler: obj-y includes accel/ only if
CONFIG_SOFTMMU is set.
The Xen stubs could be moved
On 20/12/2016 10:39, Jan Beulich wrote:
> @@ -3032,16 +3032,16 @@ void hvm_task_switch(
> if ( hvm_set_cr3(tss.cr3, 1) )
> goto out;
>
> -regs->eip= tss.eip;
> -regs->eflags = tss.eflags | 2;
> -regs->eax= tss.eax;
> -regs->ecx= tss.ecx;
> -regs->edx
On 20/12/2016 09:55, Jan Beulich wrote:
> This is a first (of three, as far as current plans go) steps to do away
> with misleading register names (eax instead of rax).
>
> 01: x86/MSR: introduce MSR access split/fold helpers
> 02: x86/guest-walk: use unambiguous register names
> 03: x86/shadow: us
On Fri, Dec 09, 2016 at 10:05:18AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 17:49, wrote:
> > @@ -1930,12 +1931,148 @@ static int __init hvm_setup_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static int __init hvm_copy_to_phys(struct domain *d, paddr_t paddr, void
> > *buf,
2016-12-20 3:42 GMT-07:00 Jan Beulich :
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Signed-off-by: Jan Beulich
>
Acked-by: Tamas K Lengyel
___
Xen-devel mail
On Tue, Dec 20, 2016 at 11:02:15AM -0600, Doug Goldstein wrote:
> On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
> >> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Fr
flight 103762 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103762/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-33 host-install(3)broken REGR. vs. 103466
test-xtf-amd64-amd
On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
>> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
Signed-off-by: Alistair Francis
>>>
>>>
>>> Why?
>>
>
Jan Beulich writes ("[Xen-devel] merlot0 and merlot1 (was Re: [xen-4.4-testing
test] 103756: trouble: blocked/broken/fail/pass)"):
> I consider this difficult to imagine, but it's also not entirely
> impossible. Since this appears to recur, are there perhaps logs
> (ideally more than one instance,
On 12/20/2016 11:46 AM, Andrew Cooper wrote:
> On 20/12/2016 15:41, Jan Beulich wrote:
> On 20.12.16 at 16:29, wrote:
>>> On 12/20/2016 09:47 AM, Jan Beulich wrote:
>>> On 20.12.16 at 15:35, wrote:
> On 12/20/2016 06:50 AM, Jan Beulich wrote:
>>> +else
>>> +{
>>> +
On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
That is OK but I think 'container_of' is more clear.
Roger, thoughts?
>
> Signed-off-by: Geliang Tang
> ---
> drivers/block/xen-blkback/blk
On 20/12/2016 15:41, Jan Beulich wrote:
On 20.12.16 at 16:29, wrote:
>> On 12/20/2016 09:47 AM, Jan Beulich wrote:
>> On 20.12.16 at 15:35, wrote:
On 12/20/2016 06:50 AM, Jan Beulich wrote:
>> +else
>> +{
>> +uint32_t v = *val;
>> +
>> +/*
On 20/12/16 15:02, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang
Reviewed-by: Juergen Gross
> ---
> drivers/xen/evtchn.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --gi
On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
> >> Signed-off-by: Alistair Francis
> >
> >
> > Why?
>
> *adjusts his distro maintainer hat* It's considered
flight 103774 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt17 guest-start/debian.repeat fail REGR. vs. 103771
Tests which
>>> On 20.12.16 at 16:29, wrote:
> On 12/20/2016 09:47 AM, Jan Beulich wrote:
> On 20.12.16 at 15:35, wrote:
>>> On 12/20/2016 06:50 AM, Jan Beulich wrote:
> +else
> +{
> +uint32_t v = *val;
> +
> +/* Status register is write-1-to-clear by guests */
>>> On 20.12.16 at 16:09, wrote:
> On 12/20/2016 08:57 AM, Jan Beulich wrote:
> On 17.12.16 at 00:18, wrote:
>>> --- a/xen/arch/x86/hvm/pmtimer.c
>>> +++ b/xen/arch/x86/hvm/pmtimer.c
>>> @@ -257,7 +257,11 @@ static int acpi_save(struct domain *d,
>>> hvm_domain_context_t *h)
>>> int rc;
On 12/20/2016 09:55 AM, Andrew Cooper wrote:
>>> Is this file is not supposed to be used by anyone outside of the Xen tree?
>> I don't think so, no. In any event - prior additions did not do
>> any precautions to guard possible foreign consumers. Maybe
>> Andrew has an opinion here ...
> Our polici
On 12/20/2016 09:47 AM, Jan Beulich wrote:
On 20.12.16 at 15:35, wrote:
>> On 12/20/2016 06:50 AM, Jan Beulich wrote:
+else
+{
+uint32_t v = *val;
+
+/* Status register is write-1-to-clear by guests */
+switch ( port & 3 )
+
On 12/20/2016 08:57 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/arch/x86/hvm/pmtimer.c
>> +++ b/xen/arch/x86/hvm/pmtimer.c
>> @@ -257,7 +257,11 @@ static int acpi_save(struct domain *d,
>> hvm_domain_context_t *h)
>> int rc;
>>
>> if ( !has_vpm(d) )
>> +{
On 20/12/2016 14:45, Jan Beulich wrote:
On 20.12.16 at 15:16, wrote:
>> On 12/20/2016 09:10 AM, Jan Beulich wrote:
>> On 20.12.16 at 15:03, wrote:
On 12/20/2016 06:24 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/include/public/arch-x86/hvm/save.h
>>
On 12/20/2016 08:37 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> @@ -128,6 +130,13 @@ static int acpi_access_common(struct domain *d, bool
>> is_guest_access,
>> *en = (((v & 0xff) << 8) | (*en & 0xff)) & *mask_en;
>> break;
>> }
>> +
>> +
>>> On 20.12.16 at 15:45, wrote:
> On 12/20/2016 08:24 AM, Jan Beulich wrote:
>>
>>> -static int acpi_access_common(struct domain *d,
>>> +static int acpi_access_common(struct domain *d, bool is_guest_access,
>> Why? I thought the domctl is needed only for updating the CPU
>> map? Or maybe it woul
>>> On 20.12.16 at 15:35, wrote:
> On 12/20/2016 06:50 AM, Jan Beulich wrote:
>>> +else
>>> +{
>>> +uint32_t v = *val;
>>> +
>>> +/* Status register is write-1-to-clear by guests */
>>> +switch ( port & 3 )
>>> +{
>>> +case 0:
>>> +*sts &
>>> On 20.12.16 at 15:16, wrote:
> On 12/20/2016 09:10 AM, Jan Beulich wrote:
> On 20.12.16 at 15:03, wrote:
>>> On 12/20/2016 06:24 AM, Jan Beulich wrote:
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save
On 12/20/2016 08:24 AM, Jan Beulich wrote:
>
>> -static int acpi_access_common(struct domain *d,
>> +static int acpi_access_common(struct domain *d, bool is_guest_access,
> Why? I thought the domctl is needed only for updating the CPU
> map? Or maybe it would help if the patch had a non-empty
> des
On 12/20/2016 06:50 AM, Jan Beulich wrote:
>
>> +
>> +if ( dir == XEN_DOMCTL_ACPI_READ )
>> +{
>> +uint32_t mask = (bytes < 4) ? ~0U << (bytes * 8) : 0;
>> +uint32_t data = (((uint32_t)*en) << 16) | *sts;
> There's one pair of pointless parentheses around the cast
> expressi
On 12/20/2016 09:10 AM, Jan Beulich wrote:
On 20.12.16 at 15:03, wrote:
>> On 12/20/2016 06:24 AM, Jan Beulich wrote:
>> On 17.12.16 at 00:18, wrote:
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -527,7 +527,37 @@ DECLARE_HVM_
>>> On 20.12.16 at 15:03, wrote:
> On 12/20/2016 06:24 AM, Jan Beulich wrote:
> On 17.12.16 at 00:18, wrote:
>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>> @@ -527,7 +527,37 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>>> /*
On 12/20/2016 06:24 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -527,7 +527,37 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>> /*
>> * PM timer
>> */
>> +#if __XEN_INT
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/xen/evtchn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index e8c7f09..6890897 100644
--- a/dri
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/block/xen-blkback/blkback.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/arch/x86/hvm/pmtimer.c
> +++ b/xen/arch/x86/hvm/pmtimer.c
> @@ -257,7 +257,11 @@ static int acpi_save(struct domain *d,
> hvm_domain_context_t *h)
> int rc;
>
> if ( !has_vpm(d) )
> +{
> +if ( !has_acpi_dm_ff(d) )
> +
>>> On 17.12.16 at 00:18, wrote:
> @@ -128,6 +130,13 @@ static int acpi_access_common(struct domain *d, bool
> is_guest_access,
> *en = (((v & 0xff) << 8) | (*en & 0xff)) & *mask_en;
> break;
> }
> +
> +/*
> + * If a new bit has been set in statu
1 - 100 of 158 matches
Mail list logo
