On March 01, 2017 2:24 PM, wrote:
>On Wed, Mar 01, 2017 at 12:38:39AM -0700, Jan Beulich wrote:
> On 01.03.17 at 04:23, wrote:
>>> On February 28, 2017 11:08 PM, Jan Beulich wrote:
>>> On 27.02.17 at 11:53, wrote:
> If guest is already in non-root mode, an posted interrupt will be
>>>
flight 106328 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106328/
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
test-amd64-amd64-xl-qemuu-
> From: Gao, Chao
> Sent: Wednesday, March 01, 2017 2:24 PM
>
>
> Good point. I ignore v->processor maybe change. I have thought over
> __vmx_deliver_posted_interrupt() again and want to share you my
> opinion.
> First of all, __vmx_deliver_posted_interrupt() is to let the target
> vCPU sync PIR
flight 106316 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 106266
Regress
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, March 02, 2017 4:36 AM
>
> On Mon, Feb 27, 2017 at 09:13:29PM +0300, Dmitry Rockosov wrote:
> > Hi guys,
> >
> > Do you know when *recognized* Virtual Interrupt on VM-Entry will be
> > delivered if Virtual-Interrupt De
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, March 01, 2017 1:40 AM
> To: xen-de...@lists.xenproject.org
> Cc: Roger Pau Monne; Ian Jackson; Wei Liu; Elena Ufimtseva; Jan Beulich;
> Andrew Cooper;
> Paul Durrant; Nakajima, Jun; Tian, Kevin
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Wednesday, March 01, 2017 11:07 PM
>
> 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
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, February 28, 2017 9:39 PM
>
> Signed-off-by: Jan Beulich
>
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 106312 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106312/
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
Last week I started an effort to use upstream qemu as a replacement
for qemu-trad in ioemu stubdom. This small series addresses some
problems I met in this effort. I believe all modifications are worth
doing regardless whether qemu upstream stubdom will become a reality
or not.
Changes in V2:
- Re
When configuring the build of qemu the configure script is building
various test programs to determine the exact version of libxencontrol.
Instead of a try and error approach needing updates for nearly each
new version of Xen just provide xencontrol.pc to be used via
pkg-config.
In the end we nee
When calling configure for qemu provide the local pkg-config directory
in order to let the configure process find the libxenctrl version.
Signed-off-by: Juergen Gross
Acked-by: Ian Jackson
---
tools/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/Makefile b/tools/Makefile
ind
Instead of using the downloaded git tree as target directory for the
qemu build create a dedicated directory for that purpose.
This way it is possible to use the same source directory of qemu to
configure and build qemu upstream in a stubdom environment in future.
Signed-off-by: Juergen Gross
Ac
A stubdom app using xenctrl.h must use the latest interface version of
Xen in order to avoid compatibility issues. Add the related config
item to the stubdom config files where needed.
Signed-off-by: Juergen Gross
---
stubdom/ioemu-minios.cfg | 1 +
1 file changed, 1 insertion(+)
diff --git a/s
flight 106307 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
105933
test-armhf-arm
Hi Jan,
Previously I saw your UMIP patches merged in xen, and we'd like to
try some unit test here in Intel. And I wonder do you have any unit test
code for this feature, or any suggestions? :)
Thanks
Yu
___
Xen-devel mailing list
Xen-devel@lists
On Thu, 23 Feb 2017, Paul Durrant wrote:
> This patch modifies the wrapper functions in xen_common.h to use the
> new xendevicemodel interface if it is available along with compatibility
> code to use the old libxenctrl interface if it is not.
>
> Signed-off-by: Paul Durrant
Hi Paul,
Sorry for
On Wed, 1 Mar 2017, Gémes Géza wrote:
> 2017-03-01 20:48 keltezéssel, Stefano Stabellini írta:
> > On Wed, 1 Mar 2017, Gémes Géza wrote:
> > > 2017-02-27 23:52 keltezéssel, Stefano Stabellini írta:
> > > > On Wed, 22 Feb 2017, Géza Gémes wrote:
> > > > > On 2017-02-21 23:10, Stefano Stabellini wrot
> From: Gémes Géza
> Date: Wed, 1 Mar 2017 18:39:51 +0100
> Subject: [PATCH] Allow running tests as non-root
>
> Allow a user with sudo rights to run the tests
>
> Signed-off-by: Gémes Géza
Reviewed-by: Stefano Stabellini
I'll commit.
> ---
> lib/common-tests.sh | 50 ++
Hi all,
Edgar reported a data corruption on network packets in dom0 when the
swiotlb-xen is in use. He also reported that the following patch "fixes"
the problem for him:
static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_dir
flight 106308 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106308/
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
test-amd64-amd64-xl-qemuu-
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-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:
Hi Stefano,
On 01/03/2017 22:15, Stefano Stabellini wrote:
This patch fixes a potential race that could happen when
gic_update_one_lr and vgic_vcpu_inject_irq run simultaneously.
When GIC_IRQ_GUEST_MIGRATING is set, we must make sure that the irq has
been removed from inflight before changing p
On 28 February 2017 at 19:15, Stefano Stabellini wrote:
> The following changes since commit 7d1730b7d9d8272a13245adfc9b0405e5a4bd0c2:
>
> Merge remote-tracking branch 'remotes/mjt/tags/trivial-patches-fetch' into
> staging (2017-02-28 16:22:41 +)
>
> are available in the git repository at:
flight 106320 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106320/
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
test-amd64-amd64-libvirt 12 mig
Move the atomic write of rank->vcpu, which sets the new vcpu target, to
vgic_migrate_irq, at the beginning of the lock protected area (protected
by the vgic lock).
This code movement reduces race conditions between vgic_migrate_irq and
setting rank->vcpu on one pcpu and gic_update_one_lr on anothe
This patch fixes a potential race that could happen when
gic_update_one_lr and vgic_vcpu_inject_irq run simultaneously.
When GIC_IRQ_GUEST_MIGRATING is set, we must make sure that the irq has
been removed from inflight before changing physical affinity, to avoid
concurrent accesses to p->inflight,
A potential race condition occurs when vgic_migrate_irq is called a
second time, while GIC_IRQ_GUEST_MIGRATING is already set. In that case,
vgic_migrate_irq takes a different vgic lock from gic_update_one_lr.
vgic_migrate_irq running concurrently with gic_update_one_lr could cause
data corruptions
Hi all,
this patch series removes three race conditions affecting the current
code base.
The first race condition is between gic_update_one_lr and
vgic_vcpu_inject_irq: as soon as gic_update_one_lr calls
irq_set_affinity a new interrupt could be injected in the new pcpu,
eventually vgic_vcpu_inje
On Mon, Feb 27, 2017 at 01:09:06PM +0800, Haozhong Zhang wrote:
> c/s e966818264908e842e2847f579ca4d94e586eaac added
> mce_need_clearbank_register below the comment of
> x86_mce_callback_register(). This commit (1) adjusts the first
> paragraph of comment to be a general statement of all callback
>
On 03/01/2017 02:54 PM, Thomas Gleixner wrote:
>
> Yes, I know it has been fixed later, but this crap should not have been
> merged in the first place.
>
> Yours grumpy
>
> tglx
Yes, we dropped the ball on this, this shouldn't have gone in without
x86 maintainers' review.
-boris
2017-03-01 20:48 keltezéssel, Stefano Stabellini írta:
On Wed, 1 Mar 2017, Gémes Géza wrote:
2017-02-27 23:52 keltezéssel, Stefano Stabellini írta:
On Wed, 22 Feb 2017, Géza Gémes wrote:
On 2017-02-21 23:10, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Géza Gémes wrote:
Hi,
I've tried to
flight 106298 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106298/
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 in 106051
REGR. vs. 105835
Hi,
The attached patch allows running the raisin tests as non-root user.
Cheers,
Geza
>From 8a1227d96697a4d8be9130fd9b16404decbe7605 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A9za=20G=C3=A9mes?=
Date: Wed, 1 Mar 2017 18:39:51 +0100
Subject: [PATCH] Allow running tests as non-root
MIME-Ver
flight 106294 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106294/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail blocked in 106265
test-armhf-armhf-libvirt 13
On Mon, Feb 27, 2017 at 09:13:29PM +0300, Dmitry Rockosov wrote:
> Hi guys,
>
> Do you know when *recognized* Virtual Interrupt on VM-Entry will be
> delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
> is blocking by STI?
This sounds like a good question to the Intel maint
On 01/03/17 16:11, Jan Beulich wrote:
On 01.03.17 at 16:49, wrote:
>> On 28/02/17 12:54, Jan Beulich wrote:
>>> @@ -340,6 +342,28 @@ static const struct {
>>> [0xff] = { ModRM }
>>> };
>>>
>>> +static const struct {
>>> +uint8_t simd_size:5;
>>> +uint8_t to_memory:1;
>> Depend
On Wed, Feb 22, 2017 at 12:41:16PM +0300, Dmitry Rockosov wrote:
> Hello guys,
>
> Could someone help me with VLAPIC and Event channel relationship? I can't
> find any good design overview for it.
LAPIC is extensively described in the Intel SDM.
The event channels are described in the header fil
Il 01 Mar 2017 20:43, Stefano Stabellini ha scritto:
Signed-off-by: Stefano Stabellini
CC: dario.faggi...@citrix.com
Reviewed-by: Dario Faggioli
(And sorry for the formatting of this email.)
Regards,
Dario
___
Xen-devel mailing list
Xen-devel@list
On 01/03/17 14:43, Jan Beulich wrote:
On 01.03.17 at 15:36, wrote:
>> On 28/02/17 12:52, Jan Beulich wrote:
>>> @@ -2505,12 +2506,21 @@ x86_decode(
>>>
>>> opcode |= b | MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
>>>
>>> +if ( !(d & ModRM) )
>>> +
On 01/03/17 14:19, Jan Beulich wrote:
On 01.03.17 at 14:59, wrote:
>> On 28/02/17 12:50, Jan Beulich wrote:
>>> Previously supported insns are being converted to the new model, and
>>> several new ones are being added.
>>>
>>> To keep the stub handling reasonably simple, integrate SET_SSE_PRE
On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote:
So this patch made it's way into Linus tree via XEN w/o an ack or reviewed
by from the x86 maintainers.
Yes, we were on CC, but it's not that hard to ping the maintainers when
they do not respond on a particular patch.
The whole series ran under the c
On Wed, Mar 01, 2017 at 10:36:13PM +0800, Zhiyuan Lv wrote:
> Hi Konrad,
>
> On Tue, Feb 28, 2017 at 10:07:18AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 24, 2017 at 02:25:27AM +, Wang, Hongbo wrote:
> > > Intel XenGT has another maillist " igv...@lists.01.org" to discuss Intel
> >
On Wed, 1 Mar 2017, Gémes Géza wrote:
> 2017-02-27 23:52 keltezéssel, Stefano Stabellini írta:
> > On Wed, 22 Feb 2017, Géza Gémes wrote:
> > > On 2017-02-21 23:10, Stefano Stabellini wrote:
> > > > On Tue, 21 Feb 2017, Géza Gémes wrote:
> > > > > Hi,
> > > > >
> > > > > I've tried to run the rais
Introduce new Xen command line parameter called "vwfi", which stands for
virtual wfi. The default is "trap": Xen traps guest wfi and wfe
instructions. In the case of wfi, Xen calls vcpu_block on the guest
vcpu; in the case of guest wfe, Xen calls vcpu_yield on the guest vcpu.
The behavior can be ch
Hi Julien,
On 02/28/2017 12:29 PM, Julien Grall wrote:
On 27/02/17 17:20, Andre Przywara wrote:
Hi,
Hi Andre,
On 24/02/17 19:57, Shanker Donthineni wrote:
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
On Wed, 1 Mar 2017, Dario Faggioli wrote:
> On Tue, 2017-02-28 at 13:12 -0800, Stefano Stabellini wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1638,6 +1638,20 @@ Note that if **watchdog** option is also
> > specified vpmu will be turned
On Wed, 1 Mar 2017, Sky Liu wrote:
> Hi, there.
> I'm a student majoring in Information Security in HUST and I'm interested in
> Xen's
> GSoC project on adding page sharing support in the VM config file.
>
> I've been working in the CGCL lab in HUST for one year and a half, and my
> interests
>
flight 106310 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106310/
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
CC'ing Julien.
On Wed, 1 Mar 2017, Dario Faggioli wrote:
> On Wed, 2017-03-01 at 02:05 +0200, Anastassios Nanos wrote:
> > On Wed, Dec 7, 2016 at 8:29 PM, Dario Faggioli
> > wrote:
> > >
> > > % Heterogeneous Multi Processing Support in Xen
> > > % Revision 1
> > >
> > > [...]
> > Hi all,
> >
On 01/03/17 13:50, Jan Beulich wrote:
>
>> This seems rather inconsistent at the moment.
> Does it? At least in this patch I can't spot an inconsistency.
I meant in general across the current use of stubs, but perhaps that is
just because of the transition to the new model.
>
>>> @@ -6159,6 +6551
flight 106291 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 106266
Regressions which
On 28/02/17 12:59, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
2017-02-27 23:52 keltezéssel, Stefano Stabellini írta:
On Wed, 22 Feb 2017, Géza Gémes wrote:
On 2017-02-21 23:10, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Géza Gémes wrote:
Hi,
I've tried to run the raisin test suite, while pv tests pass the hvm tests
fail. I've identified a number of
On 28/02/17 12:58, Jan Beulich wrote:
> ... and its AVX equivalent.
>
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -393,6 +393,7 @@ static const struct {
> [0x22] = { .simd_size = simd_none }
flight 106302 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106302/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf b834586f982174aa0bc09daf17f1375908ad04af
baseline version:
xtf f3cbcfed8a591b5fd9ec99
On Wed, 2017-03-01 at 02:05 +0200, Anastassios Nanos wrote:
> On Wed, Dec 7, 2016 at 8:29 PM, Dario Faggioli
> wrote:
> >
> > % Heterogeneous Multi Processing Support in Xen
> > % Revision 1
> >
> > [...]
> Hi all,
>
Hello,
> We are sending a branch[1] for comments on an initial implementation
flight 106285 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106285/
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-amd64-i386-fre
On 28/02/17 12:57, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 28/02/17 12:56, Jan Beulich wrote:
> ... and their AVX equivalents.
>
> Signed-off-by: Jan Beulich
(Subject to the same (vex.opcx == vex_none) concern as the previous
patch), Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen
On Thu, Feb 23, 2017 at 02:53:54PM +, Paul Durrant wrote:
> This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION
> to a new value of 490 if libxendevicemodel is present in the build
> environment.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Stefano Stabellini
> Cc: Anth
On Wed, 2017-03-01 at 16:41 +, George Dunlap wrote:
> On 01/03/17 14:53, Dario Faggioli wrote:
> > @@ -590,7 +590,7 @@ static s_time_t c2t(struct
> > csched2_runqueue_data *rqd, s_time_t credit, struct c
> > }
> >
> > /*
> > - * Runqueue related code
> > + * Runqueue related code.
>
> You
On 28/02/17 12:56, Jan Beulich wrote:
> @@ -6951,6 +7040,97 @@ x86_emulate(
> fic.insn_bytes = PFX_BYTES + 3;
> break;
>
> +case X86EMUL_OPC_66(0x0f38, 0x20): /* pmovsxbw xmm/m64,xmm */
> +case X86EMUL_OPC_66(0x0f38, 0x21): /* pmovsxbd xmm/m32,xmm */
> +case X86EMUL_
On 01/03/17 14:53, Dario Faggioli wrote:
> We record trace information about the next timeslice when
> switching to a different vcpu, but not when continuing to
> run the same cpu:
>
> csched2:schedule cpu 9, rq# 1, idle, SMT idle, tickled
> csched2:runq_candidate d0v3, 0 vcpus skipped, cpu 9 wa
Hello Julien,
On 1 March 2017 at 18:09, Julien Grall wrote:
> On 01/03/17 14:13, Volodymyr Babchuk wrote:
This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to disc
On 01/03/17 10:51, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
On 1 March 2017 at 02:52, Konrad Rzeszutek Wilk wrote:
However, the pl011 ring is similar to the console ring. So maybe we should
re-use the console header rather than re-inventing the wheel.
Can I include a xen public
On 01/03/17 14:53, Dario Faggioli wrote:
> So that they're all close among each other, and
> also near to the comment describing the runqueue
> organization (which is also moved).
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
> Cc: Anshul Makkar
On 03/01/2017 11:27 AM, Jan Beulich wrote:
On 01.03.17 at 17:14, wrote:
>> On 03/01/2017 10:48 AM, George Dunlap wrote:
>>> On 27/02/17 17:06, Boris Ostrovsky wrote:
Since dirty pages are always at the tail of page lists we are not really
searching the lists. As soon as a clean page
On 01/03/17 14:53, Dario Faggioli wrote:
> There isn't any particular reason for the accessor helpers
> to be macro, so turn them into 'static inline'-s, which are
> better.
>
> Note that it is necessary to move the function definitions
> below the structure declarations.
>
> No functional change
>>> On 01.03.17 at 17:33, wrote:
> On 01/03/17 16:22, Jan Beulich wrote:
> On 27.02.17 at 15:03, wrote:
>>> --- a/xen/arch/x86/mm/hap/guest_walk.c
>>> +++ b/xen/arch/x86/mm/hap/guest_walk.c
>>> @@ -98,7 +98,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
>>> /* Interpret the a
Hi, Konrad!
On 02/17/2017 07:33 PM, Oleksandr Andrushchenko wrote:
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:
*--
On 01/03/17 16:22, Jan Beulich wrote:
On 27.02.17 at 15:03, wrote:
>> --- a/xen/arch/x86/mm/hap/guest_walk.c
>> +++ b/xen/arch/x86/mm/hap/guest_walk.c
>> @@ -98,7 +98,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
>> /* Interpret the answer */
>> if ( missing == 0 )
>>
On 01/03/17 16:24, Jan Beulich wrote:
On 27.02.17 at 15:03, wrote:
>> Outstanding hardware issues discovered include:
>> 1) There is an observable delay in AMD Fam 10h processors between loading a
>> segment selector, and the results of the LDT/GDT memory access being
>> visible i
>>> On 01.03.17 at 17:14, wrote:
> On 03/01/2017 10:48 AM, George Dunlap wrote:
>> On 27/02/17 17:06, Boris Ostrovsky wrote:
>>> Since dirty pages are always at the tail of page lists we are not really
>>> searching the lists. As soon as a clean page is found (starting from the
>>> tail) we can st
>>> On 27.02.17 at 15:03, wrote:
> Outstanding hardware issues discovered include:
> 1) There is an observable delay in AMD Fam 10h processors between loading a
> segment selector, and the results of the LDT/GDT memory access being
> visible in the pagetables (via the Access bits being
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 01 March 2017 16:14
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini ; Paolo Bonzini ;
> Richard Henderson ; Eduardo Habkost
> ; Michael S. Tsirkin
>
>>> On 27.02.17 at 15:03, wrote:
> --- a/xen/arch/x86/mm/hap/guest_walk.c
> +++ b/xen/arch/x86/mm/hap/guest_walk.c
> @@ -98,7 +98,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
> /* Interpret the answer */
> if ( missing == 0 )
> {
> -gfn_t gfn = guest_l1e_get_gf
Hi Volodymyr,
On 01/03/17 16:09, Julien Grall wrote:
On 01/03/17 14:13, Volodymyr Babchuk wrote:
Hi, Julien
Hi Volodymyr,
On 28 February 2017 at 15:51, Julien Grall wrote:
This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread r
On Thu, Feb 23, 2017 at 02:53:53PM +, Paul Durrant wrote:
> This patch creates inline wrapper functions in xen_common.h for all open
> coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use
> of xen_xc can be made implicit. This again is in preparation for the move
> to using
On 03/01/2017 10:48 AM, George Dunlap wrote:
> On 27/02/17 17:06, Boris Ostrovsky wrote:
Briefly, the new algorithm places dirty pages at the end of heap's page
list
for each node/zone/order to avoid having to scan full list while searching
for dirty pages. One processor form e
>>> On 01.03.17 at 16:49, wrote:
> On 28/02/17 12:54, Jan Beulich wrote:
>> @@ -340,6 +342,28 @@ static const struct {
>> [0xff] = { ModRM }
>> };
>>
>> +static const struct {
>> +uint8_t simd_size:5;
>> +uint8_t to_memory:1;
>
> Depending on how often it is used, what about short
On 01/03/17 14:13, Volodymyr Babchuk wrote:
Hi, Julien
Hi Volodymyr,
On 28 February 2017 at 15:51, Julien Grall wrote:
This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to
On 28/02/17 12:55, Jan Beulich wrote:
> ... and their AVX equivalents.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Feb 28, 2017 at 05:39:39PM +, Roger Pau Monne wrote:
> 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="non
>>> On 27.02.17 at 15:03, wrote:
> The shadow logic should never create a shadow of a guest PTE which contains
> reserved bits from the guests point of view. Such a shadowed entry might not
> cause #PF[RSVD] when walked by hardware, thus won't behave architecturally
> from the guests point of vie
>>> On 27.02.17 at 15:03, wrote:
> On Intel hardware, EFER is not fully switched between host and guest
> contexts.
> In practice, this means that Xen's EFER.NX setting leaks into guest context,
> and influences the behaviour of the hardware pagewalker.
>
> When servicing a pagefault, Xen's mode
flight 106287 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106287/
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
test-amd64-amd64-xl-qemuu-
>>> On 27.02.17 at 15:03, wrote:
> -static inline int
> -guest_supports_1G_superpages(struct vcpu *v)
> +static inline bool guest_has_pse36(const struct vcpu *v)
> +{
> + /* No support for 2-level PV guests. */
> +return is_pv_vcpu(v) ? 0 : paging_mode_hap(v->domain);
Considering the retu
On 28/02/17 12:54, Jan Beulich wrote:
> Convert the few existing opcodes so far supported.
>
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -43,6 +43,8 @@
> #define SrcMask (7<<3)
> /* Generic
On 27/02/17 17:06, Boris Ostrovsky wrote:
>>> Briefly, the new algorithm places dirty pages at the end of heap's page list
>>> for each node/zone/order to avoid having to scan full list while searching
>>> for dirty pages. One processor form each node checks whether the node has
>>> any
>>> dirty
On Wed, 2017-03-01 at 15:52 +0100, Dario Faggioli wrote:
> Dario Faggioli (7):
> xen: credit2: always mark a tickled pCPU as... tickled!
> xen: credit2: don't miss accounting while doing a credit reset.
>
And these two being bugfixes, I request them to be backported to Xen
4.7 (but not
>>> On 01.03.17 at 16:23, wrote:
> On Wed, 2017-03-01 at 07:28 -0700, Jan Beulich wrote:
>> > > > On 01.03.17 at 15:22, wrote:
>> >
>> > On Wed, 2017-03-01 at 07:04 -0700, Jan Beulich wrote:
>> > > > > > On 01.03.17 at 14:44, wrote:
>> > > >
>> > > > Additionally, it would be painful to return
Roger Pau Monne writes ("Re: [PATCH v2 1/3] x86: remove PVHv1 code"):
> On Wed, Mar 01, 2017 at 02:51:33PM +, Ian Jackson wrote:
> > But config files are supposed to be written by nonprogrammers (or by
> > toolstack or orchestration system programmers).
>
> OK, I can be convinced that this is
flight 106283 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106283/
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. 105933
test-amd64-i386-xl
On Thu, Feb 23, 2017 at 02:53:52PM +, Paul Durrant wrote:
> This patch is a purely cosmetic change that avoids a name collision in
> a subsequent patch.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Anthony PERARD
--
Anthony PERARD
___
Xen-devel
On Wed, Mar 01, 2017 at 02:51:33PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v2 1/3] x86: remove PVHv1 code"):
> > It's not just the CPU extensions, we are also providing it with a
> > local APIC and ACPI tables,
>
> The host and guest system administrators do not care about
On Wed, 2017-03-01 at 07:28 -0700, Jan Beulich wrote:
> > > > On 01.03.17 at 15:22, wrote:
> >
> > On Wed, 2017-03-01 at 07:04 -0700, Jan Beulich wrote:
> > > > > > On 01.03.17 at 14:44, wrote:
> > > >
> > > > Additionally, it would be painful to return the correct error value
> > > > all the w
On Thu, Feb 23, 2017 at 02:53:51PM +, Paul Durrant wrote:
> Doing this will make the transition to using the new libxendevicemodel
> interface less intrusive on the callers of these functions, since using
> the new library will require a change of handle.
>
> NOTE: The patch also moves the 'ex
>>> On 27.02.17 at 15:03, wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
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
---
xen/arch/x86/cpu/vpmu_intel.c | 4
xen/arch/x86/domctl.c | 14 ++
xen/include/asm-x8
1 - 100 of 214 matches
Mail list logo
