>>> On 23.02.17 at 05:26, wrote:
> On 02/22/17 08:36 -0700, Jan Beulich wrote:
>> >>> On 17.02.17 at 07:39, wrote:
>> All of this said - is this really a per-vCPU property, instead of a
>> per-domain one?
>
> Per-vCPU. At least it can be set in the per-CPU way. Patch 16, which
> implements the v
>>> On 23.02.17 at 04:16, wrote:
> On 02/22/17 08:10 -0700, Jan Beulich wrote:
>> >>> On 17.02.17 at 07:39, wrote:
>> > @@ -700,26 +727,31 @@ static void intel_init_mca(struct cpuinfo_x86 *c)
>> >
>> > first = mce_firstbank(c);
>> >
>> > +if ( !mce_force_broadcast && (msr_content & M
>>> On 23.02.17 at 04:06, wrote:
> On 02/22/17 06:53 -0700, Jan Beulich wrote:
>> >>> On 17.02.17 at 07:39, wrote:
>> > @@ -1709,6 +1724,7 @@ static void mce_softirq(void)
>> > {
>> > int cpu = smp_processor_id();
>> > unsigned int workcpu;
>> > +bool lmce = per_cpu(lmce_in_process
>>> On 22.02.17 at 21:29, wrote:
Please don't top-post.
> Appreciate the feedback. I want to use these defines for parsing out SMMUv3
> components defined in ACPI. Since, I am picking these defines directly from
> Linux, I did not want to make this a part of a newly developed patch set.
What'
Hi, Stefano!
On 02/22/2017 07:10 PM, Stefano Stabellini wrote:
On Wed, 22 Feb 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano, Jan!
1. Stefano, are you still NOT considering adding
functionality to avoid memory copying? We discussed
this a little bit here [1].
Hi Oleksandr,
these macros are
flight 105989 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail REGR. vs. 105925
test-amd64-i386
flight 105984 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105984/
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
On 02/22/17 08:59 -0700, 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
> > @@ -1510,6 +1510,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
> > {
> > const cpumask_t *cpumap;
> >
This run is configured for baseline tests only.
flight 68605 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-midway 15 gu
On 02/22/17 08:55 -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 07:39, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/vmce.c
> > +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> > @@ -74,7 +74,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct
> > hvm_vmce_vcpu *ctxt)
> > unsigned long guest_mcg_cap;
On 02/22/17 08:48 -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 07:39, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mcaction.c
> > +++ b/xen/arch/x86/cpu/mcheck/mcaction.c
> > @@ -88,17 +88,19 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
> > goto vmce_failed;
> >
On 02/22/17 08:36 -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 07:39, wrote:
> > @@ -190,6 +191,25 @@ int vmce_rdmsr(uint32_t msr, uint64_t *val)
> > *val = ~0ULL;
> > mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_CTL %#"PRIx64"\n", cur,
> > *val);
> > break;
> > +
On 02/22/17 08:20 -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 07:39, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> > +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> > @@ -916,3 +916,7 @@ int vmce_intel_rdmsr(const struct vcpu *v, uint32_t
> > msr, uint64_t *val)
> > return 1;
> > }
flight 105978 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 105941
Regressions which ar
On 02/22/17 08:10 -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 07:39, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mce.h
> > +++ b/xen/arch/x86/cpu/mcheck/mce.h
> > @@ -38,6 +38,7 @@ enum mcheck_type {
> > };
> >
> > extern uint8_t cmci_apic_vector;
> > +extern bool lmce_support;
> >
> > /* I
On 02/22/17 06:53 -0700, Jan Beulich wrote:
> >>> On 17.02.17 at 07:39, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/barrier.c
> > +++ b/xen/arch/x86/cpu/mcheck/barrier.c
> > @@ -20,7 +20,7 @@ void mce_barrier_enter(struct mce_softirq_barrier *bar)
> > {
> > int gen;
> >
> > -if (!mce_broa
This run is configured for baseline tests only.
flight 68604 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68604/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
This run is configured for baseline tests only.
flight 68603 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/de
flight 105976 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105976/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail like 102692
test-armhf-arm
flight 105980 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-i386-xl-qemuu-
Hi Haoran,
Thank you for sending this patch out quickly! :-)
The title can be
[PATCH] xen: rtds: only tickle the same cpu once
On Wed, Feb 22, 2017 at 5:16 PM, Haoran Li wrote:
> From: naroahlee
>
>Modify: xen/common/sched_rt.c runq_tickle(): Check not_tickled Mask
> for a Cache-Preference
flight 105975 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105975/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105693
test-amd64-i38
From: naroahlee
Modify: xen/common/sched_rt.c runq_tickle(): Check not_tickled Mask
for a Cache-Preferenced-PCPU
The bug is introduced in Xen 4.7 when we converted RTDS scheduler from
quantum-driven model to event-driven model. We assumed whenever
runq_tickle() is invoked, we will find a P
flight 106000 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106000/
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
I'm trying to find a solution to an immediate VM crash which occurs by
simply adding "bios='ovmf' to my configuration?
I started with a standard Ubuntu install which contained Xen 4.6.0 and
had the crash. The VM works fine booting w/ SeaBIOS once the
configuration line is removed. It also work
On 2/16/2017 5:59 PM, Stefano Stabellini wrote:
> On Wed, 15 Feb 2017, Sameer Goel wrote:
>> From: Lv Zheng
>>
>> ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca
>>
>> This patch adds support for IORT (IO Remapping Table) in iasl.
>>
>> Note that some field names are modified to shrink thei
Appreciate the feedback. I want to use these defines for parsing out SMMUv3
components defined in ACPI. Since, I am picking these defines directly from
Linux, I did not want to make this a part of a newly developed patch set.
I will update the cc list.
Thanks,
Sameer
On 2/16/2017 2:57 AM, J
flight 105973 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105973/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105938
test-armhf-armhf-libvirt 13
flight 105970 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105970/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 105952 pass
in 105970
test-amd64-amd64-libvirt-q
flight 105993 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105993/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 9 debian-install fail REGR. vs. 105987
Tests which
On 02/07/2017 05:21 AM, Roger Pau Monné wrote:
> Hello Al,
>
> Thanks for your comments, please see below.
>
> On Mon, Feb 06, 2017 at 04:06:45PM -0700, Al Stone wrote:
>> On 01/24/2017 07:20 AM, Boris Ostrovsky wrote:
[snip]
>> Then it gets messy :). The APIC and/or x2APIC subtables of the
flight 105967 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs. 105855
Regressions whi
flight 105971 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105971/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-intel 17 guest-stop/l1/l2 fail in 105956 pass in
105971
test-armhf-
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
---
Changes in v3:
* Added pmu_version field to struct cpuid_policy
* vmx_vpmu_initialise() checks whether pmu version is
supported, not ju
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 (2):
x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE
x86/vpmu: Disable VPMU if guest's CPUID indi
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
flight 105966 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 105933
Regressions which
This run is configured for baseline tests only.
flight 68602 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68602/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e
baseline v
flight 105987 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105987/
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
Introduce new Xen command line parameter called "vwfi", which stands for
virtual wfi. The default is "trap": Xen traps the guest wfi instruction
and calls vcpu_block on the guest vcpu. The behavior can be changed
setting vwfi to "native", in that case Xen doesn't trap the instruction
at all, runnin
On Wed, 22 Feb 2017, Edgar E. Iglesias wrote:
> On Tue, Feb 21, 2017 at 07:20:29PM +, Julien Grall wrote:
> >
> >
> > On 21/02/2017 18:30, Stefano Stabellini wrote:
> > >On Tue, 21 Feb 2017, Julien Grall wrote:
> > >>Hi Stefano,
> > >>
> > >>On 21/02/17 17:49, Stefano Stabellini wrote:
> > >>
On Wed, 22 Feb 2017, Oleksandr Andrushchenko wrote:
> Hi, Stefano, Jan!
> 1. Stefano, are you still NOT considering adding
> functionality to avoid memory copying? We discussed
> this a little bit here [1].
Hi Oleksandr,
these macros are the generic versions of what pvcalls and xen-9pfs need,
and
On 2/22/17 7:34 AM, Daniel Kiper wrote:
> On Wed, Feb 22, 2017 at 06:42:40AM -0700, Jan Beulich wrote:
> On 21.02.17 at 20:24, wrote:
>>> On Tue, Feb 21, 2017 at 08:19:53PM +0100, Daniel Kiper wrote:
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which
On Tue, 2017-02-21 at 18:17 +, George Dunlap wrote:
> On 21/02/17 17:49, Stefano Stabellini wrote:
> > I don't know the inner working of the scheduler, but does it always
> > send
> > an interrupt to other pcpu to schedule something?
>
> Letting a guest call WFI is as safe as letting a guest
>
On 22/02/17 16:34, Boris Ostrovsky wrote:
>> I think the code as-is is ok, although it would be nice to extend the
>> basic{} union to have a named uint8_t for pmu_version.
>
> Something like this?
This please, to match the AMD side.
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/
Signed-off-by: Olaf Hering
---
docs/man/xl.cfg.pod.5.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 46f9caff3e..505c11137f 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1229,7 +1229,7 @@ O
> I think the code as-is is ok, although it would be nice to extend the
> basic{} union to have a named uint8_t for pmu_version.
Something like this?
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index bc3fc7c..f73ae19 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/
Thanks. The implementation use 'via' as param name and 'a' as local
variable which makes me think `via` is an abbreviation of something. Seems
wrong.
int xen_set_callback_via(uint64_t via)
{
struct xen_hvm_param a;
a.domid = DOMID_SELF;
a.index = HVM_PARAM_CALLBACK_IRQ;
a.value = via;
return HYPE
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1510,6 +1510,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
> {
> const cpumask_t *cpumap;
> cpumask_var_t cmv;
> +int cpu_nr;
unsigned in
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -74,7 +74,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct
> hvm_vmce_vcpu *ctxt)
> unsigned long guest_mcg_cap;
>
> if ( boot_cpu_data.x86_vendor == X86_VENDOR_I
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mcaction.c
> +++ b/xen/arch/x86/cpu/mcheck/mcaction.c
> @@ -88,17 +88,19 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
> goto vmce_failed;
> }
>
> -if ( boot_cpu_data.x86_vendo
>>> On 17.02.17 at 07:39, wrote:
> @@ -190,6 +191,25 @@ int vmce_rdmsr(uint32_t msr, uint64_t *val)
> *val = ~0ULL;
> mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_CTL %#"PRIx64"\n", cur,
> *val);
> break;
> +case MSR_IA32_MCG_EXT_CTL:
> +/*
> + * If
flight 105986 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105986/
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
On Wed, Feb 22, 2017 at 06:42:40AM -0700, Jan Beulich wrote:
> >>> On 21.02.17 at 20:24, wrote:
> > On Tue, Feb 21, 2017 at 08:19:53PM +0100, Daniel Kiper wrote:
> >> This way Xen can be loaded on EFI platforms using GRUB2 and
> >> other boot loaders which support multiboot2 protocol.
> >>
> >> Si
Today xenstored supports logging only via a command line parameter.
This means that logging is either all the time off (default) or on.
To switch logging on the Xen host has to be rebooted as xenstored
isn't restartable.
This patch series changes this by using the XS_DEBUG wire command of
Xenstore
The Xenstore protocol supports the XS_CONTROL command for triggering
various actions in the Xenstore daemon. Enhance that support by using
a command table and adding a help function.
Support multiple control commands in the associated xenstore-control
program used to issue XS_CONTROL commands.
Si
In preparation to support other than pure debug functionality via the
Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
XS_DEBUG an alias of it.
Add an alias xs_control_command for the associated xs_debug_command,
too.
Signed-off-by: Juergen Gross
---
tools/xenstore/include/xensto
Add a XS_CONTROL command to xenstored for doing a talloc report to a
file. Right now this is supported by specifying a command line option
when starting xenstored and sending a signal to the daemon to trigger
the report.
To dump the report to the standard log file call:
xenstore-control memreport
Today Xenstore supports logging only if specified at start of the
Xenstore daemon. As it can't be disabled during runtime it is not
recommended to start xenstored with logging enabled.
Add support for switching logging on and off at runtime and to
specify a (new) logfile. This is done via the XS_C
As 0 is a valid file descriptor testing a descriptor to be valid
should be done via >= 0 instead of > 0.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored
As a memory report can now be triggered via XS_CONTROL support via
command line and signal handler is no longer needed. Remove it.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --g
Move the XS_CONTROL handling of xenstored to a new source file
xenstored_control.c.
In order to avoid making get_string() in xenstored_core.c globally
visible use strlen() instead, which is save in this context due to
xs_count_strings() before returned a value > 1.
Signed-off-by: Juergen Gross
-
On 22/02/17 15:04, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 3/5]
> tools/libxendevicemodel: extract functions and add a compat layer"):
>> On 22/02/17 14:37, Ian Jackson wrote:
>>> Is the bitmap copied in each dmop call ?
>> Yes, and hence...
> Oh!
>
> I had assumed th
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -916,3 +916,7 @@ int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr,
> uint64_t *val)
> return 1;
> }
>
> +bool vmce_support_lmce(const struct vcpu *v)
> +{
>
>>> On 22.02.17 at 16:02, wrote:
> On 02/22/2017 09:38 AM, Jan Beulich wrote:
> On 22.02.17 at 15:15, wrote:
>>> On 02/22/2017 04:55 AM, Jan Beulich wrote:
>>> On 17.02.17 at 18:40, wrote:
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -884,6
On 02/22/2017 09:28 AM, Bjorn Helgaas wrote:
> On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote:
>> On 02/21/2017 10:45 AM, Juergen Gross wrote:
>>> On 21/02/17 16:31, Dan Streetman wrote:
On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 13,
On 22/02/17 15:02, Boris Ostrovsky wrote:
> On 02/22/2017 09:38 AM, Jan Beulich wrote:
> On 22.02.17 at 15:15, wrote:
>>> On 02/22/2017 04:55 AM, Jan Beulich wrote:
>>> On 17.02.17 at 18:40, wrote:
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @
>>> On 17.02.17 at 07:39, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.h
> +++ b/xen/arch/x86/cpu/mcheck/mce.h
> @@ -38,6 +38,7 @@ enum mcheck_type {
> };
>
> extern uint8_t cmci_apic_vector;
> +extern bool lmce_support;
>
> /* Init functions */
> enum mcheck_type amd_mcheck_init(struct cpui
Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 3/5] tools/libxendevicemodel:
extract functions and add a compat layer"):
> On 22/02/17 14:37, Ian Jackson wrote:
> > Is the bitmap copied in each dmop call ?
>
> Yes, and hence...
Oh!
I had assumed that this wouldn't be the case because it would
>>> On 22.02.17 at 08:12, wrote:
> On Wed, Feb 22, 2017 at 02:10:25AM -0700, Jan Beulich wrote:
> On 22.02.17 at 02:53, wrote:
>>> On Tue, Nov 22, 2016 at 05:58:56PM +0800, Jan Beulich wrote:
> @@ -637,7 +657,23 @@ static int msi_msg_to_remap_entry(
> remap_rte->address_hi = 0;
>
On 02/22/2017 09:38 AM, Jan Beulich wrote:
On 22.02.17 at 15:15, wrote:
>> On 02/22/2017 04:55 AM, Jan Beulich wrote:
>> On 17.02.17 at 18:40, wrote:
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -884,6 +884,10 @@ int vmx_vpmu_initialise(struct
On 22/02/17 14:37, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 3/5]
> tools/libxendevicemodel: extract functions and add a compat layer"):
>> On 22/02/17 14:20, Ian Jackson wrote:
>>> As I think we discussed some time last week (?), this function cannot
>>> be a DMOP. Th
Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 3/5] tools/libxendevicemodel:
extract functions and add a compat layer"):
> On 22/02/17 14:20, Ian Jackson wrote:
> > As I think we discussed some time last week (?), this function cannot
> > be a DMOP. This is because enabling track_dirty_vram cau
>>> On 22.02.17 at 15:15, wrote:
> On 02/22/2017 04:55 AM, Jan Beulich wrote:
> On 17.02.17 at 18:40, wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_intel.c
>>> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>>> @@ -884,6 +884,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
>>> if ( vpmu_mode == XENPMU_MODE_
On 22/02/17 14:20, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH v2 3/5] tools/libxendevicemodel: extract
> functions and add a compat layer"):
>> This patch extracts all functions resulting in a dm_op hypercall from
>> libxenctrl and moves them into libxendevicemodel. It also adds a compat
>>
This allows to also change the types of image_base and image_start in the Dom0
builder from char * to void *.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v6:
- New in this version.
---
xen/arch/x86/bzimage.c| 9 +
xen/arch/x86/domain_
On Tue, Nov 22, 2016 at 06:03:51PM +0800, Jan Beulich wrote:
On 18.11.16 at 02:58, wrote:
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -600,27 +600,41 @@ static int msi_msg_to_remap_entry(
>>
>> if ( !pi_desc )
>> {
>> -
Initialize Dom0 BSP/APs and setup the memory and IO permissions. This also sets
the initial BSP state in order to match the protocol specified in
docs/misc/hvmlite.markdown.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v5:
- M
On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote:
> On 02/21/2017 10:45 AM, Juergen Gross wrote:
> > On 21/02/17 16:31, Dan Streetman wrote:
> >> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
> >> wrote:
> >>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
>
Allow setting the destination vCPU for libelf, so that elf_load_image can take
it into account when loading the kernel for Dom0. This is needed for PVHv2 Dom0
build, so that hvm_copy_to_guest_phys can be called with a Dom0 vCPU instead of
current (that contains the idle vCPU at this point).
Signed
Introduce a helper to parse the Dom0 kernel.
A new helper is also introduced to libelf, that's used to store the destination
vcpu of the domain. This parameter is needed when loading the kernel on a HVM
domain (PVHv2), since hvm_copy_to_guest_phys requires passing the destination
vcpu.
While ther
Craft the Dom0 e820 memory map and populate it. Introduce a helper to remove
memory pages that are shared between Xen and a domain, and use it in order to
remove low 1MB RAM regions from dom_io in order to assign them to a PVHv2 Dom0.
On hardware lacking support for unrestricted mode also craft th
Create a new MADT table that contains the topology exposed to the guest. A
new XSDT table is also created, in order to filter the tables that we want
to expose to the guest, plus the Xen crafted MADT. This in turn requires Xen
to also create a new RSDP in order to make it point to the custom XSDT.
Hello,
The main difference with previous versions is the split of the libelf and
bzimage changes into separate patches and the rebase on top of staging, that
already contains Jan's patch for the VM86 TSS issue.
The full series can also be found on a git branch in my personal git repo:
git://xenb
PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
from physical or emulated devices over event channels using PIRQs. This
applies to both DomU and Dom0 PVHv2 guests.
Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
route physical interrupts (even
On 22/02/17 12:40, johannes.3.h...@continental-corporation.com wrote:
Hi
Hello,
I'm writing my master thesis about using hypervisors on automotive high
performance plattforms. As a part of my work for the thesis I'm trying
to set up xen on a s32v234-evb (ARMv8) board using u-boot 2016.01.
Paul Durrant writes ("[PATCH v2 5/5] tools/libxendevicemodel: add a call to
restrict the handle"):
> My recent patch [1] to the Linux privcmd module introduced a mechanism
> to restrict an open file handle to subsequently only accept operations for
> a specified domain.
Acked-by: Ian Jackson
__
Paul Durrant writes ("[PATCH v2 4/5] tools/libxendevicemodel: introduce a
Linux-specific implementation"):
> My recent patch [1] to the Linux privcmd module introduced a dedicated
> mechanism for making dm_op hypercalls.
>
> This patch adds the necessary code to libxendevicemodel to take
> advant
Paul Durrant writes ("[PATCH v2 3/5] tools/libxendevicemodel: extract functions
and add a compat layer"):
> This patch extracts all functions resulting in a dm_op hypercall from
> libxenctrl and moves them into libxendevicemodel. It also adds a compat
> layer into libxenctrl, which can be selected
Hi Andre,
On 16/02/17 20:07, Andrew Cooper wrote:
Replace one opencoded mfn_eq() and some coding style issues on altered lines.
Swap __mfn_valid() to being bool, although it can't be updated to take mfn_t
because of include dependencies.
No functional change.
Signed-off-by: Andrew Cooper
A
On 02/22/2017 04:55 AM, Jan Beulich wrote:
On 17.02.17 at 18:40, wrote:
>> --- a/xen/arch/x86/cpu/vpmu_intel.c
>> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>> @@ -884,6 +884,10 @@ int vmx_vpmu_initialise(struct vcpu *v)
>> if ( vpmu_mode == XENPMU_MODE_OFF )
>> return 0;
>>
>> +
On Wed, Feb 22, 2017 at 02:10:25AM -0700, Jan Beulich wrote:
On 22.02.17 at 02:53, wrote:
>> On Tue, Nov 22, 2016 at 05:58:56PM +0800, Jan Beulich wrote:
@@ -637,7 +657,23 @@ static int msi_msg_to_remap_entry(
remap_rte->address_hi = 0;
remap_rte->data = index - i;
>>
>>> On 22.02.17 at 14:58, wrote:
> On Wed, 2017-02-22 at 03:26 -0700, Jan Beulich wrote:
>> > > > On 17.02.17 at 16:42, wrote:
>> > --- a/xen/include/asm-x86/msr-index.h
>> > +++ b/xen/include/asm-x86/msr-index.h
>> > @@ -55,6 +55,8 @@
>> > #define MSR_IA32_PEBS_ENABLE 0x03f1
>>
Paul Durrant writes ("[PATCH v2 2/5] tools/libxendevicemodel: introduce the new
library"):
> The new xendevicemodel library is intended to be used by all Xen device
> models such that the only hypercall that use will be the dm_op hypercall
> added by commit 524a98c2.
Acked-by: Ian Jackson
> NOT
Hi Ian,
On 22/02/17 13:19, Ian Jackson wrote:
Julien Grall writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions -
FAIL"):
On 14/02/17 17:42, Wei Liu wrote:
(test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | grep
arndale
arndale-bluewater XenDTUARTPath
Paul Durrant writes ("[PATCH v2 1/5] tools/libxenctrl: fix error check after
opening libxenforeignmemory"):
> Checking the value of xch->xcall is clearly incorrect. The code should be
> checking xch->fmem (i.e. the return of the previously called function).
Acked-by: Ian Jackson
___
On Wed, Feb 22, 2017 at 01:27:34PM +, Paul Durrant wrote:
> Checking the value of xch->xcall is clearly incorrect. The code should be
> checking xch->fmem (i.e. the return of the previously called function).
>
> Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Ian, please backport this.
> --
Hello,
There was few discussions recently about hiding SMMUs from DOM0 when
using ACPI. I thought it would be good to have a separate thread for this.
When using ACPI, the SMMUs will be described in the IO Remapping Table
(IORT). The specification can be found on the ARM website [1].
For a
+
+void vpmu_initialise(struct vcpu *v)
+{
+get_vpmu(v);
+
+/*
+ * Guests without LAPIC (i.e. PV) call vpmu_arch_initialise()
+ * from pvpmu_init().
+ */
>>> implication is that PV VPMU is not counted then?
>> No. get_vpmu() is what
On 22/02/17 13:58, Sergey Dyasli wrote:
>
>>> @@ -2876,7 +2938,11 @@ static int vmx_msr_write_intercept(unsigned int msr,
>>> uint64_t msr_content)
>>> for ( ; (rc == 0) && lbr->count; lbr++ )
>>> for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
>>>
1 - 100 of 194 matches
Mail list logo
