branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree
flight 106086 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106086/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105962
test-armhf-armhf-libvirt-x
flight 106083 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
flight 106081 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 8 leak-check/basis(8) fail REGR. vs.
105933
test-amd64-amd6
On 24/02/2017 23:02, Tamas K Lengyel wrote:
> On Fri, Feb 24, 2017 at 8:10 AM, Andrew Cooper
> wrote:
>> On 24/02/17 14:42, Vlad-Ioan TOPAN wrote:
#VE, by design, raises an exception in non-root context, without
breaking out to the hypervisor.
The vcpu in question needs to set
flight 106063 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 106009
Regressions which ar
On Fri, Feb 24, 2017 at 8:10 AM, Andrew Cooper
wrote:
> On 24/02/17 14:42, Vlad-Ioan TOPAN wrote:
>>> #VE, by design, raises an exception in non-root context, without
>>> breaking out to the hypervisor.
>>>
>>> The vcpu in question needs to set up a suitable #VE handler, so it is
>>> not safe for
From: naroahlee
Bug Analysis:
When more than one idle VCPUs that have the same PCPU as their
previous running core invoke runq_tickle(), they will tickle the same
PCPU. The tickled PCPU will only pick at most one VCPU, i.e., the
highest-priority one, to execute. The other VCPUs will not be
schedu
flight 106062 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-bootfail REGR. vs. 105989
Regressions whi
On 24/02/2017 19:57, Shanker Donthineni wrote:
Hi Julien,
Hi Shanker,
On 01/31/2017 10:18 AM, Julien Grall wrote:
On 31/01/17 16:02, Jaggi, Manish wrote:
On 1/31/2017 8:47 PM, Julien Grall wrote:
On 31/01/17 14:08, Jaggi, Manish wrote:
Hi Julien,
On 1/31/2017 7:16 PM, Julien Grall
flight 106089 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106089/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
Hi Julien,
On 01/31/2017 10:18 AM, Julien Grall wrote:
On 31/01/17 16:02, Jaggi, Manish wrote:
On 1/31/2017 8:47 PM, Julien Grall wrote:
On 31/01/17 14:08, Jaggi, Manish wrote:
Hi Julien,
On 1/31/2017 7:16 PM, Julien Grall wrote:
On 31/01/17 13:19, Jaggi, Manish wrote:
On 1/31/2017
Hi Andre,
On 02/22/2017 01:06 AM, Vijay Kilari wrote:
Hi Andre,
On Tue, Jan 31, 2017 at 12:01 AM, Andre Przywara wrote:
The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may req
Hi Andre
On 02/16/2017 01:03 PM, Shanker Donthineni wrote:
Hi Andre,
On 01/30/2017 12:31 PM, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to th
flight 106057 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106057/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt 3 host-install(3) broken in 106028 pass in 106057
test-amd64-i386-xl-qemut-debi
On Wed, 2017-02-15 at 15:31 +, George Dunlap wrote:
> On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
> wrote:
> >
> > When traversing a Credit2 runqueue to select the
> > best candidate vCPU to be run next, show in the
> > trace which vCPUs we consider.
> >
> > A bit verbose, but quite usefu
Hi Boris,
On 24/02/17 16:15, Boris Ostrovsky wrote:
Looking at
void _spin_lock(spinlock_t *lock)
{
spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
LOCK_PROFILE_VAR;
check_lock(&lock->debug);
tickets.head_tail = arch_fetch_and_add(&lock->tickets.head_tail,
On Wed, 2017-02-15 at 13:57 +, George Dunlap wrote:
> On Thu, Feb 9, 2017 at 1:58 PM, Dario Faggioli
> wrote:
> >
> > Signed-off-by: Dario Faggioli
>
> Acked-by: George Dunlap
>
Thanks.
> With one comment...
>
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
On Wed, 2017-02-15 at 10:49 +, George Dunlap wrote:
> On Thu, Feb 9, 2017 at 3:33 PM, Dario Faggioli
> wrote:
> > On Thu, 2017-02-09 at 07:36 -0700, Jan Beulich wrote:
> > Nope. I'll get rid of them from above.
> > > Also I'm not sure whether the sched*.c files are an exception,
> > > but
> >
The emulation tests run `sarx %edx,(%ecx),%ebx` with 0xfedcba98 pointed at by
%ecx, and 0xff13 in %rdx.
As the instruction uses a 32bit operand size, the expected result is
0xffdb in %rbx (rather than 0xffdb), due to normal
usual zeroing of the upper half of the 64bit regis
flight 106058 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
version targeted for testi
On 24/02/17 17:49, Doug Goldstein wrote:
> On 2/24/17 10:14 AM, Juergen Gross wrote:
>> On 24/02/17 17:06, Doug Goldstein wrote:
>>> On 2/22/17 1:53 AM, Juergen Gross wrote:
On 20/02/17 16:19, Andrew Cooper wrote:
> On 20/02/17 14:43, Juergen Gross wrote:
>> On 20/02/17 15:31, Wei Liu
flight 106084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106084/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Wed, 2017-02-22 at 17:59 -0500, Meng Xu wrote:
> Hi Haoran,
>
> Thank you for sending this patch out quickly! :-)
>
> The title can be
> [PATCH] xen: rtds: only tickle the same cpu once
>
Or:
xen: rtds: only tickle non-already tickled CPUs
(Nitpicking, I know, but I don't like how "the same"
On 2/24/17 10:14 AM, Juergen Gross wrote:
> On 24/02/17 17:06, Doug Goldstein wrote:
>> On 2/22/17 1:53 AM, Juergen Gross wrote:
>>> On 20/02/17 16:19, Andrew Cooper wrote:
On 20/02/17 14:43, Juergen Gross wrote:
> On 20/02/17 15:31, Wei Liu wrote:
>> On Thu, Feb 16, 2017 at 08:47:07AM
On Fri, Feb 24, 2017 at 03:27:02PM +, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 106009:
> regressions - trouble: blocked/broken/fail/pass"):
> > Can you change PVH test to use
> > device_model_version="none"
> > instead of
> > pvh=1
>
> I had thi
Including create, reboot, shutdown, pause, unpause and destroy.
Lift a bunch of core data structures and function declarations to xl.h
because they are needed in both xl_cmdimpl.c and xl_vmcontrol.c.
Signed-off-by: Wei Liu
---
tools/xl/Makefile |1 +
tools/xl/xl.h | 67 +++
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +
tools/xl/xl_cmdimpl.c | 229 -
tools/xl/xl_tmem.c| 251 ++
3 files changed, 253 insertions(+), 229 deletions(-)
create mode 100644 tools/xl/xl
Include COLO / Remus code because they are built on top of the existing
migration protocol.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 715 ---
tools/xl/xl_migrate.c | 754
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_block.c | 129 ++
tools/xl/xl_cmdimpl.c | 99 --
3 files changed, 130 insertions(+), 100 deletions(-)
create mode 100644 tools/xl/xl_block
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 1 +
tools/xl/xl_cmdimpl.c | 122
tools/xl/xl_vtpm.c| 153 ++
3 files changed, 154 insertions(+), 122 deletions(-)
create mode 100644 tools/xl/xl_vtpm
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 247
tools/xl/xl_pci.c | 278 ++
3 files changed, 279 insertions(+), 248 deletions(-)
create mode 100644 tools/xl/xl
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 190 --
tools/xl/xl_usb.c | 222 ++
3 files changed, 223 insertions(+), 191 deletions(-)
create mode 100644 tools/xl/xl_u
The new file also contains code for channel, which is just a console
in disguise.
Replace the call to vncviewer() with libxl_vncviewer_exec() directly in
main_vncviewer.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 98 -
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 883 +--
tools/xl/xl_info.c| 925 ++
3 files changed, 929 insertions(+), 881 deletions(-)
create mode 100644 tools/xl
Add some function declarations to xl.h because they are now needed in
multiple files.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 6 +
tools/xl/xl_cmdimpl.c | 227 --
tools/xl/xl_saverestore.c | 273
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 140
tools/xl/xl_nic.c | 172 ++
3 files changed, 173 insertions(+), 141 deletions(-)
create mode 100644 tools/xl/xl_nic
A collections of functions that don't warrant their own files.
Moving main_devd there requires lifting do_daemonize to xl_utils.c.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 390 --
tools/xl/xl_misc.c| 3
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 306 -
tools/xl/xl_vcpu.c| 337 ++
3 files changed, 338 insertions(+), 307 deletions(-)
create mode 100644 tools/xl/x
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 592 ---
tools/xl/xl_cpupool.c | 624 ++
3 files changed, 625 insertions(+), 593 deletions(-)
create mode 100644 tools/xl
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 1 +
tools/xl/xl_cmdimpl.c | 856
tools/xl/xl_sched.c | 888 ++
3 files changed, 889 insertions(+), 856 deletions(-)
create mode 100644 tools/xl
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 119 ---
tools/xl/xl_flask.c | 153 ++
3 files changed, 154 insertions(+), 120 deletions(-)
create mode 100644 tools/xl/xl_flas
After splitting out all the meaty bits, xl_cmdimpl.c doesn't contain
much. Merge the rest into xl.c and delete the file.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.c | 58 +++
tools/xl/xl_cmdimpl.c | 107 ---
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cd.c | 114 ++
tools/xl/xl_cmdimpl.c | 80 ---
3 files changed, 115 insertions(+), 81 deletions(-)
create mode 100644 tools/xl/xl_cd.c
dif
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 136
tools/xl/xl_mem.c | 167 ++
3 files changed, 168 insertions(+), 137 deletions(-)
create mode 100644 tools/xl/xl_mem
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 1 +
tools/xl/xl_cmdimpl.c | 533 ---
tools/xl/xl_psr.c | 567 ++
3 files changed, 568 insertions(+), 533 deletions(-)
create mode 100644 tools/xl/
>> +for_each_vcpu( d, v )
> If you use blanks immediately inside the parentheses, there should
> also be one immediately before the opening one. Can be corrected
> upon commit of course.
Yes, please fix this when committing. Thanks.
-boris
___
xen_pmu_init/finish() functions are used in suspend.c and
enlighten.c, add stubs for now.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Kconfig | 2 +-
arch/x86/xen/Makefile | 5 +++--
arch/x86/xen/pmu.h| 5 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xe
More or less mechanically split smp.c into 3 files. XEN_PV_SMP and
XEN_PVHVM_SMP config options added to support the change.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Kconfig| 8 +
arch/x86/xen/Makefile | 3 +
arch/x86/xen/enlighten_pv.c | 9 +
arch/x86/xen/smp.c
[Adding Juergen]
On Wed, 2017-02-22 at 01:46 -0700, Jan Beulich wrote:
> > > > On 22.02.17 at 01:02, wrote:
> > (XEN) Xen call trace:
> > (XEN)[]
> > sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
> > (XEN)[]
> > sched_credit2.c#csched2_schedule+0x823/0xb4e
> > (XEN)[] schedule.c#sched
On 24/02/17 17:06, Doug Goldstein wrote:
> On 2/22/17 1:53 AM, Juergen Gross wrote:
>> On 20/02/17 16:19, Andrew Cooper wrote:
>>> On 20/02/17 14:43, Juergen Gross wrote:
On 20/02/17 15:31, Wei Liu wrote:
> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
>> There have be
Hi,
it's been a while since my 'RFC' submission in November:
https://lists.xen.org/archives/html/xen-devel/2016-11/msg01044.html
I was advised to wait till PVHv2 stuff lands upstream and as this has already
happened I'm sending the first non-RFC version.
Changes since RFC:
- Rebase
- Use enlight
Get read of #ifdefs in suspend.c by splitting the code into
suspend_pv.c and suspend_hvm.c.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Makefile | 4 ++--
arch/x86/xen/suspend.c | 58 --
arch/x86/xen/suspend_hvm.c | 22 ++
Introduce CONFIG_XEN_PV config option and split enlighten.c into
4 files. Temporary add #ifdef CONFIG_XEN_PV to smp.c and mmu.c to
not break the build and not make the patch even bigger.
xen_cpu_up_prepare*/xen_cpu_die hooks require separation to support
future xen_smp_intr_init() split.
Signed-o
Looking at
void _spin_lock(spinlock_t *lock)
{
spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
LOCK_PROFILE_VAR;
check_lock(&lock->debug);
tickets.head_tail = arch_fetch_and_add(&lock->tickets.head_tail,
tickets.head_tail);
while (
It was never intended to be committed. Lucky the high level Makefile was
correct so it didn't cause us problem when building xl.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index d4b862c9b9..32dff4058
xl_cmdimpl.c has become prohibitively large (almost 10k lines in one single
file). Try to split it up into multiple files according to the functionality of
the code.
I will run a full osstest flight before merging. Send the first version out as
quick as possible to gather feedback because I know
Move some commonly used functions to a new file. Prepend "x" to
function names to stick to consistent naming scheme.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 343 +-
tools/xl/xl_utils.c | 258
There is no reason for a client to include a private header from libxl.
Remove the inclusion and define _GNU_SOURCE for {v,}asprintf in
xl_cmdimpl.c.
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 2 --
tools/xl/xl_cmdimpl.c | 2 +-
tools/xl/xl_sxp.c | 2 --
3 files changed, 1 insertion(
Signed-off-by: Wei Liu
---
tools/xl/xl_cmdimpl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index 9901011008..1d7cf8ffa8 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -6732,7 +6732,7 @@ static int sched
We're going to split xl_cmdimpl.c into multiple files. Lift the commonly
used macros to xl_utils.h.
Signed-off-by: Wei Liu
---
tools/xl/xl_cmdimpl.c | 104 +---
tools/xl/xl_utils.h | 129 ++
2 files changed, 13
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 4 +---
tools/xl/xl.h | 2 +-
tools/xl/xl_cmdimpl.c | 4 +---
tools/xl/xl_cmdtable.c | 2 +-
tools/xl/xl_sxp.c | 4 +---
5 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/tools/xl/xl.c b/tools/xl/xl.c
index a27225815
They should be treated like any other libraries installed on the build
host. Compiler options are set correctly to point to their locations.
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 6 +++---
tools/xl/xl.h | 2 +-
tools/xl/xl_cmdimpl.c | 8
tools/xl/xl_cmdtable.c |
It is included by xl.h. Previously it was using _paths.h from some other
place. We'd better generate one for xl as well.
Signed-off-by: Wei Liu
---
.gitignore| 1 +
tools/xl/Makefile | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index
On 2/22/17 1:53 AM, Juergen Gross wrote:
> On 20/02/17 16:19, Andrew Cooper wrote:
>> On 20/02/17 14:43, Juergen Gross wrote:
>>> On 20/02/17 15:31, Wei Liu wrote:
On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
> There have been reports that Fedora 25 uses /run instead of /
flight 106051 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
105835
test-armh
On 2/22/17 5:37 AM, Wei Liu wrote:
> On Wed, Feb 22, 2017 at 08:53:24AM +0100, Juergen Gross wrote:
>> On 20/02/17 16:19, Andrew Cooper wrote:
>>> On 20/02/17 14:43, Juergen Gross wrote:
On 20/02/17 15:31, Wei Liu wrote:
> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
>> > + System administrator can change PSR allocation policy at runtime by
>> > + tool stack. Since MBA shares COS with CAT/CDP, a COS corresponds to a
>> > + 2-tuple, like [CBM, Thrtl] with only-CAT enalbed, when CDP is enable,
>> > + the COS corresponds to a 3-tuple, like [Code_CBM, Data_CBM,
>>> On 24.02.17 at 16:32, wrote:
> On 24/02/17 15:13, Roger Pau Monne wrote:
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 85cbb7c..65b7475 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -60,11 +60,8 @@ struct xen_domctl_
At 15:13 + on 24 Feb (1487949198), Roger Pau Monne wrote:
> It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
> point of view.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-deve
>>> On 22.02.17 at 19:24, wrote:
> When toolstack overrides Intel CPUID leaf 0xa's PMU version with an
> invalid value VPMU should not be available to the guest.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
with one nit:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl
>>> On 22.02.17 at 19:24, wrote:
> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
> bit. This is problematic:
> * For HVM guests VPMU context is allocated lazily, during the first
> access to VPMU MSRs. S
On 24/02/17 15:13, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 66b7aba..fa601da 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -62,10 +62,6 @@ integer_param("maxcpus", max_cpus);
>
> unsigned long __read_mostly cr4_pv32_mask;
>
On 24/02/17 15:13, Roger Pau Monne wrote:
> It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
> point of view.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On 24/02/17 15:13, Roger Pau Monne wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 85cbb7c..65b7475 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -60,11 +60,8 @@ struct xen_domctl_createdomain {
> /* Disable out-of-sync
>>> On 24.02.17 at 16:13, wrote:
> This function is only used by PVHv2 domain build, so move it together with the
> other PVH domain build functions.
>
> Just code motion, no functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 106009: regressions
- trouble: blocked/broken/fail/pass"):
> Can you change PVH test to use
> device_model_version="none"
> instead of
> pvh=1
I had this conversation with Roger and we seem to have concluded that
`pvh=1' should b
>>> On 23.02.17 at 10:41, wrote:
> The current implementation of nested VMX cannot work without HAP.
Of course the better route would be to fix the actual problem,
the more that - according to other feedback you've got elsewhere -
this apparently is a regression. Nevertheless I can see you perhap
>>> On 23.02.17 at 10:41, wrote:
> @@ -992,10 +993,30 @@ bool_t update_secondary_system_time(struct vcpu *v,
> {
> XEN_GUEST_HANDLE(vcpu_time_info_t) user_u = v->arch.time_info_guest;
> smap_check_policy_t saved_policy;
> +bool nested_guest_mode = false;
>
> if ( guest_handle
flight 106047 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106047/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 3 host-install(3) broken REGR. vs. 1059
>>> On 24.02.17 at 11:52, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1621,8 +1621,8 @@ static enum mce_result mce_action(const struct
> cpu_user_regs *regs,
> handlers = mce_uhandlers;
> }
>
> -/* At least a default handler should
flight 106048 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106048/
Failures and problems with tests :-(
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. 105973
Re
This removal applies to both the hypervisor and the toolstack side of PVHv1.
Note that on the toolstack side there's one hiccup: on xl the "pvh"
configuration option is translated to builder="hvm",
device_model_version="none". This is done because otherwise xl would start
parsing PV like options,
This function is only used by PVHv2 domain build, so move it together with the
other PVH domain build functions.
Just code motion, no functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain_build.c | 134 ++---
Hello,
This patch series removes the PVHv1 code, both from the hypervisor and the
tools, and also gets rid of the has_hvm_container_{domain/vcpu} macro, since
from Xen's point of view there are only two types of guests: PV or HVM.
Last patch is a minor code movement to have all the domain build P
Hi,
Not 100% sure, but anyway...
Can you recheck after squashing all memory nodes to a single one.
---
I guess, you have following in your device tree:
memory@4800 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
memory@5000
It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
point of view.
Signed-off-by: Roger Pau Monné
---
Cc: Christoph Egger
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Elena Ufimtseva
Cc: Georg
On 24/02/17 14:42, Vlad-Ioan TOPAN wrote:
>> #VE, by design, raises an exception in non-root context, without
>> breaking out to the hypervisor.
>>
>> The vcpu in question needs to set up a suitable #VE handler, so it is
>> not safe for an external entity to chose when a vcpu should start
>> receiv
>>> On 24.02.17 at 11:52, wrote:
> The current implementation only fills MC MSRs on vcpu0 and leaves MC
> MSRs on other vcpus empty in the broadcast case. When guest reads 0
> from MSR_IA32_MCG_STATUS on vcpuN (N > 0), it may think it's not
> possible to recover the execution on that vcpu and then
>>> On 24.02.17 at 11:52, wrote:
> On Intel CPU, an attemp to write to MSR_IA32_MCG_STATUS with any
> non-zero value would result in #GP.
>
> This commit writes 0 on AMD CPU as well instead of just clearing MCIP
> bit, because all non-reserved bits of MSR_IA32_MCG_STATUS have been
> handled at th
>>> On 24.02.17 at 11:52, wrote:
> All existing calls to x86_mcinfo_reserve() are followed by statements
> that set the size and the type of the reserved space, so move them into
> x86_mcinfo_reserve() to simplify the code.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
>>> On 24.02.17 at 11:52, wrote:
> c/s 9d13fd9fd320a7740c6446c048ff6a2990095966 turned to update the
> mcinfo buffer in-place instead of using x86_mcinfo_add(). The last
> uses of x86_mcinfo_add() were removed by that commit as well.
> Therefore, x86_mcinfo_add() was deprecated in fact.
>
> Signe
On 21/02/17 12:03, George John wrote:
Hi,
Hello,
I was trying out xen in salvator-X(M3 Board as described
in
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
I ran in to following error:
U-Boot 2015.04 (Feb 21 2017 - 14:24:48)
CPU: Renesas Electronics
flight 106071 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs.
106060
Tests
flight 106042 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 3 host-install(3) broken REGR. vs. 59254
test-amd64-i386-xl-
Hi Ian,
On 23/02/17 20:53, osstest service owner wrote:
flight 106032 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106032/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1)
> #VE, by design, raises an exception in non-root context, without
> breaking out to the hypervisor.
>
> The vcpu in question needs to set up a suitable #VE handler, so it is
> not safe for an external entity to chose when a vcpu should start
> receiving #VE's.
The problem is that from a security
This run is configured for baseline tests only.
flight 68612 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/
On 02/23/2017 08:20 PM, osstest service owner wrote:
> flight 106009 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106009/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-ovmf-am
>>> On 24.02.17 at 11:59, wrote:
> c/s 49de10f3c "x86/hvm: Don't raise #GP behind the emulators back for MSR
> accesses" missed an edge case.
>
> hvm_set_efer() raises #GP itself, so deliberately avoided the goto gp_fault
> path in hvm_msr_write_intercept().
>
> With the above change, guest upda
1 - 100 of 129 matches
Mail list logo
