In order to be able to determine the Xen guest type from within the
guest as a user there is currently no stable interface available.
Add a sysfs node for that purpose as the guest type information is
available for the kernel.
While doing this document all the other Xen related sysfs nodes.
Juer
Currently there is no reliable user interface inside a Xen guest to
determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
try to determine this by various rather hacky mechanisms (parsing of
boot messages before they are gone, trying to make use of known subtle
differences in behav
Today only a few sysfs nodes under /sys/hypervisor/ are documented
for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. Rename
this file to Documentation/ABI/testing/sysfs-hypervisor and add
descriptions of the other nodes.
Signed-off-by: Juergen Gross
---
Documentation/ABI/testing/sysfs-h
On Sat, May 20, 2017 at 03:41:57PM +, osstest service owner wrote:
> flight 109613 qemu-mainline real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109613/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64
Hello,
Over the weekend, we got some extensive testing on Xen 4.9
First of all, current staging has a broken build. This is a side effect
of c/s f745b55, 93ade42 and 728d21b, and occurs because the `make
tools-install` target no longer installs the Xen public headers into
/usr/include/xen.
As a
(CC Jan and Andrew)
On 22/05/17 09:39, Hao, Xudong wrote:
Bug detailed description:
Xen has a MCE soft injection tool xen-mceinj to test RAS, testing with
this tool cause dom0 crash and system reboot. Attach the whole log.
Environment :
HW: Skylake/Broadw
(CC Jan and Andrew)
On 22/05/17 07:35, Hao, Xudong wrote:
Bug detailed description:
Create one RHEL7.3 HVM and do live migration continuously, while doing
the 200+ or 300+ times live-migration, tool stack report error and
migration failed.
Environment :
H
On 22/05/17 07:35, Hao, Xudong wrote:
> Bug detailed description:
>
>
>
> Create one RHEL7.3 HVM and do live migration continuously, while doing the
> 200+ or 300+ times live-migration, tool stack report error and migration
> failed.
>
>
>
> Environment :
>
> --
flight 109664 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109664/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 109653
pass in 109664
test-amd64-i386-
On Tue, Jan 24, 2017 at 3:27 PM, Paul Durrant wrote:
> This patch removes the need for handling HVMOP restarts, so that
> infrastructure is removed.
This turns out to be false -- HVMOP_set_hvm_param can fail with
-ERESTART if you're setting HVM_PARAM_IDENT_PT and it fails to grab
the domain_ctl l
Hi Wei,
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
>> @@ -688,6 +688,15 @@ static int libxl__build_dom(libxl__gc *gc, uint32_t
>> domid,
>> goto out;
>> }
>>
>> +if ( info->vuart &&
>> + (ret = xc_dom_vpl011_init(CTX->xch,
>> +
This run is configured for baseline tests only.
flight 71386 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71386/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-libvirt 5 libvirt-build
osstest service owner writes ("[linux-linus test] 109656: regressions - FAIL"):
> flight 109656 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109656/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> tes
Hi Wei,
> [...]
>> >> @@ -151,13 +154,19 @@ retry_transaction:
>> >> if (rc) goto out;
>> >>
>> >> if (!libxl_only) {
>> >> -rc = libxl__xs_write_checked(gc, t,
>> >> GCSPRINTF("%s/frontend",libxl_path),
>> >> - frontend_path);
>> >> -
On Mon, May 22, 2017 at 11:18 AM, George Dunlap
wrote:
> On 22/05/17 07:35, Hao, Xudong wrote:
>> Bug detailed description:
>>
>>
>>
>> Create one RHEL7.3 HVM and do live migration continuously, while doing the
>> 200+ or 300+ times live-migration, tool stack report error and mig
> -Original Message-
> From: George Dunlap
> Sent: 22 May 2017 06:30
> To: Paul Durrant
> Cc: xen-devel ; Ian Jackson
> ; Andrew Cooper ;
> Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v8 6/8] dm_op: convert
> HVMOP_set_mem_type
>
> On Tue, Jan 24, 2017 at 3:27 PM, Paul Durrant
> wrote
On 22/05/17 12:03, George Dunlap wrote:
> On Mon, May 22, 2017 at 11:18 AM, George Dunlap
> wrote:
>> On 22/05/17 07:35, Hao, Xudong wrote:
>>> Bug detailed description:
>>>
>>>
>>>
>>> Create one RHEL7.3 HVM and do live migration continuously, while doing the
>>> 200+ or 300+ ti
Hi,
On 19/05/17 16:21, Jan Beulich wrote:
On 27.04.17 at 16:35, wrote:
+VPCI_BAR_MEM64_LO,
+VPCI_BAR_MEM64_HI,
+} type;
+/* Hardware address. */
+paddr_t paddr;
+/* Guest address where the BAR should be mapped. */
xc_{get,set}_hvm_param() are deprecated because they truncate their value
parameter in 32bit builds of libxc, and are therefore unfit for use.
As there is only a single remaining user, switch that user over to
xc_hvm_param_get() and drop these functions completely.
Signed-off-by: Andrew Cooper
-
flight 109676 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109676/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7320b8ed1879b31657a8d6a62e6cd0ff1f645754
baseline version:
ovmf 112f4ada2e6bf606d28c5
Hi Bhupinder,
On 10/05/17 15:24, Bhupinder Thakur wrote:
These functions are generic in nature and can be reused by other emulation
code in Xen. One recent example is pl011 emulation, which needs similar
funictions to read/write the registers.
s/funictions/functions/
[...]
-static inline vo
Hi Bhupinder,
On 10/05/17 15:24, Bhupinder Thakur wrote:
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index c838298..75c716e 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -172,18 +172,6 @@ static inline int REG_RANK_NR(int b, uint32_t n)
flight 109670 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
Hi Julien,
>
>> -static inline void vgic_reg##sz##_clearbits(uint##sz##_t *reg, \
>> -register_t bits,\
>> -const mmio_info_t *info)\
>> -{
> diff --git a/Documentation/ABI/testing/sysfs-hypervisor
> b/Documentation/ABI/testing/sysfs-hypervisor
> index 443196f0aa1c..06850f74ebd4 100644
> --- a/Documentation/ABI/testing/sysfs-hypervisor
> +++ b/Documentation/ABI/testing/sysfs-hypervisor
> @@ -19,6 +19,19 @@ Contact: xen-de...@lists.
_PAGE_GNTTAB is only used in debug builds of Xen; in release builds, it has
the value 0. Coverity complains that "l1e_get_flags(l1e) & 0" is logically
dead.
Add an extra condition into the logic to skip the flag check if _PAGE_GNTTAB
is 0.
No functional change.
Coverity-ID: 1362036
Signed-off-b
Hi, Dmitry!
It's been quite a while now, I'm just wondering if
you had a chance to look at the patch?
Thank you,
Oleksandr
On 05/12/2017 04:43 PM, Oleksandr Andrushchenko wrote:
gentle reminder
On 05/05/2017 07:43 AM, Oleksandr Andrushchenko wrote:
Hello, Dmitry!
On 04/21/2017 09:42 AM, Ole
Hi, Dmitry!
It's been quite a while now, I'm just wondering if
you had a chance to look at the patch?
Thank you,
Oleksandr
On 05/12/2017 04:44 PM, Oleksandr Andrushchenko wrote:
gentle reminder
On 05/05/2017 07:45 AM, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 04/21/2017 09:40 AM, Oleks
>>> On 21.05.17 at 15:09, wrote:
> v3:
> 1.add cpu_online() check in vpm_load() and vpmu_arch_destroy();
> 2.add vpmu_ prefix. rename cpu_callback() to vpmu_cpu_callback();
I had specifically objected to the latter.
> @@ -394,8 +395,11 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
>
On 05/22/2017 04:56 AM, Juergen Gross wrote:
> Today only a few sysfs nodes under /sys/hypervisor/ are documented
> for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. Rename
> this file to Documentation/ABI/testing/sysfs-hypervisor and add
> descriptions of the other nodes.
>
> Signed-off-b
>>> On 22.05.17 at 15:12, wrote:
> _PAGE_GNTTAB is only used in debug builds of Xen; in release builds, it has
> the value 0. Coverity complains that "l1e_get_flags(l1e) & 0" is logically
> dead.
>
> Add an extra condition into the logic to skip the flag check if _PAGE_GNTTAB
> is 0.
And this h
On 22/05/17 09:57, Juergen Gross wrote:
> Currently there is no reliable user interface inside a Xen guest to
> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
> try to determine this by various rather hacky mechanisms (parsing of
> boot messages before they are gone, trying
>>> On 19.05.17 at 20:49, wrote:
> We use sync_core() in the alternatives code to stop speculative
> execution of prefetched instructions because we are potentially changing
> them and don't want to execute stale bytes.
>
> What it does on most machines is call CPUID which is a serializing
> inst
>>> On 19.05.17 at 20:49, wrote:
> As identified in Linux c/s c198b121b1a1d "x86/asm: Rewrite sync_core() to use
> IRET-to-self", sync_core() is only appropriate for two very specific usecases.
>
> Xen doesn't have need of either of these usecases, so drop sync_core() to
> avoid any misuse.
>
>
>>> On 22.05.17 at 10:57, wrote:
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -9,8 +9,10 @@ enum xen_domain_type {
>
> #ifdef CONFIG_XEN
> extern enum xen_domain_type xen_domain_type;
> +extern char *xen_guest_type;
const char * ?
Jan
___
Stefano Stabellini writes ("Re: Proposal to allow setting up shared memory
areas between VMs from xl config file"):
> In this scenario, she is going to write to the VM config files of the
> two apps that one page will be shared among the two, so that they can
> send each other messages. She will h
On 22/05/17 14:38, Jan Beulich wrote:
On 19.05.17 at 20:49, wrote:
>> We use sync_core() in the alternatives code to stop speculative
>> execution of prefetched instructions because we are potentially changing
>> them and don't want to execute stale bytes.
>>
>> What it does on most machines
When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.
Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just u
On 22/05/17 15:33, Andrew Cooper wrote:
> On 22/05/17 09:57, Juergen Gross wrote:
>> Currently there is no reliable user interface inside a Xen guest to
>> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
>> try to determine this by various rather hacky mechanisms (parsing of
>>> On 22.05.17 at 15:51, wrote:
> On 22/05/17 14:38, Jan Beulich wrote:
> On 19.05.17 at 20:49, wrote:
>>> We use sync_core() in the alternatives code to stop speculative
>>> execution of prefetched instructions because we are potentially changing
>>> them and don't want to execute stale byt
On 22/05/17 15:30, Boris Ostrovsky wrote:
> On 05/22/2017 04:56 AM, Juergen Gross wrote:
>> Today only a few sysfs nodes under /sys/hypervisor/ are documented
>> for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. Rename
>> this file to Documentation/ABI/testing/sysfs-hypervisor and add
>> d
On 22/05/17 15:45, Jan Beulich wrote:
On 22.05.17 at 10:57, wrote:
>> --- a/include/xen/xen.h
>> +++ b/include/xen/xen.h
>> @@ -9,8 +9,10 @@ enum xen_domain_type {
>>
>> #ifdef CONFIG_XEN
>> extern enum xen_domain_type xen_domain_type;
>> +extern char *xen_guest_type;
>
> const char * ?
On 22/05/17 15:17, Boris Ostrovsky wrote:
>
>> diff --git a/Documentation/ABI/testing/sysfs-hypervisor
>> b/Documentation/ABI/testing/sysfs-hypervisor
>> index 443196f0aa1c..06850f74ebd4 100644
>> --- a/Documentation/ABI/testing/sysfs-hypervisor
>> +++ b/Documentation/ABI/testing/sysfs-hypervisor
Anthony PERARD writes ("Re: [Xen-devel] [qemu-mainline test] 109613:
regressions - FAIL"):
> In the screenshot:
> http://logs.test-lab.xenproject.org/osstest/logs/109613/test-amd64-amd64-xl-qemuu-win7-amd64/nocera0_win.guest.osstest-vnc.jpeg
We have a lot of Windows 7 migration failures. Thanks
Hi Bhupinder,
On 10/05/17 15:24, Bhupinder Thakur wrote:
Add emulation code to emulate read/write access to pl011 registers
and pl011 interrupts:
- Emulate DR read/write by reading and writing from/to the IN
and OUT ring buffers and raising an event to the backend when
there is
On 22/05/17 16:17, Jan Beulich wrote:
On 22.05.17 at 15:51, wrote:
>> On 22/05/17 14:38, Jan Beulich wrote:
>> On 19.05.17 at 20:49, wrote:
We use sync_core() in the alternatives code to stop speculative
execution of prefetched instructions because we are potentially changing
>
Hi Bhupinder,
On 10/05/17 15:31, Bhupinder Thakur wrote:
Add two new domctl APIs to initialize and de-initialize vpl011. It takes the
GFN and console
backend domid as input and returns an event channel to be used for
sending and receiving events from Xen.
Xen will communicate with xenconsole u
On 05/22/2017 09:33 AM, Andrew Cooper wrote:
> On 22/05/17 09:57, Juergen Gross wrote:
>> Currently there is no reliable user interface inside a Xen guest to
>> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
>> try to determine this by various rather hacky mechanisms (parsin
flight 109682 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109682/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 59f844ed70f7370da58fa5e26112a42af7c282cb
baseline version:
xtf b82bf3f43fb4749e59462d
Hi,
On 17/05/17 00:44, Stefano Stabellini wrote:
On Wed, 10 May 2017, Bhupinder Thakur wrote:
Xenconsole supports only PV console currently. This patch adds support
for vuart console, which allows emulated pl011 UART to be accessed
as a console.
Signed-off-by: Bhupinder Thakur
---
One review
On 22/05/17 15:35, Boris Ostrovsky wrote:
> On 05/22/2017 09:33 AM, Andrew Cooper wrote:
>> On 22/05/17 09:57, Juergen Gross wrote:
>>> Currently there is no reliable user interface inside a Xen guest to
>>> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
>>> try to determine
Hi Bhupinder,
On 10/05/17 15:35, Bhupinder Thakur wrote:
The SBSA uart node format is as specified in
Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:
ARM SBSA defined generic UART
--
This UART uses a subset of the PL011 registers and conse
On 05/22/2017 10:20 AM, Juergen Gross wrote:
> On 22/05/17 15:30, Boris Ostrovsky wrote:
>> On 05/22/2017 04:56 AM, Juergen Gross wrote:
>>> Today only a few sysfs nodes under /sys/hypervisor/ are documented
>>> for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. Rename
>>> this file to Docu
On Mon, May 22, 2017 at 10:57:00AM +0200, Juergen Gross wrote:
> Currently there is no reliable user interface inside a Xen guest to
> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
> try to determine this by various rather hacky mechanisms (parsing of
> boot messages before
On 22/05/17 17:23, Konrad Rzeszutek Wilk wrote:
> On Mon, May 22, 2017 at 10:57:00AM +0200, Juergen Gross wrote:
>> Currently there is no reliable user interface inside a Xen guest to
>> determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
>> try to determine this by various rathe
>>> On 22.05.17 at 16:26, wrote:
> On 22/05/17 16:17, Jan Beulich wrote:
> On 22.05.17 at 15:51, wrote:
>>> On 22/05/17 14:38, Jan Beulich wrote:
>>> On 19.05.17 at 20:49, wrote:
> We use sync_core() in the alternatives code to stop speculative
> execution of prefetched instructi
>>> On 22.05.17 at 17:28, wrote:
> On 22/05/17 17:23, Konrad Rzeszutek Wilk wrote:
>> On Mon, May 22, 2017 at 10:57:00AM +0200, Juergen Gross wrote:
>>> --- a/Documentation/ABI/testing/sysfs-hypervisor
>>> +++ b/Documentation/ABI/testing/sysfs-hypervisor
>>> @@ -19,6 +19,19 @@ Contact: xen-de...@l
Hi,
It seems there is some threading problem with the patches. I got them
split in 4 batches in my inbox.
I can't see anything in the cover letter explaining the interaction with
the guest. Mainly how the guest will know which console to use?
For instance, the UEFI firmware will always log
Due to an oversight, this was not plumbed into sg-run-job.
Signed-off-by: Ian Jackson
---
sg-run-job | 1 +
1 file changed, 1 insertion(+)
diff --git a/sg-run-job b/sg-run-job
index ceb7980..43f3daa 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -520,6 +520,7 @@ proc examine-host-examine {install}
Currently we have only two ARM64 boxes and now that the builds are
passing, the tests have become a bottleneck. Cut them down for now.
This patch should be reverted when we have more ARM64 capacity, which
is being looked into.
We drop these tests:
test-arm64-arm64-xl-multivcpu
t
I ran a special report[1] to see what to expect and:
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.
test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR.
Hi Ian,
On 22/05/17 16:45, Ian Jackson wrote:
Currently we have only two ARM64 boxes and now that the builds are
passing, the tests have become a bottleneck. Cut them down for now.
This patch should be reverted when we have more ARM64 capacity, which
is being looked into.
We drop these tests:
On 22/05/17 17:37, Jan Beulich wrote:
On 22.05.17 at 17:28, wrote:
>> On 22/05/17 17:23, Konrad Rzeszutek Wilk wrote:
>>> On Mon, May 22, 2017 at 10:57:00AM +0200, Juergen Gross wrote:
--- a/Documentation/ABI/testing/sysfs-hypervisor
+++ b/Documentation/ABI/testing/sysfs-hypervisor
>>> On 22.05.17 at 11:40, wrote:
> 2) This vmentry failure:
>
> (XEN) [ 7122.287661] d98v3 vmentry failure (reason 0x8021): Invalid
> guest state (0)
> (XEN) [ 7122.287668] * VMCS Area **
> (XEN) [ 7122.287670] *** Guest State ***
> (XEN) [ 7122.287673] CR0: actual=0x0
> > 1. Having tested live-patching thoroughly for at least some version of
> > the codebase
> >
> > 2. Having tested live-patching for one of the Xen 4.9 RCs.
> >
> > Thoughts?
>
> As a statement of what XenServer is doing:
As a statement of what Oracle is doing.
We have been using livepatching
>>> On 22.05.17 at 10:39, wrote:
> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
Not this - Xen is unavoidably going to go down in such a case, yet
your log has no hint at all what kind of problem Dom0 experienced
(e.g. whether one of the injected #MC-s caused this).
> (XEN) [
flight 109675 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109675/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 host-build-prep fail REGR. vs. 109572
Regressions which a
Hi,
On 12/05/17 15:19, Julien Grall wrote:
> Hi Andre,
>
> On 11/05/17 18:53, Andre Przywara wrote:
>> For LPIs the struct pending_irq's are dynamically allocated and the
>> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
>> at any time, teach the VGIC how to deal with irq
Hi,
On 17/05/17 16:35, Julien Grall wrote:
> Hi Andre,
>
> On 11/05/17 18:53, Andre Przywara wrote:
>> For each device we allocate one struct pending_irq for each virtual
>> event (MSI).
>> Provide a helper function which returns the pointer to the appropriate
>> struct, to be able to find the ri
Hi,
On 18/05/17 15:23, Julien Grall wrote:
> Hi Andre,
>
> On 11/05/17 18:53, Andre Przywara wrote:
>> The DISCARD command drops the connection between a DeviceID/EventID
>> and an LPI/collection pair.
>> We mark the respective structure entries as not allocated and make
>> sure that any queued I
The recent build fixes have left the install-tools rule no longer installing
the Xen public headers into /usr/include/xen/
Use pattern rules to generalise the %-tools-public-headers targets, and switch
install-tools to depend on install-tools-public-headers rather than
build-tools-public-headers.
On 22/05/17 17:49, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/05/17 15:19, Julien Grall wrote:
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at
On 22/05/17 17:50, Andre Przywara wrote:
Hi,
Hi Andre,
On 17/05/17 16:35, Julien Grall wrote:
+}
+spin_unlock(&d->arch.vgic.its_devices_lock);
+
+return pirq;
+}
+
+struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
+
On 22/05/17 17:50, Andre Przywara wrote:
Hi,
Hi Andre,
On 18/05/17 15:23, Julien Grall wrote:
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not
Hi Pranay,
I'm not familiar with QEMU, but in general case - you can't just take
image (for example RCAR-H3) and run it inside QEMU - a some things might be
different - uart, gic, timer, etc.
And i'm not sure about support of HW virtualization on QEMU - looks like
your are asking about emulation
flight 109683 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109683/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0e07733023ea26901eec5c51d17e8f38d10d0dea
baseline version:
ovmf 7320b8ed1879b31657a8d
Hi all,
We haven't branch due to some regressions found during the week-end.
Meanwhile an RC has been cut and staging has been re-opened.
Please CC me on any patch going to Xen 4.9.
Cheers,
staging is now re-opened. We haven't branch due to some
On 19/05/17 15:56, Julien Grall wrote:
Hi all
Hi,
On 22/05/17 12:11, Andrew Cooper wrote:
From 3d4ce135ea3b396bb63752c39e6234366d590c16 Mon Sep 17 00:00:00 2001
From: George Dunlap
Date: Mon, 22 May 2017 11:38:31 +0100
Subject: [PATCH] Restore HVM_OP hypercall continuation (partial revert of
ae20ccf)
Commit ae20ccf removed the hypercall
On 05/10/2017 07:13 AM, Igor Druzhinin wrote:
> The same set of functions is used to set as well as to clean
> P2M entries, except that for clean operations INVALID_MFN (~0UL)
> is passed as a parameter. Unfortunately, when calculating an
> appropriate target order for a particular mapping INVALID_
Hi all,
Xen 4.9 rc6 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.9.0-rc6
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.9.0-rc6/xen-4.9.0-rc6.tar.gz
And the signature is at:
https://downloads.xenproject.org/rel
flight 71388 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71388/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-sid-netboot-pvgrub 9 debian-di-install fail REGR. vs.
71318
test-am
> 49 files changed, 1548 insertions(+), 1477 deletions(-)
> create mode 100644 arch/x86/include/asm/paravirt_full.h
> create mode 100644 arch/x86/include/asm/paravirt_types_full.h
> create mode 100644 arch/x86/kernel/paravirt_full.c
Do you have this in a tree that can be pulled?
-boris
__
This run is configured for baseline tests only.
flight 71387 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 17 guest-star
flight 109679 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 5 xen-buildfail REGR. vs. 109662
Tests which did no
On Mon, 22 May 2017, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: Proposal to allow setting up shared memory
> areas between VMs from xl config file"):
> > In this scenario, she is going to write to the VM config files of the
> > two apps that one page will be shared among the two, so that
On Fri, 19 May 2017, Volodymyr Babchuk wrote:
> On 18 May 2017 at 22:00, Stefano Stabellini wrote:
>
> > Description of the problem: need for a place to run emulators and
> > mediators outside of Xen, with low latency.
> >
> > Explanation of what EL0 apps are. What should be their interface with
On Thu, 11 May 2017, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. We only care about mapped LPIs, so we can get away
> with having struct pending_irq's only fo
On Thu, 11 May 2017, Andre Przywara wrote:
> Upon receiving an LPI on the host, we need to find the right VCPU and
> virtual IRQ number to get this IRQ injected.
> Iterate our two-level LPI table to find this information quickly when
> the host takes an LPI. Call the existing injection function to
This run is configured for baseline tests only.
flight 71392 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71392/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
On Tue, 16 May 2017, Julien Grall wrote:
> Hi Andre,
>
> On 11/05/17 18:53, Andre Przywara wrote:
> > The target CPU for an LPI is encoded in the interrupt translation table
> > entry, so can't be easily derived from just an LPI number (short of
> > walking *all* tables and find the matching LPI).
On Tue, 16 May 2017, Julien Grall wrote:
> > @@ -436,8 +473,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu
> > *v, mmio_info_t *info,
> > switch ( gicr_reg )
> > {
> > case VREG32(GICR_CTLR):
> > -/* LPI's not implemented */
> > -goto write_ignore_32;
> >
On Thu, 11 May 2017, Andre Przywara wrote:
> +case VREG64(GITS_CWRITER):
> +if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
> +
> +reg = its->cwriter;
> +*r = vgic_reg64_extract(reg, info);
Why is this not protected by a lock? Also from the comment above I
c
On Thu, 11 May 2017, Andre Przywara wrote:
> @@ -556,6 +583,93 @@ static int its_handle_mapd(struct virt_its *its,
> uint64_t *cmdptr)
> return ret;
> }
>
> +static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +
On Fri, 19 May 2017, Stefano Stabellini wrote:
> On Thu, 11 May 2017, Andre Przywara wrote:
> > When LPIs get unmapped by a guest, they might still be in some LR of
> > some VCPU. Nevertheless we remove the corresponding pending_irq
> > (possibly freeing it), and detect this case (irq_to_pending()
On Thu, 11 May 2017, Andre Przywara wrote:
> The INV command instructs the ITS to update the configuration data for
> a given LPI by re-reading its entry from the property table.
> We don't need to care so much about the priority value, but enabling
> or disabling an LPI has some effect: We remove
This run is configured for baseline tests only.
flight 71389 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build
On Thu, 11 May 2017, Andre Przywara wrote:
> The MOVI command moves the interrupt affinity from one redistributor
> (read: VCPU) to another.
> For now migration of "live" LPIs is not yet implemented, but we store
> the changed affinity in the host LPI structure and in our virtual ITTE.
>
> Signed-
This run is configured for baseline tests only.
flight 71406 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71406/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
> >>> On 21.05.17 at 15:09, wrote:
> > v3:
> > 1.add cpu_online() check in vpm_load() and vpmu_arch_destroy();
> > 2.add vpmu_ prefix. rename cpu_callback() to vpmu_cpu_callback();
>
> I had specifically objected to the latter.
Sorry, will rollback it.
>
> > @@ -394,8 +395,11 @@ int vpmu_load
flight 109689 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109689/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1c020add31d9ba5f556d97bad174e80d7325d973
baseline version:
ovmf 0e07733023ea26901eec5
1 - 100 of 106 matches
Mail list logo
