This run is configured for baseline tests only.
flight 68577 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68577/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-su
On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier wrote:
> On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
>>
>> Can we use the read-only GDT here? When expanding the virtual address
>> for 64-bit system descriptors, isn't it sufficient to check (d->s == 0
>> && d->type != 0)?
>
> We can use t
Can we use the read-only GDT here? When expanding the virtual address
for 64-bit system descriptors, isn't it sufficient to check (d->s == 0
&& d->type != 0)?
On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote:
> The KVM segment_base function is confusing. This patch replaces integers
> with
This run is configured for baseline tests only.
flight 68576 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68576/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-oldkern5 kernel-build
flight 105890 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105890/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xtf 3 host-install(3)broken REGR. vs. 10587
flight 105889 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105889/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 3 host-install/src_host(3) broken REGR
Hello,
I have installed Xen 4.9-unstable with source on Ubuntu 15.10 and uses
4.2.0-42-generic kernel.
Before installing Xen, I used perf to check which events are supported.I
found that hardware event are supported by it. Now, I want to use
performance counters from virtual machine, so after ins
On Fri, 2017-02-17 at 14:50 -0800, Stefano Stabellini wrote:
> On Fri, 17 Feb 2017, Julien Grall wrote:
> > Please explain in which context this will be beneficial. My gut
> > feeling is
> > only will make performance worst if a multiple vCPU of the same
> > guest is
> > running on vCPU
>
> I am n
flight 105892 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105892/
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
flight 105886 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105886/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 105868 pass in
105886
test-armhf-armhf-xl-rtds
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. It is not clear what a better default value could be.
Instead, loadly warn the user when dom0_mem is unspecified and wait 3
secs. Then use 512M.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c |
On Fri, 2017-02-17 at 19:44 +, Julien Grall wrote:
> On 02/17/2017 06:40 PM, Dario Faggioli wrote:
> > Does ARM
> > have frequency scaling (I did remember something on xen-devel, but
> > I am
> > not sure whether it landed upstream)?
>
> I guess you mean the series sent by globallogic ([1])? I
flight 105882 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-xl
On Fri, 2017-02-17 at 16:02 -0800, Stefano Stabellini wrote:
> On Fri, 17 Feb 2017, Stefano Stabellini wrote:
> >
> > NODEBUG vwfi=idle credit2 fix cpumasks 40002370
> > 45003350
> > NODEBUG vwfi=idle credit1 fix cpumasks 32202180
> > 45004320
>
> Actuall
On Fri, 17 Feb 2017, Dario Faggioli wrote:
> On Thu, 2017-02-09 at 16:54 -0800, Stefano Stabellini wrote:
> > These are the results, in nanosec:
> >
> > AVG MIN MAX WARM MAX
> >
> > NODEBUG no WFI 1890 1800 3170 2070
> > NODEBUG WFI
On Fri, 17 Feb 2017, Stefano Stabellini wrote:
> On Fri, 17 Feb 2017, Julien Grall wrote:
> > Hi,
> >
> > On 02/17/2017 11:02 AM, Dario Faggioli wrote:
> > > Just very quickly...
> > >
> > > On Thu, 2017-02-16 at 15:07 -0800, Stefano Stabellini wrote:
> > > > (XEN) Active queues: 1
> > > > (XEN)
On Fri, 17 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 16/02/17 20:17, Stefano Stabellini wrote:
> > On Thu, 16 Feb 2017, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 15/02/2017 23:05, Stefano Stabellini wrote:
> > > > The default dom0_mem is 128M which is not sufficient to boot a
On Fri, 17 Feb 2017, Stefano Stabellini wrote:
> This patch introduces macros, structs and functions to handle rings in
> the format described by docs/misc/pvcalls.markdown and
> docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
> contains the indexes and the grant refs to setup t
On Fri, 17 Feb 2017, Julien Grall wrote:
> Hi,
>
> On 02/17/2017 11:02 AM, Dario Faggioli wrote:
> > Just very quickly...
> >
> > On Thu, 2017-02-16 at 15:07 -0800, Stefano Stabellini wrote:
> > > (XEN) Active queues: 1
> > > (XEN) default-weight = 256
> > > (XEN) Runqueue 0:
> > > (XEN)
On Fri, 17 Feb 2017, Julien Grall wrote:
> Hi Dario,
>
> On 02/17/2017 06:40 PM, Dario Faggioli wrote:
> > On Thu, 2017-02-09 at 16:54 -0800, Stefano Stabellini wrote:
> > Actually, TSC on this box should be stable and invariant, so I guess I
> > can try with the default governor. Will do that on
CC'ing xen-devel, I forgot on the original patch
On Fri, 17 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 02/16/2017 11:04 PM, Stefano Stabellini wrote:
> > Introduce new Xen command line parameter called "vwfi", which stands for
> > virtual wfi. The default is "sleep": on guest wfi, Xen cal
This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.
Indexes page
+
On Fri, Feb 17, 2017 at 1:00 PM, Jim Mattson wrote:
> On Fri, Feb 17, 2017 at 12:11 PM, Thomas Garnier wrote:
>> On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
>>>
>>> Can we use the read-only GDT here? When expanding the virtual address
>>> for 64-bit system descriptors, isn't it sufficien
On Fri, Feb 17, 2017 at 2:31 PM, Andrew Cooper
wrote:
> On 17/02/17 21:28, Tamas K Lengyel wrote:
>> On Fri, Feb 17, 2017 at 1:01 PM, Venu Busireddy
>> wrote:
>>> On Fri, Feb 17, 2017 at 02:29:32PM -0500, Konrad Rzeszutek Wilk wrote:
On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel
On 17/02/17 21:28, Tamas K Lengyel wrote:
> On Fri, Feb 17, 2017 at 1:01 PM, Venu Busireddy
> wrote:
>> On Fri, Feb 17, 2017 at 02:29:32PM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel wrote:
On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszute
On Fri, Feb 17, 2017 at 1:01 PM, Venu Busireddy
wrote:
> On Fri, Feb 17, 2017 at 02:29:32PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel wrote:
>> > On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszutek Wilk
>> > wrote:
>> > > . snip..
>> > >> >> >
rc6]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170217-072759
>> config: x86_64
Hi, all.
So, as I understand we have two possible solutions for the IOMMU page
table to be populated:
1. When the first device is being assigned. Retrieve all mappings
from stage-2 table.
2. When the domain is being created.
I would prefer the second variant.
Retrieving all mappings from P2M m
On Fri, Feb 17, 2017 at 9:49 AM, Jim Mattson wrote:
>
> Can we use the read-only GDT here? When expanding the virtual address
> for 64-bit system descriptors, isn't it sufficient to check (d->s == 0
> && d->type != 0)?
We can use the readonly GDT but I think doesn't matter one or the
other here.
On Fri, Feb 17, 2017 at 02:29:32PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel wrote:
> > On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszutek Wilk
> > wrote:
> > > . snip..
> > >> >> > Given this commit is pretty old, I'm also curious why it's onl
On Fri, Feb 17, 2017 at 10:08:58AM +0100, Juergen Gross wrote:
> On 30/01/17 16:10, Juergen Gross wrote:
> > Instead of using the default resolution of 800*600 for the pointing
> > device of xen-kbdfront try to read the resolution of the (virtual)
> > framebuffer device. Use the default as fallback
On Mon, Jan 30, 2017 at 01:27:29PM +0200, Oleksandr Andrushchenko wrote:
> On 01/30/2017 01:23 PM, Juergen Gross wrote:
> >On 27/01/17 17:10, Dmitry Torokhov wrote:
> >>On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
> >>>On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
> On 01/27/2
Hi Dario,
On 02/17/2017 06:40 PM, Dario Faggioli wrote:
On Thu, 2017-02-09 at 16:54 -0800, Stefano Stabellini wrote:
Actually, TSC on this box should be stable and invariant, so I guess I
can try with the default governor. Will do that on Monday. Does ARM
have frequency scaling (I did remember s
Hi,
On 02/17/2017 11:02 AM, Dario Faggioli wrote:
Just very quickly...
On Thu, 2017-02-16 at 15:07 -0800, Stefano Stabellini wrote:
(XEN) Active queues: 1
(XEN) default-weight = 256
(XEN) Runqueue 0:
(XEN) ncpus = 4
(XEN) cpus = 0-3
(XEN) max_weight
On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel wrote:
> On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszutek Wilk
> wrote:
> > . snip..
> >> >> > Given this commit is pretty old, I'm also curious why it's only
> >> >> > reported
> >> >> > on 4.8. Tamas, did you succeed with iommu=0 pre 4
> > > Stefano, you wouldn't have an patch for the ring.h somewhere
> > > would you?
> > I do have all the headers and macros for both pvcalls and 9pfs (see
> > below the 9pfs header), but not yet something generic used by both.
> > However, it shouldn't be difficult to generalize it. I'll submit a
On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszutek Wilk
wrote:
> . snip..
>> >> > Given this commit is pretty old, I'm also curious why it's only reported
>> >> > on 4.8. Tamas, did you succeed with iommu=0 pre 4.8, or 4.8 happens
>> >> > to be the one upon which you first tried iommu=0 on a platf
On 02/17/2017 09:12 PM, Stefano Stabellini wrote:
On Fri, 17 Feb 2017, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 16, 2017 at 10:36:01AM +0200, Oleksandr Andrushchenko wrote:
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I will define 2 sections:
*-- Connecto
On Fri, 17 Feb 2017, Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 16, 2017 at 10:36:01AM +0200, Oleksandr Andrushchenko wrote:
> > On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
> > > .snip..
> > > > > > > > I will define 2 sections:
> > > > > > > > *-- Connector Request Tra
. snip..
> >> > Given this commit is pretty old, I'm also curious why it's only reported
> >> > on 4.8. Tamas, did you succeed with iommu=0 pre 4.8, or 4.8 happens
> >> > to be the one upon which you first tried iommu=0 on a platform supporting
> >> > interrupt remapping?
> >>
> >> It just happens
On Fri, Feb 17, 2017 at 11:48 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Feb 17, 2017 at 11:42:20AM -0700, Tamas K Lengyel wrote:
>> On Thu, Feb 16, 2017 at 11:53 PM, Tian, Kevin wrote:
>> >> From: Tian, Kevin
>> >> Sent: Friday, February 17, 2017 11:35 AM
>> >> > >>
>> >> > >> Or wait - do you h
On Fri, Feb 17, 2017 at 11:42:20AM -0700, Tamas K Lengyel wrote:
> On Thu, Feb 16, 2017 at 11:53 PM, Tian, Kevin wrote:
> >> From: Tian, Kevin
> >> Sent: Friday, February 17, 2017 11:35 AM
> >> > >>
> >> > >> Or wait - do you have the same issue if you use
> >> > >> "iommu=no,no-intremap"? In whic
Hi Edgar,
On 07/02/17 19:42, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Implement an EEMI mediator and forward platform specific
firmware calls from guests to firmware.
The EEMI mediator is responsible for implementing access
controls modifying or blocking calls that try to operate
on
flight 105877 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105877/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105689
test-armhf-armhf-
On Thu, Feb 16, 2017 at 11:53 PM, Tian, Kevin wrote:
>> From: Tian, Kevin
>> Sent: Friday, February 17, 2017 11:35 AM
>> > >>
>> > >> Or wait - do you have the same issue if you use
>> > >> "iommu=no,no-intremap"? In which case the problem would be
>> > >> that "iommu=no" should clear more than ju
On Thu, 2017-02-09 at 16:54 -0800, Stefano Stabellini wrote:
> These are the results, in nanosec:
>
> AVG MIN MAX WARM MAX
>
> NODEBUG no WFI 1890 1800 3170 2070
> NODEBUG WFI 4850 4810 7030 4980
> NODEBUG no WFI credit2
On Fri, 17 Feb 2017, Jan Beulich wrote:
> >>> On 16.02.17 at 19:38, wrote:
> > On Thu, 16 Feb 2017, Jan Beulich wrote:
> >> >>> On 16.02.17 at 16:23, wrote:
> >> On 14.02.17 at 15:56, wrote:
> >> >> On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote:
> >> >>> Not so far. It appears
flight 105888 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105888/
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
flight 105873 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105873/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 105861 pass
in 105873
test-armhf-armhf-xl-arn
This run is configured for baseline tests only.
flight 68575 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68575/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eb470e05a3c7c251cfa50863ea119ba70e9777a3
baseline v
On Fri, Feb 17, 2017 at 1:20 AM, Jan Beulich wrote:
On 17.02.17 at 07:53, wrote:
>>> From: Tian, Kevin
>>> Sent: Friday, February 17, 2017 11:35 AM
>>> > >>
>>> > >> Or wait - do you have the same issue if you use
>>> > >> "iommu=no,no-intremap"? In which case the problem would be
>>> > >>
Hi Pasi,
Yes, I have already found the mentioned links.
I am facing difficulties building the project with mingw and msys.
I am looking out for pointers mentioning configuration of msys that would
help me build the project.
On Fri, Feb 17, 2017 at 11:08 PM, Pasi Kärkkäinen wrote:
> On Tue, Fe
Changes to how the hypervisor allocates and keeps track of active
VPMUs. The main purpose is to fix vpmu_enabled() reporting but this
also makes VPMU ref counting more consistent.
Boris Ostrovsky (3):
x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE
x86/vpmu: Disable VPMU if guest's CPUID indic
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. Since the leaf is typically queried before gu
PV guests support VPMU and therefore leaf 0xa can be exposed
to them.
Signed-off-by: Boris Ostrovsky
---
CC: Ian Jackson
CC: Wei Liu
---
* New in v2
tools/libxc/xc_cpuid_x86.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 73a2
When toolstack overrides CPUID leaf 0xa values (on Intel processors)
VPMU should not be available to the guest.
Signed-off-by: Boris Ostrovsky
---
* New in v2
xen/arch/x86/cpu/vpmu_intel.c | 4
xen/arch/x86/domctl.c | 14 ++
2 files changed, 18 insertions(+)
diff --gi
On Tue, Feb 14, 2017 at 09:40:17AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 14, 2017 at 11:08:11AM +0530, rohan kumbhar wrote:
> > Hi,
> >
> > I am interested to restart Hosted Xen Project.
> >
> > I have gone through the presentation of Hosted Xen and Ian Pratt's video in
> > Xen Summit
On 02/17/2017 06:33 PM, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 16, 2017 at 10:36:01AM +0200, Oleksandr Andrushchenko wrote:
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I will define 2 sections:
*-- Connector Request Transport Parameters
-
On 02/17/2017 11:41 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 16, 2017 at 08:52:51AM -0500, Boris Ostrovsky wrote:
On 02/16/2017 02:47 AM, Juergen Gross wrote:
There have been reports that Fedora 25 uses /run instead of /var/run.
Add a --with-rundir option ito configure to be able to sp
Hello,
I have installed Ubuntu 15.10 in which have installed Xen with source.
Booting is done with Xen as well as commands like xl infor, xl list are
also working fine.
For creating Virtual Machine, I have installed Virtual Machine Manager, but
when I try to run it, it gives error as follows:
On Thu, Feb 16, 2017 at 08:52:51AM -0500, Boris Ostrovsky wrote:
>
>
> On 02/16/2017 02:47 AM, Juergen Gross wrote:
> > There have been reports that Fedora 25 uses /run instead of /var/run.
> >
> > Add a --with-rundir option ito configure to be able to specify that
> > directory. Default is stil
On 02/17/2017 10:58 AM, Andrew Cooper wrote:
On 17/02/17 14:17, Boris Ostrovsky wrote:
On 02/17/2017 03:27 AM, Jan Beulich wrote:
On 16.02.17 at 19:09, wrote:
On 02/16/2017 12:09 PM, Andrew Cooper wrote:
Second, if it is available, has the toolstack chosen to allow the
domain
to use it.
On Thu, Feb 16, 2017 at 10:36:01AM +0200, Oleksandr Andrushchenko wrote:
> On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
> > .snip..
> > > > > > > I will define 2 sections:
> > > > > > > *-- Connector Request Transport Parameters
> > > > > > > ---
> > > >
>>> On 17.02.17 at 09:49, wrote:
> On Fri, Feb 17, 2017 at 09:37:45AM +, Xuquan (Quan Xu) wrote:
>>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 00:00:00 2001
>>From: Quan Xu
>>Date: Sat, 18 Feb 2017 09:27:37 +0800
>>Subject: [PATCH] x86/apicv: enhance posted-interrupt processing
>
flight 105878 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105878/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eb470e05a3c7c251cfa50863ea119ba70e9777a3
baseline version:
ovmf 958163561e9b6d8fa40ea
flight 105881 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105881/
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
flight 105868 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105868/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 105796
Regressions which
On Thu, Feb 16, 2017 at 10:51:44PM +0100, Vincent JARDIN wrote:
> Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit :
> > > Is it time now to officially remove Dom0 support?
> > So we do have an prototype implementation of netback but it is waiting
> > for review of xen-devel to the spec.
> >
>
tip/auto-latest v4.9-rc8
> v4.9-rc7 v4.9-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:https://github.com/0day-ci/linux/commits/Thomas-Garnier/
> x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170217-0
On 17/02/17 14:17, Boris Ostrovsky wrote:
>
>
> On 02/17/2017 03:27 AM, Jan Beulich wrote:
> On 16.02.17 at 19:09, wrote:
>>> On 02/16/2017 12:09 PM, Andrew Cooper wrote:
Second, if it is available, has the toolstack chosen to allow the
domain
to use it. This should determine w
On Fri, Feb 17, 2017 at 09:37:45AM +, Xuquan (Quan Xu) wrote:
>From a589074281cc22a30ed75a5bccba60e83d2312a6 Mon Sep 17 00:00:00 2001
>From: Quan Xu
>Date: Sat, 18 Feb 2017 09:27:37 +0800
>Subject: [PATCH] x86/apicv: enhance posted-interrupt processing
>
>If guest is already in non-root mode,
Replace linear scan with vmx_find_msr(). This way the time complexity
of searching for required MSR reduces from linear to logarithmic.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- a new patch, factored out from v1 1/2
xen/arch/x86/hvm/vmx/vmcs.c | 26 --
1 file change
During VM entry, H/W will automatically load guest's MSRs from MSR-load
area in the same way as they would be written by WRMSR.
However, under the following conditions:
1. LBR (Last Branch Record) MSRs were placed in the MSR-load area
2. Address format of LBR includes TSX bits 61:62
3
The first 2 patches is a general optimization which is nice to have
prior to the 3rd patch which contains the real fix.
A similar bug was fixed in Linux's perf subsystem in Jun 2016:
commit 19fc9ddd61e059cc45464bdf6e8fa304bb94080f
("perf/x86/intel: Fix MSR_LAST_BRANCH_FROM_x bug when no T
Modify vmx_add_msr() to use a variation of insertion sort algorithm:
find a place for the new entry and shift all subsequent elements before
insertion.
The new vmx_find_msr() exploits the fact that MSR list is now sorted
and reuses the existing code for binary search.
Signed-off-by: Sergey Dyasli
On 02/17/2017 10:13 AM, Jan Beulich wrote:
On 17.02.17 at 16:01, wrote:
On 02/17/2017 05:26 AM, Jan Beulich wrote:
On 17.02.17 at 07:39, wrote:
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs *r
flight 105867 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-xl
This run is configured for baseline tests only.
flight 68574 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68574/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 958163561e9b6d8fa40ea4aac49d46cc889015ac
baseline v
> Should vpl011.h be in include/xen/public/ ? If so you need
> a different license for that file.
>
> I have moved the file from the public folder and keeping it in xen/arch/arm/
Huh? But if this is a ring protocol that is used by an OS that is not
part of of Xen tree it needs
On Thu, Feb 16, 2017 at 02:34:30PM +, Julien Grall wrote:
> Hi,
>
> On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote:
> > On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote:
> > > Hi Konrad,
> > >
> > > Thanks for the feedback.
> > >
> > > On 7 February 2017 at 00:05, Konrad Rzes
Hi Jan,
On 17/02/17 07:43, Jan Beulich wrote:
Well, in the end it's your call, but I don't think this is an acceptable
model in the general case. Quite often - see the Viridian support in
x86 Xen for a very good example - distros (XenServer in this case)
enable functionality even if a guest (Lin
Hi Stefano,
On 16/02/17 20:17, Stefano Stabellini wrote:
On Thu, 16 Feb 2017, Julien Grall wrote:
Hi Stefano,
On 15/02/2017 23:05, Stefano Stabellini wrote:
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. Increase it to 512M.
Signed-off-by: Stefano Stabellin
>>> On 17.02.17 at 16:01, wrote:
> On 02/17/2017 05:26 AM, Jan Beulich wrote:
> On 17.02.17 at 07:39, wrote:
>>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>>> @@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs
>>> *regs)
>>> gstatus
Hi Stefano,
On 16/02/17 18:40, Stefano Stabellini wrote:
On Thu, 16 Feb 2017, Julien Grall wrote:
Hello,
The last two community calls went really good and I am suggesting to have a
new one on Wednesday 1st March at 4pm UTC. Any opinions?
Is it possible to change the time to 5pm?
I am fine
On Thu, 16 Feb 2017 23:11:22 -0800
Joe Perches wrote:
> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index 38868adf07ea..4a55e453296d 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -121,9 +121,8 @@ static int __init init(void)
>
On 02/17/2017 05:26 AM, Jan Beulich wrote:
On 17.02.17 at 07:39, wrote:
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
if ((gstatus & MCG
flight 68573 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68573/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
flight 105870 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105870/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105785
test-armhf-armhf-libvirt 13
On 17/02/17 15:30, Boris Ostrovsky wrote:
>
>
> On 02/17/2017 09:19 AM, Juergen Gross wrote:
>> On 17/02/17 15:05, Boris Ostrovsky wrote:
>>>
>>>
>>> On 02/17/2017 02:36 AM, Juergen Gross wrote:
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid(
On 02/17/2017 09:19 AM, Juergen Gross wrote:
On 17/02/17 15:05, Boris Ostrovsky wrote:
On 02/17/2017 02:36 AM, Juergen Gross wrote:
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
as not being present by spec
On 02/17/2017 03:28 AM, Jan Beulich wrote:
On 16.02.17 at 18:31, wrote:
On 02/16/2017 11:59 AM, Jan Beulich wrote:
Also this new model basically limits the opportunity to change the
mode to the case where no guest at all is running, iiuc. Previously
this would have been possible with any num
On 17/02/17 15:05, Boris Ostrovsky wrote:
>
>
> On 02/17/2017 02:36 AM, Juergen Gross wrote:
>> When running as pv domain xen_cpuid() is being used instead of
>> native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
>> as not being present by special casing the related cpuid leaf.
>
On 02/17/2017 03:27 AM, Jan Beulich wrote:
On 16.02.17 at 19:09, wrote:
On 02/16/2017 12:09 PM, Andrew Cooper wrote:
Second, if it is available, has the toolstack chosen to allow the domain
to use it. This should determine whether features/information are
visible in CPUID.
You mean if too
On 16.02.17 23:11:22, Joe Perches wrote:
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for arch/x86
>
> Prior to this patch, there were 46 uses of pr_warning and
> 122 uses of pr_warn in arch/x86
>
> Miscellanea:
>
> o Coalesce a few formats and realign argume
On 02/17/2017 02:36 AM, Juergen Gross wrote:
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
as not being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu c
This run is configured for baseline tests only.
flight 68572 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68572/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 9 redhat
flight 105880 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852
test-armhf-a
Hi Rafael,
On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki wrote:
> On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
>> There are ~4300 uses of pr_warn and ~250 uses of the older
>> pr_warning in the kernel source tree.
>>
>> Make the use of pr_warn consistent across all kernel files.
>>
>
Hi,
I'm adjusting python bindings to work on python3 too. This will require
few #if in the code (to compile for both python2 and python3), but it
isn't that bad. But there are some major changes in python3, which
require some decision about the bindings API:
1. Python3 has no longer separate 'int
Hi,
On 16 February 2017 at 20:04, Julien Grall wrote:
> Hi,
>
>
> On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote:
>>
>> On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote:
>>>
>>> Hi Konrad,
>>>
>>> Thanks for the feedback.
>>>
>>> On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk
1 - 100 of 175 matches
Mail list logo
