Re: [Xen-devel] [PATCHv6 2/3] grant_table: convert grant table rwlock to percpu rwlock

[Jan Beulich]

>>> On 22.01.16 at 14:41,  wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -178,6 +178,8 @@ struct active_grant_entry {
>  #define _active_entry(t, e) \
>  ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>  
> +DEFINE_PERCPU_RWLOCK_GLOBAL(grant_rwlock);
> +
>  static inline void gnttab_flush_tlb(const struct domain *d)
>  {
>  if ( !paging_mode_external(d) )
> @@ -208,7 +210,13 @@ active_entry_acquire(struct grant_table *t, grant_ref_t 
> e)
>  {
>  struct active_grant_entry *act;
>  
> -ASSERT(rw_is_locked(>lock));
> +/* 
> + * The grant table for the active entry should be locked but the 
> + * percpu rwlock cannot be checked for read lock without race conditions
> + * or high overhead so we cannot use an ASSERT 
> + *
> + *   ASSERT(rw_is_locked(>lock));
> + */

There are a number of trailing blanks being added here (and further
down), which I'm fixing up as I'm in the process of applying this. The
reason I noticed though is that this hunk ...

> @@ -660,7 +668,13 @@ static int grant_map_exists(const struct domain *ld,
>  {
>  unsigned int ref, max_iter;
>  
> -ASSERT(rw_is_locked(>lock));
> +/* 
> + * The remote grant table should be locked but the percpu rwlock
> + * cannot be checked for read lock without race conditions or high 
> + * overhead so we cannot use an ASSERT 
> + *
> + *   ASSERT(rw_is_locked(>lock));
> + */
>  
>  max_iter = min(*ref_count + (1 << GNTTABOP_CONTINUATION_ARG_SHIFT),
> nr_grant_entries(rgt));

... doesn't apply at all due to being white space damaged (the line
immediately preceding the ASSERT() which gets removed actually
has four blanks on it in the source tree (which is wrong, but should
nevertheless be reflected in your patch). Due to the other trailing
whitespace found above I can also exclude the mail system to have
eaten that white space on the way here, so I really wonder which
tree this patch got created against.

Considering the hassle with the first commit attempt yesterday,
may I please ask that you apply a little more care?

Thanks, Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv6 2/3] grant_table: convert grant table rwlock to percpu rwlock

[Ian Campbell]

On Fri, 2016-01-22 at 08:15 -0700, Jan Beulich wrote:
> 
> There are a number of trailing blanks being added here (and further
> down), which I'm fixing up as I'm in the process of applying this.

Aside: Do you know about "git am --whitespace=fix" ? It automates the
removal of trailing whitespace...

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID

[Jan Beulich]

>>> On 22.01.16 at 15:59,  wrote:
> El 22/01/16 a les 14.34, Andrew Cooper ha escrit:
>> On 22/01/16 12:43, Roger Pau Monné wrote:
>>> IOAPIC: tied to LAPIC (so either both enabled or none).
>> 
>> An IOAPIC is by no means required - they are only for turning legacy
>> interrupts into MSIs.  It would be perfectly fine for a PVH domain to
>> have an LAPIC and an SRIOV virtual function, without an IOAPIC at all.
>> 
>> The presence of LAPICs and IOAPICs reside in the MADT ACPI table.
> 
> Right, so as said in the reply to Jan, we will require ACPI in order to
> enable any of this pieces. I don't have a problem with that, just wasn't
> sure if this requirement was desired.

The question is whether a non-Dom0 HVMlite guest needs any
of these in the first place. Because if it doesn't (and that's the
mode we provide right now), making them dependent on ACPI
availability should be quite fine: If we need them for some
purpose in the guest, we'd need to make ACPI tables available.

> If that's the plan, then I think we would also need to fixup the tables
> provided to Dom0 in order to match what's available, but that can be
> discussed later.

I don't see what you're getting at here: The IO-APIC information
should be usable as is for Dom0 (as is the case for PV).

>>> So, we have the following devices that are assumed to be there: RTC,
>>> PIC, PIT. Everything else I think can be signalled by other means
>>> already available.
>>>
>>> IMHO, I think we could say that the PIC is never going to be available
>>> to HVMlite guests (in any case we would enable the lapic/ioapic), and
>>> maybe enable the RTC and PIT by default?
>>>
>>> Then I think we could get away without any Xen-specific way of reporting
>>> enabled devices.
>> 
>> DMLite is a new container type.  I would far rather it was assumed that
>> there was no legacy hardware at all.
> 
> So I take that you are in favour of only considering enabling the local
> APIC and IO APIC maybe for HVMlite, because of the performance benefits,
> while the other devices are _never_ going to be available to HVMlite
> guests/hosts at all? (Dom0 already gets the hw VGA)
> 
> IMHO, I would like to be able to eventually enable them in order to
> provide an environment that's as close as possible to a compatible PC,
> in order to reduce the amount of changes required in order to port an OS
> to run in this mode.

I didn't think that's among the goals for HVMlite. Just like PV and PVH,
HVMlite requires OS awareness.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[David Miller]

From: One Thousand Gnomes 
Date: Fri, 22 Jan 2016 20:25:21 +

>> The fact what include/linux/license.h:license_is_gpl_compatible includes
>> "Dual MIT/GPL" as an option seems to suggest that it is enough of a thing
>> to be validly used as the contents of a MODULE_LICENSE() thing.
> 
> Yes. The MIT licence most definitely exists, and people know what it
> means.
> 
> Also nobody should be changing the licence on anything unless they have
> the written permission of all rights holders on record, so it's best to
> leave it be 8)

+1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] disk=['file://..xvda'] not working for boot disks anymore?

[Konrad Rzeszutek Wilk]

Hey,

This parameter
disk = 
['file:/root/sol.dd,xvda,w','file:/root/sol-11_2_15_5_1-text-x86.iso,xvdb:cdrom,r']

works with qemu-traditional, but if I try with qemu-xen it
does not find the disk:

(d15) [2016-01-22 20:50:03] enter handle_19:
(d15) [2016-01-22 20:50:03]   NULL
(d15) [2016-01-22 20:50:03] Booting from ROM...
(d15) [2016-01-22 20:50:03] Booting from c980:0361

while with qemu-traditional:

(d14) [2016-01-22 20:43:15] Bochs BIOS - build: 06/23/99
(d14) [2016-01-22 20:43:15] $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(d14) [2016-01-22 20:43:15] Options: apmbios pcibios eltorito PMM
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15] ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (12288 
MBytes)
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15] Press F12 for boot menu.
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15] Booting from Hard Disk...

It does work with Xen 4.4, but that is ancient. I hadn't yet
tried Xen 4.5 nor 4.6.

I am hoping one of you knows exactly which commit might have made
this change?

Note that the name is 'xvda', not 'hda'. Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[One Thousand Gnomes]

> The fact what include/linux/license.h:license_is_gpl_compatible includes
> "Dual MIT/GPL" as an option seems to suggest that it is enough of a thing
> to be validly used as the contents of a MODULE_LICENSE() thing.

Yes. The MIT licence most definitely exists, and people know what it
means.

Also nobody should be changing the licence on anything unless they have
the written permission of all rights holders on record, so it's best to
leave it be 8)

Alan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-mingo-tip-master test] 78785: regressions - FAIL

[osstest service owner]

flight 78785 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a

version targeted for testing:
 linuxa1bbcf95250d57df9f8153d87698595b709c4c9d
baseline version:
 linux

Re: [Xen-devel] disk=['file://..xvda'] not working for boot disks anymore?

[Boris Ostrovsky]

On 01/22/2016 03:54 PM, Konrad Rzeszutek Wilk wrote:

Hey,

This parameter
disk = 
['file:/root/sol.dd,xvda,w','file:/root/sol-11_2_15_5_1-text-x86.iso,xvdb:cdrom,r']

works with qemu-traditional, but if I try with qemu-xen it
does not find the disk:

(d15) [2016-01-22 20:50:03] enter handle_19:
(d15) [2016-01-22 20:50:03]   NULL
(d15) [2016-01-22 20:50:03] Booting from ROM...
(d15) [2016-01-22 20:50:03] Booting from c980:0361

while with qemu-traditional:

(d14) [2016-01-22 20:43:15] Bochs BIOS - build: 06/23/99
(d14) [2016-01-22 20:43:15] $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(d14) [2016-01-22 20:43:15] Options: apmbios pcibios eltorito PMM
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15] ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (12288 
MBytes)
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15] Press F12 for boot menu.
(d14) [2016-01-22 20:43:15]
(d14) [2016-01-22 20:43:15] Booting from Hard Disk...

It does work with Xen 4.4, but that is ancient. I hadn't yet
tried Xen 4.5 nor 4.6.

I am hoping one of you knows exactly which commit might have made
this change?

Note that the name is 'xvda', not 'hda'. Thanks!


Probably this one:

http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01529.html


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 01/12] x86/smp: Make start_secondary() and initial_pg_pmd visible globally

[Boris Ostrovsky]

Xen's HVMlite guests will want to use them.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/include/asm/smp.h |1 +
 arch/x86/kernel/head_32.S  |2 +-
 arch/x86/kernel/smpboot.c  |2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index dfcf072..739abb0 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -147,6 +147,7 @@ void x86_idle_thread_init(unsigned int cpu, struct 
task_struct *idle);
 
 void smp_store_boot_cpu_info(void);
 void smp_store_cpu_info(int id);
+void start_secondary(void *unused);
 #define cpu_physical_id(cpu)   per_cpu(x86_cpu_to_apicid, cpu)
 
 #else /* !CONFIG_SMP */
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 6bc9ae2..eeb5c42 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -666,7 +666,7 @@ ENTRY(setup_once_ref)
 __PAGE_ALIGNED_BSS
.align PAGE_SIZE
 #ifdef CONFIG_X86_PAE
-initial_pg_pmd:
+ENTRY(initial_pg_pmd)
.fill 1024*KPMDS,4,0
 #else
 ENTRY(initial_page_table)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 24d57f7..cba00bc 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -199,7 +199,7 @@ static int enable_start_cpu0;
 /*
  * Activate a secondary processor.
  */
-static void notrace start_secondary(void *unused)
+void notrace start_secondary(void *unused)
 {
/*
 * Don't put *anything* before cpu_init(), SMP booting is too
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 09/12] xen/hvmlite: Extend APIC operations for HVMlite guests

[Boris Ostrovsky]

HVMlite guests need to be viewed as having APIC, otherwise smpboot code,
for example, will complain.

Signed-off-by: Boris Ostrovsky 
---

Not sure about xen_cpu_present_to_apicid() being an identity function, given
xen_x86_32_early_logical_apicid().

 arch/x86/xen/apic.c |   39 +--
 arch/x86/xen/smp.c  |2 +-
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index abf4901..2a59c39 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include "xen-ops.h"
 #include "pmu.h"
 #include "smp.h"
@@ -78,6 +79,21 @@ static void xen_apic_write(u32 reg, u32 val)
return;
}
 
+   if (xen_hvmlite) {
+   switch (reg) {
+   case APIC_TASKPRI:
+   case APIC_SPIV:
+   case APIC_ESR:
+   case APIC_LVTT:
+   case APIC_LVT0:
+   case APIC_LVT1:
+   case APIC_LVTERR:
+   pr_debug("Unimplemented APIC register %x,"
+" value: %x\n", reg, val);
+   return;
+   }
+   }
+
/* Warn to see if there's any stray references */
WARN(1,"register: %x, value: %x\n", reg, val);
 }
@@ -100,7 +116,7 @@ static u32 xen_safe_apic_wait_icr_idle(void)
 
 static int xen_apic_probe_pv(void)
 {
-   if (xen_pv_domain())
+   if (xen_pv_domain() || xen_hvmlite)
return 1;
 
return 0;
@@ -142,6 +158,19 @@ static void xen_silent_inquire(int apicid)
 {
 }
 
+static int xen_cpu_present_to_apicid(int cpu)
+{
+   return cpu;
+}
+
+static int xen_wakeup_secondary_cpu(int cpu, unsigned long start_eip)
+{
+   if (!xen_hvmlite)
+   return -EINVAL;
+
+   return HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
+}
+
 static struct apic xen_pv_apic = {
.name   = "Xen PV",
.probe  = xen_apic_probe_pv,
@@ -162,7 +191,7 @@ static struct apic xen_pv_apic = {
 
.ioapic_phys_id_map = default_ioapic_phys_id_map, /* Used 
on 32-bit */
.setup_apic_routing = NULL,
-   .cpu_present_to_apicid  = default_cpu_present_to_apicid,
+   .cpu_present_to_apicid  = xen_cpu_present_to_apicid,
.apicid_to_cpu_present  = physid_set_mask_of_physid, /* Used on 
32-bit */
.check_phys_apicid_present  = default_check_phys_apicid_present, /* 
smp_sanity_check needs it */
.phys_pkg_id= xen_phys_pkg_id, /* detect_ht */
@@ -180,6 +209,9 @@ static struct apic xen_pv_apic = {
.send_IPI_all   = xen_send_IPI_all,
.send_IPI_self  = xen_send_IPI_self,
 #endif
+
+   .wakeup_secondary_cpu   = xen_wakeup_secondary_cpu,
+
/* .wait_for_init_deassert- used  by AP bootup - smp_callin which we 
don't use */
.inquire_remote_apic= xen_silent_inquire,
 
@@ -216,5 +248,8 @@ void __init xen_init_apic(void)
apic = _pv_apic;
 
x86_platform.apic_post_init = xen_apic_check;
+
+   if (xen_hvmlite)
+   setup_force_cpu_cap(X86_FEATURE_APIC);
 }
 apic_driver(xen_pv_apic);
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index b265c4f..fb085ef 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -214,7 +214,7 @@ static int xen_smp_intr_init(unsigned int cpu)
 * The IRQ worker on PVHVM goes through the native path and uses the
 * IPI mechanism.
 */
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_hvmlite)
return 0;
 
callfunc_name = kasprintf(GFP_KERNEL, "irqwork%d", cpu);
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 07/12] xen/hvmlite: Prepare cpu_initialize_context() routine for HVMlite SMP

[Boris Ostrovsky]

Subsequent patch will add support for starting secondary VCPUs in
HVMlite guest. This patch exists to make review easier.

No functional changes (except for introduction of 'if (!xen_hvmlite)').

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/smp.c |  104 ---
 1 files changed, 57 insertions(+), 47 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3f4ebf0..5fc4afb 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -390,70 +390,80 @@ cpu_initialize_context(unsigned int cpu, struct 
task_struct *idle)
if (cpumask_test_and_set_cpu(cpu, xen_cpu_initialized_map))
return 0;
 
-   ctxt = kzalloc(sizeof(*ctxt), GFP_KERNEL);
-   if (ctxt == NULL)
-   return -ENOMEM;
+   if (!xen_hvmlite) {
 
-   gdt = get_cpu_gdt_table(cpu);
+   ctxt = kzalloc(sizeof(*ctxt), GFP_KERNEL);
+   if (ctxt == NULL)
+   return -ENOMEM;
+
+   gdt = get_cpu_gdt_table(cpu);
 
 #ifdef CONFIG_X86_32
-   /* Note: PVH is not yet supported on x86_32. */
-   ctxt->user_regs.fs = __KERNEL_PERCPU;
-   ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
+   /* Note: PVH is not yet supported on x86_32. */
+   ctxt->user_regs.fs = __KERNEL_PERCPU;
+   ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
 #endif
-   memset(>fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
+   memset(>fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-   if (!xen_feature(XENFEAT_auto_translated_physmap)) {
-   ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-   ctxt->flags = VGCF_IN_KERNEL;
-   ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
-   ctxt->user_regs.ds = __USER_DS;
-   ctxt->user_regs.es = __USER_DS;
-   ctxt->user_regs.ss = __KERNEL_DS;
+   if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+   ctxt->user_regs.eip =
+   (unsigned long)cpu_bringup_and_idle;
+   ctxt->flags = VGCF_IN_KERNEL;
+   ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+   ctxt->user_regs.ds = __USER_DS;
+   ctxt->user_regs.es = __USER_DS;
+   ctxt->user_regs.ss = __KERNEL_DS;
 
-   xen_copy_trap_info(ctxt->trap_ctxt);
+   xen_copy_trap_info(ctxt->trap_ctxt);
 
-   ctxt->ldt_ents = 0;
+   ctxt->ldt_ents = 0;
 
-   BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+   BUG_ON((unsigned long)gdt & ~PAGE_MASK);
 
-   gdt_mfn = arbitrary_virt_to_mfn(gdt);
-   make_lowmem_page_readonly(gdt);
-   make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+   gdt_mfn = arbitrary_virt_to_mfn(gdt);
+   make_lowmem_page_readonly(gdt);
+   make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-   ctxt->gdt_frames[0] = gdt_mfn;
-   ctxt->gdt_ents  = GDT_ENTRIES;
+   ctxt->gdt_frames[0] = gdt_mfn;
+   ctxt->gdt_ents  = GDT_ENTRIES;
 
-   ctxt->kernel_ss = __KERNEL_DS;
-   ctxt->kernel_sp = idle->thread.sp0;
+   ctxt->kernel_ss = __KERNEL_DS;
+   ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-   ctxt->event_callback_cs = __KERNEL_CS;
-   ctxt->failsafe_callback_cs  = __KERNEL_CS;
+   ctxt->event_callback_cs = __KERNEL_CS;
+   ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #else
-   ctxt->gs_base_kernel = per_cpu_offset(cpu);
+   ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
-   ctxt->event_callback_eip=
-   (unsigned long)xen_hypervisor_callback;
-   ctxt->failsafe_callback_eip =
-   (unsigned long)xen_failsafe_callback;
-   ctxt->user_regs.cs = __KERNEL_CS;
-   per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
-   }
+   ctxt->event_callback_eip=
+   (unsigned long)xen_hypervisor_callback;
+   ctxt->failsafe_callback_eip =
+   (unsigned long)xen_failsafe_callback;
+   ctxt->user_regs.cs = __KERNEL_CS;
+   per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
+   }
 #ifdef CONFIG_XEN_PVH
-   else {
-   /*
-* The vcpu comes on kernel page tables which have the NX pte
-* bit set. This means before DS/SS is touched, NX in
-* EFER must be set. Hence the following assembly 

[Xen-devel] [PATCH v1 00/12] HVMlite domU support

[Boris Ostrovsky]

This series introduces HVMlite support for unprivileged guests.

It has been tested on Intel/AMD, both 32- and 64-bit, including CPU on- and
offlining and save/restore. (Restore will result in APIC write warnings
which exist now for 32-bit PV guests as well so I didn't address this in
this series)

Compile-tested on ARM

Boris Ostrovsky (12):
  x86/smp: Make start_secondary() and initial_pg_pmd visible globally
  xen/hvmlite: Factor out common kernel init code
  xen/hvmlite: Import hvmlite-related Xen public interfaces
  xen/hvmlite: Bootstrap HVMlite guest
  xen/hvmlite: Allow HVMlite guests delay initializing grant table
  xen/hvmlite: Initialize PCI
  xen/hvmlite: Prepare cpu_initialize_context() routine for HVMlite SMP
  xen/hvmlite: Initialize context for secondary VCPUs
  xen/hvmlite: Extend APIC operations for HVMlite guests
  xen/hvmlite: Use x86's default timer init for HVMlite guests
  xen/hvmlite: Boot secondary CPUs
  xen/hvmlite: Enable CPU on-/offlining

 arch/x86/include/asm/smp.h   |1 +
 arch/x86/kernel/head_32.S|2 +-
 arch/x86/kernel/smpboot.c|2 +-
 arch/x86/pci/xen.c   |2 +-
 arch/x86/xen/Makefile|1 +
 arch/x86/xen/apic.c  |   39 -
 arch/x86/xen/enlighten.c |  318 ++
 arch/x86/xen/grant-table.c   |4 +-
 arch/x86/xen/platform-pci-unplug.c   |4 +-
 arch/x86/xen/pmu.c   |4 +-
 arch/x86/xen/smp.c   |  248 ++
 arch/x86/xen/smp.h   |4 +
 arch/x86/xen/time.c  |5 +-
 arch/x86/xen/xen-hvmlite.S   |  173 ++
 drivers/xen/grant-table.c|8 +-
 include/xen/interface/elfnote.h  |   12 ++-
 include/xen/interface/hvm/hvm_vcpu.h |  143 +++
 include/xen/interface/xen.h  |   24 +++
 include/xen/xen.h|6 +
 19 files changed, 801 insertions(+), 199 deletions(-)
 create mode 100644 arch/x86/xen/xen-hvmlite.S
 create mode 100644 include/xen/interface/hvm/hvm_vcpu.h


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky]

Start HVMlite guest XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/Makefile  |1 +
 arch/x86/xen/enlighten.c   |   91 +-
 arch/x86/xen/xen-hvmlite.S |  158 
 include/xen/xen.h  |6 ++
 4 files changed, 255 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/xen/xen-hvmlite.S

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index e47e527..1d913d7 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_XEN_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
 obj-$(CONFIG_SWIOTLB_XEN)  += pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
+obj-$(CONFIG_XEN_PVHVM)+= xen-hvmlite.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2cf446a..2ed8b2b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -118,7 +118,8 @@ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
  */
 DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
 
-enum xen_domain_type xen_domain_type = XEN_NATIVE;
+enum xen_domain_type xen_domain_type
+   __attribute__((section(".data"))) = XEN_NATIVE;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
 unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START;
@@ -171,6 +172,17 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
+#ifdef CONFIG_XEN_PVHVM
+/*
+ * HVMlite variables. These need to live in data segment since they are
+ * initialized before startup_{32|64}, which clear .bss, are invoked.
+ */
+int xen_hvmlite __attribute__((section(".data"))) = 0;
+struct hvm_start_info hvmlite_start_info __attribute__((section(".data")));
+uint hvmlite_start_info_sz = sizeof(hvmlite_start_info);
+struct boot_params xen_hvmlite_boot_params __attribute__((section(".data")));
+#endif
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -1736,6 +1748,83 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
+#ifdef CONFIG_XEN_PVHVM
+static void __init hvmlite_bootparams(void)
+{
+   struct xen_memory_map memmap;
+   int i;
+
+   memset(_hvmlite_boot_params, 0, sizeof(xen_hvmlite_boot_params));
+
+   memmap.nr_entries = ARRAY_SIZE(xen_hvmlite_boot_params.e820_map);
+   set_xen_guest_handle(memmap.buffer, xen_hvmlite_boot_params.e820_map);
+   if (HYPERVISOR_memory_op(XENMEM_memory_map, )) {
+   xen_raw_console_write("XENMEM_memory_map failed\n");
+   BUG();
+   }
+
+   xen_hvmlite_boot_params.e820_map[memmap.nr_entries].addr =
+   ISA_START_ADDRESS;
+   xen_hvmlite_boot_params.e820_map[memmap.nr_entries].size =
+   ISA_END_ADDRESS - ISA_START_ADDRESS;
+   xen_hvmlite_boot_params.e820_map[memmap.nr_entries++].type =
+   E820_RESERVED;
+
+   sanitize_e820_map(xen_hvmlite_boot_params.e820_map,
+ ARRAY_SIZE(xen_hvmlite_boot_params.e820_map),
+ _entries);
+
+   xen_hvmlite_boot_params.e820_entries = memmap.nr_entries;
+   for (i = 0; i < xen_hvmlite_boot_params.e820_entries; i++)
+   e820_add_region(xen_hvmlite_boot_params.e820_map[i].addr,
+   xen_hvmlite_boot_params.e820_map[i].size,
+   xen_hvmlite_boot_params.e820_map[i].type);
+
+   xen_hvmlite_boot_params.hdr.cmd_line_ptr =
+   hvmlite_start_info.cmdline_paddr;
+
+   /* The first module is always ramdisk */
+   if (hvmlite_start_info.nr_modules) {
+   struct hvm_modlist_entry *modaddr =
+   __va(hvmlite_start_info.modlist_paddr);
+   xen_hvmlite_boot_params.hdr.ramdisk_image = modaddr->paddr;
+   xen_hvmlite_boot_params.hdr.ramdisk_size = modaddr->size;
+   }
+
+   /*
+* See Documentation/x86/boot.txt.
+*
+* Version 2.12 supports Xen entry point but we will use default x86/PC
+* environment (i.e. hardware_subarch 0).
+*/
+   xen_hvmlite_boot_params.hdr.version = 0x212;
+   xen_hvmlite_boot_params.hdr.type_of_loader = 9; /* Xen loader */
+}
+
+/*
+ * This routine (and those that it might call) should not use
+ * anything that lives in .bss since that segment will be cleared later
+ */
+void __init xen_prepare_hvmlite(void)
+{
+   u32 eax, ecx, edx, msr;
+   u64 pfn;
+
+   cpuid(xen_cpuid_base() + 2, , , , );
+   pfn = __pa(hypercall_page);
+   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+
+   pv_info.name = "Xen HVMlite";
+   xen_domain_type = XEN_HVM_DOMAIN;
+   xen_hvmlite = 1;
+
+   x86_init.oem.arch_setup = xen_init_kernel;
+   x86_init.oem.banner = xen_banner;
+
+   hvmlite_bootparams();
+}
+#endif
+
 void __ref xen_hvm_init_shared_info(void)
 {
   

[Xen-devel] [PATCH v1 03/12] xen/hvmlite: Import hvmlite-related Xen public interfaces

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 include/xen/interface/elfnote.h  |   12 +++-
 include/xen/interface/hvm/hvm_vcpu.h |  143 ++
 include/xen/interface/xen.h  |   24 ++
 3 files changed, 178 insertions(+), 1 deletions(-)
 create mode 100644 include/xen/interface/hvm/hvm_vcpu.h

diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index f90b034..9e9f9bf 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -193,9 +193,19 @@
 #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
 
 /*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. When requested to launch the
+ * guest kernel in a HVM container, Xen will use this entry point to
+ * launch the guest in 32bit protected mode with paging disabled.
+ * Ignored otherwise.
+ */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+
+/*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
 
 #endif /* __XEN_PUBLIC_ELFNOTE_H__ */
 
diff --git a/include/xen/interface/hvm/hvm_vcpu.h 
b/include/xen/interface/hvm/hvm_vcpu.h
new file mode 100644
index 000..32ca83e
--- /dev/null
+++ b/include/xen/interface/hvm/hvm_vcpu.h
@@ -0,0 +1,143 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2015, Roger Pau Monne 
+ */
+
+#ifndef __XEN_PUBLIC_HVM_HVM_VCPU_H__
+#define __XEN_PUBLIC_HVM_HVM_VCPU_H__
+
+#include "../xen.h"
+
+struct vcpu_hvm_x86_32 {
+uint32_t eax;
+uint32_t ecx;
+uint32_t edx;
+uint32_t ebx;
+uint32_t esp;
+uint32_t ebp;
+uint32_t esi;
+uint32_t edi;
+uint32_t eip;
+uint32_t eflags;
+
+uint32_t cr0;
+uint32_t cr3;
+uint32_t cr4;
+
+uint32_t pad1;
+
+/*
+ * EFER should only be used to set the NXE bit (if required)
+ * when starting a vCPU in 32bit mode with paging enabled or
+ * to set the LME/LMA bits in order to start the vCPU in
+ * compatibility mode.
+ */
+uint64_t efer;
+
+uint32_t cs_base;
+uint32_t ds_base;
+uint32_t ss_base;
+uint32_t es_base;
+uint32_t tr_base;
+uint32_t cs_limit;
+uint32_t ds_limit;
+uint32_t ss_limit;
+uint32_t es_limit;
+uint32_t tr_limit;
+uint16_t cs_ar;
+uint16_t ds_ar;
+uint16_t ss_ar;
+uint16_t es_ar;
+uint16_t tr_ar;
+
+uint16_t pad2[3];
+};
+
+/*
+ * The layout of the _ar fields of the segment registers is the
+ * following:
+ *
+ * Bits   [0,3]: type (bits 40-43).
+ * Bit4: s(descriptor type, bit 44).
+ * Bit[5,6]: dpl  (descriptor privilege level, bits 45-46).
+ * Bit7: p(segment-present, bit 47).
+ * Bit8: avl  (available for system software, bit 52).
+ * Bit9: l(64-bit code segment, bit 53).
+ * Bit   10: db   (meaning depends on the segment, bit 54).
+ * Bit   11: g(granularity, bit 55)
+ * Bits [12,15]: unused, must be blank.
+ *
+ * A more complete description of the meaning of this fields can be
+ * obtained from the Intel SDM, Volume 3, section 3.4.5.
+ */
+
+struct vcpu_hvm_x86_64 {
+uint64_t rax;
+uint64_t rcx;
+uint64_t rdx;
+uint64_t rbx;
+uint64_t rsp;
+uint64_t rbp;
+uint64_t rsi;
+uint64_t rdi;
+uint64_t rip;
+uint64_t rflags;
+
+uint64_t cr0;
+uint64_t cr3;
+uint64_t cr4;
+uint64_t efer;
+
+/*
+ * Using VCPU_HVM_MODE_64B implies that the vCPU is launched
+ * directly in long mode, so the cached parts of the segment
+ * registers get set to match that environment.
+ *
+ * If the user wants to launch the vCPU in compatibility mode
+ * the 32-bit structure should be used instead.
+ */
+};
+
+struct vcpu_hvm_context {
+#define VCPU_HVM_MODE_32B 0  /* 32bit fields of the structure will be used. */
+#define 

[Xen-devel] [PATCH v1 08/12] xen/hvmlite: Initialize context for secondary VCPUs

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/smp.c |   57 
 arch/x86/xen/smp.h |4 +++
 arch/x86/xen/xen-hvmlite.S |7 +
 3 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 5fc4afb..b265c4f 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -384,6 +385,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct 
*idle)
struct vcpu_guest_context *ctxt;
struct desc_struct *gdt;
unsigned long gdt_mfn;
+   void *ctxt_arg;
 
/* used to tell cpu_init() that it can proceed with initialization */
cpumask_set_cpu(cpu, cpu_callout_mask);
@@ -392,7 +394,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct 
*idle)
 
if (!xen_hvmlite) {
 
-   ctxt = kzalloc(sizeof(*ctxt), GFP_KERNEL);
+   ctxt_arg = ctxt = kzalloc(sizeof(*ctxt), GFP_KERNEL);
if (ctxt == NULL)
return -ENOMEM;
 
@@ -460,14 +462,59 @@ cpu_initialize_context(unsigned int cpu, struct 
task_struct *idle)
ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_gfn(swapper_pg_dir));
} else {
-   ctxt = NULL; /* To quiet down compiler */
-   BUG();
+#ifdef CONFIG_XEN_PVHVM
+   struct vcpu_hvm_context *hctxt;
+
+   ctxt_arg = hctxt = kzalloc(sizeof(*hctxt), GFP_KERNEL);
+   if (hctxt == NULL)
+   return -ENOMEM;
+
+#ifdef CONFIG_X86_64
+   hctxt->mode = VCPU_HVM_MODE_64B;
+   hctxt->cpu_regs.x86_64.rip =
+   (unsigned long)secondary_startup_64;
+   hctxt->cpu_regs.x86_64.rsp = stack_start;
+
+   hctxt->cpu_regs.x86_64.cr0 =
+   X86_CR0_PG | X86_CR0_WP | X86_CR0_PE;
+   hctxt->cpu_regs.x86_64.cr4 = X86_CR4_PAE;
+   hctxt->cpu_regs.x86_64.cr3 =
+   xen_pfn_to_cr3(virt_to_mfn(init_level4_pgt));
+   hctxt->cpu_regs.x86_64.efer = EFER_LME | EFER_NX;
+#else
+   hctxt->mode = VCPU_HVM_MODE_32B;
+   /*
+* startup_32_smp expects GDT loaded so we can't jump
+* there directly.
+*/
+   hctxt->cpu_regs.x86_32.eip =
+   (unsigned long)hvmlite_smp_32 - __START_KERNEL_map;
+
+   hctxt->cpu_regs.x86_32.cr0 = X86_CR0_PE;
+
+   hctxt->cpu_regs.x86_32.cs_base = 0;
+   hctxt->cpu_regs.x86_32.cs_limit = ~0u;
+   hctxt->cpu_regs.x86_32.cs_ar = 0xc9b;
+   hctxt->cpu_regs.x86_32.ds_base = 0;
+   hctxt->cpu_regs.x86_32.ds_limit = ~0u;
+   hctxt->cpu_regs.x86_32.ds_ar = 0xc93;
+   hctxt->cpu_regs.x86_32.es_base = 0;
+   hctxt->cpu_regs.x86_32.es_limit = ~0u;
+   hctxt->cpu_regs.x86_32.es_ar = 0xc93;
+   hctxt->cpu_regs.x86_32.ss_base = 0;
+   hctxt->cpu_regs.x86_32.ss_limit = ~0u;
+   hctxt->cpu_regs.x86_32.ss_ar = 0xc93;
+   hctxt->cpu_regs.x86_32.tr_base = 0;
+   hctxt->cpu_regs.x86_32.tr_limit = 0xff;
+   hctxt->cpu_regs.x86_32.tr_ar = 0x8b;
+#endif
+#endif
}
 
-   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
+   if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt_arg))
BUG();
 
-   kfree(ctxt);
+   kfree(ctxt_arg);
return 0;
 }
 
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 963d62a..b4a833c 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -8,6 +8,10 @@ extern void xen_send_IPI_allbutself(int vector);
 extern void xen_send_IPI_all(int vector);
 extern void xen_send_IPI_self(int vector);
 
+#ifdef CONFIG_X86_32
+extern void hvmlite_smp_32(void);
+#endif
+
 #ifdef CONFIG_XEN_PVH
 extern void xen_pvh_early_cpu_init(int cpu, bool entry);
 #else
diff --git a/arch/x86/xen/xen-hvmlite.S b/arch/x86/xen/xen-hvmlite.S
index 90f03d0..8d6a642 100644
--- a/arch/x86/xen/xen-hvmlite.S
+++ b/arch/x86/xen/xen-hvmlite.S
@@ -134,6 +134,13 @@ ENTRY(hvmlite_start_xen)
ljmp$0x10, $_pa(startup_32)
 #endif
 
+#ifdef CONFIG_X86_32
+ENTRY(hvmlite_smp_32)
+mov $_pa(boot_gdt_descr), %eax
+lgdt (%eax)
+jmp startup_32_smp
+#endif
+
.data
 gdt:
.word   gdt_end - gdt
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 10/12] xen/hvmlite: Use x86's default timer init for HVMlite guests

[Boris Ostrovsky]

xen_timer_init() will be called from apic_bsp_setup().

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/time.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..93745e7 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -439,7 +439,10 @@ void __init xen_init_time_ops(void)
 {
pv_time_ops = xen_time_ops;
 
-   x86_init.timers.timer_init = xen_time_init;
+   if (!xen_hvmlite)
+   x86_init.timers.timer_init = xen_time_init;
+   else
+   x86_init.timers.timer_init = x86_init_noop;
x86_init.timers.setup_percpu_clockev = x86_init_noop;
x86_cpuinit.setup_percpu_clockev = x86_init_noop;
 
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-jessie test] 38684: trouble: broken/pass

[Platform Team regression test user]

flight 38684 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38684/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-jessie-netboot-pygrub 3 host-install(3) broken REGR. vs. 
38641

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass

baseline version:
 flight   38641

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  broken  



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

[Boris Ostrovsky]

HVMlite guests (to be introduced in subsequent patches) share most
of the kernel initialization code with PV(H).

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/enlighten.c |  225 --
 1 files changed, 119 insertions(+), 106 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d09e4c9..2cf446a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1505,19 +1505,14 @@ static void __init xen_pvh_early_guest_init(void)
 }
 #endif/* CONFIG_XEN_PVH */
 
-/* First C function to be called on Xen boot */
-asmlinkage __visible void __init xen_start_kernel(void)
+
+static void __init xen_init_kernel(void)
 {
struct physdev_set_iopl set_iopl;
unsigned long initrd_start = 0;
u64 pat;
int rc;
 
-   if (!xen_start_info)
-   return;
-
-   xen_domain_type = XEN_PV_DOMAIN;
-
xen_setup_features();
 #ifdef CONFIG_XEN_PVH
xen_pvh_early_guest_init();
@@ -1529,48 +1524,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
if (xen_initial_domain())
pv_info.features |= PV_SUPPORTED_RTC;
pv_init_ops = xen_init_ops;
-   if (!xen_pvh_domain()) {
-   pv_cpu_ops = xen_cpu_ops;
-
-   x86_platform.get_nmi_reason = xen_get_nmi_reason;
-   }
-
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
-   else
-   x86_init.resources.memory_setup = xen_memory_setup;
-   x86_init.oem.arch_setup = xen_arch_setup;
-   x86_init.oem.banner = xen_banner;
 
xen_init_time_ops();
 
-   /*
-* Set up some pagetable state before starting to set any ptes.
-*/
-
-   xen_init_mmu_ops();
-
-   /* Prevent unwanted bits from being set in PTEs. */
-   __supported_pte_mask &= ~_PAGE_GLOBAL;
-
-   /*
-* Prevent page tables from being allocated in highmem, even
-* if CONFIG_HIGHPTE is enabled.
-*/
-   __userpte_alloc_gfp &= ~__GFP_HIGHMEM;
-
-   /* Work out if we support NX */
-   x86_configure_nx();
-
-   /* Get mfn list */
-   xen_build_dynamic_phys_to_machine();
-
-   /*
-* Set up kernel GDT and segment registers, mainly so that
-* -fstack-protector code can be executed.
-*/
-   xen_setup_gdt(0);
-
xen_init_irq_ops();
xen_init_cpuid_mask();
 
@@ -1580,21 +1536,8 @@ asmlinkage __visible void __init xen_start_kernel(void)
 */
xen_init_apic();
 #endif
-
-   if (xen_feature(XENFEAT_mmu_pt_update_preserve_ad)) {
-   pv_mmu_ops.ptep_modify_prot_start = xen_ptep_modify_prot_start;
-   pv_mmu_ops.ptep_modify_prot_commit = 
xen_ptep_modify_prot_commit;
-   }
-
machine_ops = xen_machine_ops;
 
-   /*
-* The only reliable way to retain the initial address of the
-* percpu gdt_page is to remember it here, so we can go and
-* mark it RW later, when the initial percpu area is freed.
-*/
-   xen_initial_gdt = _cpu(gdt_page, 0);
-
xen_smp_init();
 
 #ifdef CONFIG_ACPI_NUMA
@@ -1609,66 +1552,126 @@ asmlinkage __visible void __init xen_start_kernel(void)
   possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
 
-   local_irq_disable();
-   early_boot_irqs_disabled = true;
+   if (!xen_hvm_domain()) {
+   if (!xen_pvh_domain()) {
+   pv_cpu_ops = xen_cpu_ops;
 
-   xen_raw_console_write("mapping kernel into physical memory\n");
-   xen_setup_kernel_pagetable((pgd_t *)xen_start_info->pt_base,
-  xen_start_info->nr_pages);
-   xen_reserve_special_pages();
+   x86_platform.get_nmi_reason = xen_get_nmi_reason;
+   }
 
-   /*
-* Modify the cache mode translation tables to match Xen's PAT
-* configuration.
-*/
-   rdmsrl(MSR_IA32_CR_PAT, pat);
-   pat_init_cache_modes(pat);
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   x86_init.resources.memory_setup =
+   xen_auto_xlated_memory_setup;
+   else
+   x86_init.resources.memory_setup = xen_memory_setup;
+   x86_init.oem.arch_setup = xen_arch_setup;
+   x86_init.oem.banner = xen_banner;
 
-   /* keep using Xen gdt for now; no urgent need to change it */
+   /*
+* Set up some pagetable state before starting to set any ptes.
+*/
 
-#ifdef CONFIG_X86_32
-   pv_info.kernel_rpl = 1;
-   if (xen_feature(XENFEAT_supervisor_mode_kernel))
-   pv_info.kernel_rpl = 0;
-#else
-   pv_info.kernel_rpl = 0;
-#endif
-   /* set the limit of our 

[Xen-devel] [PATCH v1 11/12] xen/hvmlite: Boot secondary CPUs

[Boris Ostrovsky]

HVMlite secondary VCPUs use baremetal bringup path (i.e. native_*
smp_ops) but need to do some preparation in PV code.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/enlighten.c |2 +
 arch/x86/xen/pmu.c   |4 +-
 arch/x86/xen/smp.c   |   60 +-
 3 files changed, 47 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2ed8b2b..850ce66 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1937,6 +1937,8 @@ static void __init xen_hvm_guest_init(void)
xen_have_vector_callback = 1;
xen_hvm_smp_init();
register_cpu_notifier(_hvm_cpu_notifier);
+   if (xen_hvmlite)
+   smp_found_config = 1;
xen_unplug_emulated_devices();
x86_init.irqs.intr_init = xen_init_IRQ;
xen_hvm_init_time_ops();
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 724a087..7bc209b 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -518,7 +518,7 @@ void xen_pmu_init(int cpu)
 
BUILD_BUG_ON(sizeof(struct xen_pmu_data) > PAGE_SIZE);
 
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_hvmlite)
return;
 
xenpmu_data = (struct xen_pmu_data *)get_zeroed_page(GFP_KERNEL);
@@ -556,7 +556,7 @@ void xen_pmu_finish(int cpu)
 {
struct xen_pmu_params xp;
 
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_hvmlite)
return;
 
xp.vcpu = cpu;
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index fb085ef..fbad829 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -348,26 +348,31 @@ static void __init xen_smp_prepare_cpus(unsigned int 
max_cpus)
}
xen_init_lock_cpu(0);
 
-   smp_store_boot_cpu_info();
-   cpu_data(0).x86_max_cores = 1;
+   if (!xen_hvmlite) {
+   smp_store_boot_cpu_info();
+   cpu_data(0).x86_max_cores = 1;
+
+   for_each_possible_cpu(i) {
+   zalloc_cpumask_var(_cpu(cpu_sibling_map, i),
+  GFP_KERNEL);
+   zalloc_cpumask_var(_cpu(cpu_core_map, i),
+  GFP_KERNEL);
+   zalloc_cpumask_var(_cpu(cpu_llc_shared_map, i),
+  GFP_KERNEL);
+   }
+   set_cpu_sibling_map(0);
 
-   for_each_possible_cpu(i) {
-   zalloc_cpumask_var(_cpu(cpu_sibling_map, i), GFP_KERNEL);
-   zalloc_cpumask_var(_cpu(cpu_core_map, i), GFP_KERNEL);
-   zalloc_cpumask_var(_cpu(cpu_llc_shared_map, i), GFP_KERNEL);
+   if (!alloc_cpumask_var(_cpu_initialized_map, GFP_KERNEL))
+   panic("could not allocate xen_cpu_initialized_map\n");
+
+   cpumask_copy(xen_cpu_initialized_map, cpumask_of(0));
}
-   set_cpu_sibling_map(0);
 
xen_pmu_init(0);
 
if (xen_smp_intr_init(0))
BUG();
 
-   if (!alloc_cpumask_var(_cpu_initialized_map, GFP_KERNEL))
-   panic("could not allocate xen_cpu_initialized_map\n");
-
-   cpumask_copy(xen_cpu_initialized_map, cpumask_of(0));
-
/* Restrict the possible_map according to max_cpus. */
while ((num_possible_cpus() > 1) && (num_possible_cpus() > max_cpus)) {
for (cpu = nr_cpu_ids - 1; !cpu_possible(cpu); cpu--)
@@ -375,8 +380,11 @@ static void __init xen_smp_prepare_cpus(unsigned int 
max_cpus)
set_cpu_possible(cpu, false);
}
 
-   for_each_possible_cpu(cpu)
+   for_each_possible_cpu(cpu) {
set_cpu_present(cpu, true);
+   if (xen_hvmlite)
+   physid_set(cpu, phys_cpu_present_map);
+   }
 }
 
 static int
@@ -810,10 +818,15 @@ void __init xen_smp_init(void)
 
 static void __init xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
 {
+   if (xen_hvmlite)
+   xen_smp_prepare_cpus(max_cpus);
+
native_smp_prepare_cpus(max_cpus);
-   WARN_ON(xen_smp_intr_init(0));
 
-   xen_init_lock_cpu(0);
+   if (!xen_hvmlite) {
+   WARN_ON(xen_smp_intr_init(0));
+   xen_init_lock_cpu(0);
+   }
 }
 
 static int xen_hvm_cpu_up(unsigned int cpu, struct task_struct *tidle)
@@ -836,8 +849,21 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct 
task_struct *tidle)
*/
rc = xen_smp_intr_init(cpu);
WARN_ON(rc);
-   if (!rc)
-   rc =  native_cpu_up(cpu, tidle);
+
+   if (xen_hvmlite) {
+   rc = cpu_initialize_context(cpu, tidle);
+   if (rc) {
+   xen_smp_intr_free(cpu);
+   return rc;
+   }
+   xen_pmu_init(cpu);
+   }
+
+   if (!rc) {
+   rc = native_cpu_up(cpu, tidle);
+   if (rc && 

[Xen-devel] [PATCH v1 06/12] xen/hvmlite: Initialize PCI

[Boris Ostrovsky]

HVMlite guests need PCI frontend and always have PV devices

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/pci/xen.c |2 +-
 arch/x86/xen/platform-pci-unplug.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index ff31ab4..d847f7d 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -405,7 +405,7 @@ static void xen_teardown_msi_irq(unsigned int irq)
 
 int __init pci_xen_init(void)
 {
-   if (!xen_pv_domain() || xen_initial_domain())
+   if ((!xen_pv_domain() && !xen_hvmlite) || xen_initial_domain())
return -ENODEV;
 
printk(KERN_INFO "PCI: setting up Xen PCI frontend stub\n");
diff --git a/arch/x86/xen/platform-pci-unplug.c 
b/arch/x86/xen/platform-pci-unplug.c
index 9586ff3..802ec90 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -73,8 +73,8 @@ bool xen_has_pv_devices(void)
if (!xen_domain())
return false;
 
-   /* PV domains always have them. */
-   if (xen_pv_domain())
+   /* PV and HVMlite domains always have them. */
+   if (xen_pv_domain() || xen_hvmlite)
return true;
 
/* And user has xen_platform_pci=0 set in guest config as
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 05/12] xen/hvmlite: Allow HVMlite guests delay initializing grant table

[Boris Ostrovsky]

.. just like we currently do for PVH guests

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/grant-table.c |4 ++--
 drivers/xen/grant-table.c  |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..40ad9c2 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -110,7 +110,7 @@ int arch_gnttab_init(unsigned long nr_shared)
return arch_gnttab_valloc(_shared_vm_area, nr_shared);
 }
 
-#ifdef CONFIG_XEN_PVH
+#ifdef CONFIG_XEN_PVHVM
 #include 
 #include 
 #include 
@@ -164,7 +164,7 @@ static int __init xlated_setup_gnttab_pages(void)
 
 static int __init xen_pvh_gnttab_setup(void)
 {
-   if (!xen_pvh_domain())
+   if (!xen_pvh_domain() && !xen_hvmlite)
return -ENODEV;
 
return xlated_setup_gnttab_pages();
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index effbaf9..8c6c0cf 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1147,13 +1147,13 @@ EXPORT_SYMBOL_GPL(gnttab_init);
 
 static int __gnttab_init(void)
 {
+   if (!xen_domain())
+   return -ENODEV;
+
/* Delay grant-table initialization in the PV on HVM case */
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_hvmlite)
return 0;
 
-   if (!xen_pv_domain())
-   return -ENODEV;
-
return gnttab_init();
 }
 /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 12/12] xen/hvmlite: Enable CPU on-/offlining

[Boris Ostrovsky]

When offlining, we should properly clean up interrupts and wait
until hypervisor declares VCPU as down before cleaning up.

After VCPU that was previously offlined is brought back to life
we want to jump back to bare-metal entry points. It's a simple
jump on 64-bit but requires minor tweaking for 32-bit case.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/smp.c |   35 +--
 arch/x86/xen/xen-hvmlite.S |8 
 2 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index fbad829..7e96a23 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -143,7 +143,7 @@ static void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_callfuncsingle_irq, cpu).name);
per_cpu(xen_callfuncsingle_irq, cpu).name = NULL;
}
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_hvmlite)
return;
 
if (per_cpu(xen_irq_work, cpu).irq >= 0) {
@@ -585,7 +585,8 @@ static int xen_cpu_disable(void)
 
 static void xen_cpu_die(unsigned int cpu)
 {
-   while (xen_pv_domain() && HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL)) {
+   while ((xen_pv_domain() || xen_hvmlite) &&
+  HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL)) {
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ/10);
}
@@ -602,14 +603,28 @@ static void xen_play_dead(void) /* used only with 
HOTPLUG_CPU */
 {
play_dead_common();
HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
-   cpu_bringup();
-   /*
-* commit 4b0c0f294 (tick: Cleanup NOHZ per cpu data on cpu down)
-* clears certain data that the cpu_idle loop (which called us
-* and that we return from) expects. The only way to get that
-* data back is to call:
-*/
-   tick_nohz_idle_enter();
+
+   if (!xen_hvm_domain()) {
+   cpu_bringup();
+   /*
+* commit 4b0c0f294 (tick: Cleanup NOHZ per cpu data on cpu
+* down) clears certain data that the cpu_idle loop (which
+* called us and that we return from) expects. The only way to
+* get that data back is to call:
+*/
+   tick_nohz_idle_enter();
+   } else {
+   /*
+* For 64-bit we can jump directly to SMP entry point but for
+* 32-bit we need to disable paging and load boot GDT (just
+* like in cpu_initialize_context()).
+*/
+#ifdef CONFIG_X86_64
+   asm("jmp secondary_startup_64");
+#else
+   asm("jmp hvmlite_smp_32_hp");
+#endif
+   }
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */
diff --git a/arch/x86/xen/xen-hvmlite.S b/arch/x86/xen/xen-hvmlite.S
index 8d6a642..4edd6ef 100644
--- a/arch/x86/xen/xen-hvmlite.S
+++ b/arch/x86/xen/xen-hvmlite.S
@@ -135,6 +135,14 @@ ENTRY(hvmlite_start_xen)
 #endif
 
 #ifdef CONFIG_X86_32
+ENTRY(hvmlite_smp_32_hp)
+   movl $_pa(initial_page_table), %eax
+   movl %eax, %cr3
+   ljmp $__KERNEL_CS,$_pa(5f)
+5:
+   movl $X86_CR0_PE, %eax
+   movl %eax, %cr0
+
 ENTRY(hvmlite_smp_32)
 mov $_pa(boot_gdt_descr), %eax
 lgdt (%eax)
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

[Luis R. Rodriguez]

On Fri, Jan 22, 2016 at 11:06 AM, H. Peter Anvin  wrote:
> On 01/22/2016 05:44 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>
>>> Something that confuses me is that gcc seems to give these sections the
>>> "aw" attributes which makes as complain.  This might be a gcc bug.
>>
>> Workaround: use an (possibly empty) intializer:
>>
>> struct foo {int i;};
>> const struct foo
>> __attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};
>>
>
> And indeed that works.  Awesome!  Much better than having to do an
> assembly hack.

BTW before we set these in stone given that subarch (lguest, Xen, PC)
really does provide a split in run time code we *know* we could
technically free code for subarchs not needed. I don't expect this to
happen now, but its possibility to do later seems worthy for us to
consider on architecture here on the way we define the linker tables.
As I have it linker tables are associated associated with a struct
(which hpa asked to enable anyone to peg *anything* not just structs),
these structs then have a priority which uses the linker later to sort
things for us, and it also has a subarch bitmask which tells us the
supported subarchs.

Should it be possible to resuse free_init_pages() and/or
free_reserved_area() only for routines (members in the array in this
case of a struct of fns) that don't meet our subarch once we're done
iterating over the routies and know we can discard things we know we
can drop? Through a cursory glance, *I think* its possible as-is, we
would just need easy access to the respective start and end addresses
and I guess there lies the challenge. Question is, is would that be
clean enough for us? Or are there other things you can think of that
perhaps might make this prospect cleaner later to add?

I figure better ask now for architectural purposes than later after merged.

 Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] disk=['file://..xvda'] not working for boot disks anymore?

[Konrad Rzeszutek Wilk]

On Fri, Jan 22, 2016 at 03:59:09PM -0500, Boris Ostrovsky wrote:
> On 01/22/2016 03:54 PM, Konrad Rzeszutek Wilk wrote:
> >Hey,
> >
> >This parameter
> >disk = 
> >['file:/root/sol.dd,xvda,w','file:/root/sol-11_2_15_5_1-text-x86.iso,xvdb:cdrom,r']
> >
> >works with qemu-traditional, but if I try with qemu-xen it
> >does not find the disk:
> >
> >(d15) [2016-01-22 20:50:03] enter handle_19:
> >(d15) [2016-01-22 20:50:03]   NULL
> >(d15) [2016-01-22 20:50:03] Booting from ROM...
> >(d15) [2016-01-22 20:50:03] Booting from c980:0361
> >
> >while with qemu-traditional:
> >
> >(d14) [2016-01-22 20:43:15] Bochs BIOS - build: 06/23/99
> >(d14) [2016-01-22 20:43:15] $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> >(d14) [2016-01-22 20:43:15] Options: apmbios pcibios eltorito PMM
> >(d14) [2016-01-22 20:43:15]
> >(d14) [2016-01-22 20:43:15] ata0 master: QEMU HARDDISK ATA-7 Hard-Disk 
> >(12288 MBytes)
> >(d14) [2016-01-22 20:43:15]
> >(d14) [2016-01-22 20:43:15]
> >(d14) [2016-01-22 20:43:15]
> >(d14) [2016-01-22 20:43:15] Press F12 for boot menu.
> >(d14) [2016-01-22 20:43:15]
> >(d14) [2016-01-22 20:43:15] Booting from Hard Disk...
> >
> >It does work with Xen 4.4, but that is ancient. I hadn't yet
> >tried Xen 4.5 nor 4.6.
> >
> >I am hoping one of you knows exactly which commit might have made
> >this change?
> >
> >Note that the name is 'xvda', not 'hda'. Thanks!
> 
> Probably this one:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01529.html

You are good.

That was it.

CC-ing Anthony - are you OK if the patch was reverted?

> 
> 
> -boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

[H. Peter Anvin]

On 01/22/2016 05:44 AM, Michael Matz wrote:
> Hi,
> 
> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
> 
>> Something that confuses me is that gcc seems to give these sections the 
>> "aw" attributes which makes as complain.  This might be a gcc bug.
> 
> Workaround: use an (possibly empty) intializer:
> 
> struct foo {int i;};
> const struct foo
> __attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};
> 

And indeed that works.  Awesome!  Much better than having to do an
assembly hack.

-hpa



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.6-testing baseline-only test] 38681: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38681 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken REGR. 
vs. 38674
 test-amd64-i386-freebsd10-amd64  3 host-install(3)  broken REGR. vs. 38674
 test-amd64-amd64-xl-multivcpu  3 host-install(3)broken REGR. vs. 38674
 test-amd64-i386-rumpuserxen-i386  3 host-install(3) broken REGR. vs. 38674
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 38674
 test-amd64-i386-xl-qemut-win7-amd64  3 host-install(3)  broken REGR. vs. 38674
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 38674
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)broken REGR. vs. 38674
 test-armhf-armhf-xl-midway   16 guest-start.2 fail REGR. vs. 38674
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 38674

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   3 host-install(3) broken REGR. vs. 38674
 test-amd64-amd64-libvirt  3 host-install(3) broken REGR. vs. 38674
 test-amd64-amd64-rumpuserxen-amd64  3 host-install(3)broken like 38674
 test-amd64-amd64-xl-pvh-amd   3 host-install(3)  broken like 38674
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)broken like 38674
 test-amd64-amd64-qemuu-nested-amd  3 host-install(3) broken like 38674
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)broken like 38674
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3) broken like 38674
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 38674
 test-amd64-amd64-xl 19 guest-start/debian.repeat fail blocked in 38674
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 38674
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 38674

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1fd615aa0108490ffc558d27627f509183cbfdaf
baseline version:
 xen  6150df9f3f99ecbcbd9917002186d1d895b5602e

Last test of basis38674  2016-01-20 13:21:50 Z2 days
Testing same since38681  2016-01-21 17:27:19 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Feng Wu 

[Xen-devel] [xen-unstable-smoke test] 78820: tolerable all pass - PUSHED

[osstest service owner]

flight 78820 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78820/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2e46e3f2539d026594ec1618e7df2c2bc8785b42
baseline version:
 xen  5757c7067ee1cd0f520142e4f3aa86e8e5b010ba

Last test of basis78812  2016-01-22 15:01:27 Z0 days
Testing same since78820  2016-01-22 17:09:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Malcolm Crossley 
  Roger Pau Monné 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2e46e3f2539d026594ec1618e7df2c2bc8785b42
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2e46e3f2539d026594ec1618e7df2c2bc8785b42
+ branch=xen-unstable-smoke
+ revision=2e46e3f2539d026594ec1618e7df2c2bc8785b42
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x2e46e3f2539d026594ec1618e7df2c2bc8785b42 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} 

Re: [Xen-devel] xen-netfront crash when detaching network while some network activity

[Marek Marczykowski-Górecki]

On Thu, Jan 21, 2016 at 12:30:48PM +, Joao Martins wrote:
> 
> 
> On 01/20/2016 09:59 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Dec 01, 2015 at 11:32:58PM +0100, Marek Marczykowski-Górecki wrote:
> >> On Tue, Dec 01, 2015 at 05:00:42PM -0500, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Nov 17, 2015 at 03:45:15AM +0100, Marek Marczykowski-Górecki 
> >>> wrote:
>  On Wed, Oct 21, 2015 at 08:57:34PM +0200, Marek Marczykowski-Górecki 
>  wrote:
> > On Wed, May 27, 2015 at 12:03:12AM +0200, Marek Marczykowski-Górecki 
> > wrote:
> >> On Tue, May 26, 2015 at 11:56:00AM +0100, David Vrabel wrote:
> >>> On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
>  Hi all,
> 
>  I'm experiencing xen-netfront crash when doing xl network-detach 
>  while
>  some network activity is going on at the same time. It happens only 
>  when
>  domU has more than one vcpu. Not sure if this matters, but the 
>  backend
>  is in another domU (not dom0). I'm using Xen 4.2.2. It happens on 
>  kernel
>  3.9.4 and 4.1-rc1 as well.
> 
>  Steps to reproduce:
>  1. Start the domU with some network interface
>  2. Call there 'ping -f some-IP'
>  3. Call 'xl network-detach NAME 0'
> >>>
> >>> Do you see this all the time or just on occassions?
> >>
> >> Using above procedure - all the time.
> >>
> >>> I tried to reproduce it and couldn't see it. Is your VM an PV or HVM?
> >>
> >> PV, started by libvirt. This may have something to do, the problem didn't
> >> existed on older Xen (4.1) and started by xl. I'm not sure about kernel
> >> version there, but I think I've tried there 3.18 too, which has this
> >> problem.
> >>
> >> But I don't see anything special in domU config file (neither backend
> >> nor frontend) - it may be some libvirt default. If that's really the
> >> cause. Can I (and how) get any useful information about that?
> > 
> > libvirt naturally does some libxl calls, and they may be different.
> > 
> > Any chance you could give me an idea of:
> >  - What commands you use in libvirt?
> >  - Do you use a bond or bridge?
> >  - What version of libvirt you are using?
> > 
> > Thanks!
> > CC-ing Joao just in case he has seen this.
> >>
> Hm, So far I couldn't reproduce the issue with upstream Xen/linux/libvirt, 
> using
> both libvirt or plain xl (both on a bridge setup) and also irrespective of the
> both load and direction of traffic (be it a ping flood, pktgen with min.
> sized packets or iperf).

I've ran the test again, on vanilla 4.4 and collected some info:
 - xenstore dump of frontend (xs-frontend-before.txt)
 - xenstore dump of backend (xs-backend-before.txt)
 - kernel messages (console output) (console.log)
 - kernel config (config-4.4)
 - libvirt config of that domain (netdebug.conf)

Versions:
 - kernel 4.4 (frontend), 4.2.8 (backend)
 - libvirt 1.2.20
 - xen 4.6.0

In backend domain there is no bridge or anything like that - only
routing. The same in frontend - nothing fancy - just IP set on eth0
there.

Steps to reproduce were the same:
 - start frontend domain (virsh create ...)
 - call ping -f
 - xl network-detach NAME 0

Note that the crash doesn't happen with attached patch applied (as noted
in mail on Oct 21), but I have no idea whether is it a proper fix, or
just prevents the crash by a coincidence.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC  
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.0-1.pvops.qubes.x86_64 (user@devel-3rdparty) 
(gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) ) #20 SMP Fri Jan 22 
00:39:29 CET 2016
[0.00] Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 
rd_NO_PLYMOUTH 3 rd.break
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] ACPI in unprivileged domain disabled
[0.00] Released 0 page(s)
[0.00] e820: BIOS-provided physical RAM map:
[0.00] Xen: [mem 0x-0x0009] usable
[0.00] Xen: [mem 0x000a-0x000f] reserved
[0.00] Xen: [mem 0x0010-0xf9ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] DMI not present or invalid.
[0.00] Hypervisor detected: Xen
[0.00] e820: last_pfn = 0xfa000 max_arch_pfn = 0x4
[0.00] MTRR: Disabled
[0.00] RAMDISK: [mem 0x0203-0x027c6fff]
[0.00] NUMA turned off
[0.00] Faking a node at [mem 0x-0xf9ff]
[0.00] NODE_DATA(0) allocated [mem 

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Andrew Cooper]

On 22/01/2016 08:57, Håkon Alstadheim wrote:
> Den 17. jan. 2016 16:25, skrev Andrew Cooper:
>> On 17/01/16 15:16, Andrew Cooper wrote:
> This isn't the first time we have seen this on Haswell processors. Do
> you have microcode loading set up?
>
> ~Andrew
>
 Still happening with kernel-genkernel-x86_64-4.1.15-gentoo and updated
 cpu microcode, using microcode from 20151106.
> ...
 Actually, this will be more useful:

 diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
 index 1228568..4e75b03 100644
 --- a/xen/arch/x86/irq.c
 +++ b/xen/arch/x86/irq.c
 @@ -1165,6 +1165,15 @@ static void __do_IRQ_guest(int irq)
  if ( action->ack_type == ACKTYPE_EOI )
  {
  sp = pending_eoi_sp(peoi);
 +if ( unlikely(!((sp == 0) || (peoi[sp-1].vector < vector))) )
 +{
 +int p;
 +
 +printk("** sp %d, irq %d, vec %#x\n", sp, irq, vector);
 +for ( p = sp; p > 0; --p )
 +printk("**peoi[%d] = {%d, %#x, %d}\n",
 +   p-1, peoi[p-1].irq, peoi[p-1].vector,
 peoi[p-1].ready);
 +}
  ASSERT((sp == 0) || (peoi[sp-1].vector < vector));
  ASSERT(sp < (NR_DYNAMIC_VECTORS-1));
  peoi[sp].irq = irq;



> Got one again. dom5 is my desktop, dom1 is my
> mail-server/router/firewall. (planning to split that up ... ) . Is there
> any additional info that would be useful?
>
> Running now with gentoo xen 4.6.0-r8 and xen-tools 4.6.0-r7. dom0 kernel
> is gentoo-sources-4.1.15-r1 , and the above patch.
>
> I tried running with maxcpus=6 for a while, but I had to disable some
> services to get that running. So, when nothing happened for a while I
> re-enabled all my cores (two cpus, 12 cores, 24 threads). I was running
> with two cpu-pools, one for each cpu. I have not re-enabled that.

grant_table.c:1491:d1v3 Expanding dom (1) grant table from (12) to (13)
frames.
** sp 1, irq 107, vec 0x3b
**peoi[0] = {107, 0x3b, 0}
Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1172
[ Xen-4.6.0  x86_64  debug=y  Tainted:C ]

Xen call trace:
   [] do_IRQ+0x451/0x6ea
   [] common_interrupt+0x62/0x70
   [] mwait_idle+0x2cb/0x315
   [] idle_loop+0x51/0x6b

So we have been interrupted with an interrupt we already believe to be
pending.  I wonder if there is an erratum to do with going to sleep with
a pending interrupt.

I will see about extending the debugging patch to stash the IIR/ISR
before going to sleep.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 28/31] xen/x86: Context switch all levelling state in context_switch()

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -300,6 +300,9 @@ static void __init noinline amd_init_levelling(void)
>   cpumask_defaults._6c &= (~0ULL << 32);
>   cpumask_defaults._6c |= ecx;
>   }
> +
> +if (levelling_caps)
> +ctxt_switch_levelling = amd_ctxt_switch_levelling;
>  }

Indentation.

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -86,6 +86,13 @@ static const struct cpu_dev default_cpu = {
>  };
>  static const struct cpu_dev *this_cpu = _cpu;
>  
> +void default_ctxt_switch_levelling(const struct domain *nextd)

static

> +{
> +/* Nop */
> +}
> +void (*ctxt_switch_levelling)(const struct domain *nextd) __read_mostly =
> +default_ctxt_switch_levelling;

While current and past gcc may accept (and honor) this placement of
the __read_mostly annotation, I think it is wrong from a strict language
syntax pov. Imo it instead ought to be

void (*__read_mostly ctxt_switch_levelling)(const struct domain *nextd) =

Also - indentation again.

> @@ -145,6 +145,13 @@ void intel_ctxt_switch_levelling(const struct domain 
> *nextd)
>   struct cpumasks *these_masks = _cpu(cpumasks);
>   const struct cpumasks *masks = _defaults;
>  
> + if (cpu_has_cpuid_faulting) {
> + set_cpuid_faulting(nextd && is_pv_domain(nextd) &&
> +!is_control_domain(nextd) &&
> +!is_hardware_domain(nextd));
> + return;
> + }

Considering that you don't even probe the masking MSRs, this seems
inconsistent with your "always level the entire system" choice. As said
I'm opposed to that (i.e. the code here is fine), but at the very least
things ought to be consistent.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 29/31] x86/pv: Provide custom cpumasks for PV domains

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -203,7 +203,9 @@ static void __init noinline probe_masking_msrs(void)
>  void amd_ctxt_switch_levelling(const struct domain *nextd)
>  {
>   struct cpumasks *these_masks = _cpu(cpumasks);
> - const struct cpumasks *masks = _defaults;
> + const struct cpumasks *masks =
> +(nextd && is_pv_domain(nextd) && nextd->arch.pv_domain.masks)
> +? nextd->arch.pv_domain.masks : _defaults;

Can nextd really ever be NULL here?

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -578,6 +578,12 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  goto fail;
>  clear_page(d->arch.pv_domain.gdt_ldt_l1tab);
>  
> +d->arch.pv_domain.masks = xmalloc(struct cpumasks);
> +if ( !d->arch.pv_domain.masks )
> +goto fail;
> +memcpy(d->arch.pv_domain.masks, _defaults,
> +   sizeof(*d->arch.pv_domain.masks));

Structure assignment, to make the thing type safe?

Also there's a change missing to the cleanup code after the "fail"
label.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 30/31] x86/domctl: Update PV domain cpumasks when setting cpuid policy

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:

> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -77,6 +77,74 @@ static void update_domain_cpuid_info(struct domain *d,
>  d->arch.x86_model = (ctl->eax >> 4) & 0xf;
>  if ( d->arch.x86 >= 0x6 )
>  d->arch.x86_model |= (ctl->eax >> 12) & 0xf0;
> +
> +if ( is_pv_domain(d) )
> +{
> +uint64_t mask = cpumask_defaults._1cd;
> +
> +if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +mask &= ((uint64_t)ctl->edx << 32) | ctl->ecx;
> +else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
> +mask &= ((uint64_t)ctl->ecx << 32) | ctl->edx;

I'd prefer switch() to be used in cases like this, but anyway
Reviewed-by: Jan Beulich 
notwithstanding possible mechanical adjustments to the patch due
to changes to earlier ones.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/6] libxl: introduce LIBXL_VGA_INTERFACE_TYPE_UNKNOWN

[Ian Campbell]

On Thu, 2016-01-21 at 17:51 +0100, Roger Pau Monne wrote:
> And use it as the default value for the VGA kind. This allows libxl to
> set
> it to the default value later on when the domain type is known. For HVM
> guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
> HVMlite the default value is LIBXL_VGA_INTERFACE_TYPE_NONE.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Ian Campbell 

There a behavioural change from an xl users PoV, WRT the dmlite/qemu=none,
which warrants a documentation change I think. That might need to be part
of a bigger overhaul of the xl manpages to incorporate discussion of
pvh/dmlite though? and in any case can come in a followup.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services

[Stefano Stabellini]

On Fri, 22 Jan 2016, Shannon Zhao wrote:
> On 2016/1/19 1:03, Stefano Stabellini wrote:
> > On Fri, 15 Jan 2016, Shannon Zhao wrote:
> >> > From: Shannon Zhao 
> >> > 
> >> > When running on Xen hypervisor, runtime services are supported through
> >> > hypercall. So call Xen specific function to initialize runtime services.
> >> > 
> >> > Signed-off-by: Shannon Zhao 
> > Thanks Shannon, much much better!  Just a couple of questions.
> > 
> > 
> >> >  arch/arm/xen/enlighten.c |  5 +
> >> >  arch/arm64/xen/Makefile  |  1 +
> >> >  arch/arm64/xen/efi.c | 36 
> >> >  drivers/xen/Kconfig  |  2 +-
> >> >  include/xen/xen-ops.h|  1 +
> >> >  5 files changed, 44 insertions(+), 1 deletion(-)
> >> >  create mode 100644 arch/arm64/xen/efi.c
> >> > 
> >> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> > index 485e117..84f27ec 100644
> >> > --- a/arch/arm/xen/enlighten.c
> >> > +++ b/arch/arm/xen/enlighten.c
> >> > @@ -414,6 +414,11 @@ static int __init xen_guest_init(void)
> >> >  if (xen_initial_domain())
> >> >  
> >> > pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
> >> >  
> >> > +if (IS_ENABLED(CONFIG_XEN_EFI)) {
> >> > +if (efi_enabled(EFI_PARAVIRT))
> >> > +xen_efi_runtime_setup();
> >> > +}
> >> > +
> >> >  return 0;
> >> >  }
> >> >  early_initcall(xen_guest_init);
> >> > diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
> >> > index 74a8d87..62e6fe2 100644
> >> > --- a/arch/arm64/xen/Makefile
> >> > +++ b/arch/arm64/xen/Makefile
> >> > @@ -1,2 +1,3 @@
> >> >  xen-arm-y   += $(addprefix ../../arm/xen/, enlighten.o 
> >> > grant-table.o p2m.o mm.o)
> >> >  obj-y   := xen-arm.o hypercall.o
> >> > +obj-$(CONFIG_XEN_EFI) += efi.o
> >> > diff --git a/arch/arm64/xen/efi.c b/arch/arm64/xen/efi.c
> >> > new file mode 100644
> >> > index 000..33046b0
> >> > --- /dev/null
> >> > +++ b/arch/arm64/xen/efi.c
> >> > @@ -0,0 +1,36 @@
> >> > +/*
> >> > + * Copyright (c) 2015, Linaro Limited, Shannon Zhao
> >> > + *
> >> > + * This program is free software; you can redistribute it and/or modify
> >> > + * it under the terms of the GNU General Public License as published by
> >> > + * the Free Software Foundation; either version 2 of the License, or
> >> > + * (at your option) any later version.
> >> > + *
> >> > + * This program is distributed in the hope that it will be useful,
> >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> > + * GNU General Public License for more details.
> >> > + *
> >> > + * You should have received a copy of the GNU General Public License 
> >> > along
> >> > + * with this program.  If not, see .
> >> > + */
> >> > +
> >> > +#include 
> >> > +#include 
> >> > +
> >> > +void __init xen_efi_runtime_setup(void)
> >> > +{
> >> > +efi.get_time = xen_efi_get_time;
> >> > +efi.set_time = xen_efi_set_time;
> >> > +efi.get_wakeup_time  = xen_efi_get_wakeup_time;
> >> > +efi.set_wakeup_time  = xen_efi_set_wakeup_time;
> >> > +efi.get_variable = xen_efi_get_variable;
> >> > +efi.get_next_variable= xen_efi_get_next_variable;
> >> > +efi.set_variable = xen_efi_set_variable;
> >> > +efi.query_variable_info  = xen_efi_query_variable_info;
> >> > +efi.update_capsule   = xen_efi_update_capsule;
> >> > +efi.query_capsule_caps   = xen_efi_query_capsule_caps;
> >> > +efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
> >> > +efi.reset_system = NULL;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
> > This looks very similar to struct efi efi_xen previously in
> > drivers/xen/efi.c.  Maybe it makes sense to leave struct efi efi_xen in
> > drivers/xen/efi.c, export it in include/xen/xen-ops.h, then here just:
> > 
> >   efi = efi_xen;
> > 
> > Would that improve code readability?
> 
> Rethink about this. It's a little different on ARM since we call
> xen_efi_runtime_setup after parsing the FDT and setting some members of
> efi already, e.g. efi.systab, efi.acpi20. So it necessary to have a
> different way to initialize the struct efi.

OK, fair enough.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 26/31] xen/x86: Rework AMD masking MSR setup

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> This patch is best reviewed as its end result rather than as a diff, as it
> rewrites almost all of the setup.

This, I think, doesn't belong in the commit message itself.

> @@ -126,126 +133,172 @@ static const struct cpuidmask *__init noinline 
> get_cpuidmask(const char *opt)
>  }
>  
>  /*
> - * Mask the features and extended features returned by CPUID.  Parameters are
> - * set from the boot line via two methods:
> - *
> - *   1) Specific processor revision string
> - *   2) User-defined masks
> - *
> - * The processor revision string parameter has precedene.
> + * Sets caps in expected_levelling_cap, probes for the specified mask MSR, 
> and
> + * set caps in levelling_caps if it is found.  Processors prior to Fam 10h
> + * required a 32-bit password for masking MSRs.  Reads the default value into
> + * msr_val.
>   */
> -static void __devinit set_cpuidmask(const struct cpuinfo_x86 *c)
> +static void __init __probe_mask_msr(unsigned int msr, uint64_t caps,
> +uint64_t *msr_val)
>  {
> - static unsigned int feat_ecx, feat_edx;
> - static unsigned int extfeat_ecx, extfeat_edx;
> - static unsigned int l7s0_eax, l7s0_ebx;
> - static unsigned int thermal_ecx;
> - static bool_t skip_feat, skip_extfeat;
> - static bool_t skip_l7s0_eax_ebx, skip_thermal_ecx;
> - static enum { not_parsed, no_mask, set_mask } status;
> - unsigned int eax, ebx, ecx, edx;
> -
> - if (status == no_mask)
> - return;
> + unsigned int hi, lo;
> +
> +expected_levelling_cap |= caps;

Mixing indentation styles.

> +
> + if ((rdmsr_amd_safe(msr, , ) == 0) &&
> + (wrmsr_amd_safe(msr, lo, hi) == 0))
> + levelling_caps |= caps;

This logic assumes that faults are possible only because the MSR is
not there at all, not because of the actual value used. Is this a safe
assumption, the more that you don't use the "safe" variants
anymore at runtime?

> +/*
> + * Probe for the existance of the expected masking MSRs.  They might easily
> + * not be available if Xen is running virtualised.
> + */
> +static void __init noinline probe_masking_msrs(void)
> +{
> + const struct cpuinfo_x86 *c = _cpu_data;
>  
> - ASSERT((status == not_parsed) && (c == _cpu_data));
> - status = no_mask;
> + /*
> +  * First, work out which masking MSRs we should have, based on
> +  * revision and cpuid.
> +  */
>  
>   /* Fam11 doesn't support masking at all. */
>   if (c->x86 == 0x11)
>   return;
>  
> - if (~(opt_cpuid_mask_ecx & opt_cpuid_mask_edx &
> -   opt_cpuid_mask_ext_ecx & opt_cpuid_mask_ext_edx &
> -   opt_cpuid_mask_l7s0_eax & opt_cpuid_mask_l7s0_ebx &
> -   opt_cpuid_mask_thermal_ecx)) {
> - feat_ecx = opt_cpuid_mask_ecx;
> - feat_edx = opt_cpuid_mask_edx;
> - extfeat_ecx = opt_cpuid_mask_ext_ecx;
> - extfeat_edx = opt_cpuid_mask_ext_edx;
> - l7s0_eax = opt_cpuid_mask_l7s0_eax;
> - l7s0_ebx = opt_cpuid_mask_l7s0_ebx;
> - thermal_ecx = opt_cpuid_mask_thermal_ecx;
> - } else if (*opt_famrev == '\0') {
> + __probe_mask_msr(MSR_K8_FEATURE_MASK, LCAP_1cd,
> +  _defaults._1cd);
> + __probe_mask_msr(MSR_K8_EXT_FEATURE_MASK, LCAP_e1cd,
> +  _defaults.e1cd);
> +
> + if (c->cpuid_level >= 7)
> + __probe_mask_msr(MSR_AMD_L7S0_FEATURE_MASK, LCAP_7ab0,
> +  _defaults._7ab0);
> +
> + if (c->x86 == 0x15 && c->cpuid_level >= 6 && cpuid_ecx(6))
> + __probe_mask_msr(MSR_AMD_THRM_FEATURE_MASK, LCAP_6c,
> +  _defaults._6c);
> +
> + /*
> +  * Don't bother warning about a mismatch if virtualised.  These MSRs
> +  * are not architectural and almost never virtualised.
> +  */
> + if ((expected_levelling_cap == levelling_caps) ||
> + cpu_has_hypervisor)
>   return;
> - } else {
> - const struct cpuidmask *m = get_cpuidmask(opt_famrev);
> +
> + printk(XENLOG_WARNING "Mismatch between expected (%#x"
> +") and real (%#x) levelling caps: missing %#x\n",

Breaking a format string inside parentheses is certainly a little odd.
Also I don't think the "missing" part is really useful, considering that
you already print both values used in its calculation.

> +expected_levelling_cap, levelling_caps,
> +(expected_levelling_cap ^ levelling_caps) & levelling_caps);
> + printk(XENLOG_WARNING "Fam %#x, model %#x level %#x\n",
> +c->x86, c->x86_model, c->cpuid_level);
> + printk(XENLOG_WARNING
> +"If not running virtualised, please report a bug\n");

Well - you checked for running virtualized, so making it here when
running virtualized is already a bug (albeit not in the code here)?

> +void 

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

[Shannon Zhao]

On 2016/1/22 16:47, Jan Beulich wrote:
 On 22.01.16 at 09:38,  wrote:
>> > 
>> > On 2016/1/18 21:33, Jan Beulich wrote:
>> > On 16.01.16 at 06:01,  wrote:
> >>> > --- a/xen/drivers/acpi/osl.c
> >>> > +++ b/xen/drivers/acpi/osl.c
> >>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
>> > acpi_os_get_root_pointer(void)
> >>> >  void __iomem *
> >>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> >>> >  {
> >>> > -   if (system_state >= SYS_STATE_active) {
> >>> > -   mfn_t mfn = _mfn(PFN_DOWN(phys));
> >>> > -   unsigned int offs = phys & (PAGE_SIZE - 1);
> >>> > -
> >>> > -   /* The low first Mb is always mapped. */
> >>> > -   if ( !((phys + size - 1) >> 20) )
> >>> > -   return __va(phys);
> >>> > -   return __vmap(, PFN_UP(offs + size), 1, 1,
> >>> > - PAGE_HYPERVISOR_NOCACHE) + offs;
> >>> > -   }
> >>> > -   return __acpi_map_table(phys, size);
> >>> > +   return arch_acpi_os_map_memory(phys, size);
> >>> >  }
>>> >> I'm quite sure I've said before that this goes too far: The __vmap()
>>> >> part and likely also the early-boot __acpi_map_table() one already
>>> >> are architecture independent and hence should stay. The factoring
>>> >> hence should only concern the first Mb handling and maybe the
>>> >> the mapping attributes passed to __vmap().
>> > 
>> > Yes, the first MB handling and __vmap() should refactor. So if it only
>> > moves them to an architecture function, how about below patch?
>> > 
>> > diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>> > index cc15ea3..5885a3a 100644
>> > --- a/xen/arch/x86/acpi/lib.c
>> > +++ b/xen/arch/x86/acpi/lib.c
>> > @@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>> > 
>> > +void __iomem *
>> > +arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> > +{
>> > +   mfn_t mfn = _mfn(PFN_DOWN(phys));
>> > +   unsigned int offs = phys & (PAGE_SIZE - 1);
>> > +
>> > +   /* The low first Mb is always mapped. */
>> > +   if ( !((phys + size - 1) >> 20) )
>> > +   return __va(phys);
>> > +   return __vmap(, PFN_UP(offs + size), 1, 1,
>> > + PAGE_HYPERVISOR_NOCACHE) + offs;
>> > +}
> Well, I had clearly said the vmap() part is generic; if there's
> anything architecture dependent here, then the mapping
> attributes (and hence only _those_ should be factored out,
> not the entire function invocation).
I know what you said. But how can we change the attribute for ARM in
acpi_os_map_memory() without moving these codes out?

Thanks,
-- 
Shannon


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan]

Hi Jan,

On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
 On 22.01.16 at 02:56,  wrote:
>> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>>At the very least it would need to be avoided by denying the request.
>>>Upon shared use, either all parties agree, or only one may use the
>>>clock. And passing through a (platform) device would therefore imply
>>>validating that the needed clock(s) are available to the target domain.
>>>Doing this in a consistent way with all control in one component's
>>>hands seems doable only if hypervisor and/or tool stack are the
>>>controlling (and arbitrating) entity. In the end this is one of the
>>>reasons why to me a simple PV I/O interface doesn't seem suitable
>>>here.
>> 
>> How about let userspace libxl pvclk code to denying the request?
>
>Userspace would be fine, but

Then you are ok with the pvclk way to handle clock for platform device 
passthrough?

>- How would this fit in your frontend/backend model, where
>  userspace shouldn't be involved at all?

rethought about this. clk is binded to device. we can not passthrough
one device to two guest, so this means we can not let two different
guest access one clk input. Since this is mainly for embedded products,
just as Ian said "experts option", the developer should be aware of
the clk sharing between two device.

If we truly need to let userspace deny the request. If one clk
already assigned to Dom1, then the toolstack need to fail
the creation of Dom2, if Dom2 want to use the same clock.

In xl configuraiton file for Dom1, introduce such an entry,
vclks=["gpu_root_clk,uart2_root_clk,usdhc2_root_clk"]
and toolstack will create the xenstore nodes.
/local/domain/0/backend/vclk/1/0/nrclks-->3
/local/domain/0/backend/vclk/1/0/clk-0/name-->gpu_root_clk
/local/domain/0/backend/vclk/1/0/clk-1/name-->uart2_root_clk
/local/domain/0/backend/vclk/1/0/clk-2/name-->usdhc2_root_clk

/local/domain/1/device/vclk/0/clk-ring-ref
/local/domain/1/device/vclk/0/event-channel

The DomU dts also contains the clk names. Maybe the dts for clk node can 
be created by the toolstack.

If Dom2 also want to use gpu_root_clk, it should be blocked by toolstack.


Thanks,
Peng.
>- Libxl may be a little too high up the stack, libxc would seem a
>  more appropriate place to me (but that's subject to tools
>  maintainers disagreeing with me).
>
>Jan
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Minios-devel] [PATCH v8 0/] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

On Tue, 2016-01-19 at 15:44 +, Ian Campbell wrote:
> On Fri, 2016-01-15 at 13:22 +, Ian Campbell wrote:
> >  
> > Therefore needing attention from Ian and/or Wei are:
> > 
> > tools/libs/foreignmemory: Mention restrictions on fork in docs.
> > N   tools/libs/evtchn: Use uint32_t for domid arguments
> > D   tools/libs/gnttab: Extensive updates to API documentation.
> >       tools/libs/call: linux: touch newly allocated pages after madvise
> > l
> > tools/libs/{call,evtchn}: Document requirements around forking.
> >    Rtools/libs/*: Use O_CLOEXEC on Linux and FreeBSD
> 
> Thanks to Wei for acking all of these. This set of series is now ready to
> go in, but we've not had a push for a little while and this is
> potentially
> disruptive so I'm going to hold off for now until we get a push.

We've now had a push in 78610 so I'm going to go ahead with applying this
mass of patches today.

> There are one or two patches which will require rebasing over Jeurgens
> introduction of tools/helpers, I'll resend just those ones though (or at
> least only the Xen part of this series).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] VirtFS support on Xen

[Wei Liu]

On Fri, Jan 22, 2016 at 06:45:30PM +0800, Bob Liu wrote:
> Hi Wei,
> 
> On 01/21/2016 06:59 PM, Wei Liu wrote:
> > On Thu, Jan 21, 2016 at 10:50:08AM +, David Vrabel wrote:
> >> On 21/01/16 10:28, Wei Liu wrote:
> >>> [RFC] VirtFS support on Xen
> >>>
> >>> # Introduction
> >>>
> >>> QEMU/KVM supports file system passthrough via an interface called
> >>> VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
> >>> VirtIO transport.
> >>>
> >>> Xen used to have its own implementation of file system passthrough
> >>> called XenFS, but that has been inactive for a few years. The latest
> >>> update was in 2009 [2].
> >>>
> >>> This project aims to add VirtFS support on Xen. This is more
> >>> sustainable than inventing our own wheel.#
> >>
> >> What's the use case for this?  Who wants this feature?
> >>
> > 
> > Anyone who wants file system passthrough.  More specifically, VM-based
> > container solutions can share files from host file system.
> > 
> 
> I'm a bit confused, can't we just use the VirtFS of Qemu?
> E.g
> ./configure --with-extra-qemuu-configure-args="--enable-virtfs"
> 

Yes, in theory you can -- with VirtIO transport. But I'm not sure if
Virtio has been fixed to work with Xen.  That also means you need QEMU
emulation, which we don't really need (or want) when running in PV or
PVH mode.


Wei.


> Thanks,
> Bob
> 
> > http://xendevsummit2015.sched.org/event/3WDg/xen-containers-better-way-to-run-docker-containers-sainath-grandhi-intel?iframe=no==yes=no
> > http://xendevsummit2015.sched.org/event/3X1L/hyper-make-vm-run-like-containers-xu-wang-hyper?iframe=no==yes=no
> > 
> > Wei.
> > 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID

[Jan Beulich]

>>> On 21.01.16 at 17:51,  wrote:
> Add a new HVM-specific feature flag that signals the presence of a bitmap
> that contains the current set of enabled emulated devices. The bitmap is
> placed in the ecx register. The bit fields used in the bitmap are the same
> as the ones used in the xen_arch_domainconfig emulation_flags field, and
> their meaning can be found at arch-x86/xen.h.
> 
> This will allow Xen to enable emulated devices for HVMlite guests in the
> future, by having a proper ABI for reporting which devices are enabled.

The idea is certainly nice and appreciated, but ...

> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -78,12 +78,17 @@
>   * HVM-specific features
>   * EAX: Features
>   * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
> + * ECX: bitmap of enabled devices, according to the bit fields defined in
> + *  arch-x86/xen.h.

... this set of definitions is not currently a stable ABI (limited to
hypervisor and tool stack), and if we wanted to make it stable
we'd first need to think a little about the complications that may
arise if the granularity chosen (think about the PM bit and the
discussion around it before your changes went in) turns out to
be a problem later on.

Also at least some of the features can be determined by other
means (CPUID, ACPI tables), so I'm not even sure we need all
of this, and I'd really prefer to avoid multiple distinct ways to
learn of a certain feature, as it's too easy for the two (or more)
mechanisms to get out of sync.

> All unused bits have undefined values.

Nor is this an option, but maybe this is just a wording issue:
Perhaps you mean to say that they're reserved for future use?
Since truly unused bits have are guaranteed to have the value
zero, just that the set of bits varies.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/6] libxl: initialise the build info before calling prepare_config

[Ian Campbell]

On Thu, 2016-01-21 at 17:51 +0100, Roger Pau Monne wrote:
> libxl__arch_domain_prepare_config has access to the
> libxl_domain_build_info
> struct, so make sure it's properly initialised. Note that prepare_config
> is
> called from within libxl__domain_make.
> 
> This is not a bug at the moment, because prepare_config doesn't access
> libxl_domain_build_info yet, but this is likely going to change.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Ian Campbell 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 4/6] x86/PV: allow PV guests to have an emulated PIT

[Ian Campbell]

On Fri, 2016-01-22 at 03:48 -0700, Jan Beulich wrote:
> > > > On 21.01.16 at 17:51,  wrote:
> > This fixes the fallout from the HVMlite series, that removed the
> > emulated
> > PIT from PV(H) guests. Also, this patch forces the hardware domain to
> > always have an emulated PIT, regardless of whether the toolstack
> > specified
> > one or not.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Jan Beulich 
> albeit ...
> 
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -542,8 +542,11 @@ int arch_domain_create(struct domain *d, unsigned
> > int 
> > domcr_flags,
> > d->domain_id, config->emulation_flags);
> >  return -EINVAL;
> >  }
> > +if ( is_hardware_domain(d) )
> > +config->emulation_flags |= XEN_X86_EMU_PIT;
> >  if ( config->emulation_flags != 0 &&
> > - (!is_hvm_domain(d) || config->emulation_flags !=
> > XEN_X86_EMU_ALL) )
> > + (is_hvm_domain(d) ? (config->emulation_flags !=
> > XEN_X86_EMU_ALL) :
> > + (config->emulation_flags !=
> > XEN_X86_EMU_PIT)) )
> >  {
> 
> ... you having chosen the != route instead of the suggested &
> one, I guess I'll take the liberty to further simplify this while
> committing (as the ?: is now only needed on the right side of the
> != and I'm generally of the opinion that redundancy like this is
> hampering readability).

Readability would be even greater IMHO with the use of a
"required_emulation_flags" variable suitably initialised and then checked,
compared with the use of bitops etc.

> 
> Jan
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.6-testing test] 78701: tolerable FAIL - PUSHED

[osstest service owner]

flight 78701 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78701/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 78618
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 78618
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 78618
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 78618
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78618
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 78618

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  19fc53a92312876761659e82a1ae5d69b603a4ef
baseline version:
 xen  1fd615aa0108490ffc558d27627f509183cbfdaf

Last test of basis78618  2016-01-20 13:17:45 Z1 days
Testing same since78701  2016-01-21 17:20:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Edgar E. Iglesias 
  Ian Campbell 
  Julien Grall 
  Kevin Tian 
  Paul Durrant 
  Tim Deegan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops   

Re: [Xen-devel] netfront/netback multiqueue exhausting grants

[Jan Beulich]

>>> On 22.01.16 at 11:40,  wrote:
> On 01/22/2016 03:53 PM, Jan Beulich wrote:
> On 22.01.16 at 04:36,  wrote:
>>> By the way, do you think it's possible to make grant table support bigger 
>>> page e.g 64K?
>>> One grant-ref per 64KB instead of 4KB, this should able to reduce the grant 
>>> entry consumption significantly.
>> 
>> How would that work with an underlying page size of 4k, and pages
>> potentially being non-contiguous in machine address space? Besides
>> that the grant table hypercall interface isn't prepared to support
>> 64k page size, due to its use of uint16_t for the length of copy ops.
> 
> Right, and I mean whether we should consider address all the place as your 
> mentioned.

Just from an abstract perspective: How would you envision to avoid
machine address discontiguity? Or would you want to limit such an
improvement to only HVM/PVH/HVMlite guests?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] EDAC infomation partially missing

[Andreas Pflug]

Am 21.01.16 um 17:41 schrieb Jan Beulich:
 On 20.01.16 at 16:01,  wrote:
>> Initially reported to debian
>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here:
>>
>> With AMD Opteron 6xxx processors, half of the memory controllers are
>> missing from /sys/devices/system/edac/mc
>> Checked with single 6120 (dual memory controller) and twin 6344 (2x dual
>> MC), other dual-module CPUs might be affected too.
>>
>> Booting plain Linux (3.2, 3.16, 4.1, 4.3), all memory controllers are
>> listed under /sys/devices/system/edac/mc as expected. Same happens, when
>> Xen 4.1 is used: all MCs present.
>>
>> Starting with Xen 4.4 (Debian Jessie), only mc1 (on the single CPU
>> machine) or mc2/mc3 (dual CPU machine) are present, although the full
>> system memory is accessible. Checked versions were 4.1.4 (Debian
>> Wheezy), 4.4.1 (Jessie) and 4.6.0 (Sid)
> As already indicated by Ian in that bug, you should supply us with
> full kernel and hypervisor logs for both the good and bad cases
> (ideally with the same kernel version use in both runs, so that we
> can exclude kernel behavior differences).
Here are some dmesg excerpts, all performed with Linux 4.1.3.

When booting with Xen 4.1.4:

AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV
:00:18.2 (INTERRUPT)
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 1).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV
:00:19.2 (INTERRUPT)

When booting with Xen 4.4.1:

AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will
not load.
 Either enable ECC checking or force module loading by setting
'ecc_enable_override'.
 (Note that use of the override may cause unknown side effects.)
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 1).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV
:00:19.2 (INTERRUPT)

Apparently Xen4.4 doesn't report the BIOS flag correctly. I added
ecc_enable_override=1 to amd64_edac_mod, and then I get

EDAC MC: Ver: 3.0.0
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.
EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will
not load.
EDAC amd64: Forcing ECC on!
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV
:00:18.2 (INTERRUPT)
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 1).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0: 0MB 1: 0MB
EDAC amd64: MC: 2:  2048MB 3:  2048MB
EDAC amd64: MC: 4: 0MB 5: 0MB
EDAC amd64: MC: 6: 0MB 7: 0MB
EDAC amd64: using x8 syndromes.
EDAC amd64: MCT channel count: 2
EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV
:00:19.2 (INTERRUPT)

This restored both MCs, so the BIOS flag seems 

Re: [Xen-devel] Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)

[Ian Campbell]

On Thu, 2016-01-07 at 11:22 +, Ian Campbell wrote:
> So this arose because Stefano was unaware that 4.2 was no longer
> supported.
> Neither am I ever confident about where the cut-off lie, e.g. I
> always have
> to ask if I am doing backports for a security issue.
> 
> We should add rows to 
> http://wiki.xen.org/wiki/Xen_Release_Features right
> under Initial Release giving first the date until which that tree is
> supported with backports and second the date until which security
> support
> will exist. We might also want to add a third "status" row. e.g.
> "Supported", "Security Support only", "EOL" (we'll deal with extended
> support by a third party when that next arises).
> 
> I'm happy to make the edits, however I don't know what dates I would
> write 
> here. Taking it to be 18 months of Support and a further 18 months of
> security support I would get:

> Xen 4.0 Xen 4.1 Xen 4.2 Xen 
> 4.3 Xen 4.4 Xen 4.5 Xen 4.6
> Initial Release 7 April 201025 March 2011   17 Sept 20129 
> July 2013 10 March 2014   15 Jan 2015 13 Oct 2015 
> Supported until EOL - ???   EOL - ???   EOL - ???   EOL - 
> Jan 2015  EOL - Sept 2015 July 2016   April 2017
> Security support tilEOL - ???   EOL - ???   EOL - ???   July 
> 2016   March 2016  Jan 2017Oct 2018

George pointed out that 4.4 only has 6 months security support here,
which is just me counting wrong I think. It should be March 2017.

Likewise 4.5 followed suite.

Both of them should have been 1 year later. I have updated the wiki.

Ian.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure initialization

[Oleksii Kurochko]

Hello Greg,

Thanks for answer.

I am trying that you advice me.
Seems that there is same results.

Currently I am stopped this task, but if someone have more ideas why it can
be write please, Ill check.

Btw, I tried to look at /sys/kernel/debug/vgt/irqinfo and here seems all is
fine:

> --
>
> Interrupt control
> status:
> vGT: VLVDEISR is 10, VLVDEIIR is 0, VLVDEIMR is fffdff7f, VLVDEIER is
> 200f0
> vGT: DEISR is 0, DEIIR is 0, DEIMR is 0, DEIER is
> 8000
> vGT: SDEISR is 0, SDEIIR is 0, SDEIMR is 0, SDEIER is
> 0
> vGT: GTISR is 0, GTIIR is 0, GTIMR is 41, GTIER is
> 401001
> vGT: PMISR is 0, PMIIR is 0, PMIMR is 0, PMIER is
> 70
> vGT: RCS_IMR is , VCS_IMR is ffe00fff, BCS_IMR is
> 
> Total 207574 interrupts
> logged:
> #   WARNING: precisely this is the number of
> vGT
> #   physical interrupt handler be
> called,
> #   each calling several events can
> be
> #   been handled, so usually this
> number
> #   is less than the total events
> number.
> 4042: Render Command Streamer MI USER
> INTERRUPT
>1: Render MMIO sync flush
> status
>1: Video MMIO sync flush
> status
>  426: Blitter Command Streamer MI USER
> INTERRUPT
>1: Billter MMIO sync flush
> status
>   202447: Pipe A
> vblank
>38975: Render geyserville UP evaluation interval
> interrupt
> 1987: RP UP threshold
> interrupt
>   21: Render Frequency Downward Timeout During RC6
> interrupt
>   11740980876912: Last
> pirq
>   11740981018263: Last
> virq
>78066: Average pirq
> cycles
>15262: Average virq
> cycles
>   228105: Average delay between pirq/virq
> handling
>
>
> -->vgt-0:
>
> vreg (gtlc_mir: 8000, vlvier: 200f0, vlviir: 0, vlvimr: fffdff2f,
> vlvis)
> vreg (gtier: 401001, gtiir: 0, gtimr: 41, gtisr:
> 0)
> vreg (sdeier: 0, sdeiir: 0, sdeimr: 0, sdeisr:
> 0)
> vreg (pmier: 70, pmiir: 0, pmimr: 0, pmisr:
> 0)
> vreg (rcs_imr: , vcs_imr: 0, bcs_imr:
> 
>   11740981028847: Last
> injection
> Total 208373 virtual irq
> injection:
> 3399: Render Command Streamer MI USER
> INTERRUPT
>1: Render MMIO sync flush
> status
>1: Video MMIO sync flush
> status
>  405: Blitter Command Streamer MI USER
> INTERRUPT
>1: Billter MMIO sync flush
> status
>   202205: Pipe A
> vblank
> 2304: Primary Plane A flip
> done
>38642: Render geyserville UP evaluation interval
> interrupt
> 1737: RP UP threshold
> interrupt
>   21: Render Frequency Downward Timeout During RC6
> interrupt
>
>
> -->vgt-1:
>
> vreg (gtlc_mir: 8000, vlvier: 0, vlviir: 0, vlvimr: ,
> vlvisr: 0)
> vreg (gtier: 401001, gtiir: 0, gtimr: 41, gtisr:
> 0)
> vreg (sdeier: 0, sdeiir: 0, sdeimr: 0, sdeisr:
> 0)
> vreg (pmier: 0, pmiir: 0, pmimr: 0, pmisr:
> 0)
> vreg (rcs_imr: , vcs_imr: 0, bcs_imr:
> 
>9054347637006: Last
> injection
> Total 259251 virtual irq
> injection:
> 3359: Render Command Streamer MI USER
> INTERRUPT
>1: Render MMIO sync flush
> status
>1: Video MMIO sync flush
> status
>  174: Blitter Command Streamer MI USER
> INTERRUPT
>1: Billter MMIO sync flush
> status
>   391176: Pipe A
> vblank
> 3604: Primary Plane A flip
> done
>

With best regards,
 Oleksii



On Thu, Jan 21, 2016 at 8:56 PM, Dr. Greg Wettstein 
wrote:

> On Jan 5, 10:04am, Oleksii Kurochko wrote:
> } Subject: Re: [Xen-devel] [XenGT][IGVT-g] DomU pgt_device structure
> initial
>
> > Hey.
>
> Hi Oleksii, I hope this note finds your day going well.
>
> > Strange for me was that I got vmid=0 and gen_type=0, so I decided go
> > to i915_gem_vgtbuffer_ioctl and write next at the start: if
> > (!xen_initial_domain()) { return -EPERM; } Also same code is in 3.17
> > kernel from XenGT-kernel repo.
> >
> > it seems that there is no more this error now( from vgt_fb_decoder ), BUT
> > there is often freeze or very laggy UI in guest.
> >
> > What it can be?
>
> It wasn't in this e-mail but I went through the console logs which
> were in one of your postings on the IGVT-g list.  I believe you have
> your hypervisor configured for synchronous serial console output
> (sync_console command-line parameter) and you are directing your dom0
> kernel console logging through the Xen provided serial interface.
>
> Setting this option is documented to cause significant latencies.  In
> fact there is a warning about this in the Xen console logs when the
> hypervisor boots.  Here is the 

Re: [Xen-devel] [PATCH v4 1/6] libelf: rewrite symtab/strtab loading for Dom0

[Roger Pau Monné]

El 22/01/16 a les 9.11, Jan Beulich ha escrit:
 On 21.01.16 at 18:55,  wrote:
>> El 21/01/16 a les 18.29, Ian Jackson ha escrit:
>>> Roger Pau Monne writes ("[PATCH v4 1/6] libelf: rewrite symtab/strtab 
>> loading for Dom0"):
 Current implementation of elf_load_bsdsyms is broken when loading inside of
 a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
 memory space, which it is not.

 Take the oportunity to do some cleanup and properly document how
 elf_{parse/load}_bsdsyms works. The new implementation uses elf_load_image
 when dealing with data that needs to be copied to the guest memory space.
 Also reduce the number of section headers copied to the minimum necessary.
>>> ...
  #define elf_hdr_elm(_elf, _hdr, _elm, _val) \
  do {\
  if ( elf_64bit(_elf) )  \
 -elf_store_field(_elf, _hdr, e64._elm, _val);  \
 +(_hdr).e64._elm = _val; \
>>>
>>> This seems to bypass the safe store mechanism which was introduced to
>>> fix XSA-55.
>>
>> This macro is only used to store fields inside of a structure that's
>> allocated on the stack, and it doesn't involve any kind of pointer
>> magic/arithmetic. The way it was used previously in this function indeed
>> required the use of the _safe mechanism in order to prevent writing into
>> arbitrary memory places, because we were actually modifying guest memory
>> IIRC.
>>
>> I could restore the previous behaviour, but that would mean adding some
>> handlers in order to access the structure. Since this is only used for
>> Dom0, which already makes use of the elf_memcpy_unchecked function as
>> called by elf_store_val which is in turn called from elf_store_field, so
>> it's not like we were protected previously anyway.
> 
> If this is indeed Dom0-only code, could (and perhaps should) it be
> guarded suitably by an #ifdef to make obvious it's not used for
> DomU loading, and hence not security sensitive? From looking at
> the call sites of elf_{parse,load}_bsdsyms() I can't, btw., tell that
> this is Dom0-only ...

You are completely right, TBH I'm not sure what's going on with this.
xc_dom_elfloader.c has it's own functions to load the strtab/symtab, but
it's also calling elf_load_binary which, AFAICT, will call
elf_load_bsdsyms. Am I missing something, or are we loading the
symtab/strtab twice from libxc?

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Jan Beulich]

>>> On 22.01.16 at 10:20,  wrote:
> ** sp 1, irq 107, vec 0x3b
> **peoi[0] = {107, 0x3b, 0}
> Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1172
> [ Xen-4.6.0  x86_64  debug=y  Tainted:C ]
> 
> Xen call trace:
>[] do_IRQ+0x451/0x6ea
>[] common_interrupt+0x62/0x70
>[] mwait_idle+0x2cb/0x315
>[] idle_loop+0x51/0x6b
> 
> So we have been interrupted with an interrupt we already believe to be
> pending.  I wonder if there is an erratum to do with going to sleep with
> a pending interrupt.

An immediate way to check whether that's (part of) the problem
would be to run with "cpuidle=0" for a while.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 25/31] xen/x86: Common infrastructure for levelling context switching

[Andrew Cooper]

On 22/01/16 08:56, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -35,6 +35,9 @@ integer_param("cpuid_mask_ext_edx", 
>> opt_cpuid_mask_ext_edx);
>>  unsigned int __initdata expected_levelling_cap;
>>  unsigned int __read_mostly levelling_caps;
>>  
>> +DEFINE_PER_CPU(struct cpumasks, cpumasks);
>> +struct cpumasks __read_mostly cpumask_defaults;
> Any reason these can't be introduced when first used? (The question
> really applies to the rest of this patch too, I guess.)

The subsequent two patches are sufficiently complicated in their own
right that I deliberately pulled these bits out.

>
>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -585,6 +585,21 @@ int microcode_resume_cpu(unsigned int cpu);
>>   */
>>  extern unsigned int expected_levelling_cap, levelling_caps;
>>  
>> +struct cpumasks
>> +{
>> +uint64_t _1cd;
>> +uint64_t e1cd;
>> +uint64_t Da1;
>> +uint64_t _6c;
>> +uint64_t _7ab0;
>> +};
> While I see the need for these underscore prefixes with the
> current naming scheme, perhaps it would be better to make
> this fully consistent with the acronym #define-s, by e.g.
> prefixing the base ones with 'b'? Such full naming consistency
> would allow for string concatenation in macros, should such a
> possibility ever arise, no matter whether manifest constants
> or structure members here are needed to be accessed.
>
> As to the name of the structure itself - perhaps better
> cpuidmasks?

Ok.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Jan Beulich]

>>> On 22.01.16 at 10:27,  wrote:
> Hi Jan,
> 
> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
> On 22.01.16 at 02:56,  wrote:
>>> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
At the very least it would need to be avoided by denying the request.
Upon shared use, either all parties agree, or only one may use the
clock. And passing through a (platform) device would therefore imply
validating that the needed clock(s) are available to the target domain.
Doing this in a consistent way with all control in one component's
hands seems doable only if hypervisor and/or tool stack are the
controlling (and arbitrating) entity. In the end this is one of the
reasons why to me a simple PV I/O interface doesn't seem suitable
here.
>>> 
>>> How about let userspace libxl pvclk code to denying the request?
>>
>>Userspace would be fine, but
> 
> Then you are ok with the pvclk way to handle clock for platform device 
> passthrough?

No, not really. While I accept that doing clock management in the
hypervisor is undesirable, we're still not at the point where such
a frontend/backend pair would look like the only possible route
out of a dilemma, and I continue to think that this proposed model
should indeed only be the last resort.

In particular, with the user space exposure of clock control
discussed in another sub-thread, the next best option would
seem to be to handle this via emulation in a device model. Yes,
ARM guests currently have no qemu attached to them, but I
guess sooner or later this will need to change anyway.

>>- How would this fit in your frontend/backend model, where
>>  userspace shouldn't be involved at all?
> 
> rethought about this. clk is binded to device. we can not passthrough
> one device to two guest, so this means we can not let two different
> guest access one clk input. Since this is mainly for embedded products,
> just as Ian said "experts option", the developer should be aware of
> the clk sharing between two device.
> 
> If we truly need to let userspace deny the request. If one clk
> already assigned to Dom1, then the toolstack need to fail
> the creation of Dom2, if Dom2 want to use the same clock.

I.e. you're now proposing actual assignment of clocks to guests?
That's at least one step in the (from my pov) right direction...

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] EDAC infomation partially missing

[Jan Beulich]

>>> On 22.01.16 at 10:09,  wrote:
> When booting with Xen 4.4.1:
> 
> AMD64 EDAC driver v3.4.0
> EDAC amd64: DRAM ECC enabled.
> EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.

I wonder how valid his message is. We actually write this MSR with
all ones during boot.

However, considering involved functions like
nb_mce_bank_enabled_on_node() or node_to_amd_nb() taking
node IDs as inputs, and considering that PV guests (including
Dom0) don't have a topology matching that of the host, I doubt
very much that this driver is even remotely prepared to run
under Xen. It working on Xen 4.1.x would then be by pure
accident.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] netfront/netback multiqueue exhausting grants

[Bob Liu]

On 01/22/2016 03:53 PM, Jan Beulich wrote:
 On 22.01.16 at 04:36,  wrote:
>> By the way, do you think it's possible to make grant table support bigger 
>> page e.g 64K?
>> One grant-ref per 64KB instead of 4KB, this should able to reduce the grant 
>> entry consumption significantly.
> 
> How would that work with an underlying page size of 4k, and pages
> potentially being non-contiguous in machine address space? Besides
> that the grant table hypercall interface isn't prepared to support
> 64k page size, due to its use of uint16_t for the length of copy ops.
> 

Right, and I mean whether we should consider address all the place as your 
mentioned.
With multi-queue xen-block and xen-network, we got more reports that the grants 
were exhausted.

-- 
Regards,
-Bob

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 4/6] x86/PV: allow PV guests to have an emulated PIT

[Jan Beulich]

>>> On 21.01.16 at 17:51,  wrote:
> This fixes the fallout from the HVMlite series, that removed the emulated
> PIT from PV(H) guests. Also, this patch forces the hardware domain to
> always have an emulated PIT, regardless of whether the toolstack specified
> one or not.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 
albeit ...

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -542,8 +542,11 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
> d->domain_id, config->emulation_flags);
>  return -EINVAL;
>  }
> +if ( is_hardware_domain(d) )
> +config->emulation_flags |= XEN_X86_EMU_PIT;
>  if ( config->emulation_flags != 0 &&
> - (!is_hvm_domain(d) || config->emulation_flags != 
> XEN_X86_EMU_ALL) )
> + (is_hvm_domain(d) ? (config->emulation_flags != 
> XEN_X86_EMU_ALL) :
> + (config->emulation_flags != 
> XEN_X86_EMU_PIT)) )
>  {

... you having chosen the != route instead of the suggested &
one, I guess I'll take the liberty to further simplify this while
committing (as the ?: is now only needed on the right side of the
!= and I'm generally of the opinion that redundancy like this is
hampering readability).

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 26/31] xen/x86: Rework AMD masking MSR setup

[Andrew Cooper]

On 22/01/16 09:27, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> This patch is best reviewed as its end result rather than as a diff, as it
>> rewrites almost all of the setup.
> This, I think, doesn't belong in the commit message itself.

Why not? It applies equally to anyone reading the commit in tree.

>
>> @@ -126,126 +133,172 @@ static const struct cpuidmask *__init noinline 
>> get_cpuidmask(const char *opt)
>>  }
>>  
>>  /*
>> - * Mask the features and extended features returned by CPUID.  Parameters 
>> are
>> - * set from the boot line via two methods:
>> - *
>> - *   1) Specific processor revision string
>> - *   2) User-defined masks
>> - *
>> - * The processor revision string parameter has precedene.
>> + * Sets caps in expected_levelling_cap, probes for the specified mask MSR, 
>> and
>> + * set caps in levelling_caps if it is found.  Processors prior to Fam 10h
>> + * required a 32-bit password for masking MSRs.  Reads the default value 
>> into
>> + * msr_val.
>>   */
>> -static void __devinit set_cpuidmask(const struct cpuinfo_x86 *c)
>> +static void __init __probe_mask_msr(unsigned int msr, uint64_t caps,
>> +uint64_t *msr_val)
>>  {
>> -static unsigned int feat_ecx, feat_edx;
>> -static unsigned int extfeat_ecx, extfeat_edx;
>> -static unsigned int l7s0_eax, l7s0_ebx;
>> -static unsigned int thermal_ecx;
>> -static bool_t skip_feat, skip_extfeat;
>> -static bool_t skip_l7s0_eax_ebx, skip_thermal_ecx;
>> -static enum { not_parsed, no_mask, set_mask } status;
>> -unsigned int eax, ebx, ecx, edx;
>> -
>> -if (status == no_mask)
>> -return;
>> +unsigned int hi, lo;
>> +
>> +expected_levelling_cap |= caps;
> Mixing indentation styles.

Yes - sadly some crept in, despite my best efforts.  I have already
fixed all I can find in the series.

>
>> +
>> +if ((rdmsr_amd_safe(msr, , ) == 0) &&
>> +(wrmsr_amd_safe(msr, lo, hi) == 0))
>> +levelling_caps |= caps;
> This logic assumes that faults are possible only because the MSR is
> not there at all, not because of the actual value used. Is this a safe
> assumption, the more that you don't use the "safe" variants
> anymore at runtime?

Yes - it is a safe assumption.

The MSRs on AMD are at fixed indices and all specified to cover the full
32bit of a cpuid feature leaf.  All we really care about is whether the
MSR is present (and to read its defaults, if it is).

If the MSR isn't present, levelling_caps won't be updated, and Xen will
never touch the MSR again.

>
>> +/*
>> + * Probe for the existance of the expected masking MSRs.  They might easily
>> + * not be available if Xen is running virtualised.
>> + */
>> +static void __init noinline probe_masking_msrs(void)
>> +{
>> +const struct cpuinfo_x86 *c = _cpu_data;
>>  
>> -ASSERT((status == not_parsed) && (c == _cpu_data));
>> -status = no_mask;
>> +/*
>> + * First, work out which masking MSRs we should have, based on
>> + * revision and cpuid.
>> + */
>>  
>>  /* Fam11 doesn't support masking at all. */
>>  if (c->x86 == 0x11)
>>  return;
>>  
>> -if (~(opt_cpuid_mask_ecx & opt_cpuid_mask_edx &
>> -  opt_cpuid_mask_ext_ecx & opt_cpuid_mask_ext_edx &
>> -  opt_cpuid_mask_l7s0_eax & opt_cpuid_mask_l7s0_ebx &
>> -  opt_cpuid_mask_thermal_ecx)) {
>> -feat_ecx = opt_cpuid_mask_ecx;
>> -feat_edx = opt_cpuid_mask_edx;
>> -extfeat_ecx = opt_cpuid_mask_ext_ecx;
>> -extfeat_edx = opt_cpuid_mask_ext_edx;
>> -l7s0_eax = opt_cpuid_mask_l7s0_eax;
>> -l7s0_ebx = opt_cpuid_mask_l7s0_ebx;
>> -thermal_ecx = opt_cpuid_mask_thermal_ecx;
>> -} else if (*opt_famrev == '\0') {
>> +__probe_mask_msr(MSR_K8_FEATURE_MASK, LCAP_1cd,
>> + _defaults._1cd);
>> +__probe_mask_msr(MSR_K8_EXT_FEATURE_MASK, LCAP_e1cd,
>> + _defaults.e1cd);
>> +
>> +if (c->cpuid_level >= 7)
>> +__probe_mask_msr(MSR_AMD_L7S0_FEATURE_MASK, LCAP_7ab0,
>> + _defaults._7ab0);
>> +
>> +if (c->x86 == 0x15 && c->cpuid_level >= 6 && cpuid_ecx(6))
>> +__probe_mask_msr(MSR_AMD_THRM_FEATURE_MASK, LCAP_6c,
>> + _defaults._6c);
>> +
>> +/*
>> + * Don't bother warning about a mismatch if virtualised.  These MSRs
>> + * are not architectural and almost never virtualised.
>> + */
>> +if ((expected_levelling_cap == levelling_caps) ||
>> +cpu_has_hypervisor)
>>  return;
>> -} else {
>> -const struct cpuidmask *m = get_cpuidmask(opt_famrev);
>> +
>> +printk(XENLOG_WARNING "Mismatch between expected (%#x"
>> +   ") and real (%#x) levelling caps: missing %#x\n",
> Breaking a format string inside parentheses is certainly a little odd.
> Also I don't think 

Re: [Xen-devel] Uniform commands for booting xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 18.01.2016 11:28, Ian Campbell wrote:
> On Mon, 2016-01-11 at 15:06 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> On 13.11.2015 10:50, Ian Campbell wrote:
>>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
> How do you express modules other than kernel+initrd in that
> scheme, without grub needing to be aware of any new addition we
> may find necessary going forward?
>

 Are modules used by Xen self-identifying? Is it enough to simply pass
 Xen kernel list of binary blobs or Xen kernel must be told what these
 binary blobs are? If they are self identifying, why arm needs to be
 passed module type in the first place?
>>>
>>> At first Xen/ARM required the bootloader to identify, but that was
>>> since
>>> identified as causing madness and fixed by having Xen/ARM do as Xen/x86
>>> does and figure things out for itself, but I failed to communicate this
>>> clearly and things got implemented on the grub side under the old
>>> assumptions.
>>>
>> This changes a lot. This removes most of hurdles towards uniformity. Are
>> you ok with replacing xen_kernel/xen_xsm/... with just xen_module and
>> dropping type altogether?
> 
> So ending up with xen_hypervisor followed by one or more xen_module lines?
> That's fine with me. This bit:
> 
> @@ -203,15 +155,11 @@ prepare_xen_module_params (struct xen_boot_binary 
> *module, void *xen_boot_fdt)
>grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name);
>  
>retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible",
> - module->node_info.compat_string,
> - (grub_uint32_t) module->
> - node_info.compat_string_size);
> + "deprecated", sizeof("deprecated") - 1);
> 
> Seems to be changing the compatibility string of hte node to "deprecated",
> which isn't right (or at least won't work). The nodes still need to be
> identified as being modules per http://xenbits.xen.org/docs/unstable/misc/a
> rm/device-tree/booting.txt that means "multiboot,module" (or if you insist
> "xen,multiboot-module").
> 
Changed to "multiboot,module" and committed
>> Do you think that it makes sense to have xen_initrd in order to have
>> in-memory initrd concatenation like baremetal counterpart? In either
>> case we can add it later. I'd rather not have a command than to change
>> its meaning later.
> 
> If it is useful on baremetal (and I can see that it would be) then I think
> it would be useful on Xen too.
> 
> Ian.
> 
> 




signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 27/31] xen/x86: Rework Intel masking/faulting setup

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> + if (msr_basic)
> + __probe_mask_msr(_basic, LCAP_1cd, _defaults._1cd);
> +
> + if (msr_ext)
> + __probe_mask_msr(_ext, LCAP_e1cd, _defaults.e1cd);
> +
> + if (msr_xsave)
> + __probe_mask_msr(_xsave, LCAP_Da1, _defaults.Da1);
> +
> + /*
> +  * Don't bother warning about a mismatch if virtualised.  These MSRs
> +  * are not architectural and almost never virtualised.
> +  */
> + if ((expected_levelling_cap == levelling_caps) ||
> + cpu_has_hypervisor)
> + return;
> +
> + printk(XENLOG_WARNING "Mismatch between expected (%#x"
> +") and real (%#x) levelling caps: missing %#x\n",
> +expected_levelling_cap, levelling_caps,
> +(expected_levelling_cap ^ levelling_caps) & levelling_caps);
> + printk(XENLOG_WARNING "Fam %#x, model %#x expected (%#x/%#x/%#x), "
> +"got (%#x/%#x/%#x)\n", c->x86, c->x86_model,
> +exp_msr_basic, exp_msr_ext, exp_msr_xsave,
> +msr_basic, msr_ext, msr_xsave);

I may not have noticed the same on the AMD patch, but printing
zeros as "missing" MSR indexes seems strange to me. Why not
print the missing MSRs with their textual names, easing cross
referencing with the FlexMigration document?

> +/*
> + * opt_cpuid_mask_ecx/edx: cpuid.1[ecx, edx] feature mask.
> + * For example, E8400[Intel Core 2 Duo Processor series] ecx = 0x0008E3FD,
> + * edx = 0xBFEBFBFF when executing CPUID.EAX = 1 normally. If you want to
> + * 'rev down' to E8400, you can set these values in these Xen boot 
> parameters.
> + */
> +static void __init noinline intel_init_levelling(void)
> +{
> + if ( !probe_intel_cpuid_faulting() )
> + probe_masking_msrs();
> +
> + if ( msr_basic )
> + {
> + cpumask_defaults._1cd =
> + ((u64)opt_cpuid_mask_edx << 32) | opt_cpuid_mask_ecx;
> +
> + if ( !~(opt_cpuid_mask_ecx & opt_cpuid_mask_edx) )
>   printk("Writing CPUID feature mask ecx:edx -> 
> %08x:%08x\n",
>  opt_cpuid_mask_ecx, opt_cpuid_mask_edx);

Are these messages, without adjustment to their wording, not
going to be confusing? After all the intention is to not just write
a single, never modified value. E.g. better "Defaulting ..."?

> @@ -183,22 +237,13 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>   (boot_cpu_data.x86_mask == 3 || boot_cpu_data.x86_mask == 4))
>   paddr_bits = 36;
>  
> - if (c == _cpu_data && c->x86 == 6) {
> - if (probe_intel_cpuid_faulting())
> - __set_bit(X86_FEATURE_CPUID_FAULTING,
> -   c->x86_capability);
> - } else if (boot_cpu_has(X86_FEATURE_CPUID_FAULTING)) {
> - BUG_ON(!probe_intel_cpuid_faulting());
> - __set_bit(X86_FEATURE_CPUID_FAULTING, c->x86_capability);
> - }
> + if (c == _cpu_data)
> + intel_init_levelling();
> +
> + if (test_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability))
> +__set_bit(X86_FEATURE_CPUID_FAULTING, c->x86_capability);

So you intentionally delete the validation of CPUID faulting being
available on APs? Also - indentation.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: Add support for dom0 with Linux kernel 3.19 and newer

[David Vrabel]

On 21/01/16 20:13, Daniel Kiper wrote:
> Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
> (xen: switch to linear virtual mapped sparse p2m list), which
> appeared in 3.19, introduced linear virtual mapped sparse p2m
> list. If readmem() reads p2m then it access this list using
> physical addresses. Sadly, VMA to physical address translation
> in crash requires access to p2m list. This means that we have
> a chicken and egg problem. In general this issue must be solved
> by introducing some changes in libxl, Linux kernel and crash
> (I have added this task to my long TODO list). However, in dom0
> case we can use crash_xen_info_t.dom0_pfn_to_mfn_frame_list_list
> which is available out of the box. So, let's use it and make
> at least some users happy.

I'm confused.  How does a virtual address to (pseudo-)physical address
lookup require access to the p2m?  Surely this is a walk of the page
tables followed by a M2P lookup on the MFN in the L1 PTE?

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

[Jan Beulich]

>>> On 22.01.16 at 10:37,  wrote:

> 
> On 2016/1/22 16:47, Jan Beulich wrote:
> On 22.01.16 at 09:38,  wrote:
>>> > 
>>> > On 2016/1/18 21:33, Jan Beulich wrote:
>>> > On 16.01.16 at 06:01,  wrote:
>> >>> > --- a/xen/drivers/acpi/osl.c
>> >>> > +++ b/xen/drivers/acpi/osl.c
>> >>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
>>> > acpi_os_get_root_pointer(void)
>> >>> >  void __iomem *
>> >>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >>> >  {
>> >>> > -  if (system_state >= SYS_STATE_active) {
>> >>> > -  mfn_t mfn = _mfn(PFN_DOWN(phys));
>> >>> > -  unsigned int offs = phys & (PAGE_SIZE - 1);
>> >>> > -
>> >>> > -  /* The low first Mb is always mapped. */
>> >>> > -  if ( !((phys + size - 1) >> 20) )
>> >>> > -  return __va(phys);
>> >>> > -  return __vmap(, PFN_UP(offs + size), 1, 1,
>> >>> > -PAGE_HYPERVISOR_NOCACHE) + offs;
>> >>> > -  }
>> >>> > -  return __acpi_map_table(phys, size);
>> >>> > +  return arch_acpi_os_map_memory(phys, size);
>> >>> >  }
 >> I'm quite sure I've said before that this goes too far: The __vmap()
 >> part and likely also the early-boot __acpi_map_table() one already
 >> are architecture independent and hence should stay. The factoring
 >> hence should only concern the first Mb handling and maybe the
 >> the mapping attributes passed to __vmap().
>>> > 
>>> > Yes, the first MB handling and __vmap() should refactor. So if it only
>>> > moves them to an architecture function, how about below patch?
>>> > 
>>> > diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>>> > index cc15ea3..5885a3a 100644
>>> > --- a/xen/arch/x86/acpi/lib.c
>>> > +++ b/xen/arch/x86/acpi/lib.c
>>> > @@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>>> > 
>>> > +void __iomem *
>>> > +arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>>> > +{
>>> > +   mfn_t mfn = _mfn(PFN_DOWN(phys));
>>> > +   unsigned int offs = phys & (PAGE_SIZE - 1);
>>> > +
>>> > +   /* The low first Mb is always mapped. */
>>> > +   if ( !((phys + size - 1) >> 20) )
>>> > +   return __va(phys);
>>> > +   return __vmap(, PFN_UP(offs + size), 1, 1,
>>> > + PAGE_HYPERVISOR_NOCACHE) + offs;
>>> > +}
>> Well, I had clearly said the vmap() part is generic; if there's
>> anything architecture dependent here, then the mapping
>> attributes (and hence only _those_ should be factored out,
>> not the entire function invocation).
> I know what you said. But how can we change the attribute for ARM in
> acpi_os_map_memory() without moving these codes out?

By having each arch #define their value, and use that constant here?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] VirtFS support on Xen

[Bob Liu]

Hi Wei,

On 01/21/2016 06:59 PM, Wei Liu wrote:
> On Thu, Jan 21, 2016 at 10:50:08AM +, David Vrabel wrote:
>> On 21/01/16 10:28, Wei Liu wrote:
>>> [RFC] VirtFS support on Xen
>>>
>>> # Introduction
>>>
>>> QEMU/KVM supports file system passthrough via an interface called
>>> VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
>>> VirtIO transport.
>>>
>>> Xen used to have its own implementation of file system passthrough
>>> called XenFS, but that has been inactive for a few years. The latest
>>> update was in 2009 [2].
>>>
>>> This project aims to add VirtFS support on Xen. This is more
>>> sustainable than inventing our own wheel.#
>>
>> What's the use case for this?  Who wants this feature?
>>
> 
> Anyone who wants file system passthrough.  More specifically, VM-based
> container solutions can share files from host file system.
> 

I'm a bit confused, can't we just use the VirtFS of Qemu?
E.g
./configure --with-extra-qemuu-configure-args="--enable-virtfs"

Thanks,
Bob

> http://xendevsummit2015.sched.org/event/3WDg/xen-containers-better-way-to-run-docker-containers-sainath-grandhi-intel?iframe=no==yes=no
> http://xendevsummit2015.sched.org/event/3X1L/hyper-make-vm-run-like-containers-xu-wang-hyper?iframe=no==yes=no
> 
> Wei.
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] disk=['file://..xvda'] not working for boot disks anymore?

[Konrad Rzeszutek Wilk]

On Fri, Jan 22, 2016 at 04:54:21PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 22, 2016 at 03:59:09PM -0500, Boris Ostrovsky wrote:
> > On 01/22/2016 03:54 PM, Konrad Rzeszutek Wilk wrote:
> > >Hey,
> > >
> > >This parameter
> > >disk = 
> > >['file:/root/sol.dd,xvda,w','file:/root/sol-11_2_15_5_1-text-x86.iso,xvdb:cdrom,r']
> > >
> > >works with qemu-traditional, but if I try with qemu-xen it
> > >does not find the disk:
> > >
> > >(d15) [2016-01-22 20:50:03] enter handle_19:
> > >(d15) [2016-01-22 20:50:03]   NULL
> > >(d15) [2016-01-22 20:50:03] Booting from ROM...
> > >(d15) [2016-01-22 20:50:03] Booting from c980:0361
> > >
> > >while with qemu-traditional:
> > >
> > >(d14) [2016-01-22 20:43:15] Bochs BIOS - build: 06/23/99
> > >(d14) [2016-01-22 20:43:15] $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> > >(d14) [2016-01-22 20:43:15] Options: apmbios pcibios eltorito PMM
> > >(d14) [2016-01-22 20:43:15]
> > >(d14) [2016-01-22 20:43:15] ata0 master: QEMU HARDDISK ATA-7 Hard-Disk 
> > >(12288 MBytes)
> > >(d14) [2016-01-22 20:43:15]
> > >(d14) [2016-01-22 20:43:15]
> > >(d14) [2016-01-22 20:43:15]
> > >(d14) [2016-01-22 20:43:15] Press F12 for boot menu.
> > >(d14) [2016-01-22 20:43:15]
> > >(d14) [2016-01-22 20:43:15] Booting from Hard Disk...
> > >
> > >It does work with Xen 4.4, but that is ancient. I hadn't yet
> > >tried Xen 4.5 nor 4.6.
> > >
> > >I am hoping one of you knows exactly which commit might have made
> > >this change?
> > >
> > >Note that the name is 'xvda', not 'hda'. Thanks!
> > 
> > Probably this one:
> > 
> > http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01529.html
> 
> You are good.
> 
> That was it.
> 
> CC-ing Anthony - are you OK if the patch was reverted?

And I dug in the thread.

There is a bit of problem here. This patch breaks some existing guests (Solaris 
11.2
for example). It assumes that when running under Xen it would only use PV 
drivers.
Which is fine - except that the bootup part (GRUB2) is all done using QEMU - and
if the guest config has 'xvda' then SeaBIOS won't see the disk anymore. QEMU
traditional will still show the disk.

Ideas how to deal with the existing guests?

P.S.
Solaris OS cannot run as PV guest, only HVM.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.5-testing test] 78736: tolerable FAIL - PUSHED

[osstest service owner]

flight 78736 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78736/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 78640 pass in 78736
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail in 78640 
pass in 78736
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 78640 
pass in 78736
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 78640 
pass in 78736
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail pass in 78640
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate   fail pass in 78640

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 78529
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 78529
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 78529
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78529

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass

version targeted for testing:
 xen  7afddd3b945b11a7f5162d1355283b6b9ae7aba3
baseline version:
 xen  a34fbcf30bbe5a9aa8b57d21e7afcfa7b78c520a

Last test of basis78529  2016-01-19 14:11:11 Z3 days
Testing same since78640  2016-01-20 22:36:08 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Jan Beulich 
  Kevin Tian 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 

Re: [Xen-devel] disk=['file://..xvda'] not working for boot disks anymore?

[Jim Fehlig]

On 01/22/2016 02:54 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 22, 2016 at 03:59:09PM -0500, Boris Ostrovsky wrote:
>> On 01/22/2016 03:54 PM, Konrad Rzeszutek Wilk wrote:
>>> Hey,
>>>
>>> This parameter
>>> disk = 
>>> ['file:/root/sol.dd,xvda,w','file:/root/sol-11_2_15_5_1-text-x86.iso,xvdb:cdrom,r']
>>>
>>> works with qemu-traditional, but if I try with qemu-xen it
>>> does not find the disk:
>>>
>>> (d15) [2016-01-22 20:50:03] enter handle_19:
>>> (d15) [2016-01-22 20:50:03]   NULL
>>> (d15) [2016-01-22 20:50:03] Booting from ROM...
>>> (d15) [2016-01-22 20:50:03] Booting from c980:0361
>>>
>>> while with qemu-traditional:
>>>
>>> (d14) [2016-01-22 20:43:15] Bochs BIOS - build: 06/23/99
>>> (d14) [2016-01-22 20:43:15] $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
>>> (d14) [2016-01-22 20:43:15] Options: apmbios pcibios eltorito PMM
>>> (d14) [2016-01-22 20:43:15]
>>> (d14) [2016-01-22 20:43:15] ata0 master: QEMU HARDDISK ATA-7 Hard-Disk 
>>> (12288 MBytes)
>>> (d14) [2016-01-22 20:43:15]
>>> (d14) [2016-01-22 20:43:15]
>>> (d14) [2016-01-22 20:43:15]
>>> (d14) [2016-01-22 20:43:15] Press F12 for boot menu.
>>> (d14) [2016-01-22 20:43:15]
>>> (d14) [2016-01-22 20:43:15] Booting from Hard Disk...
>>>
>>> It does work with Xen 4.4, but that is ancient. I hadn't yet
>>> tried Xen 4.5 nor 4.6.
>>>
>>> I am hoping one of you knows exactly which commit might have made
>>> this change?
>>>
>>> Note that the name is 'xvda', not 'hda'. Thanks!
>> Probably this one:
>>
>> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01529.html
> You are good.
>
> That was it.
>
> CC-ing Anthony - are you OK if the patch was reverted?

I'd prefer this not be reverted, and instead use 'hda' in your config. Unless
you know of another way for libxl apps to request a xen virtual disk without the
accompanying emulated one.

Regards,
Jim


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

[Luis R. Rodriguez]

On Fri, Jan 22, 2016 at 04:35:48PM -0500, Boris Ostrovsky wrote:
> HVMlite guests (to be introduced in subsequent patches) share most
> of the kernel initialization code with PV(H).
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/xen/enlighten.c |  225 
> --
>  1 files changed, 119 insertions(+), 106 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index d09e4c9..2cf446a 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1505,19 +1505,14 @@ static void __init xen_pvh_early_guest_init(void)
>  }
>  #endif/* CONFIG_XEN_PVH */
>  
> -/* First C function to be called on Xen boot */
> -asmlinkage __visible void __init xen_start_kernel(void)
> +
> +static void __init xen_init_kernel(void)
>  {
>   struct physdev_set_iopl set_iopl;
>   unsigned long initrd_start = 0;
>   u64 pat;
>   int rc;
>  
> - if (!xen_start_info)
> - return;
> -
> - xen_domain_type = XEN_PV_DOMAIN;
> -
>   xen_setup_features();
>  #ifdef CONFIG_XEN_PVH
>   xen_pvh_early_guest_init();
> @@ -1529,48 +1524,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
>   if (xen_initial_domain())
>   pv_info.features |= PV_SUPPORTED_RTC;
>   pv_init_ops = xen_init_ops;
> - if (!xen_pvh_domain()) {
> - pv_cpu_ops = xen_cpu_ops;
> -
> - x86_platform.get_nmi_reason = xen_get_nmi_reason;
> - }
> -
> - if (xen_feature(XENFEAT_auto_translated_physmap))
> - x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
> - else
> - x86_init.resources.memory_setup = xen_memory_setup;
> - x86_init.oem.arch_setup = xen_arch_setup;
> - x86_init.oem.banner = xen_banner;
>  
>   xen_init_time_ops();
>  
> - /*
> -  * Set up some pagetable state before starting to set any ptes.
> -  */
> -
> - xen_init_mmu_ops();
> -
> - /* Prevent unwanted bits from being set in PTEs. */
> - __supported_pte_mask &= ~_PAGE_GLOBAL;
> -
> - /*
> -  * Prevent page tables from being allocated in highmem, even
> -  * if CONFIG_HIGHPTE is enabled.
> -  */
> - __userpte_alloc_gfp &= ~__GFP_HIGHMEM;
> -
> - /* Work out if we support NX */
> - x86_configure_nx();
> -
> - /* Get mfn list */
> - xen_build_dynamic_phys_to_machine();
> -
> - /*
> -  * Set up kernel GDT and segment registers, mainly so that
> -  * -fstack-protector code can be executed.
> -  */
> - xen_setup_gdt(0);
> -
>   xen_init_irq_ops();
>   xen_init_cpuid_mask();
>  
> @@ -1580,21 +1536,8 @@ asmlinkage __visible void __init xen_start_kernel(void)
>*/
>   xen_init_apic();
>  #endif
> -
> - if (xen_feature(XENFEAT_mmu_pt_update_preserve_ad)) {
> - pv_mmu_ops.ptep_modify_prot_start = xen_ptep_modify_prot_start;
> - pv_mmu_ops.ptep_modify_prot_commit = 
> xen_ptep_modify_prot_commit;
> - }
> -
>   machine_ops = xen_machine_ops;
>  
> - /*
> -  * The only reliable way to retain the initial address of the
> -  * percpu gdt_page is to remember it here, so we can go and
> -  * mark it RW later, when the initial percpu area is freed.
> -  */
> - xen_initial_gdt = _cpu(gdt_page, 0);
> -
>   xen_smp_init();
>  
>  #ifdef CONFIG_ACPI_NUMA
> @@ -1609,66 +1552,126 @@ asmlinkage __visible void __init 
> xen_start_kernel(void)
>  possible map and a non-dummy shared_info. */
>   per_cpu(xen_vcpu, 0) = _shared_info->vcpu_info[0];
>  
> - local_irq_disable();
> - early_boot_irqs_disabled = true;
> + if (!xen_hvm_domain()) {
> + if (!xen_pvh_domain()) {
> + pv_cpu_ops = xen_cpu_ops;
>  
> - xen_raw_console_write("mapping kernel into physical memory\n");
> - xen_setup_kernel_pagetable((pgd_t *)xen_start_info->pt_base,
> -xen_start_info->nr_pages);
> - xen_reserve_special_pages();
> + x86_platform.get_nmi_reason = xen_get_nmi_reason;
> + }
>  
> - /*
> -  * Modify the cache mode translation tables to match Xen's PAT
> -  * configuration.
> -  */
> - rdmsrl(MSR_IA32_CR_PAT, pat);
> - pat_init_cache_modes(pat);
> + if (xen_feature(XENFEAT_auto_translated_physmap))
> + x86_init.resources.memory_setup =
> + xen_auto_xlated_memory_setup;
> + else
> + x86_init.resources.memory_setup = xen_memory_setup;
> + x86_init.oem.arch_setup = xen_arch_setup;
> + x86_init.oem.banner = xen_banner;
>  
> - /* keep using Xen gdt for now; no urgent need to change it */
> + /*
> +  * Set up some pagetable state before starting to set any ptes.
> +  */
>  
> -#ifdef CONFIG_X86_32
> - pv_info.kernel_rpl = 

Re: [Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

[Boris Ostrovsky]

On 01/22/2016 06:01 PM, Luis R. Rodriguez wrote:

On Fri, Jan 22, 2016 at 04:35:48PM -0500, Boris Ostrovsky wrote:

HVMlite guests (to be introduced in subsequent patches) share most
of the kernel initialization code with PV(H).

Signed-off-by: Boris Ostrovsky 
---
  arch/x86/xen/enlighten.c |  225 --
  1 files changed, 119 insertions(+), 106 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d09e4c9..2cf446a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c

Whoa, I'm lost, its hard for me to tell what exactly stayed and what
got pulled into a helper, etc. Is there a possibility to split this
patch in 2 somehow to make the actual functional changes easier to
read? There are too many changes here and I just can't tell easily
what's going on.



The only real changes that this patch introduces is it reorders some of 
the operations that used to be in xen_start_kernel(). This is done so 
that in the next patch when we add hvmlite we can easily put those 
specific to PV(H) inside 'if (!xen_hvm_domain())'. I probably should 
have said so in the commit message.


It is indeed difficult to review but I don't see how I can split this. 
Even if I just moved it (without reordering) it would still be hard to read.


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/6] libelf: rewrite symtab/strtab loading for Dom0

[Jan Beulich]

>>> On 21.01.16 at 18:55,  wrote:
> El 21/01/16 a les 18.29, Ian Jackson ha escrit:
>> Roger Pau Monne writes ("[PATCH v4 1/6] libelf: rewrite symtab/strtab 
> loading for Dom0"):
>>> Current implementation of elf_load_bsdsyms is broken when loading inside of
>>> a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
>>> memory space, which it is not.
>>>
>>> Take the oportunity to do some cleanup and properly document how
>>> elf_{parse/load}_bsdsyms works. The new implementation uses elf_load_image
>>> when dealing with data that needs to be copied to the guest memory space.
>>> Also reduce the number of section headers copied to the minimum necessary.
>> ...
>>>  #define elf_hdr_elm(_elf, _hdr, _elm, _val) \
>>>  do {\
>>>  if ( elf_64bit(_elf) )  \
>>> -elf_store_field(_elf, _hdr, e64._elm, _val);  \
>>> +(_hdr).e64._elm = _val; \
>> 
>> This seems to bypass the safe store mechanism which was introduced to
>> fix XSA-55.
> 
> This macro is only used to store fields inside of a structure that's
> allocated on the stack, and it doesn't involve any kind of pointer
> magic/arithmetic. The way it was used previously in this function indeed
> required the use of the _safe mechanism in order to prevent writing into
> arbitrary memory places, because we were actually modifying guest memory
> IIRC.
> 
> I could restore the previous behaviour, but that would mean adding some
> handlers in order to access the structure. Since this is only used for
> Dom0, which already makes use of the elf_memcpy_unchecked function as
> called by elf_store_val which is in turn called from elf_store_field, so
> it's not like we were protected previously anyway.

If this is indeed Dom0-only code, could (and perhaps should) it be
guarded suitably by an #ifdef to make obvious it's not used for
DomU loading, and hence not security sensitive? From looking at
the call sites of elf_{parse,load}_bsdsyms() I can't, btw., tell that
this is Dom0-only ...

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

[Shannon Zhao]

On 2016/1/18 21:33, Jan Beulich wrote:
 On 16.01.16 at 06:01,  wrote:
>> > --- a/xen/drivers/acpi/osl.c
>> > +++ b/xen/drivers/acpi/osl.c
>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
>> > acpi_os_get_root_pointer(void)
>> >  void __iomem *
>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >  {
>> > -  if (system_state >= SYS_STATE_active) {
>> > -  mfn_t mfn = _mfn(PFN_DOWN(phys));
>> > -  unsigned int offs = phys & (PAGE_SIZE - 1);
>> > -
>> > -  /* The low first Mb is always mapped. */
>> > -  if ( !((phys + size - 1) >> 20) )
>> > -  return __va(phys);
>> > -  return __vmap(, PFN_UP(offs + size), 1, 1,
>> > -PAGE_HYPERVISOR_NOCACHE) + offs;
>> > -  }
>> > -  return __acpi_map_table(phys, size);
>> > +  return arch_acpi_os_map_memory(phys, size);
>> >  }
> I'm quite sure I've said before that this goes too far: The __vmap()
> part and likely also the early-boot __acpi_map_table() one already
> are architecture independent and hence should stay. The factoring
> hence should only concern the first Mb handling and maybe the
> the mapping attributes passed to __vmap().

Yes, the first MB handling and __vmap() should refactor. So if it only
moves them to an architecture function, how about below patch?

diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
index cc15ea3..5885a3a 100644
--- a/xen/arch/x86/acpi/lib.c
+++ b/xen/arch/x86/acpi/lib.c
@@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
 u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
 {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };

+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+   mfn_t mfn = _mfn(PFN_DOWN(phys));
+   unsigned int offs = phys & (PAGE_SIZE - 1);
+
+   /* The low first Mb is always mapped. */
+   if ( !((phys + size - 1) >> 20) )
+   return __va(phys);
+   return __vmap(, PFN_UP(offs + size), 1, 1,
+ PAGE_HYPERVISOR_NOCACHE) + offs;
+}
+
 /*
  * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
  * from the fixed base.  That's why we start at FIX_ACPI_END and
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index a2fc8c4..e2dda2e 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -88,16 +88,8 @@ acpi_physical_address __init
acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-   if (system_state >= SYS_STATE_active) {
-   mfn_t mfn = _mfn(PFN_DOWN(phys));
-   unsigned int offs = phys & (PAGE_SIZE - 1);
-
-   /* The low first Mb is always mapped. */
-   if ( !((phys + size - 1) >> 20) )
-   return __va(phys);
-   return __vmap(, PFN_UP(offs + size), 1, 1,
- PAGE_HYPERVISOR_NOCACHE) + offs;
-   }
+   if (system_state >= SYS_STATE_active)
+   return arch_acpi_os_map_memory(phys, size);
return __acpi_map_table(phys, size);
 }


-- 
Shannon


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

[Jan Beulich]

>>> On 22.01.16 at 09:38,  wrote:

> 
> On 2016/1/18 21:33, Jan Beulich wrote:
> On 16.01.16 at 06:01,  wrote:
>>> > --- a/xen/drivers/acpi/osl.c
>>> > +++ b/xen/drivers/acpi/osl.c
>>> > @@ -86,17 +86,7 @@ acpi_physical_address __init 
> acpi_os_get_root_pointer(void)
>>> >  void __iomem *
>>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>>> >  {
>>> > - if (system_state >= SYS_STATE_active) {
>>> > - mfn_t mfn = _mfn(PFN_DOWN(phys));
>>> > - unsigned int offs = phys & (PAGE_SIZE - 1);
>>> > -
>>> > - /* The low first Mb is always mapped. */
>>> > - if ( !((phys + size - 1) >> 20) )
>>> > - return __va(phys);
>>> > - return __vmap(, PFN_UP(offs + size), 1, 1,
>>> > -   PAGE_HYPERVISOR_NOCACHE) + offs;
>>> > - }
>>> > - return __acpi_map_table(phys, size);
>>> > + return arch_acpi_os_map_memory(phys, size);
>>> >  }
>> I'm quite sure I've said before that this goes too far: The __vmap()
>> part and likely also the early-boot __acpi_map_table() one already
>> are architecture independent and hence should stay. The factoring
>> hence should only concern the first Mb handling and maybe the
>> the mapping attributes passed to __vmap().
> 
> Yes, the first MB handling and __vmap() should refactor. So if it only
> moves them to an architecture function, how about below patch?
> 
> diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
> index cc15ea3..5885a3a 100644
> --- a/xen/arch/x86/acpi/lib.c
> +++ b/xen/arch/x86/acpi/lib.c
> @@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
> 
> +void __iomem *
> +arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> +{
> +   mfn_t mfn = _mfn(PFN_DOWN(phys));
> +   unsigned int offs = phys & (PAGE_SIZE - 1);
> +
> +   /* The low first Mb is always mapped. */
> +   if ( !((phys + size - 1) >> 20) )
> +   return __va(phys);
> +   return __vmap(, PFN_UP(offs + size), 1, 1,
> + PAGE_HYPERVISOR_NOCACHE) + offs;
> +}

Well, I had clearly said the vmap() part is generic; if there's
anything architecture dependent here, then the mapping
attributes (and hence only _those_ should be factored out,
not the entire function invocation).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/3] tools: introduce parameter max_wp_ram_ranges.

[Jan Beulich]

>>> On 22.01.16 at 04:20,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -940,6 +940,10 @@ static int hvm_ioreq_server_alloc_rangesets(struct 
> hvm_ioreq_server *s,
>  {
>  unsigned int i;
>  int rc;
> +unsigned int max_wp_ram_ranges =
> +( s->domain->arch.hvm_domain.params[HVM_PARAM_MAX_WP_RAM_RANGES] > 0 
> ) ?
> +s->domain->arch.hvm_domain.params[HVM_PARAM_MAX_WP_RAM_RANGES] :
> +MAX_NR_IO_RANGES;

Besides this having stray blanks inside the parentheses it truncates
the value from 64 to 32 bits and would benefit from using the gcc
extension of omitting the middle operand of ?:. But even better
would imo be if you avoided the local variable and ...

> @@ -962,7 +966,10 @@ static int hvm_ioreq_server_alloc_rangesets(struct 
> hvm_ioreq_server *s,
>  if ( !s->range[i] )
>  goto fail;
>  
> -rangeset_limit(s->range[i], MAX_NR_IO_RANGES);
> +if ( i == HVMOP_IO_RANGE_WP_MEM )
> +rangeset_limit(s->range[i], max_wp_ram_ranges);
> +else
> +rangeset_limit(s->range[i], MAX_NR_IO_RANGES);

... did the entire computation here, using ?: for the second argument
of the function invocation.

> @@ -6009,6 +6016,7 @@ static int hvm_allow_set_param(struct domain *d,
>  case HVM_PARAM_IOREQ_SERVER_PFN:
>  case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
>  case HVM_PARAM_ALTP2M:
> +case HVM_PARAM_MAX_WP_RAM_RANGES:
>  if ( value != 0 && a->value != value )
>  rc = -EEXIST;
>  break;

Is there a particular reason you want this limit to be unchangeable
after having got set once?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

[Michael Brown]

On 21/01/16 21:37, Konrad Rzeszutek Wilk wrote:

On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:

Sure, do we know if that ICC compatible? Do we care? There are a
series of ICC hacks put in place on ipxe's original solution which
I've folded in, it seems that works but if we care about ICC those
folks should perhaps help review as well.


I didn't know the kernel could even be compiled with ICC? Thought
only GCC worked?

Anyhow - it may be that those fixes were for quite old ICC versions.
Does the latest one manifest these oddities?


I haven't tested building iPXE with icc for some time.  (The support for 
icc was originally added with the plan to be able to compile to EFI Byte 
Code; this plan was swiftly abandoned.)


The most recent version of icc that I have personally used with that 
code was 10.1.018.


Michael

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 25/31] xen/x86: Common infrastructure for levelling context switching

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -35,6 +35,9 @@ integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
>  unsigned int __initdata expected_levelling_cap;
>  unsigned int __read_mostly levelling_caps;
>  
> +DEFINE_PER_CPU(struct cpumasks, cpumasks);
> +struct cpumasks __read_mostly cpumask_defaults;

Any reason these can't be introduced when first used? (The question
really applies to the rest of this patch too, I guess.)

> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -585,6 +585,21 @@ int microcode_resume_cpu(unsigned int cpu);
>   */
>  extern unsigned int expected_levelling_cap, levelling_caps;
>  
> +struct cpumasks
> +{
> +uint64_t _1cd;
> +uint64_t e1cd;
> +uint64_t Da1;
> +uint64_t _6c;
> +uint64_t _7ab0;
> +};

While I see the need for these underscore prefixes with the
current naming scheme, perhaps it would be better to make
this fully consistent with the acronym #define-s, by e.g.
prefixing the base ones with 'b'? Such full naming consistency
would allow for string concatenation in macros, should such a
possibility ever arise, no matter whether manifest constants
or structure members here are needed to be accessed.

As to the name of the structure itself - perhaps better
cpuidmasks?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 26/31] xen/x86: Rework AMD masking MSR setup

[Jan Beulich]

>>> On 22.01.16 at 12:01,  wrote:
> On 22/01/16 09:27, Jan Beulich wrote:
> On 16.12.15 at 22:24,  wrote:
>>> +  expected_levelling_cap, levelling_caps,
>>> +  (expected_levelling_cap ^ levelling_caps) & levelling_caps);
>>> +   printk(XENLOG_WARNING "Fam %#x, model %#x level %#x\n",
>>> +  c->x86, c->x86_model, c->cpuid_level);
>>> +   printk(XENLOG_WARNING
>>> +  "If not running virtualised, please report a bug\n");
>> Well - you checked for running virtualized, so making it here when
>> running virtualized is already a bug (albeit not in the code here)?
> 
> Why would it be a bug?  The virtualising environment might provide these
> MSRs, in which case we should use them.

Because you won't make it here when cpu_has_hypervisor.

>>> +void amd_ctxt_switch_levelling(const struct domain *nextd)
>>> +{
>>> +   struct cpumasks *these_masks = _cpu(cpumasks);
>>> +   const struct cpumasks *masks = _defaults;
>>> +
>>> +#define LAZY(cap, msr, field)  
>>> \
>>> +   ({  \
>>> +   if ( ((levelling_caps & cap) == cap) && \
>>> +(these_masks->field != masks->field) ) \
>>> +   {   \
>>> +   wrmsr_amd(msr, masks->field);   \
>>> +   these_masks->field = masks->field;  \
>>> +   }   \
>>> +   })
>>> +
>>> +   LAZY(LCAP_1cd,  MSR_K8_FEATURE_MASK,   _1cd);
>>> +   LAZY(LCAP_e1cd, MSR_K8_EXT_FEATURE_MASK,   e1cd);
>>> +   LAZY(LCAP_7ab0, MSR_AMD_L7S0_FEATURE_MASK, _7ab0);
>>> +   LAZY(LCAP_6c,   MSR_AMD_THRM_FEATURE_MASK, _6c);
>> So here we already have the first example where fully consistent
>> naming would allow elimination of a macro parameter.
> 
> Token concatenation deliberately obscures code from tool like grep and
> cscope.  There is already too much of the Xen source code obscured like
> this; I'd prefer not to add to it.

I'm not sure grep-abilty is more important than code readability.
My personal opinion surely is that the latter is more important.

>> And then, how is this supposed to work? You only restore defaults,
>> but never write non-default values. Namely, nextd is an unused
>> function parameter ...
>>
>> Also I guess my comment about adding unused code needs
>> repeating here.
> 
> Future patches build on this, both using the parameter, and not using
> the defaults.
> 
> I am also certain that if I did two patches, the first putting in a void
> function, and the second changing it to a pointer, your review would ask
> me to turn it into this.

Well, I realize things will all make sense by the end of the series, but
honestly in some of the cases I'm not sure the split between patches
was well done. But just to be clear, none of the related comments
mean I would outright reject any of the patches just for that reason.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PULL 10/11] Add Error **errp for xen_pt_config_init()

[Paolo Bonzini]

On 21/01/2016 18:01, Stefano Stabellini wrote:
> -XEN_PT_LOG(>dev, "Failed to initialize %d/%ld reg 
> 0x%x in grp_type=0x%x (%d/%ld), rc=%d\n",
> -   j, 
> ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
> -   regs->offset, 
> xen_pt_emu_reg_grps[i].grp_type,
> -   i, ARRAY_SIZE(xen_pt_emu_reg_grps), rc);
> +xen_pt_config_reg_init(s, reg_grp_entry, regs, );
> +if (err) {
> +error_append_hint(, "Failed to initialize %d/%zu"
> +" reg 0x%x in grp_type = 0x%x (%d/%zu)",
> +j, 
> ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),

Coverity noticed a preexisting problem here.  emu_regs is a pointer,
thus ARRAY_SIZE doesn't return what you expect.

Paolo

> +regs->offset, 
> xen_pt_emu_reg_grps[i].grp_type,
> +i, ARRAY_SIZE(xen_pt_emu_reg_grps));
> +error_propagate(errp, err);

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v11 2/3] Differentiate IO/mem resources tracked by ioreq server

[Jan Beulich]

>>> On 22.01.16 at 04:20,  wrote:
> @@ -2601,6 +2605,16 @@ struct hvm_ioreq_server 
> *hvm_select_ioreq_server(struct domain *d,
>  type = (p->type == IOREQ_TYPE_PIO) ?
>  HVMOP_IO_RANGE_PORT : HVMOP_IO_RANGE_MEMORY;
>  addr = p->addr;
> +if ( type == HVMOP_IO_RANGE_MEMORY )
> +{
> + ram_page = get_page_from_gfn(d, p->addr >> PAGE_SHIFT,
> +  , P2M_UNSHARE);

It seems to me like I had asked before: Why P2M_UNSHARE instead
of just P2M_QUERY? (This could surely be fixed up while committing,
the more that I've already done some cleanup here, but I'd like to
understand this before it goes in.)

> + if ( p2mt == p2m_mmio_write_dm )
> + type = HVMOP_IO_RANGE_WP_MEM;
> +
> + if ( ram_page )
> + put_page(ram_page);
> +}
>  }
>  
>  list_for_each_entry ( s,
> @@ -2642,6 +2656,11 @@ struct hvm_ioreq_server 
> *hvm_select_ioreq_server(struct domain *d,
>  }
>  
>  break;
> +case HVMOP_IO_RANGE_WP_MEM:
> +if ( rangeset_contains_singleton(r, PFN_DOWN(addr)) )
> +return s;

Considering you've got p2m_mmio_write_dm above - can this
validly return false here?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/4] xl: consolidate adhoc parsers

[Wei Liu]

This patch series consolidates adhoc parsers in xl.

There are currently 4 types of devices:

1. block
2. netowrk
3. vtpm
4. pci

that support hotplug as well as being specified in config file.

Block and pci devices are fine because they use libxlu to parse
configuration strings.

Network and vtpms config parsers are not in a very good state, which
need to be consolidated.

Note that there is code repetition in the newly introduced parser
code. We either need to have very long macro definition or code
repetition. I chose the latter. Let me know your opinion.

Wei.

Wei Liu (4):
  xl: remove unused macros
  xl: wrap long lines where possible
  xl: rework vif config parsing code
  xl: rework vtpm config parsing code

 tools/libxl/xl_cmdimpl.c | 312 +++
 1 file changed, 207 insertions(+), 105 deletions(-)

-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/4] xl: remove unused macros

[Wei Liu]

They were added back in 2011 to be used in an adhoc parser which has now
been removed.

Signed-off-by: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f9933cb..f380799 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -556,14 +556,6 @@ static int parse_action_on_shutdown(const char *buf, 
libxl_action_on_shutdown *a
 return 0;
 }
 
-#define DSTATE_INITIAL   0
-#define DSTATE_TAP   1
-#define DSTATE_PHYSPATH  2
-#define DSTATE_VIRTPATH  3
-#define DSTATE_VIRTTYPE  4
-#define DSTATE_RW5
-#define DSTATE_TERMINAL  6
-
 static void parse_disk_config_multistring(XLU_Config **config,
   int nspecs, const char *const *specs,
   libxl_device_disk *disk)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan]

Hi Jan,

On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote:
 On 22.01.16 at 10:27,  wrote:
>> Hi Jan,
>> 
>> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
>> On 22.01.16 at 02:56,  wrote:
 On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>At the very least it would need to be avoided by denying the request.
>Upon shared use, either all parties agree, or only one may use the
>clock. And passing through a (platform) device would therefore imply
>validating that the needed clock(s) are available to the target domain.
>Doing this in a consistent way with all control in one component's
>hands seems doable only if hypervisor and/or tool stack are the
>controlling (and arbitrating) entity. In the end this is one of the
>reasons why to me a simple PV I/O interface doesn't seem suitable
>here.
 
 How about let userspace libxl pvclk code to denying the request?
>>>
>>>Userspace would be fine, but
>> 
>> Then you are ok with the pvclk way to handle clock for platform device 
>> passthrough?
>
>No, not really. While I accept that doing clock management in the
>hypervisor is undesirable, we're still not at the point where such
>a frontend/backend pair would look like the only possible route
>out of a dilemma, and I continue to think that this proposed model
>should indeed only be the last resort.

Thanks for following the thread and giving comments.
Alougth this frustrate me, we still need to find a better option for this.

>
>In particular, with the user space exposure of clock control
>discussed in another sub-thread, the next best option would
>seem to be to handle this via emulation in a device model. Yes,
>ARM guests currently have no qemu attached to them, but I
>guess sooner or later this will need to change anyway.

I have not look into qemu for xen.
If using qemu, then we still need to expose the clk interface to userspace?

>
>>>- How would this fit in your frontend/backend model, where
>>>  userspace shouldn't be involved at all?
>> 
>> rethought about this. clk is binded to device. we can not passthrough
>> one device to two guest, so this means we can not let two different
>> guest access one clk input. Since this is mainly for embedded products,
>> just as Ian said "experts option", the developer should be aware of
>> the clk sharing between two device.
>> 
>> If we truly need to let userspace deny the request. If one clk
>> already assigned to Dom1, then the toolstack need to fail
>> the creation of Dom2, if Dom2 want to use the same clock.
>
>I.e. you're now proposing actual assignment of clocks to guests?
>That's at least one step in the (from my pov) right direction...

Based on the pvclk, I am coding the userspace tool part. Alought we have
not find a good solution for this, I first need it work on my platform.

Later I'll also try the fixed clock way.

Thanks,
Peng.
>
>Jan
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

[Jan Beulich]

>>> On 22.01.16 at 12:55,  wrote:

> 
> On 2016/1/22 18:15, Jan Beulich wrote:
> On 22.01.16 at 10:37,  wrote:
>>> >
>>> >On 2016/1/22 16:47, Jan Beulich wrote:
>>> >On 22.01.16 at 09:38,  wrote:
>> >>> >
>> >>> >On 2016/1/18 21:33, Jan Beulich wrote:
>> >>> >On 16.01.16 at 06:01,  
>> >>> >wrote:
 >> >>> >--- a/xen/drivers/acpi/osl.c
 >> >>> >+++ b/xen/drivers/acpi/osl.c
 >> >>> >@@ -86,17 +86,7 @@ acpi_physical_address __init
>> >>> >acpi_os_get_root_pointer(void)
 >> >>> >  void __iomem *
 >> >>> >  acpi_os_map_memory(acpi_physical_address phys, 
 >> >>> > acpi_size size)
 >> >>> >  {
 >> >>> >-  if (system_state >= SYS_STATE_active) {
 >> >>> >-  mfn_t mfn = _mfn(PFN_DOWN(phys));
 >> >>> >-  unsigned int offs = phys & (PAGE_SIZE - 
 >> >>> >1);
 >> >>> >-
 >> >>> >-  /* The low first Mb is always mapped. */
 >> >>> >-  if ( !((phys + size - 1) >> 20) )
 >> >>> >-  return __va(phys);
 >> >>> >-  return __vmap(, PFN_UP(offs + 
 >> >>> >size), 1, 1,
 >> >>> >-PAGE_HYPERVISOR_NOCACHE) 
 >> >>> >+ offs;
 >> >>> >-  }
 >> >>> >-  return __acpi_map_table(phys, size);
 >> >>> >+  return arch_acpi_os_map_memory(phys, size);
 >> >>> >  }
  >>I'm quite sure I've said before that this goes too far: The 
  >>__vmap()
  >>part and likely also the early-boot __acpi_map_table() one 
  >>already
  >>are architecture independent and hence should stay. The 
  >>factoring
  >>hence should only concern the first Mb handling and maybe the
  >>the mapping attributes passed to __vmap().
>> >>> >
>> >>> >Yes, the first MB handling and __vmap() should refactor. So if it 
>> >>> >only
>> >>> >moves them to an architecture function, how about below patch?
>> >>> >
>> >>> >diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>> >>> >index cc15ea3..5885a3a 100644
>> >>> >--- a/xen/arch/x86/acpi/lib.c
>> >>> >+++ b/xen/arch/x86/acpi/lib.c
>> >>> >@@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>> >>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>> >>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>> >>> >
>> >>> >+void __iomem *
>> >>> >+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >>> >+{
>> >>> >+   mfn_t mfn = _mfn(PFN_DOWN(phys));
>> >>> >+   unsigned int offs = phys & (PAGE_SIZE - 1);
>> >>> >+
>> >>> >+   /* The low first Mb is always mapped. */
>> >>> >+   if ( !((phys + size - 1) >> 20) )
>> >>> >+   return __va(phys);
>> >>> >+   return __vmap(, PFN_UP(offs + size), 1, 1,
>> >>> >+ PAGE_HYPERVISOR_NOCACHE) + offs;
>> >>> >+}
 >>Well, I had clearly said the vmap() part is generic; if there's
 >>anything architecture dependent here, then the mapping
 >>attributes (and hence only_those_  should be factored out,
 >>not the entire function invocation).
>>> >I know what you said. But how can we change the attribute for ARM in
>>> >acpi_os_map_memory() without moving these codes out?
>> By having each arch #define their value, and use that constant here?
> You really want that?

Yes.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID

[Roger Pau Monné]

El 22/01/16 a les 11.57, Jan Beulich ha escrit:
 On 21.01.16 at 17:51,  wrote:
>> Add a new HVM-specific feature flag that signals the presence of a bitmap
>> that contains the current set of enabled emulated devices. The bitmap is
>> placed in the ecx register. The bit fields used in the bitmap are the same
>> as the ones used in the xen_arch_domainconfig emulation_flags field, and
>> their meaning can be found at arch-x86/xen.h.
>>
>> This will allow Xen to enable emulated devices for HVMlite guests in the
>> future, by having a proper ABI for reporting which devices are enabled.
> 
> The idea is certainly nice and appreciated, but ...
> 
>> --- a/xen/include/public/arch-x86/cpuid.h
>> +++ b/xen/include/public/arch-x86/cpuid.h
>> @@ -78,12 +78,17 @@
>>   * HVM-specific features
>>   * EAX: Features
>>   * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag)
>> + * ECX: bitmap of enabled devices, according to the bit fields defined in
>> + *  arch-x86/xen.h.
> 
> ... this set of definitions is not currently a stable ABI (limited to
> hypervisor and tool stack), and if we wanted to make it stable
> we'd first need to think a little about the complications that may
> arise if the granularity chosen (think about the PM bit and the
> discussion around it before your changes went in) turns out to
> be a problem later on.

Yes, in fact I'm having second thoughts on the PM flag, and I think I
should have split it into ACPI_PM and ACPI_TIMER instead.

> Also at least some of the features can be determined by other
> means (CPUID, ACPI tables), so I'm not even sure we need all
> of this, and I'd really prefer to avoid multiple distinct ways to
> learn of a certain feature, as it's too easy for the two (or more)
> mechanisms to get out of sync.

So let's look at the flags and whether there's an existing way to signal
it's presence:

LAPIC: CPUID.01h:EDX[bit 9]
IOAPIC: tied to LAPIC (so either both enabled or none).

HPET: can only be enabled from/with ACPI, since it's base memory address
is not fixed, and we would need to find a way to pass it's address to
the OS in the absence of ACPI.

RTC: I don't know of any way to signal the RTC presence, AFAICT it's
always assumed to be there in the PC architecture. Could maybe return ~0
when reading from IO port 0x71, but that's meh..., not the best way IMHO.

PIC: same as RTC, I don't know of any way to signal it's presence since
it's assumed to be there.

VGA: again I don't think there's an easy way to signal it's presence,
apart from returning ~0 from the multiple IO ports it uses. The fact
that the 0xA-0xB memory range is also marked as RAM in the e820
map in HVMlite DomUs should also trigger OSes into disabling VGA due to
the lack of proper MMIO range, but sadly I think most OSes just assume
it's there.

PIT: assumed to be always present in the PC architecture.

PM: I'm leaning to split this into ACPI_PM and ACPI_TIMER as said
before. ACPI_TIMER presence it's contained inside of ACPI tables, and
the availability of ACPI_PM (power management) can be inferred from the
presence of ACPI itself.

AMD guest IOMMU: AFAICT this seems to be currently disabled, since the
MMIO range it checks is [~0ULL, ~0ULL + 0x8000]. There is a function to
change the base address ~0ULL to something else, but it doesn't seem to
be reachable from any path. In any case, I guess the presence of this
device will be reported from ACPI.

So, we have the following devices that are assumed to be there: RTC,
PIC, PIT. Everything else I think can be signalled by other means
already available.

IMHO, I think we could say that the PIC is never going to be available
to HVMlite guests (in any case we would enable the lapic/ioapic), and
maybe enable the RTC and PIT by default?

Then I think we could get away without any Xen-specific way of reporting
enabled devices.

>> All unused bits have undefined values.
> 
> Nor is this an option, but maybe this is just a wording issue:
> Perhaps you mean to say that they're reserved for future use?
> Since truly unused bits have are guaranteed to have the value
> zero, just that the set of bits varies.

Yes, that's exactly what I meant to say, thanks.

Roger.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andrew Cooper]

On 22/01/16 12:56, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 22.09.2015 10:53, Ian Campbell wrote:
>> Hi Vladimir & grub-devel,
>>
>> Do you have any thoughts on this issue with i386 pv-grub2?
>>
> Is it still an issue? If so I'll try to replicate it. From stack dump I
> see that it has jumped to NULL. GRUB has no threads so it's not a race
> condition with itself but may be one with some Xen part. An altrnative
> possibility is that grub forgets to flush cache at some point in boot
> process.

Looks like GRUB doesn't have a traptable registered with Xen (the PV
equivalent of the IDT).

First, Xen tried to inject a #GP fault and found that the entry EIP was
at 0 (which is sadly the default if nothing is specified).  It then took
a pagefault while attempting to inject the #GP, and crashed the domain.

~Andrew

>> Thanks, Ian.
>>
>> On Mon, 2015-09-21 at 22:03 +0200, Andreas Sundstrom wrote:
>>> This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
>>> applied) and Xen 4.4.1
>>>
>>> I originally posted a bug report with Debian but got the suggestion to
>>> file bugs with upstream as well.
>>> Debian bug report:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480
>>>
>>> Note that my original thought was that this bug probably is within GRUB.
>>> But Ian asked me to file a bug with Xen as well, you have to live with
>>> the
>>> fact that it is centered around GRUB though.
>>>
>>> Here's the information from my original bug report:
>>>
>>> Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
>>> fail when chainloading the domU's grub. 64-bit domU seem to work 100%
>>> of the time.
>>>
>>> My understanding of the process:
>>>
>>>  * dom0 launches domU with grub that is loaded from dom0's disk.
>>>  * Grub reads config file from memdisk, and then looks for grub binary in
>>> domU filesystem.
>>>  * If grub is found in domU it then chainloads (multiboot) that grub
>>> binary
>>> and the domU grub reads grub.cfg and continue booting.
>>>  * If grub is not found in domU it reads grub.cfg and continues with
>>> boot.
>>>
>>> It fails at step 3 in my list of the boot process, but sometimes it
>>> does work so it may be something like a race condition that causes the
>>> problem?
>>>
>>> A workaround is to not install or rename /boot/xen in domU so that the
>>> first grub that is loaded from dom0's disk will not find the grub
>>> binary in the domU filesystem and hence continues to read grub.cfg and
>>> boot. The drawback of this is of course that the two versions can't
>>> differ too much as there are different setups creating grub.cfg and
>>> then reading/parsing it at boot time.
>>>
>>> I am not sure at this point whether this is a problem in XEN or a
>>> problem in grub but I compiled the legacy pvgrub that uses some minios
>>> from XEN (don't really know much more about it) and when that legacy
>>> pvgrub chainloads the domU grub it seems to work 100% of the time. Now
>>> the legace pvgrub is not a real alternative as it's not packaged for
>>> Debian though.
>>>
>>> When it fails "xl create vm -c" outputs this:
>>> Parsing config from /etc/xen/vm
>>> libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
>>> type for domid=16
>>> Unable to attach console
>>> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
>>> child [0] exited with error status 1
>>>
>>> And "xl dmesg" shows errors like this:
>>> (XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from
>>> 0x to 0x.
>>> (XEN) d16:v0: unhandled page fault (ec=0010)
>>> (XEN) Pagetable walk from :
>>> (XEN) L4[0x000] = 000200256027 049c
>>> (XEN) L3[0x000] = 000200255027 049d
>>> (XEN) L2[0x000] = 000200251023 04a1
>>> (XEN) L1[0x000] =  
>>> (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
>>> compat_create_bounce_frame+0xc6/0xde
>>> (XEN) Domain 16 (vcpu#0) crashed on cpu#0:
>>> (XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ]
>>> (XEN) CPU: 0
>>> (XEN) RIP: e019:[<>]
>>> (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest
>>> (XEN) rax:  rbx:  rcx: 
>>> (XEN) rdx:  rsi: 00499000 rdi: 0080
>>> (XEN) rbp: 000a rsp: 005a5ff0 r8: 
>>> (XEN) r9:  r10: 83023e9b9000 r11: 83023e9b9000
>>> (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940
>>> (XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0
>>> (XEN) cr3: 000200b7a000 cr2: 
>>> (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019
>>> (XEN) Guest stack trace from esp=005a5ff0:
>>> (XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
>>> 0016b388
>>> (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent

[Shannon Zhao]

On 2016/1/22 18:15, Jan Beulich wrote:

On 22.01.16 at 10:37,  wrote:

>
>On 2016/1/22 16:47, Jan Beulich wrote:

>On 22.01.16 at 09:38,  wrote:

>>> >
>>> >On 2016/1/18 21:33, Jan Beulich wrote:

>>> >On 16.01.16 at 06:01,  wrote:

>> >>> >--- a/xen/drivers/acpi/osl.c
>> >>> >+++ b/xen/drivers/acpi/osl.c
>> >>> >@@ -86,17 +86,7 @@ acpi_physical_address __init

>>> >acpi_os_get_root_pointer(void)

>> >>> >  void __iomem *
>> >>> >  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> >>> >  {
>> >>> >- if (system_state >= SYS_STATE_active) {
>> >>> >- mfn_t mfn = _mfn(PFN_DOWN(phys));
>> >>> >- unsigned int offs = phys & (PAGE_SIZE - 1);
>> >>> >-
>> >>> >- /* The low first Mb is always mapped. */
>> >>> >- if ( !((phys + size - 1) >> 20) )
>> >>> >- return __va(phys);
>> >>> >- return __vmap(, PFN_UP(offs + size), 1, 1,
>> >>> >-   PAGE_HYPERVISOR_NOCACHE) + offs;
>> >>> >- }
>> >>> >- return __acpi_map_table(phys, size);
>> >>> >+ return arch_acpi_os_map_memory(phys, size);
>> >>> >  }

 >>I'm quite sure I've said before that this goes too far: The __vmap()
 >>part and likely also the early-boot __acpi_map_table() one already
 >>are architecture independent and hence should stay. The factoring
 >>hence should only concern the first Mb handling and maybe the
 >>the mapping attributes passed to __vmap().

>>> >
>>> >Yes, the first MB handling and __vmap() should refactor. So if it only
>>> >moves them to an architecture function, how about below patch?
>>> >
>>> >diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
>>> >index cc15ea3..5885a3a 100644
>>> >--- a/xen/arch/x86/acpi/lib.c
>>> >+++ b/xen/arch/x86/acpi/lib.c
>>> >@@ -33,6 +33,19 @@ u8 __read_mostly acpi_disable_value;
>>> >  u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
>>> >  {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
>>> >
>>> >+void __iomem *
>>> >+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>>> >+{
>>> >+   mfn_t mfn = _mfn(PFN_DOWN(phys));
>>> >+   unsigned int offs = phys & (PAGE_SIZE - 1);
>>> >+
>>> >+   /* The low first Mb is always mapped. */
>>> >+   if ( !((phys + size - 1) >> 20) )
>>> >+   return __va(phys);
>>> >+   return __vmap(, PFN_UP(offs + size), 1, 1,
>>> >+ PAGE_HYPERVISOR_NOCACHE) + offs;
>>> >+}

>>Well, I had clearly said the vmap() part is generic; if there's
>>anything architecture dependent here, then the mapping
>>attributes (and hence only_those_  should be factored out,
>>not the entire function invocation).

>I know what you said. But how can we change the attribute for ARM in
>acpi_os_map_memory() without moving these codes out?

By having each arch #define their value, and use that constant here?
You really want that? Even though the way here I use is not too many 
dunplicated codes (and I think it looks clearer).


--
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[Wei Liu]

The comment at the beginning of the file is the canonical source of
licenses for this module. Currently it contains GPL and MIT license. Fix
the code to reflect the reality.

Signed-off-by: Wei Liu 
---
 drivers/net/xen-netback/netback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 61b97c3..2427242 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -2192,5 +2192,5 @@ static void __exit netback_fini(void)
 }
 module_exit(netback_fini);
 
-MODULE_LICENSE("Dual BSD/GPL");
+MODULE_LICENSE("Dual MIT/GPL");
 MODULE_ALIAS("xen-backend:vif");
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/3] xen-blkback: fix license ident used in MODULE_LICENSE

[Wei Liu]

The comment at the beginning of the file is the canonical source of
licenses for this module. Currently it contains GPL and MIT license.
Fix the code to reflect the reality.

Signed-off-by: Wei Liu 
---
 drivers/block/xen-blkback/blkback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 4809c15..01cc572 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -1496,5 +1496,5 @@ static int __init xen_blkif_init(void)
 
 module_init(xen_blkif_init);
 
-MODULE_LICENSE("Dual BSD/GPL");
+MODULE_LICENSE("Dual MIT/GPL");
 MODULE_ALIAS("xen-backend:vbd");
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.09.2015 10:53, Ian Campbell wrote:
> Hi Vladimir & grub-devel,
> 
> Do you have any thoughts on this issue with i386 pv-grub2?
> 
Is it still an issue? If so I'll try to replicate it. From stack dump I
see that it has jumped to NULL. GRUB has no threads so it's not a race
condition with itself but may be one with some Xen part. An altrnative
possibility is that grub forgets to flush cache at some point in boot
process.
> Thanks, Ian.
> 
> On Mon, 2015-09-21 at 22:03 +0200, Andreas Sundstrom wrote:
>> This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
>> applied) and Xen 4.4.1
>>
>> I originally posted a bug report with Debian but got the suggestion to
>> file bugs with upstream as well.
>> Debian bug report:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480
>>
>> Note that my original thought was that this bug probably is within GRUB.
>> But Ian asked me to file a bug with Xen as well, you have to live with
>> the
>> fact that it is centered around GRUB though.
>>
>> Here's the information from my original bug report:
>>
>> Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
>> fail when chainloading the domU's grub. 64-bit domU seem to work 100%
>> of the time.
>>
>> My understanding of the process:
>>
>>  * dom0 launches domU with grub that is loaded from dom0's disk.
>>  * Grub reads config file from memdisk, and then looks for grub binary in
>> domU filesystem.
>>  * If grub is found in domU it then chainloads (multiboot) that grub
>> binary
>> and the domU grub reads grub.cfg and continue booting.
>>  * If grub is not found in domU it reads grub.cfg and continues with
>> boot.
>>
>> It fails at step 3 in my list of the boot process, but sometimes it
>> does work so it may be something like a race condition that causes the
>> problem?
>>
>> A workaround is to not install or rename /boot/xen in domU so that the
>> first grub that is loaded from dom0's disk will not find the grub
>> binary in the domU filesystem and hence continues to read grub.cfg and
>> boot. The drawback of this is of course that the two versions can't
>> differ too much as there are different setups creating grub.cfg and
>> then reading/parsing it at boot time.
>>
>> I am not sure at this point whether this is a problem in XEN or a
>> problem in grub but I compiled the legacy pvgrub that uses some minios
>> from XEN (don't really know much more about it) and when that legacy
>> pvgrub chainloads the domU grub it seems to work 100% of the time. Now
>> the legace pvgrub is not a real alternative as it's not packaged for
>> Debian though.
>>
>> When it fails "xl create vm -c" outputs this:
>> Parsing config from /etc/xen/vm
>> libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
>> type for domid=16
>> Unable to attach console
>> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
>> child [0] exited with error status 1
>>
>> And "xl dmesg" shows errors like this:
>> (XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from
>> 0x to 0x.
>> (XEN) d16:v0: unhandled page fault (ec=0010)
>> (XEN) Pagetable walk from :
>> (XEN) L4[0x000] = 000200256027 049c
>> (XEN) L3[0x000] = 000200255027 049d
>> (XEN) L2[0x000] = 000200251023 04a1
>> (XEN) L1[0x000] =  
>> (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
>> compat_create_bounce_frame+0xc6/0xde
>> (XEN) Domain 16 (vcpu#0) crashed on cpu#0:
>> (XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ]
>> (XEN) CPU: 0
>> (XEN) RIP: e019:[<>]
>> (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest
>> (XEN) rax:  rbx:  rcx: 
>> (XEN) rdx:  rsi: 00499000 rdi: 0080
>> (XEN) rbp: 000a rsp: 005a5ff0 r8: 
>> (XEN) r9:  r10: 83023e9b9000 r11: 83023e9b9000
>> (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940
>> (XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0
>> (XEN) cr3: 000200b7a000 cr2: 
>> (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019
>> (XEN) Guest stack trace from esp=005a5ff0:
>> (XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
>> 0016b388
>> (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381
>> 0016b380
>> (XEN) 0016b37f 0016b37e 0016b37d 0016b37c 0016b37b 0016b37a 0016b379
>> 0016b378
>> (XEN) 0016b377 0016b376 0016b375 0016b374 0016b373 0016b372 0016b371
>> 0016b370
>> (XEN) 0016b36f 0016b36e 0016b36d 0016b36c 0016b36b 0016b36a 0016b369
>> 0016b368
>> (XEN) 0016b367 0016b366 0016b365 0016b364 0016b363 0016b362 0016b361
>> 0016b360
>> (XEN) 0016b35f 0016b35e 0016b35d 0016b35c 0016b35b 0016b35a 0016b359
>> 0016b358
>> (XEN) 0016b357 0016b356 0016b355 0016b354 

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.01.2016 14:01, Andrew Cooper wrote:
> On 22/01/16 12:56, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 22.09.2015 10:53, Ian Campbell wrote:
>>> Hi Vladimir & grub-devel,
>>>
>>> Do you have any thoughts on this issue with i386 pv-grub2?
>>>
>> Is it still an issue? If so I'll try to replicate it. From stack dump I
>> see that it has jumped to NULL. GRUB has no threads so it's not a race
>> condition with itself but may be one with some Xen part. An altrnative
>> possibility is that grub forgets to flush cache at some point in boot
>> process.
> 
> Looks like GRUB doesn't have a traptable registered with Xen (the PV
> equivalent of the IDT).
> 
> First, Xen tried to inject a #GP fault and found that the entry EIP was
> at 0 (which is sadly the default if nothing is specified).  It then took
> a pagefault while attempting to inject the #GP, and crashed the domain.
> 
Do you have a link how to add one? We can put a catch-stacktrace-abort
on it.
> ~Andrew
> 
>>> Thanks, Ian.
>>>
>>> On Mon, 2015-09-21 at 22:03 +0200, Andreas Sundstrom wrote:
 This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
 applied) and Xen 4.4.1

 I originally posted a bug report with Debian but got the suggestion to
 file bugs with upstream as well.
 Debian bug report:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480

 Note that my original thought was that this bug probably is within GRUB.
 But Ian asked me to file a bug with Xen as well, you have to live with
 the
 fact that it is centered around GRUB though.

 Here's the information from my original bug report:

 Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
 fail when chainloading the domU's grub. 64-bit domU seem to work 100%
 of the time.

 My understanding of the process:

  * dom0 launches domU with grub that is loaded from dom0's disk.
  * Grub reads config file from memdisk, and then looks for grub binary in
 domU filesystem.
  * If grub is found in domU it then chainloads (multiboot) that grub
 binary
 and the domU grub reads grub.cfg and continue booting.
  * If grub is not found in domU it reads grub.cfg and continues with
 boot.

 It fails at step 3 in my list of the boot process, but sometimes it
 does work so it may be something like a race condition that causes the
 problem?

 A workaround is to not install or rename /boot/xen in domU so that the
 first grub that is loaded from dom0's disk will not find the grub
 binary in the domU filesystem and hence continues to read grub.cfg and
 boot. The drawback of this is of course that the two versions can't
 differ too much as there are different setups creating grub.cfg and
 then reading/parsing it at boot time.

 I am not sure at this point whether this is a problem in XEN or a
 problem in grub but I compiled the legacy pvgrub that uses some minios
 from XEN (don't really know much more about it) and when that legacy
 pvgrub chainloads the domU grub it seems to work 100% of the time. Now
 the legace pvgrub is not a real alternative as it's not packaged for
 Debian though.

 When it fails "xl create vm -c" outputs this:
 Parsing config from /etc/xen/vm
 libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
 type for domid=16
 Unable to attach console
 libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
 child [0] exited with error status 1

 And "xl dmesg" shows errors like this:
 (XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from
 0x to 0x.
 (XEN) d16:v0: unhandled page fault (ec=0010)
 (XEN) Pagetable walk from :
 (XEN) L4[0x000] = 000200256027 049c
 (XEN) L3[0x000] = 000200255027 049d
 (XEN) L2[0x000] = 000200251023 04a1
 (XEN) L1[0x000] =  
 (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
 compat_create_bounce_frame+0xc6/0xde
 (XEN) Domain 16 (vcpu#0) crashed on cpu#0:
 (XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ]
 (XEN) CPU: 0
 (XEN) RIP: e019:[<>]
 (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest
 (XEN) rax:  rbx:  rcx: 
 (XEN) rdx:  rsi: 00499000 rdi: 0080
 (XEN) rbp: 000a rsp: 005a5ff0 r8: 
 (XEN) r9:  r10: 83023e9b9000 r11: 83023e9b9000
 (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940
 (XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0
 (XEN) cr3: 000200b7a000 cr2: 
 (XEN) ds: e021 es: e021 fs: 

[Xen-devel] [PATCH 3/4] xl: rework vif config parsing code

[Wei Liu]

The original parse_nic_config was in fact only parsing tokens.
main_networkattach erroneously used it to parse raw config string, which
led to xl network-attach not respecting network configuration syntax.

Rework vif config parser:

1. Extract the snippet in parse_config_data to parse_nic_config_one.
2. Rename original parse_nic_config to parse_nic_config_token.
3. Provide _multistring variant.
4. Implement parse_nic_config with _multistring variant.
5. Use _multistring variant in main_networkattach.

Finally the call chain becomes: parse_nic_config ->
parse_nic_config_multistring -> parse_nic_config_one ->
parse_nic_config_token.

Some other less important changes:

1. Change prototypes of parse_nic_config functions to match
   block counterpart.
2. parse_nic_config will now exit if parsing failed.
3. main_networkattach doesn't call set_default_nic_values anymore.

Signed-off-by: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 82 +++-
 1 file changed, 60 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index ff561c3..f736f95 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1000,8 +1000,9 @@ static int match_option_size(const char *prefix, size_t 
len,
 /* Parses network data and adds info into nic
  * Returns 1 if the input token does not match one of the keys
  * or parsed values are not correct. Successful parse returns 0 */
-static int parse_nic_config(libxl_device_nic *nic, XLU_Config **config,
-char *token)
+static int parse_nic_config_token(XLU_Config **config,
+  char *token,
+  libxl_device_nic *nic)
 {
 char *endptr, *oparg;
 int i;
@@ -1056,6 +1057,59 @@ static int parse_nic_config(libxl_device_nic *nic, 
XLU_Config **config,
 return 0;
 }
 
+static int parse_nic_config_one(XLU_Config **config,
+const char *config_str,
+libxl_device_nic *nic)
+{
+char *buf = xstrdup(config_str);
+char *p;
+int ret;
+
+set_default_nic_values(nic);
+
+p = strtok(buf, ",");
+if (!p) {
+ret = 0;
+goto out;
+}
+
+do {
+while (*p == ' ')
+p++;
+ret = parse_nic_config_token(config, p, nic);
+} while ((p = strtok(NULL, ",")) != NULL && ret == 0);
+
+out:
+free(buf);
+
+return ret;
+}
+
+static void parse_nic_config_multistring(XLU_Config **config,
+ int nspecs, const char *const *specs,
+ libxl_device_nic *nic)
+{
+int i;
+
+libxl_device_nic_init(nic);
+
+if (!*config) {
+*config = xlu_cfg_init(stderr, "command line");
+if (!*config) { perror("xlu_cfg_init"); exit(-1); }
+}
+
+for (i = 0; i < nspecs; i++) {
+if (parse_nic_config_one(config, specs[i], nic))
+exit(EXIT_FAILURE);
+}
+}
+
+static void parse_nic_config(XLU_Config **config, const char *buf,
+ libxl_device_nic *nic)
+{
+parse_nic_config_multistring(config, 1, , nic);
+}
+
 static unsigned long parse_ulong(const char *str)
 {
 char *endptr;
@@ -1928,24 +1982,10 @@ static void parse_config_data(const char *config_source,
 while ((buf = xlu_cfg_get_listitem (nics, d_config->num_nics))
!= NULL) {
 libxl_device_nic *nic;
-char *buf2 = strdup(buf);
-char *p;
-
 nic = ARRAY_EXTEND_INIT(d_config->nics,
 d_config->num_nics,
 libxl_device_nic_init);
-set_default_nic_values(nic);
-
-p = strtok(buf2, ",");
-if (!p)
-goto skip_nic;
-do {
-while (*p == ' ')
-p++;
-parse_nic_config(nic, , p);
-} while ((p = strtok(NULL, ",")) != NULL);
-skip_nic:
-free(buf2);
+parse_nic_config(, buf, nic);
 }
 }
 
@@ -6532,12 +6572,10 @@ int main_networkattach(int argc, char **argv)
 }
 
 libxl_device_nic_init();
-set_default_nic_values();
 
-for (argv += optind+1, argc -= optind+1; argc > 0; ++argv, --argc) {
-if (parse_nic_config(, , *argv))
-return 1;
-}
+optind++;
+parse_nic_config_multistring(, argc-optind,
+ (const char* const*) argv + optind, );
 
 if (dryrun_only) {
 char *json = libxl_device_nic_to_json(ctx, );
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/3] xen-scsiback: fix license ident used in MODULE_LICENSE

[Wei Liu]

The comment at the beginning of the file is the canonical source of
licenses for this module. Currently it contains GPL and MIT license.
Fix the code to reflect the reality.

Signed-off-by: Wei Liu 
---
 drivers/xen/xen-scsiback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index ad4eb10..0695cf8 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -1915,6 +1915,6 @@ module_init(scsiback_init);
 module_exit(scsiback_exit);
 
 MODULE_DESCRIPTION("Xen SCSI backend driver");
-MODULE_LICENSE("Dual BSD/GPL");
+MODULE_LICENSE("Dual MIT/GPL");
 MODULE_ALIAS("xen-backend:vscsi");
 MODULE_AUTHOR("Juergen Gross ");
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] xen-blkback: fix license ident used in MODULE_LICENSE

[Roger Pau Monné]

El 22/01/16 a les 13.34, Wei Liu ha escrit:
> The comment at the beginning of the file is the canonical source of
> licenses for this module. Currently it contains GPL and MIT license.
> Fix the code to reflect the reality.
> 
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen-scsiback: fix license ident used in MODULE_LICENSE

[Juergen Gross]

On 22/01/16 13:34, Wei Liu wrote:
> The comment at the beginning of the file is the canonical source of
> licenses for this module. Currently it contains GPL and MIT license.
> Fix the code to reflect the reality.
> 
> Signed-off-by: Wei Liu 

Acked-by: Juergen Gross 

> ---
>  drivers/xen/xen-scsiback.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
> index ad4eb10..0695cf8 100644
> --- a/drivers/xen/xen-scsiback.c
> +++ b/drivers/xen/xen-scsiback.c
> @@ -1915,6 +1915,6 @@ module_init(scsiback_init);
>  module_exit(scsiback_exit);
>  
>  MODULE_DESCRIPTION("Xen SCSI backend driver");
> -MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_LICENSE("Dual MIT/GPL");
>  MODULE_ALIAS("xen-backend:vscsi");
>  MODULE_AUTHOR("Juergen Gross ");
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] VirtFS support on Xen

[Paul Durrant]

> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Wei Liu
> Sent: 22 January 2016 10:51
> To: Bob Liu
> Cc: Xen-devel; Wei Liu; David Vrabel
> Subject: Re: [Xen-devel] [RFC] VirtFS support on Xen
> 
> On Fri, Jan 22, 2016 at 06:45:30PM +0800, Bob Liu wrote:
> > Hi Wei,
> >
> > On 01/21/2016 06:59 PM, Wei Liu wrote:
> > > On Thu, Jan 21, 2016 at 10:50:08AM +, David Vrabel wrote:
> > >> On 21/01/16 10:28, Wei Liu wrote:
> > >>> [RFC] VirtFS support on Xen
> > >>>
> > >>> # Introduction
> > >>>
> > >>> QEMU/KVM supports file system passthrough via an interface called
> > >>> VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
> > >>> VirtIO transport.
> > >>>
> > >>> Xen used to have its own implementation of file system passthrough
> > >>> called XenFS, but that has been inactive for a few years. The latest
> > >>> update was in 2009 [2].
> > >>>
> > >>> This project aims to add VirtFS support on Xen. This is more
> > >>> sustainable than inventing our own wheel.#
> > >>
> > >> What's the use case for this?  Who wants this feature?
> > >>
> > >
> > > Anyone who wants file system passthrough.  More specifically, VM-
> based
> > > container solutions can share files from host file system.
> > >
> >
> > I'm a bit confused, can't we just use the VirtFS of Qemu?
> > E.g
> > ./configure --with-extra-qemuu-configure-args="--enable-virtfs"
> >
> 
> Yes, in theory you can -- with VirtIO transport. But I'm not sure if
> Virtio has been fixed to work with Xen.  That also means you need QEMU
> emulation, which we don't really need (or want) when running in PV or
> PVH mode.
> 

Is there not scope for:

a) Fixing VirtIO so it does work with Xen?
b) Resurrecting the idea of emulator disaggregation so that we could spawn a 
QEMU that only serves as a VirtIO backend so that this can be used for PV/PHV 
guests?

Seems like a better solution that implementing our own 9p transport and backend.

  Paul

> 
> Wei.
> 
> 
> > Thanks,
> > Bob
> >
> > > http://xendevsummit2015.sched.org/event/3WDg/xen-containers-
> better-way-to-run-docker-containers-sainath-grandhi-
> intel?iframe=no==yes=no
> > > http://xendevsummit2015.sched.org/event/3X1L/hyper-make-vm-run-
> like-containers-xu-wang-hyper?iframe=no==yes=no
> > >
> > > Wei.
> > >
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] VirtFS support on Xen

[Wei Liu]

On Fri, Jan 22, 2016 at 11:12:01AM +, Paul Durrant wrote:
> > -Original Message-
> > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> > boun...@lists.xen.org] On Behalf Of Wei Liu
> > Sent: 22 January 2016 10:51
> > To: Bob Liu
> > Cc: Xen-devel; Wei Liu; David Vrabel
> > Subject: Re: [Xen-devel] [RFC] VirtFS support on Xen
> > 
> > On Fri, Jan 22, 2016 at 06:45:30PM +0800, Bob Liu wrote:
> > > Hi Wei,
> > >
> > > On 01/21/2016 06:59 PM, Wei Liu wrote:
> > > > On Thu, Jan 21, 2016 at 10:50:08AM +, David Vrabel wrote:
> > > >> On 21/01/16 10:28, Wei Liu wrote:
> > > >>> [RFC] VirtFS support on Xen
> > > >>>
> > > >>> # Introduction
> > > >>>
> > > >>> QEMU/KVM supports file system passthrough via an interface called
> > > >>> VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
> > > >>> VirtIO transport.
> > > >>>
> > > >>> Xen used to have its own implementation of file system passthrough
> > > >>> called XenFS, but that has been inactive for a few years. The latest
> > > >>> update was in 2009 [2].
> > > >>>
> > > >>> This project aims to add VirtFS support on Xen. This is more
> > > >>> sustainable than inventing our own wheel.#
> > > >>
> > > >> What's the use case for this?  Who wants this feature?
> > > >>
> > > >
> > > > Anyone who wants file system passthrough.  More specifically, VM-
> > based
> > > > container solutions can share files from host file system.
> > > >
> > >
> > > I'm a bit confused, can't we just use the VirtFS of Qemu?
> > > E.g
> > > ./configure --with-extra-qemuu-configure-args="--enable-virtfs"
> > >
> > 
> > Yes, in theory you can -- with VirtIO transport. But I'm not sure if
> > Virtio has been fixed to work with Xen.  That also means you need QEMU
> > emulation, which we don't really need (or want) when running in PV or
> > PVH mode.
> > 
> 
> Is there not scope for:
> 
> a) Fixing VirtIO so it does work with Xen?

Presumably you mean fixing VirtIO to work with Xen HVM guest.  Yes.
Stefano sent patches for fixing that. That involves changing some
assumptions in Virtio design. Not sure how it goes at the moment. As far
as I can tell those patches are not yet upstreamed or have been
superseded by some other patches promised to be written by someone else.

> b) Resurrecting the idea of emulator disaggregation so that we could
> spawn a QEMU that only serves as a VirtIO backend so that this can be
> used for PV/PHV guests?
> 

I think disaggregation of emulators is a different and orthogonal issue.
(There is on-going work to spawn two QEMU for HVM guests, one for PV
backends, one for emulation.)

PV can't use existing Virtio transports because there is no emulation
for PV guest, unless we write Xen transport for Virtio. After
investigation I found it very hard to finish in a finite time frame  and
unsustainable in the long run.

PVH can possibly use VirtIO, but how it is going to be implemented is
unclear.  There are a few things to get hashed out before we can think
of VirtIO with PVH guests.  There is nothing that prevents we make
VirtIO work with PVH in the future though, once everything is in place.

Wei.

> Seems like a better solution that implementing our own 9p transport and 
> backend.
> 
>   Paul
> 
> > 
> > Wei.
> > 
> > 
> > > Thanks,
> > > Bob
> > >
> > > > http://xendevsummit2015.sched.org/event/3WDg/xen-containers-
> > better-way-to-run-docker-containers-sainath-grandhi-
> > intel?iframe=no==yes=no
> > > > http://xendevsummit2015.sched.org/event/3X1L/hyper-make-vm-run-
> > like-containers-xu-wang-hyper?iframe=no==yes=no
> > > >
> > > > Wei.
> > > >
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] EDAC infomation partially missing

[Andreas Pflug]

Am 22.01.16 um 11:40 schrieb Jan Beulich:
 On 22.01.16 at 10:09,  wrote:
>> When booting with Xen 4.4.1:
>>
>> AMD64 EDAC driver v3.4.0
>> EDAC amd64: DRAM ECC enabled.
>> EDAC amd64: NB MCE bank disabled, set MSR 0x017b[4] on node 0 to enable.
> I wonder how valid his message is. We actually write this MSR with
> all ones during boot.
>
> However, considering involved functions like
> nb_mce_bank_enabled_on_node() or node_to_amd_nb() taking
> node IDs as inputs, and considering that PV guests (including
> Dom0) don't have a topology matching that of the host, I doubt
> very much that this driver is even remotely prepared to run
> under Xen. It working on Xen 4.1.x would then be by pure
> accident.
The dmesg is identical with or without Xen4.1, so I'd guess it does work
if flags are detected correctly.

Regards
Andreas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 4/4] xl: rework vtpm config parsing code

[Wei Liu]

Follow the same pattern as vif config parse to introduce
parse_vtpm_config_token, parse_vtpm_config_one,
parse_vtpm_config_multistring and parse_vtpm_config. Then replace
open-coded parsing code with appropriate functions.

Signed-off-by: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 119 ++-
 1 file changed, 76 insertions(+), 43 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f736f95..1444b0b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1110,6 +1110,76 @@ static void parse_nic_config(XLU_Config **config, const 
char *buf,
 parse_nic_config_multistring(config, 1, , nic);
 }
 
+static int parse_vtpm_config_token(XLU_Config **config, char *token,
+   libxl_device_vtpm *vtpm)
+{
+char *oparg;
+
+if (MATCH_OPTION("uuid", token, oparg)) {
+if(libxl_uuid_from_string(>uuid, oparg)) {
+fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);
+return 1;
+}
+} else if (MATCH_OPTION("backend", token, oparg)) {
+replace_string(>backend_domname, oparg);
+} else {
+fprintf(stderr, "unrecognized argument `%s'\n", token);
+return 1;
+}
+
+return 0;
+}
+
+static int parse_vtpm_config_one(XLU_Config **config, const char *config_str,
+ libxl_device_vtpm *vtpm)
+{
+char *buf = xstrdup(config_str);
+char *p;
+int ret;
+
+p = strtok(buf, ",");
+if (!p) {
+ret = 0;
+goto out;
+}
+
+do {
+while (*p == ' ')
+p++;
+ret = parse_vtpm_config_token(config, p, vtpm);
+} while ((p = strtok(NULL, ",")) != NULL && ret == 0);
+
+out:
+free(buf);
+
+return ret;
+}
+
+static void parse_vtpm_config_multistring(XLU_Config **config,
+  int nspecs, const char *const *specs,
+  libxl_device_vtpm *vtpm)
+{
+int i;
+
+libxl_device_vtpm_init(vtpm);
+
+if (!*config) {
+*config = xlu_cfg_init(stderr, "command line");
+if (!*config) { perror("xlu_cfg_init"); exit(-1); }
+}
+
+for (i = 0; i < nspecs; i++) {
+if (parse_vtpm_config_one(config, specs[i], vtpm))
+exit(EXIT_FAILURE);
+}
+}
+
+static void parse_vtpm_config(XLU_Config **config, const char *buf,
+  libxl_device_vtpm *vtpm)
+{
+parse_vtpm_config_multistring(config, 1, , vtpm);
+}
+
 static unsigned long parse_ulong(const char *str)
 {
 char *endptr;
@@ -1858,42 +1928,17 @@ static void parse_config_data(const char *config_source,
 while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms))
!= NULL) {
 libxl_device_vtpm *vtpm;
-char * buf2 = strdup(buf);
-char *p, *p2;
-bool got_backend = false;
 
 vtpm = ARRAY_EXTEND_INIT(d_config->vtpms,
  d_config->num_vtpms,
  libxl_device_vtpm_init);
 
-p = strtok(buf2, ",");
-if(p) {
-   do {
-  while(*p == ' ')
- ++p;
-  if ((p2 = strchr(p, '=')) == NULL)
- break;
-  *p2 = '\0';
-  if (!strcmp(p, "backend")) {
- vtpm->backend_domname = strdup(p2 + 1);
- got_backend = true;
-  } else if(!strcmp(p, "uuid")) {
- if( libxl_uuid_from_string(>uuid, p2 + 1) ) {
-fprintf(stderr,
-  "Failed to parse vtpm UUID: %s\n", p2 + 1);
-exit(1);
-}
-  } else {
- fprintf(stderr, "Unknown string `%s' in vtpm spec\n", p);
- exit(1);
-  }
-   } while ((p = strtok(NULL, ",")) != NULL);
-}
-if(!got_backend) {
+parse_vtpm_config(, buf, vtpm);
+
+if(!vtpm->backend_domname) {
fprintf(stderr, "vtpm spec missing required backend field!\n");
exit(1);
 }
-free(buf2);
 }
 }
 
@@ -6812,8 +6857,8 @@ int main_vtpmattach(int argc, char **argv)
 {
 int opt;
 libxl_device_vtpm vtpm;
-char *oparg;
 uint32_t domid;
+XLU_Config *config = 0;
 
 SWITCH_FOREACH_OPT(opt, "", NULL, "vtpm-attach", 1) {
 /* No options */
@@ -6825,20 +6870,8 @@ int main_vtpmattach(int argc, char **argv)
 }
 ++optind;
 
-libxl_device_vtpm_init();
-for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) {
-if (MATCH_OPTION("uuid", *argv, oparg)) {
-if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
-fprintf(stderr, "Invalid uuid specified (%s)\n", 

[Xen-devel] [PATCH 2/4] xl: wrap long lines where possible

[Wei Liu]

No functional changes introduced.

Signed-off-by: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 107 ---
 1 file changed, 73 insertions(+), 34 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f380799..ff561c3 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -237,12 +237,14 @@ static int acquire_lock(void)
 fl.l_len = 0;
 fd_lock = open(lockfile, O_WRONLY|O_CREAT, S_IWUSR);
 if (fd_lock < 0) {
-fprintf(stderr, "cannot open the lockfile %s errno=%d\n", lockfile, 
errno);
+fprintf(stderr, "cannot open the lockfile %s errno=%d\n",
+lockfile, errno);
 return ERROR_FAIL;
 }
 if (fcntl(fd_lock, F_SETFD, FD_CLOEXEC) < 0) {
 close(fd_lock);
-fprintf(stderr, "cannot set cloexec to lockfile %s errno=%d\n", 
lockfile, errno);
+fprintf(stderr, "cannot set cloexec to lockfile %s errno=%d\n",
+lockfile, errno);
 return ERROR_FAIL;
 }
 get_lock:
@@ -538,12 +540,16 @@ out:
 return ret;
 }
 
-static int parse_action_on_shutdown(const char *buf, libxl_action_on_shutdown 
*a)
+static int parse_action_on_shutdown(const char *buf,
+libxl_action_on_shutdown *a)
 {
-int i;
+int i, size;
 const char *n;
 
-for (i = 0; i < sizeof(action_on_shutdown_names) / 
sizeof(action_on_shutdown_names[0]); i++) {
+size = sizeof(action_on_shutdown_names) /
+sizeof(action_on_shutdown_names[0]);
+
+for (i = 0; i < size; i++) {
 n = action_on_shutdown_names[i];
 
 if (!n) continue;
@@ -994,7 +1000,8 @@ static int match_option_size(const char *prefix, size_t 
len,
 /* Parses network data and adds info into nic
  * Returns 1 if the input token does not match one of the keys
  * or parsed values are not correct. Successful parse returns 0 */
-static int parse_nic_config(libxl_device_nic *nic, XLU_Config **config, char 
*token)
+static int parse_nic_config(libxl_device_nic *nic, XLU_Config **config,
+char *token)
 {
 char *endptr, *oparg;
 int i;
@@ -1040,7 +1047,8 @@ static int parse_nic_config(libxl_device_nic *nic, 
XLU_Config **config, char *to
 } else if (MATCH_OPTION("rate", token, oparg)) {
 parse_vif_rate(config, oparg, nic);
 } else if (MATCH_OPTION("accel", token, oparg)) {
-fprintf(stderr, "the accel parameter for vifs is currently not 
supported\n");
+fprintf(stderr,
+"the accel parameter for vifs is currently not supported\n");
 } else {
 fprintf(stderr, "unrecognized argument `%s'\n", token);
 return 1;
@@ -1580,13 +1588,15 @@ static void parse_config_data(const char *config_source,
 
 if (l < LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS ||
 l > LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING) {
-fprintf(stderr, "ERROR: invalid value %ld for 
\"timer_mode\"\n", l);
+fprintf(stderr,
+"ERROR: invalid value %ld for \"timer_mode\"\n", l);
 exit (1);
 }
 b_info->u.hvm.timer_mode = l;
 } else if (!xlu_cfg_get_string(config, "timer_mode", , 0)) {
 if (libxl_timer_mode_from_string(buf, _info->u.hvm.timer_mode)) {
-fprintf(stderr, "ERROR: invalid value \"%s\" for 
\"timer_mode\"\n",
+fprintf(stderr,
+"ERROR: invalid value \"%s\" for \"timer_mode\"\n",
 buf);
 exit (1);
 }
@@ -1605,7 +1615,8 @@ static void parse_config_data(const char *config_source,
 if (!strcmp(buf, "generate")) {
 e = libxl_ms_vm_genid_generate(ctx, 
_info->u.hvm.ms_vm_genid);
 if (e) {
-fprintf(stderr, "ERROR: failed to generate a VM Generation 
ID\n");
+fprintf(stderr,
+"ERROR: failed to generate a VM Generation ID\n");
 exit(1);
 }
 } else if (!strcmp(buf, "none")) {
@@ -1621,7 +1632,8 @@ static void parse_config_data(const char *config_source,
 break;
 case LIBXL_DOMAIN_TYPE_PV:
 {
-xlu_cfg_replace_string (config, "bootloader", 
_info->u.pv.bootloader, 0);
+xlu_cfg_replace_string (config, "bootloader",
+_info->u.pv.bootloader, 0);
 switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
   _info->u.pv.bootloader_args, 1))
 {
@@ -1772,7 +1784,8 @@ static void parse_config_data(const char *config_source,
 if (!xlu_cfg_get_list (config, "disk", , 0, 0)) {
 d_config->num_disks = 0;
 d_config->disks = NULL;
-while ((buf = xlu_cfg_get_listitem (vbds, d_config->num_disks)) != 
NULL) {
+while ((buf = 

[Xen-devel] [PATCH 0/3] xen: fix wrong idents in MODULE_LICENSE in some drivers

[Wei Liu]

Wei Liu (3):
  xen-netback: fix license ident used in MODULE_LICENSE
  xen-blkback: fix license ident used in MODULE_LICENSE
  xen-scsiback: fix license ident used in MODULE_LICENSE

 drivers/block/xen-blkback/blkback.c | 2 +-
 drivers/net/xen-netback/netback.c   | 2 +-
 drivers/xen/xen-scsiback.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Jan Beulich]

>>> On 22.01.16 at 13:12,  wrote:
> On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote:
>>In particular, with the user space exposure of clock control
>>discussed in another sub-thread, the next best option would
>>seem to be to handle this via emulation in a device model. Yes,
>>ARM guests currently have no qemu attached to them, but I
>>guess sooner or later this will need to change anyway.
> 
> I have not look into qemu for xen.
> If using qemu, then we still need to expose the clk interface to userspace?

I think so, yes. In fact - see above - the discussed userspace
exposure made me consider this option.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Luis R. Rodriguez]

On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
> Start HVMlite guest XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
> page, initialize boot_params, enable early page tables.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/xen/Makefile  |1 +
>  arch/x86/xen/enlighten.c   |   91 +-
>  arch/x86/xen/xen-hvmlite.S |  158 
> 
>  include/xen/xen.h  |6 ++
>  4 files changed, 255 insertions(+), 1 deletions(-)
>  create mode 100644 arch/x86/xen/xen-hvmlite.S
> 
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index e47e527..1d913d7 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_XEN_DEBUG_FS)  += debugfs.o
>  obj-$(CONFIG_XEN_DOM0)   += vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)+= pci-swiotlb-xen.o
>  obj-$(CONFIG_XEN_EFI)+= efi.o
> +obj-$(CONFIG_XEN_PVHVM)  += xen-hvmlite.o
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 2cf446a..2ed8b2b 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -118,7 +118,8 @@ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>   */
>  DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
>  
> -enum xen_domain_type xen_domain_type = XEN_NATIVE;
> +enum xen_domain_type xen_domain_type
> + __attribute__((section(".data"))) = XEN_NATIVE;
>  EXPORT_SYMBOL_GPL(xen_domain_type);

But why? This is not explained.

>  
>  unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START;
> @@ -171,6 +172,17 @@ struct tls_descs {
>   */
>  static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
>  
> +#ifdef CONFIG_XEN_PVHVM
> +/*
> + * HVMlite variables. These need to live in data segment since they are
> + * initialized before startup_{32|64}, which clear .bss, are invoked.
> + */

I guess for this reason.. Perhaps a bit more clear:

/*
 * HVMlite variables. These need to live in data segment since they are 
 * before before startup_{32|64} is invoked, otherwise they would be cleared.
 */

> +int xen_hvmlite __attribute__((section(".data"))) = 0;
> +struct hvm_start_info hvmlite_start_info __attribute__((section(".data")));
> +uint hvmlite_start_info_sz = sizeof(hvmlite_start_info);
> +struct boot_params xen_hvmlite_boot_params __attribute__((section(".data")));
> +#endif
> +
>  static void clamp_max_cpus(void)
>  {
>  #ifdef CONFIG_SMP
> @@ -1736,6 +1748,83 @@ asmlinkage __visible void __init xen_start_kernel(void)
>  #endif
>  }
>  
> +#ifdef CONFIG_XEN_PVHVM
> +static void __init hvmlite_bootparams(void)
> +{

Hrm.

> + struct xen_memory_map memmap;
> + int i;
> +
> + memset(_hvmlite_boot_params, 0, sizeof(xen_hvmlite_boot_params));
> +
> + memmap.nr_entries = ARRAY_SIZE(xen_hvmlite_boot_params.e820_map);
> + set_xen_guest_handle(memmap.buffer, xen_hvmlite_boot_params.e820_map);
> + if (HYPERVISOR_memory_op(XENMEM_memory_map, )) {
> + xen_raw_console_write("XENMEM_memory_map failed\n");
> + BUG();
> + }
> +
> + xen_hvmlite_boot_params.e820_map[memmap.nr_entries].addr =
> + ISA_START_ADDRESS;
> + xen_hvmlite_boot_params.e820_map[memmap.nr_entries].size =
> + ISA_END_ADDRESS - ISA_START_ADDRESS;
> + xen_hvmlite_boot_params.e820_map[memmap.nr_entries++].type =
> + E820_RESERVED;
> +
> + sanitize_e820_map(xen_hvmlite_boot_params.e820_map,
> +   ARRAY_SIZE(xen_hvmlite_boot_params.e820_map),
> +   _entries);
> +
> + xen_hvmlite_boot_params.e820_entries = memmap.nr_entries;
> + for (i = 0; i < xen_hvmlite_boot_params.e820_entries; i++)
> + e820_add_region(xen_hvmlite_boot_params.e820_map[i].addr,
> + xen_hvmlite_boot_params.e820_map[i].size,
> + xen_hvmlite_boot_params.e820_map[i].type);
> +
> + xen_hvmlite_boot_params.hdr.cmd_line_ptr =
> + hvmlite_start_info.cmdline_paddr;
> +
> + /* The first module is always ramdisk */
> + if (hvmlite_start_info.nr_modules) {
> + struct hvm_modlist_entry *modaddr =
> + __va(hvmlite_start_info.modlist_paddr);
> + xen_hvmlite_boot_params.hdr.ramdisk_image = modaddr->paddr;
> + xen_hvmlite_boot_params.hdr.ramdisk_size = modaddr->size;
> + }
> +
> + /*
> +  * See Documentation/x86/boot.txt.
> +  *
> +  * Version 2.12 supports Xen entry point but we will use default x86/PC
> +  * environment (i.e. hardware_subarch 0).
> +  */
> + xen_hvmlite_boot_params.hdr.version = 0x212;
> + xen_hvmlite_boot_params.hdr.type_of_loader = 9; /* Xen loader */
> +}

I realize PV got away with setting up boot_params on C code but best
ask now that this new code is being introduced: why can't we just have
the Xen hypervisor fill this in? It'd save us all this code.

On 

Re: [Xen-devel] [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code

[Luis R. Rodriguez]

On Fri, Jan 22, 2016 at 06:12:47PM -0500, Boris Ostrovsky wrote:
> On 01/22/2016 06:01 PM, Luis R. Rodriguez wrote:
> >On Fri, Jan 22, 2016 at 04:35:48PM -0500, Boris Ostrovsky wrote:
> >>HVMlite guests (to be introduced in subsequent patches) share most
> >>of the kernel initialization code with PV(H).
> >>
> >>Signed-off-by: Boris Ostrovsky 
> >>---
> >>  arch/x86/xen/enlighten.c |  225 
> >> --
> >>  1 files changed, 119 insertions(+), 106 deletions(-)
> >>
> >>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >>index d09e4c9..2cf446a 100644
> >>--- a/arch/x86/xen/enlighten.c
> >>+++ b/arch/x86/xen/enlighten.c
> >Whoa, I'm lost, its hard for me to tell what exactly stayed and what
> >got pulled into a helper, etc. Is there a possibility to split this
> >patch in 2 somehow to make the actual functional changes easier to
> >read? There are too many changes here and I just can't tell easily
> >what's going on.
> 
> 
> The only real changes that this patch introduces is it reorders some
> of the operations that used to be in xen_start_kernel(). This is
> done so that in the next patch when we add hvmlite we can easily put
> those specific to PV(H) inside 'if (!xen_hvm_domain())'. I probably
> should have said so in the commit message.

Ah, I see thanks.

> It is indeed difficult to review but I don't see how I can split
> this. Even if I just moved it (without reordering) it would still be
> hard to read.

A code shuffle but yet introducing non-functional changes as you did
in some other patches might help if possible, but sure if you can say
this is non-functional here or if you can split this up.

  Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Luis R. Rodriguez]

On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
 wrote:
> I would have though the correct way to do direct Linux support would be
> to have a very small init stub which constructs an appropriate zero
> page, and lets the native entry point get on with things.

As hpa noted recently in another thread [0] that is precisely what
hardware_subarch and hardware_subarch_data was meant to be used for,
and its what I'm alluding to.

The only thing though is that as far as we're concerned on x86 we had
expected use of hardware_subarch and hardware_subarch_data only for
PV, and not for HVM. This seems to be HVM related, but I think this is
just a rebranding of PVH to HVMLite, right, so I think the use case of
hardware_subarch and hardware_subarch_data are still welcomed as
expected in the original design.

[0] http://lkml.kernel.org/r/56a130b5.8060...@zytor.com

 Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] schedulers and topology exposing questions

[Elena Ufimtseva]

On Fri, Jan 22, 2016 at 06:29:19PM +0100, Dario Faggioli wrote:
> On Fri, 2016-01-22 at 11:54 -0500, Elena Ufimtseva wrote:
> > Hello all!
> >
> Hello,
>
> > Let me put some intro to our findings. I may forget something or put
> > something
> > not too explicit, please ask me.
> >
> > Customer filled a bug where some of the applications were running
> > slow in their HVM DomU setups.
> > These running times were compared against baremetal running same
> > kernel version as HVM DomU.
> >
> > After some investigation by different parties, the test case scenario
> > was found
> > where the problem was easily seen. The test app is a udp
> > server/client pair where
> > client passes some message n number of times.
> > The test case was executed on baremetal and Xen DomU with kernel
> > version 2.6.39.
> > Bare metal showed 2x times better result that DomU.
> >
> > Konrad came up with a workaround that was setting the flag for domain
> > scheduler in linux
> > As the guest is not aware of SMT-related topology, it has a flat
> > topology initialized.
> > Kernel has domain scheduler flags for scheduling domain CPU set to
> > 4143 for 2.6.39.
> > Konrad discovered that changing the flag for CPU sched domain to 4655
> > works as a workaround and makes Linux think that the topology has SMT
> > threads.
> > This workaround makes the test to complete almost in same time as on
> > baremetal (or insignificantly worse).
> >
> > This workaround is not suitable for kernels of higher versions as we
> > discovered.
> >
> > The hackish way of making domU linux think that it has SMT threads
> > (along with matching cpuid)
> > made us thinks that the problem comes from the fact that cpu topology
> > is not exposed to
> > guest and Linux scheduler cannot make intelligent decision on
> > scheduling.
> >
> So, me an Juergen (from SuSE) have been working on this for a while
> too.
>
> As far as my experiments goes, there are at least two different issues,
> both traceable to Linux's scheduler behavior. One has to do with what
> you just say, i.e., topology.
>
> Juergen has developed a set of patches, and I'm running benchamrks with
> them applied to both Dom0 and DomU, to see how they work.
>
> I'm not far from finishing running a set of 324 different test cases
> (each one run both without and with Juergen's patches). I am running
> different benchamrks, such as:
>  - iperf,
>  - a Xen build,
>  - sysbench --oltp,
>  - sysbench --cpu,
>  - unixbench
>
> and I'm also varying how loaded the host is, how big the VMs are, and
> how loaded the VMs are.

Thats pretty cool. I also tried in my tests oversubscribed tests.

>
> 324 is the result of various combinations of the above... It's quite an
> extensive set! :-P

It is! Even with my few tests its a lot of work.
>
> As soon as everything finishes running, I'll data mine the results, and
> let you know how they look like.
>
>
> The other issue that I've observed is that tweaking some _non_ topology
> related scheduling domains' flags also impact performance, sometimes in
> a quite sensible way.
>
> I have got the results from the 324 test cases described above of
> running with flags set to 4131 inside all the DomUs. That value was
> chosen after quite a bit of preliminary benchmarking and investigation
> as well.
>
> I'll share the results of that data set as well as soon as I manage to
> extract them from the raw output.

>
> > Joao Martins from Oracle developed set of patches that fixed the
> > smt/core/cashe
> > topology numbering and provided matching pinning of vcpus and
> > enabling options,
> > allows to expose to guest correct topology.
> > I guess Joao will be posting it at some point.
> >
> That is one way of approaching the topology issue. The other, which is
> what me and Juergen are pursuing, is the opposite one, i.e., make the
> DomU (and Dom0, actually) think that the topology is always completely
> flat.
>
> I think, ideally, we want both: flat topology as the default, if no
> pinning is specifying. Matching topology if it is.
>
> > With this patches we decided to test the performance impact on
> > different kernel versionand Xen versions.
> >
> That is really interesting, and thanks a lot for sharing it with us.
>
> I'm in the middle of something here, so I just wanted to quickly let
> you know that we're also working on something related... I'll have a
> look at the rest of the email and at the graphs ASAP.

Great!
I am attaching the io and cpu-bound tests that were used to get the
data.

Thanks Dario!
>
> Thanks again and Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)
>




perf_tests.tar.gz
Description: application/gzip
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel