flight 95419 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 95358
Tests which did not succe
flight 95406 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 94728
test-armhf-armhf-libvi
On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> One of the more relevant changes in 4.7 regarding FreeBSD is the support for
> block hotplug scripts. This means that we now have the option to use
> backends different than simple block or regular files, provided that someone
> writes the proper hot
On Wed, 2016-06-08 at 15:28 +0100, Wei Liu wrote:
> It interrogates QEMU for CPUs and update the bitmap accordingly.
>
> Signed-off-by: Wei Liu
>
Reviewed-by: Dario Faggioli
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, ht
On Wed, 2016-06-08 at 15:28 +0100, Wei Liu wrote:
> ... because the available vcpu bitmap can change during domain life
> time
> due to cpu hotplug and unplug.
>
> For QEMU upstream, we interrogate QEMU for the number of vcpus. For
> others, we look directly into xenstore for information.
>
> Rep
On 06/08/16 04:26, Julien Grall wrote:
> Hello Jiandi,
>
> On 08/06/2016 07:54, Jiandi An wrote:
>> As the number of CPUs supported on the system grows, number of
>> GIC redistributors and mmio handlers increase. We need to increase
>> MAX_RDIST_COUNT and MAX_IO_HANDLER which makes size of struct
flight 95408 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94729
test-armhf-armhf-libvir
Hi i have a question about device tree block area
In the function setup_mm xen copy original device tree block to the end of
xen heap space
Original device tree block area seems useless during domain0 creation but
xen discard it with kernel modules after dom0 memory allocation finished
Is there
On Wed, 8 Jun 2016, Marcin Cieslak wrote:
> On Fri, 3 Jun 2016, Roger Pau Monné wrote:
>
> > Hello,
> >
> > First of all, this message is only relevant to those that use FreeBSD as
> > Dom0 (host), not as a DomU (guest), so don't panic.
> >
> > I've imported the latest Xen version (4.7-rc4) in
On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> Hello,
>
> First of all, this message is only relevant to those that use FreeBSD as
> Dom0 (host), not as a DomU (guest), so don't panic.
>
> I've imported the latest Xen version (4.7-rc4) into the ports tree, it's
> still not the final version, but
On 06/07/2016 11:41 AM, Jan Beulich wrote:
On 07.06.16 at 17:17, wrote:
>> On 06/07/2016 10:12 AM, Jan Beulich wrote:
>> On 07.06.16 at 16:02, wrote:
On 06/07/2016 02:06 AM, Jan Beulich wrote:
On 06.06.16 at 19:31, wrote:
>> On 06/06/2016 09:38 AM, Jan Beulich wrote:
>
flight 95407 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 95164
test-amd64-amd64-qemuu
On 06/08/2016 02:43 PM, Dario Faggioli wrote:
> On Wed, 2016-06-08 at 04:42 -0600, Jan Beulich wrote:
> On 07.06.16 at 17:54, wrote:
>>> So, it looks to me that the TSC is actually ok, and it could be the
>>> local_tsc_stamp and scale_delta() magic done in get_s_time_fixed()
>>> (which, AFAICU
flight 95449 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95449/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
flight 95397 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
94856
test-amd64-i38
On Wed, Jun 08, 2016 at 07:22:45PM +0100, Julien Grall wrote:
> Hi Konrad,
>
> On 08/06/16 19:17, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 1f010bd..495f9d8 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.
flight 95410 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95410/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 host-install(3) broken REG
Hi Konrad,
On 08/06/16 19:17, Konrad Rzeszutek Wilk wrote:
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 1f010bd..495f9d8 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -129,6 +129,9 @@ SECTIONS
_sinittext = .;
*(.init.text)
_eini
> >>diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> >>index 1f010bd..495f9d8 100644
> >>--- a/xen/arch/arm/xen.lds.S
> >>+++ b/xen/arch/arm/xen.lds.S
> >>@@ -129,6 +129,9 @@ SECTIONS
> >>_sinittext = .;
> >>*(.init.text)
> >>_einittext = .;
> >>+#ifdef CONFIG_
On Tue, Jun 07, 2016 at 05:29:14PM +0100, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 02:58:05PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH OSSTEST v2 0/2] Test booting hvm guest with empty
> > cdrom drive"):
> > > This can only go in after the bug is fixed and possibly backported to all
On Wed, Jun 08, 2016 at 06:17:55PM +0200, Olaf Hering wrote:
> On Wed, Jun 08, George Dunlap wrote:
>
> > CC'ing Olaf and Konrad for their information. :-)
>
> I'm fine with the revert.
Me too!
Thanks!
>
> Olaf
___
Xen-devel mailing list
Xen-devel@l
flight 95443 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95443/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 6/8/16 12:53 PM, Julien Grall wrote:
> Hi Doug,
>
> On 24/05/16 14:56, Doug Goldstein wrote:
>> diff --git a/xen/Rules.mk b/xen/Rules.mk
>> index 961d533..da2f490 100644
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -20,13 +20,14 @@ include $(XEN_ROOT)/Config.mk
>> ifeq ($(debug),y)
>>
flight 95386 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 95235
test-amd64-amd64-
Hi Doug,
On 24/05/16 14:56, Doug Goldstein wrote:
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 961d533..da2f490 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -20,13 +20,14 @@ include $(XEN_ROOT)/Config.mk
ifeq ($(debug),y)
verbose := y
frame_pointer := y
-else
-CFLAGS += -DNDEBUG
On Wed, Jun 08, George Dunlap wrote:
> CC'ing Olaf and Konrad for their information. :-)
I'm fine with the revert.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 08/06/16 16:52, Wei Liu wrote:
> On Wed, Jun 08, 2016 at 04:32:13PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("[PATCH for-4.7] Revert "libxl: No emulated disk driver for
>> xvdX disk""):
>>> This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
>>>
>>> That commit causes regression on the s
On Wed, Jun 08, 2016 at 01:13:03PM +0200, Olaf Hering wrote:
> On Wed, Jun 08, George Dunlap wrote:
>
> > We definitely don't want to be putting this new stuff we're discussing
> > in 4.7.0. I'd be OK with reverting the original change for the release.
>
> I'm fine with delaying a change to addr
On Wed, Jun 08, 2016 at 04:32:13PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] Revert "libxl: No emulated disk driver for
> xvdX disk""):
> > This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
> >
> > That commit causes regression on the semantics of our diskspec.
> > See [0]
Hi Lars,
On Wed, Jun 8, 2016 at 9:02 AM, Lars Kurth wrote:
> We recently announced the program and speakers [1] for our Xen Project
> Developer Summit [2] happening in Toronto, Canada from August 25-26, 2016.
> The event will be co-located with LinuxCon North America [3].
>
> The Xen Project hy
Wei Liu writes ("[PATCH for-4.7] Revert "libxl: No emulated disk driver for
xvdX disk""):
> This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
>
> That commit causes regression on the semantics of our diskspec.
> See [0] for more information.
>
> [0] http://lists.xen.org/archives/html/xen-de
This reverts c0c099d157cc5bc942afef766cf141628a6380a1.
That commit causes regression on the semantics of our diskspec.
See [0] for more information.
[0] http://lists.xen.org/archives/html/xen-devel/2016-05/msg02876.html
Signed-off-by: Wei Liu
---
Please review carefully about this patch. There
Wei Liu writes ("Re: [PATCH] libxl: Fix NULL pointer due to XSA-178 fix wrong
XS nodename"):
> Reviewed-by: Wei Liu
Thanks. As per discussion on irc, I have now pushed this to all the
affected branches.
I think we should issue an update to XSA-178. Given that we warned in
the advisory that th
On Wed, Jun 08, 2016 at 03:56:36PM +0100, Ian Jackson wrote:
> In "libxl: Do not trust backend for disk eject vdev" (c69871a2fb26 on
> xen.git#staging) we changed libxl_evenable_disk_eject to read the
> device vdev out of xenstore from the /libxl path, rather than the
> backend path, and to read it
>>> On 08.06.16 at 16:28, wrote:
> Calculate the final bitmap for CPUs to add to avoid having annoying
> error messages complaining those CPUs are already present.
Ah, nice - I had noticed these odd errors too, but didn't dare to
complain about such a cosmetic issue at the same time.
Jan
_
In "libxl: Do not trust backend for disk eject vdev" (c69871a2fb26 on
xen.git#staging) we changed libxl_evenable_disk_eject to read the
device vdev out of xenstore from the /libxl path, rather than the
backend path, and to read it during setup rather than on each event.
However, the patch has a mi
flight 95438 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95438/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Signed-off-by: Ian Jackson
---
mg-debian-installer-update-all |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mg-debian-installer-update-all b/mg-debian-installer-update-all
index 4e76a69..d88ebf5 100755
--- a/mg-debian-installer-update-all
+++ b/mg-debian-installer
>>> On 08.06.16 at 10:58, wrote:
> From: Quan Xu
>
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
>
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Kevin Tian
> CC: Feng Wu
> CC: Jan Beulich
> CC: Andrew Cooper
CC: Suravee Suthikulpanit
> v7: just drop 'Reviewed-by: Jan Beulich ',
There is a new d-i kernel for wheezy. I have set it the new d-i in
Cambridge and Massachusetts using mg-debian-installer-update-all.
Use it.
Signed-off-by: Ian Jackson
---
production-config |2 +-
production-config-cambridge |2 +-
2 files changed, 2 insertions(+), 2 deletion
>>> On 08.06.16 at 10:59, wrote:
> @@ -169,6 +203,7 @@ static int enter_state(u32 state)
Right above here we have
if ( (error = device_power_down()) )
which is now wrong as long as SAVED_ALL is not zero.
> {
> printk(XENLOG_ERR "Some devices failed to power down.");
>
... because the available vcpu bitmap can change during domain life time
due to cpu hotplug and unplug.
For QEMU upstream, we interrogate QEMU for the number of vcpus. For
others, we look directly into xenstore for information.
Reported-by: Jan Beulich
Signed-off-by: Wei Liu
---
tools/libxl/li
Patch 3 is not really related to the bug, but something we can fix when after
having first patch.
Wei Liu (3):
libxl: introduce libxl__qmp_query_cpus
libxl: update vcpus bitmap in retrieved guest config
libxl: only issue cpu-add call to QEMU for not present CPU
tools/libxl/libxl.c
It interrogates QEMU for CPUs and update the bitmap accordingly.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 37 +
2 files changed, 40 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/l
Calculate the final bitmap for CPUs to add to avoid having annoying
error messages complaining those CPUs are already present.
We can also properly handle error from QMP now.
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c | 39 +--
1 file changed, 29 insertio
flight 95389 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 3 host-install(3) broken REGR. vs. 93974
test-am
On Wed, Jun 08, 2016 at 02:46:38PM +0800, Bob Liu wrote:
>
> On 06/07/2016 11:25 PM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 01, 2016 at 01:49:23PM +0800, Bob Liu wrote:
> >>
> >> On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrot
On Wed, Jun 08, 2016 at 10:43:33AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 08, 2016 at 08:11:22AM +0100, Ross Lagerwall wrote:
> > On 06/07/2016 07:15 PM, Konrad Rzeszutek Wilk wrote:
> > >.. in the design document. The official location is:
> > >
> > >git://xenbits.xen.org/livepatch-
On 08/06/16 14:11, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 08.06.16 at 10:58, wrote:
> From: Quan Xu
>
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Jun 08, 2016 at 08:11:22AM +0100, Ross Lagerwall wrote:
> On 06/07/2016 07:15 PM, Konrad Rzeszutek Wilk wrote:
> >.. in the design document. The official location is:
> >
> >git://xenbits.xen.org/livepatch-builds-tools.git
> >
> >Wiki is also updated with this URL.
> >
> >Signed-off-by:
>>> On 08.06.16 at 10:58, wrote:
> From: Quan Xu
>
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 08.06.16 at 10:58, wrote:
> @@ -831,10 +837,24 @@ out:
> {
> if ( iommu_flags )
> for ( i = 0; i < (1 << order); i++ )
> -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
> +{
> +rc = iomm
>>> On 08.06.16 at 15:43, wrote:
> On Wed, 2016-06-08 at 04:42 -0600, Jan Beulich wrote:
>> How big of system are we talking about? I'm asking to assess the
>> overhead of adding some cross-CPU checks to get_s_time_fixed()
>> (in a debugging patch), logging relevant values if non-monotonic
>> outp
The first three are Linux imports, while the 4th is an adjustment genuine
to our clone, and the 5th is an adjustment #3, the Linux equivalent of
which I didn't get any feedback on so far.
1: add SKX support
2: add KBL support
3: add BXT support
4: add a missing __init annotation
5: correct/improve
Linux commit 5dcef69486 ("intel_idle: add BXT support") added an
8-element lookup array with just a 2-bit value used for lookups. As per
the SDM that bit field is really 3 bits wide. Since the top two array
entries are zero, deal with the resulting invalid (zero) values by
moving the zero-MSR-value
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -983,7 +983,7 @@ static void __init bxt_idle_state_table_
* On SKL-H (model 0x5e) disable C8 and C9 if:
* C10 is enabled and SGX disabled
*/
-static void sklh_idle_state_table_update(void)
Broxton has all the HSW C-states, except C3.
BXT C-state timing is slightly different.
Here we trust the IRTL MSRs as authority
on maximum C-state latency, and override the driver's tables
with the values found in the associated IRTL MSRs.
Further we set the target_residency to 1x maximum latency,
KBL is similar to SKL
Signed-off-by: Len Brown
[Linux commit: 3ce093d4de753d6c92cc09366e29d0618a62f542]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -825,6 +825,8 @@ static const struct x86_cpu_id intel_idl
ICPU(0x56, bdw),
SKX is similar to BDX
Signed-off-by: Len Brown
[Linux commit: f9e71657c2c0a8f1c50884ab45794be2854e158e]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -530,6 +530,28 @@ static struct cpuidle_state skl_cstates[
{}
};
+static const
On Wed, 2016-06-08 at 04:42 -0600, Jan Beulich wrote:
> > > > On 07.06.16 at 17:54, wrote:
> > So, it looks to me that the TSC is actually ok, and it could be the
> > local_tsc_stamp and scale_delta() magic done in get_s_time_fixed()
> > (which, AFAICUI, is there to convert cycles to time) that do
Don't fetch CS explicitly, leverage the fact that hvm_emulate_prepare()
already does (and that hvm_virtual_to_linear_addr() doesn't alter it).
At once increase the length passed to hvm_virtual_to_linear_addr() by
one: There definitely needs to be at least one more opcode byte, and we
can avoid mis
... to clarify to callers that they don't need to fear the pointed to
data changing (which will be made use of subsequently).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2411,7 +2411,7 @@ int hvm_set_cr4(unsigned long value, boo
bool_t hvm_virtual_
1: constify hvm_virtual_to_linear_addr()'s segment register parameter
2: re-order operations in hvm_ud_intercept()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
The Masked interrupt status register (UARTMIS) is not described in ARM
SBSA 2.x document. Anding of two registers UARTMSC and UARTRIS values
gives the same information as register UARTMIS.
UARTRIS, UARTMSC and UARTMIS definitions are found in PrimeCell UART
PL011 (Revision: r1p4).
- 3.3.10 Interr
The ARM Server Base System Architecture describes a generic UART
interface. It doesn't support clock control registers, modem
control, DMA and hardware flow control features. So, extend the
driver probe() to handle SBSA interface and skip the accessing
PL011 registers that are not described in SBSA
The default baud and clock_hz configuration parameters are hardcoded
(commit 60ff980995008caf) for Versatile Express. Other platforms,
these default values may not be valid and might cause problems by
programming registers IBRD and FBRD incorrectly.
So, removing driver logic that sets the baud
In the control/hardware domain case without it we simply re-read the
same value that was put into b near the top of the function.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1119,8 +1119,7 @@ void pv_cpuid(struct cpu_user_regs *regs
* domain
Don't call shadow_hash_lookup() at all when get_gfn_query_unlocked()
didn't return a valid MFN.
Also no need for local variables used only once, the more with scopes
much wider than their actual use.
Signed-off-by: Jan Beulich
---
Question is whether we shouldn't also get rid of
guest_l[234]e_ge
As a follow-up to commit af07377007 ("IOMMU/x86: per-domain control
structure is not HVM-specific"), fold hvm/iommu.h into iommu.h.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/iommu.h
+++ /dev/null
@@ -1,66 +0,0 @@
-#ifndef __ASM_X86_HVM_IOMMU_H__
-#define __ASM_X86_HVM_IOMMU_H__
-
Signed-off-by: Jan Beulich
--- a/xen/include/public/errno.h
+++ b/xen/include/public/errno.h
@@ -91,8 +91,8 @@ XEN_ERRNO(EDEADLK,35) /* Resource deadl
XEN_ERRNO(EDEADLOCK, 35) /* Resource deadlock would occur. Aliases
EDEADLK */
XEN_ERRNO(ENAMETOOLONG,36) /* File name
No need to force inclusion of xen/config.h - AFLAGS incorporates
CFLAGS, which already does this.
Also no need to use nested $(filter-out ...) - one of them can deal
with any number of patterns.
Signed-off-by: Jan Beulich
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,7 +64,7 @@ ifneq ($(max_phys
If we have the translation result available already, we should also use
is here. In my tests with Linux guests this eliminates all calls to
hvmemul_linear_to_phys() out of the two functions being changed.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.
... to avoid re-doing the same translation later again (in a retry, for
example). This doesn't help very often according to my testing, but
it's pretty cheap to have, and will be of further use subsequently.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emula
On Wed, Jun 08, 2016 at 02:05:10PM +0100, George Dunlap wrote:
> On 08/06/16 13:46, Wei Liu wrote:
> > On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote:
> >> On 6/8/16 6:57 AM, George Dunlap wrote:
> >>> On 08/06/16 11:07, Daniel P. Berrange wrote:
> On Wed, Jun 08, 2016 at 10:50
flight 95373 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95373/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 95234
test-armhf-armhf-
On 08/06/16 13:46, Wei Liu wrote:
> On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote:
>> On 6/8/16 6:57 AM, George Dunlap wrote:
>>> On 08/06/16 11:07, Daniel P. Berrange wrote:
On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote:
> On 07/06/16 16:57, Wei Liu wrote:
1: latch linear->phys translation results
2: use available linear->phys translations in REP MOVS/STOS handling
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
We recently announced the program and speakers [1] for our Xen Project
Developer Summit [2] happening in Toronto, Canada from August 25-26, 2016. The
event will be co-located with LinuxCon North America [3].
The Xen Project hypervisor powers the new needs of computing and virtualization
through
On 08/06/16 13:11, Daniel P. Berrange wrote:
> On Wed, Jun 08, 2016 at 11:57:45AM +0100, George Dunlap wrote:
>>
>> Well we definitely want to make it possible for people to use xl while
>> still avoiding DoSes. But at the simplest level this could be done by
>> having qemu's stderr/stdout piped t
This allows us to see the full ioreq without having to peek into state
which is supposedly private to the emulation framework.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -199,9 +199,8 @@ static struct msi_desc *msixtbl_ad
We can calculate the needed value at the single use site more easily.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -411,7 +411,7 @@ static void add_msixtbl_entry(struct dom
INIT_RCU_HEAD(&entry->rcu);
atomic_set(&entry->refcnt, 0);
-en
msixtbl_pt_{,un}register() already run with both the PCI devices lock
and the domain event lock held, so there's no need for another lock.
Just to be on the safe side, acquire the domain event lock in the
cleanup function (albeit I don't think this is strictly necessary).
Signed-off-by: Jan Beulic
There's no point in registering the internal MSI-X table intercept
functions on all domains - it is sufficient to do so once a domain gets
an MSI-X capable device assigned.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -644,8 +644,6 @@ int hvm_domain_ini
Make obvious that xcomp_bv is expected to be clear when we get here
with XSTATE_COMPACTION_ENABLED not set.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -387,8 +387,11 @@ void xrstor(struct vcpu *v, uint64_t mas
{ \
if ( unlikely(!(p
1: defer intercept handler registration
2: drop list lock
3: drop pci_msix_get_table_len()
4: use generic intercept handler in place of MMIO one
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-dev
On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote:
> On 6/8/16 6:57 AM, George Dunlap wrote:
> > On 08/06/16 11:07, Daniel P. Berrange wrote:
> >> On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote:
> >>> On 07/06/16 16:57, Wei Liu wrote:
> > I must admit I'm not familia
flight 95426 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95426/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Hello Shanker,
On 08/06/16 13:11, Shanker Donthineni wrote:
I don't know exactly which of the patch causing the issue. I have
noticed a couple of drivers are not receiving SPI interrupts in DOM0.
I need to digest your patches before tracing/investigate the problem
to get more details.
FYI, our
On 6/7/16 12:08 PM, Doug Goldstein wrote:
> LLVM repos are currently down so drop them from being installed so we
> can get some testing back.
Signed-off-by: Doug Goldstein
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
On Wed, Jun 08, 2016 at 11:07:16AM +0100, Daniel P. Berrange wrote:
[...]
> > situation, but that's just a matter of plumbing I think.)
> >
> > The options we've come up with, broadly, are as follows:
> >
> > 1. Try to use the existing syslog facilities
> >
> > 2. Re-purpose one of our existing
On Wed, Jun 08, 2016 at 11:57:45AM +0100, George Dunlap wrote:
>
> Well we definitely want to make it possible for people to use xl while
> still avoiding DoSes. But at the simplest level this could be done by
> having qemu's stderr/stdout piped to /dev/null by default, and allowing
> an option f
I don't know exactly which of the patch causing the issue. I have
noticed a couple of drivers are not receiving SPI interrupts in DOM0.
I need to digest your patches before tracing/investigate the problem
to get more details.
FYI, our system uses both the EDGE and LEVEL interrupts, any major
chang
On Wed, Jun 08, 2016 at 02:04:45PM +0200, Olaf Hering wrote:
> On Wed, Jun 08, Wei Liu wrote:
>
> > I think we should just revert the patch in question and solve this issue
> > properly in 4.8.
>
> What impact does reverting c0c099d have for OVMF?
> I dont know myself, just used it the first time
On Wed, Jun 08, Wei Liu wrote:
> I think we should just revert the patch in question and solve this issue
> properly in 4.8.
What impact does reverting c0c099d have for OVMF?
I dont know myself, just used it the first time now with staging-4.6.
Olaf
_
>>> On 07.06.16 at 18:08, wrote:
> LLVM repos are currently down so drop them from being installed so we
> can get some testing back.
> ---
I was about to commit this, but you didn't provide an S-o-b.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xe
On Tue, Jun 07, 2016 at 10:18:38AM +, Euan Harris wrote:
> Guest reads of MSR_IA32_VMX_VMFUNC should be handled by
> the logic in vmx_msr_read_intercept(). Otherwise a guest
> can read the raw host value of this MSR, even if nested
> vmx is disabled.
>
> Signed-off-by: Euan Harris
For 4.7:
On 6/8/16 6:57 AM, George Dunlap wrote:
> On 08/06/16 11:07, Daniel P. Berrange wrote:
>> On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote:
>>> On 07/06/16 16:57, Wei Liu wrote:
> I must admit I'm not familiar with the division of responsibility
> for managing QEMU between the
On 08/06/16 12:48, Shanker Donthineni wrote:
Hi Julien,
Tested on our hardware, this patchset fixed the deadlock issue but
some of the SPIs are not working.
Can you give a bit more of details?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Hi Julien,
Tested on our hardware, this patchset fixed the deadlock issue but
some of the SPIs are not working.
--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Co
1 - 100 of 147 matches
Mail list logo
