On 22/05/17 21:42, Boris Ostrovsky wrote:
>
>> 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 yo
Hi Julien,
>>
>> -/*
>> - * 64 bits registers are only supported on platform with 64-bit long.
>> - * This is also allow us to optimize the 32 bit case by using
>> - * unsigned long rather than uint64_t
>> - */
>> -#if BITS_PER_LONG == 64
>> -VGIC_REG_HELPERS(64, 0x7);
>> -#endif
>> -VGIC_REG_HEL
flight 109681 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109681/
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-amd64-xl-q
This run is configured for baseline tests only.
flight 71407 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71407/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 109680 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 109656
test-amd64-i386-libv
We performed Xen 4.9 RC4 testing on Intel Xeon Skylake, Broadwell, Haswell
server platforms, verified many functional features on Xen 4.9. We'd like to
share the result out.
Most of features passed to testing on Xen 4.9 RC4, RAS and nested has some bugs.
RAS:
1. xen-mceinj tool testing ca
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
> >>> 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
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 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 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 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
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:
> @@ -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 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 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 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).
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 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
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 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 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
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
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
> 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
__
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
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
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,
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
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
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 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
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
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: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
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.
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
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 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
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
> > 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) [
>>> 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
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
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:
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.
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
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
>>> 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
>>> 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 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 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 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
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 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,
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
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
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
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 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: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
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
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
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: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 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: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
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 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
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 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
___
>>> 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 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 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 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 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 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)
>
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
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
_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
> 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.
Hi Julien,
>
>> -static inline void vgic_reg##sz##_clearbits(uint##sz##_t *reg, \
>> -register_t bits,\
>> -const mmio_info_t *info)\
>> -{
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 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)
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
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
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
-
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. */
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
> -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 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
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);
>> >> -
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
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
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,
>> +
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
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 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 :
>
> --
(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
1 - 100 of 106 matches
Mail list logo
