On Mon, May 29, Jan Beulich wrote:
> Finally I don't think a host wide option will do. If it is to be of use
> (considering that it used wrong may break applications), it needs
> to be per-domain, and its value needs to be migrated (perhaps
> in the form of a low/high pair of TSC frequency values)
On Mon, May 29, Jan Beulich wrote:
> Well, no, what jitter may be acceptable depends on the
> applications running inside the guest. I.e. you can only know
> for yourself or ask the application vendor(s). I think such an
> option, if we really want to have it, would need to be
> prominently docume
This patch is an RFC on top of Andre's v10 series.
https://www.mail-archive.com/xen-devel@lists.xen.org/msg109093.html
This patch deny's access to ITS region for the guest and also updates
the acpi tables for dom0.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3.c| 49 +
Hi Julien,
On 5/29/2017 11:44 PM, Julien Grall wrote:
On 05/29/2017 03:30 AM, Manish Jaggi wrote:
Hi Julien,
Hello Manish,
On 5/26/2017 10:44 PM, Julien Grall wrote:
PCI pass-through allows the guest to receive full control of
physical PCI
devices. This means the guest will have full and
On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >Hi Oleksandr,
> >
> >On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> >>From: Oleksandr Andrushchenko
> >>
> >>Extend xen_kbdfront
flight 109834 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 17 guest-start/debian.repeat fail REGR. vs. 106776
test-amd64-amd64-xl-q
flight 109833 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109833/
Regressions :-(
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. vs.
109821
build-armhf-pv
This run is configured for baseline tests only.
flight 71456 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71456/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 109832 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 7 host-ping-check-xen fail REGR. vs. 109656
test-amd64-i386-lib
flight 109835 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109835/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b9036ebee9ddaf26afc9fbe3236c3d03f83c1b0a
baseline version:
ovmf f4d3ba87bb8f5d82d3b80
On 26/05/17 21:01, Stefano Stabellini wrote:
> On Fri, 26 May 2017, Juergen Gross wrote:
>> On 26/05/17 18:19, Ian Jackson wrote:
>>> Juergen Gross writes ("HVM guest performance regression"):
Looking for the reason of a performance regression of HVM guests under
Xen 4.7 against 4.5 I fou
On 05/29/2017 08:13 AM, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
On 26 May 2017 at 19:12, Bhupinder Thakur wrote:
+#ifndef _VPL011_H_
+
+#define _VPL011_H_
+
+#include
+#include
+
+DEFINE_XEN_FLEX_RING(vpl011);
I am sure someone already said it in a previous version. The vpl0
On 05/29/2017 03:30 AM, Manish Jaggi wrote:
Hi Julien,
Hello Manish,
On 5/26/2017 10:44 PM, Julien Grall wrote:
PCI pass-through allows the guest to receive full control of physical PCI
devices. This means the guest will have full and direct access to the PCI
device.
ARM is supporting a k
---
docs/man/xl.pod.1.in | 362 +--
1 file changed, 179 insertions(+), 183 deletions(-)
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 78bf884af2..326c5fef5b 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1,6 +1,6 @
Hey everyone!
As we've been doing some crazy stuff with cpu masking on our systems we turned
to the documentation a lot and I noticed that it could use some improvements.
I've cleaned xl(1) up a bit to make it all adhere to one style, fixed all the
typos I found, fixed some incorrect information t
The current misc/pvh.markdown document refers to PVHv1, remove it to
avoid confusion with PVHv2 since the PVHv1 code has already been
removed.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabelli
On 5/29/17 10:03 AM, Roger Pau Monné wrote:
>> IIUC, Xen 4.9 + kernel-default > v4.11 should now fully support PVHv2?
>
> For DomUs yes, for Dom0 not yet.
thx
> Forget about this document, I should have removed it as part of the
> PVHv1 code removal. In any case, those where PVHv1 internal detai
On Mon, May 29, 2017 at 08:58:04AM -0700, PGNet Dev wrote:
> Starting with
>
> Xen Changes For Linux 4.11: Lands PVHv2 Guest Support
>
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes
>
> [GIT PULL] xen: features and fixes for 4.11-rc0
> http:/
>>> On 18.05.17 at 19:10, wrote:
> Replace bool_t with bool. Delete trailing white spaces. Fix some coding
> style issues.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.o
>>> On 18.05.17 at 19:10, wrote:
> Fix coding style issues. No functional change.
Same general comment as on the earlier cleanup patch.
> @@ -318,17 +325,19 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid,
> unsigned int trap_nr)
> return -EBUSY;
>
> /* We are c
>>> On 18.05.17 at 19:10, wrote:
> Export hypercall_page_initialise_ring1_kernel as the code is moved.
This one again wants to go into hypercall.c. compat_iret() wants to go
next to do_iret() (wherever that ends up), and similarly I think other
functions would better go next to their non-compat c
>>> On 18.05.17 at 19:09, wrote:
> And export it via pv/domain.h.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/pv/traps.c | 36
I'm pretty certain hypercall.c would be a better fit here.
Jan
__
>>> On 18.05.17 at 19:09, wrote:
> No functional change.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/pv/traps.c | 148 +++
callback.c ?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://l
>>> On 18.05.17 at 19:09, wrote:
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
Albeit putting it into its own file (iret.c) would also be an option. Not
sure how fine grained we want things to be.
Jan
___
Xen-devel mail
>>> On 18.05.17 at 19:09, wrote:
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 18.05.17 at 19:09, wrote:
> Move from x86_64/traps.c to pv/traps.c.
This again doesn't necessarily fit into traps.c (but it's an option).
Perhaps we want some misc.c or util.c?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lis
Starting with
Xen Changes For Linux 4.11: Lands PVHv2 Guest Support
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes
[GIT PULL] xen: features and fixes for 4.11-rc0
http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03209.html
IIUC, Xen 4.
>>> On 18.05.17 at 19:09, wrote:
As said on patch 10(?), this shouldn't be moved alone. And whether
we want to move it in the first place depends on what the PVH
plans here are.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
>>> On 18.05.17 at 19:09, wrote:
> --- a/xen/arch/x86/pv/traps.c
> +++ b/xen/arch/x86/pv/traps.c
> @@ -264,6 +264,24 @@ long unregister_guest_nmi_callback(void)
> return 0;
> }
>
> +int guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
bool and all pointers (including the local v
>>> On 18.05.17 at 19:09, wrote:
> It needs to be non-static when we split PV specific code out.
I don't follow here: The variable is used by send_guest_trap() to
communicate with its helper nmi_mce_softirq(). How would you
move one without the other? The main cleanup potential I see
here would b
>>> On 18.05.17 at 19:09, wrote:
> +/*
> + * Called from asm to set up the MCE trapbounce info.
> + * Returns 0 if no callback is set up, else 1.
> + */
The comments suggest both of them want to actually return bool.
> +int set_guest_machinecheck_trapbounce(void)
> +{
> +struct vcpu *v = cur
>>> On 18.05.17 at 19:09, wrote:
> @@ -128,6 +132,75 @@ unsigned long do_get_debugreg(int reg)
> return -EINVAL;
> }
>
> +void pv_inject_event(const struct x86_event *event)
> +{
> +struct vcpu *v = current;
Could you take the opportunity and name this curr?
Jan
__
>>> On 18.05.17 at 19:09, wrote:
> The following handlers are moved:
> 1. do_set_trap_table
This one makes sense to move to pv/traps.c, but ...
> 2. do_set_debugreg
> 3. do_get_debugreg
> 4. do_fpu_taskswitch
... none of these do. I could see them go into pv/hypercall.c,
but I could also see th
>>> On 18.05.17 at 19:09, wrote:
> Fix coding style issues. Replace bool_t with bool. Add spaces around
> binary ops.
For these it would probably be fine to do them while moving the code.
But you did the extra work to put this into a separate patch, so I'm
not going to object to this approach.
>
>>> On 29.05.17 at 17:05, wrote:
> On Mon, May 29, 2017 at 08:16:41AM -0600, Jan Beulich wrote:
>> >>> On 29.05.17 at 14:57, wrote:
>> > On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote:
>> >> >>> On 27.04.17 at 16:35, wrote:
>> >> > +int xen_vpci_add_register(struct pci_dev *pdev, vp
>>> On 18.05.17 at 19:09, wrote:
> And remove the now unused instruction_done in x86/traps.c.
Hmm, that's another candidate for moving early and making non-static
then, I guess.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
>>> On 18.05.17 at 19:09, wrote:
> ---
> xen/arch/x86/pv/emulate.c | 20
And this one, together with emulate_forced_invalid_op(), perhaps
invalid.c?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.or
>>> On 18.05.17 at 19:09, wrote:
> ---
> xen/arch/x86/pv/emulate.c | 403 +
Along the lines of comments to patch 1, gate-op.c?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-d
>>> On 18.05.17 at 19:28, wrote:
> From 58df816b937dc7a3598de01f053a6030e631057e Mon Sep 17 00:00:00 2001
> From: Wei Liu
> Date: Thu, 18 May 2017 16:18:56 +0100
> Subject: [PATCH] x86/traps: move privilege instruction emulation code
privileged
> Move relevant code to pv/emulate.c. Export emula
flight 109830 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109830/
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
On Mon, May 29, 2017 at 08:16:41AM -0600, Jan Beulich wrote:
> >>> On 29.05.17 at 14:57, wrote:
> > On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote:
> >> >>> On 27.04.17 at 16:35, wrote:
> >> > +/* Read/write of unset register. */
> >> > +VPCI_READ_CHECK(8, 4, 0x);
> >
>>> On 26.05.17 at 15:41, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -37,7 +37,7 @@
> #include "hvm/save.h"
> #include "memory.h"
>
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x000d
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x000e
>
> /*
> * NB.
>>> On 24.05.17 at 16:25, wrote:
> @@ -2024,6 +2029,13 @@ void tsc_set_info(struct domain *d,
> d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
> d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
> set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
> +if (!opt_
>>> On 24.05.17 at 17:33, wrote:
> On Wed, May 24, 2017 at 05:25:03PM +0200, Olaf Hering wrote:
>> On Wed, May 24, Konrad Rzeszutek Wilk wrote:
>>
>> > How can that be determined? As in how can the guest (domU) be within
>> > the range? Is there some way to determine that? Is there some
>> > matr
>>> On 18.05.17 at 17:07, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -466,6 +466,54 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn,
> xenmem_access_t *access)
> }
>
> /*
> + * Set/clear the #VE suppress bit for a page. Only available on VMX.
>>> On 29.05.17 at 14:57, wrote:
> On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote:
>> >>> On 27.04.17 at 16:35, wrote:
>> > +/* Read/write of unset register. */
>> > +VPCI_READ_CHECK(8, 4, 0x);
>> > +VPCI_READ_CHECK(8, 2, 0x);
>> > +VPCI_READ_CHECK(8, 1, 0
On Mon, May 29, 2017 at 07:38:14AM -0600, Jan Beulich wrote:
> >>> On 27.04.17 at 16:35, wrote:
> > The following series contain an implementation of handlers for the PCI
> > configuration space inside of Xen. This allows Xen to detect accesses to the
> > PCI configuration space and react accordin
On 29/05/2017 13:37, Jan Beulich wrote:
> hap_teardown() unconditionally releases the paging lock and is always
> being called without the lock held: Lock acquire should then be
> unconditional too.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
>>> On 27.04.17 at 16:35, wrote:
> The following series contain an implementation of handlers for the PCI
> configuration space inside of Xen. This allows Xen to detect accesses to the
> PCI configuration space and react accordingly.
>
> Although there hasn't been a lot of review on the previous
>>> On 27.04.17 at 16:35, wrote:
> +static int vpci_index_capabilities(struct pci_dev *pdev)
> +{
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
> +uint8_t pos = PCI_CAPABILITY_LIST;
> +uint16_t status;
> +uns
>>> On 27.04.17 at 16:35, wrote:
> +static int vpci_msix_control_write(struct pci_dev *pdev, unsigned int reg,
> + union vpci_val val, void *data)
> +{
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pd
On 05/26/17 18:38, Jan Beulich wrote:
On 26.05.17 at 16:37, wrote:
>> On 05/26/17 17:29, Jan Beulich wrote:
>> On 25.05.17 at 11:40, wrote:
I've noticed that, with pages marked NX and vm_event emulation, we can
end up emulating an ud2, for which hvm_emulate_one() returns
X
flight 109828 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109828/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 109764 pass
in 109828
test-armhf-armhf-xl-rt
The improved type-checking version of container_of() triggers a warning for
xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t
contains a signed value:
drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events':
arch/x86/include/asm/cmpxchg.h:87:21: error: 'pend
On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote:
> >>> On 27.04.17 at 16:35, wrote:
> > --- a/tools/libxl/libxl_x86.c
> > +++ b/tools/libxl/libxl_x86.c
> > @@ -11,7 +11,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> > if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM
hap_teardown() unconditionally releases the paging lock and is always
being called without the lock held: Lock acquire should then be
unconditional too.
Signed-off-by: Jan Beulich
---
While this is only a cosmetic change afaict I would still like to
explore whether to include this in 4.9.
--- a/
On 05/29/17 15:11, Andrew Cooper wrote:
> On 29/05/2017 12:46, Razvan Cojocaru wrote:
>> On 05/29/17 14:05, Jan Beulich wrote:
>> On 29.05.17 at 11:20, wrote:
On 05/26/17 18:11, Andrew Cooper wrote:
> On 26/05/17 15:29, Jan Beulich wrote:
> On 25.05.17 at 11:40, wrote:
>>
On 29/05/2017 12:46, Razvan Cojocaru wrote:
> On 05/29/17 14:05, Jan Beulich wrote:
> On 29.05.17 at 11:20, wrote:
>>> On 05/26/17 18:11, Andrew Cooper wrote:
On 26/05/17 15:29, Jan Beulich wrote:
On 25.05.17 at 11:40, wrote:
>> I've noticed that, with pages marked NX and vm
On 05/29/17 14:05, Jan Beulich wrote:
On 29.05.17 at 11:20, wrote:
>> On 05/26/17 18:11, Andrew Cooper wrote:
>>> On 26/05/17 15:29, Jan Beulich wrote:
>>> On 25.05.17 at 11:40, wrote:
> I've noticed that, with pages marked NX and vm_event emulation, we can
> end up emulating an
On Wed, May 24, 2017 at 11:56:28AM -0400, Dave Anderson wrote:
> - Original Message -
> > crash patch c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add support for
> > dom0 with Linux kernel 3.19 and newer) from Daniel made crash utility
> > support xen dom0 vmcores after linux kernel comm
>>> On 29.05.17 at 11:20, wrote:
> On 05/26/17 18:11, Andrew Cooper wrote:
>> On 26/05/17 15:29, Jan Beulich wrote:
>> On 25.05.17 at 11:40, wrote:
I've noticed that, with pages marked NX and vm_event emulation, we can
end up emulating an ud2, for which hvm_emulate_one() returns
>>>
flight 71454 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71454/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail blocked in 71388
test-amd64-amd64-am
On 05/26/17 18:11, Andrew Cooper wrote:
> On 26/05/17 15:29, Jan Beulich wrote:
> On 25.05.17 at 11:40, wrote:
>>> I've noticed that, with pages marked NX and vm_event emulation, we can
>>> end up emulating an ud2, for which hvm_emulate_one() returns
>>> X86EMUL_EXCEPTION in hvm_emulate_one_vm
>>> On 29.05.17 at 11:03, wrote:
> On 29/05/2017 09:58, Jan Beulich wrote:
> On 26.05.17 at 19:03, wrote:
>>> --- a/xen/arch/x86/mm/guest_walk.c
>>> +++ b/xen/arch/x86/mm/guest_walk.c
>>> @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain
>>> *p2m,
>>> ASSERT(!(wa
When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.
Signed-off-by: Juergen Gross
---
drivers/xen/manage.c | 7 +--
1 f
On 29/05/2017 09:58, Jan Beulich wrote:
On 26.05.17 at 19:03, wrote:
>> --- a/xen/arch/x86/mm/guest_walk.c
>> +++ b/xen/arch/x86/mm/guest_walk.c
>> @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain
>> *p2m,
>> ASSERT(!(walk & PFEC_implicit) ||
>> !(wa
>>> On 26.05.17 at 19:03, wrote:
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain
> *p2m,
> ASSERT(!(walk & PFEC_implicit) ||
> !(walk & (PFEC_insn_fetch | PFEC_user_mode)));
>
>>> On 26.05.17 at 19:03, wrote:
> This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
>
> When determining Access Rights, Protection Keys only take effect when CR4.PKE
> it set, and 4-level paging is active. All other circumstances (notibly, 32bit
> PAE paging) skip the Protection Key
On Fri, May 26, Ian Jackson wrote:
> This seems like a real problem which should be improved. But maybe we
> should use Xen's EXTRAVERSION by default ?
After thinking about it, why does the tools build not just enforce a
fixed string? There is no point for scripts/buildversion.py to put
current
flight 109821 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109821/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 21 leak-check/check fail in 109809 REGR. vs.
109656
Tests which are
On 28/05/17 21:55, PGNet Dev wrote:
> Working with Xen 4.9.0 host on kernel 4.11.3
>
> dmesg | egrep -i "linux version|xen version"
> [0.00] Linux version 4.11.3-2.g7262353-default
> (geeko@buildhost) (gcc version 7.1.1 20170517 [gcc-7-branch revision 248152]
> (SUSE
Hi Julien,
On 26 May 2017 at 19:12, Bhupinder Thakur wrote:
>>> +#ifndef _VPL011_H_
>>> +
>>> +#define _VPL011_H_
>>> +
>>> +#include
>>> +#include
>>> +
>>> +DEFINE_XEN_FLEX_RING(vpl011);
>>
>>
>> I am sure someone already said it in a previous version. The vpl011 is the
>> console ring. So wh
72 matches
Mail list logo