Re: [Xen-devel] Question about Xen reboot on panic

[Meng Xu]

Hi Jan,

2015-11-12 12:08 GMT-05:00 Jan Beulich :
 On 12.11.15 at 17:57,  wrote:
>>> After looking into the code, I found the following code in the
>>> machine_restart(), which is quite suspicious.
>>>
>>> if ( system_state >= SYS_STATE_smp_boot )
>>>
>>> {
>>>
>>> local_irq_enable();
>>>
>>>
>>> /* Ensure we are the boot CPU. */
>>>
>>> if ( get_apic_id() != boot_cpu_physical_apicid )
>>
>> If we are at the boot CPU and the if statement return true
>>
>>>
>>> {
>>>
>>> /* Send IPI to the boot CPU (logical cpu 0). */
>>>
>>> on_selected_cpus(cpumask_of(0), __machine_restart,
>>>
>>>  _millisecs, 0);
>>
>> we will send an IPI from CPU 0 to CPU to run machine_restart.
>
> The other way around you mean.
>
>>>
>>> for ( ; ; )
>>>
>>> halt();
>>
>> and CPU 0 will halt immediately.
>>
>> If the IPI arrives later on CPU 0, CPU 0 won't be able to handle it,
>> since it has been halted.
>
> It's CPUn that gets halted, not CPU0. This ...

You are right.  When system_state > SYS_STATE_smp_boot, CPU i (i != 0)
will send IPI to CPU 0.


>
>> (XEN) On P0
>> As this line suggests, P0 sends P0 an IPI and P0 goes to halt immediately...
>
> ... is suspicious: Is boot_cpu_physical_apicid not set correctly?
> Or is get_apic_id() returning rubbish?

After printing out the boot_cpu_physical_apicid and get_apic_id, I
found that are correct!

However, the line after that if statement is:
smp_send_stop();

which is not in the if ( get_apic_id() != boot_cpu_physical_apicid ) statement.

So P0 may run this code, and from what I read from this
smp_send_stop(), it has the following code:

local_irq_disable();

__stop_this_cpu();

disable_IO_APIC();

hpet_disable();

local_irq_enable();

I'm guessing at __stop_this_cpu() when it is on P0, P0 will be
stopped. That's why P0 will never have the chance to proceed to the
rest of logic in the machine_restart(). Therefore, the machine won't
restart.

If I move this  smp_send_stop(void) into the if statement, Xen will reboot.

Do you think this could be a fix?
If I misunderstood anything, please let me know...

Thanks,

Meng


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCHv2] 23/27] build: convert HAS_MEM_PAGING use to Kconfig

[Razvan Cojocaru]

On 11/11/2015 06:50 PM, Doug Goldstein wrote:
> Use the Kconfig generated CONFIG_HAS_MEM_PAGING defines in the code base.
> 
> Signed-off-by: Doug Goldstein 
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Razvan Cojocaru 
> CC: Tamas K Lengyel 
> CC: Daniel De Graaf 
> Signed-off-by: Doug Goldstein 

The changes in the code I'm responsible for appear to be exclusively
mechanical (a macro has been renamed), so assuming that macro is
correctly being #defined by the build system:

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCHv2] 22/27] build: convert HAS_MEM_ACCESS use to Kconfig

[Razvan Cojocaru]

On 11/11/2015 06:50 PM, Doug Goldstein wrote:
> Use the Kconfig generated CONFIG_HAS_MEM_ACCESS defines in the code base.
> 
> Signed-off-by: Doug Goldstein 
> 
> CC: Ian Campbell 
> CC: Stefano Stabellini 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Razvan Cojocaru 
> CC: Tamas K Lengyel 
> CC: Daniel De Graaf 
> Signed-off-by: Doug Goldstein 

The changes in the code I'm responsible for appear to be exclusively
mechanical (a macro has been renamed), so assuming that macro is
correctly being #defined by the build system:

Acked-by: Razvan Cojocaru 


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

Re: [Xen-devel] [PATCH v4 0/9] libxc: support building large pv-domains

[Wei Liu]

On Thu, Nov 12, 2015 at 06:09:54AM +0100, Juergen Gross wrote:
> On 05/11/15 15:36, Juergen Gross wrote:
> > The Xen hypervisor supports starting a dom0 with large memory (up to
> > the TB range) by not including the initrd and p2m list in the initial
> > kernel mapping. Especially the p2m list can grow larger than the
> > available virtual space in the initial mapping.
> > 
> > The started kernel is indicating the support of each feature via
> > elf notes.
> > 
> > This series enables the domain builder in libxc to do the same as the
> > hypervisor. This enables starting of huge pv-domUs via xl.
> > 
> > Unmapped initrd is supported for 64 and 32 bit domains, omitting the
> > p2m from initial kernel mapping is possible for 64 bit domains only.
> > 
> > Tested with:
> > - 32 bit domU (kernel not supporting unmapped initrd)
> > - 32 bit domU (kernel supporting unmapped initrd)
> > - 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
> > - 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> > - 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> > - HVM domU
> > 
> > Changes in v4:
> > - updated patch 1 as suggested by Wei Liu (comment and variable name)
> > - modify comment in patch 6 as suggested by Wei Liu
> > - rework of patch 8 reducing line count by nearly 100
> > - added some additional plausibility checks to patch 8 as suggested by
> >   Wei Liu
> > - renamed round_pg() to round_pg_up() in patch 9 as suggested by Wei Liu
> > 
> > Changes in v3:
> > - Rebased the complete series to new staging (hvm builder patches by
> >   Roger Pau Monne)
> > - Removed old patch 1 as it broke stubdom build
> > - Introduced new Patch 1 to make allocation of guest memory more clear
> >   regarding virtual/physical memory allocation (requested by Ian Campbell)
> > - Change name of flag to indicate support of unmapped initrd in patch 2
> >   (requested by Ian Campbell)
> > - Introduce new patches 3, 4, 5 ("rename domain builder count_pgtables to
> >   alloc_pgtables", "introduce domain builder architecture specific data",
> >   "use domain builder architecture private data for x86 pv domains") to
> >   assist later page table work
> > - don't fiddle with initrd virtual address in patch 6 (was patch 3 in v2),
> >   add explicit initrd parameters for start_info in struct xc_dom_image
> >   instead (requested by Ian Campbell)
> > - Introduce new patch 8 ("rework of domain builder's page table handler")
> >   to be able to use common helpers for unmapped p2m list (requested by
> >   Ian Campbell)
> > - use now known segment size in pages for p2m list in patch 9 (was patch
> >   5 in v2) instead of fiddling with segment end address (requested by
> >   Ian Campbell)
> > - split alloc_p2m_list() in patch 9 (was patch 5 in v2) to 32/64 bit
> >   variants (requested by Ian Campbell)
> > 
> > Changes in v2:
> > - patch 2 has been removed as it has been applied already
> > - introduced new patch 2 as suggested by Ian Campbell: add a flag
> >   indicating support of an unmapped initrd to the parsed elf data of
> >   the elf_dom_parms structure
> > - updated patch description of patch 3 as requested by Ian Campbell
> > 
> > 
> > Juergen Gross (9):
> >   libxc: reorganize domain builder guest memory allocator
> >   xen: add generic flag to elf_dom_parms indicating support of unmapped
> > initrd
> >   libxc: rename domain builder count_pgtables to alloc_pgtables
> >   libxc: introduce domain builder architecture specific data
> >   libxc: use domain builder architecture private data for x86 pv domains
> >   libxc: create unmapped initrd in domain builder if supported
> >   libxc: split p2m allocation in domain builder from other magic pages
> >   libxc: rework of domain builder's page table handler
> >   libxc: create p2m list outside of kernel mapping if supported
> > 
> >  stubdom/grub/kexec.c   |  12 +-
> >  tools/libxc/include/xc_dom.h   |  34 +--
> >  tools/libxc/xc_dom_arm.c   |   6 +-
> >  tools/libxc/xc_dom_core.c  | 180 
> >  tools/libxc/xc_dom_x86.c   | 563 
> > +
> >  tools/libxc/xg_private.h   |  39 +--
> >  xen/arch/x86/domain_build.c|   4 +-
> >  xen/common/libelf/libelf-dominfo.c |   3 +
> >  xen/include/xen/libelf.h   |   1 +
> >  9 files changed, 490 insertions(+), 352 deletions(-)
> 
> Could someone please comment on patches 1, 8 and 9?
> 

It's on my radar. I haven't got to this yet. I will review this series
at some point.

Wei.

> 
> Juergen
> 

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

Re: [Xen-devel] Runtime services support for Xen on ARM

[Shannon Zhao]

On 2015/11/10 20:36, Ian Campbell wrote:
> On Tue, 2015-11-10 at 12:26 +, Stefano Stabellini wrote:
>> CC'ing xen-devel and Jan
>>
>> On Tue, 10 Nov 2015, Shannon Zhao wrote:
>>> Hi Stefano,
>>>
>>> I'm working on adding Runtime services support at Xen side. Most of
>>> work
>>> is adding the ARM part in xen/common/efi/runtime.c.
>>>
>>> There is one problem which block me. That is how to implement
>>> efi_rs_enter() and efi_rs_leave() for ARM, since I think current
>>> implementation is x86 specific and won't work on ARM. Also the
>>> rtc_lock.
>>>
>>> Could you give some suggestion? Thanks!
>>
>> efi_rs_enter() and efi_rs_leave() look very PV x86 specific. It is
>> possible that we don't actually need to do anything at all on ARM, aside
>> from refactoring the code. Jan?
> 
> I think these functions derive from the USE_SET_VIRTUAL_ADDRESS_MAP option.
> If that is set we call efi_rs->SetVirtualAddressMap to tell the f/w about
> our virtual address layout and can then call rs directly with no faff.
> 
> Unfortunately SetVirtualAddressMap is incompatible with kexec (I think you
> can only call it once), so we have this USE_SET_VIRTUAL_ADDRESS_MAP option.
> 
> Without USE_SET_VIRTUAL_ADDRESS_MAP we need to switch to a set of page
> tables which are "OK" for calling the runtime services. I'm not sure what
> "OK" means here -- but I suspect it means "1:1" in some part.
> 
> So sadly I think we do _eventually_ need to support this mode (for kexec),
> which would mean quite a bit of refactoring (since the relevant code
> in xen/common/efi/boot.c has some x86-isms).
> 
> But right now, since we do not yet support kexec,  I think we could get the
> ball rolling wrt RS support by setting USE_SET_VIRTUAL_ADDRESS_MAP on ARM
> and dodging the need to make efi_rs_enter() work right now. (IOW make it
> the problem of whomever wants kexec support...)
> 
Hi Ian,

Today I try the way you suggested. Set USE_SET_VIRTUAL_ADDRESS_MAP on
ARM and make a fake efi_rs_enter() and efi_rs_leave(). But when calling
efi_init_memory, it fails with below log:

(XEN) Hypervisor Trap. HSR=0x9605 EC=0x25 IL=1 Syndrome=0x5
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.7-unstable  arm64  debug=y  Not tainted ]
(XEN) CPU:0
(XEN) PC: 00294564 efi_init_memory+0x4c/0x88
(XEN) LR: 0029455c
(XEN) SP: 002bfe00
(XEN) CPSR:   83c9 MODE:64-bit EL2h (Hypervisor, handler)

(XEN) Xen call trace:
(XEN)[<00294564>] efi_init_memory+0x4c/0x88 (PC)
(XEN)[<0029455c>] efi_init_memory+0x44/0x88 (LR)
(XEN)[<0028d7c0>] arch_init_memory+0x84/0x8c
(XEN)[<0028f6e4>] start_xen+0xa64/0xca8
(XEN)[<0020060c>] paging+0x84/0xbc

It fails at below line:

efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size,
 mdesc_ver, efi_memmap);

While in efi_init_memory of xen/common/efi/boot.c, I see below words:

else
{
#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
/* XXX allocate e.g. down from FIXADDR_START */
#endif
printk(XENLOG_ERR "No mapping for MFNs %#lx-%#lx\n",
   smfn, emfn - 1);
}

I don't understand this function well and what do we need to do here for
ARM?

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH RFC 5/4] x86: #PF error code adjustments

[Jan Beulich]

>>> On 11.11.15 at 17:30,  wrote:
> On 11/11/15 08:33, Jan Beulich wrote:
>> RFC because I noticed that nothing seems to ever set PFEC_page_paged,
>> so I wonder whether we really need that flag.
> 
> It is set in hap_p2m_ga_to_gfn() for frames with types of P2M_PAGING_TYPES
> 
> Did you miss this, or wish to imply that it is actually dead code?

I missed it, apparently due to a bad grep pattern I used in an attempt
to see paged and shared at once, but not present.

Jan


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

Re: [Xen-devel] [PATCHv2] 24/27] build: convert HAS_MEM_SHARING use to Kconfig

[Razvan Cojocaru]

On 11/11/2015 06:50 PM, Doug Goldstein wrote:
> Use the Kconfig generated CONFIG_HAS_MEM_SHARING defines in the code base.
> 
> Signed-off-by: Doug Goldstein 
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Razvan Cojocaru 
> CC: Tamas K Lengyel 
> CC: Daniel De Graaf 
> Signed-off-by: Doug Goldstein 

Again, the changes in the code I'm responsible for appear to be
exclusively mechanical (a macro has been renamed), so assuming that
macro is correctly being #defined by the build system:

Acked-by: Razvan Cojocaru 


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

[Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Wei Liu]

The new osstest tested head contains a fix for gcc-4.4 toolchain.

Signed-off-by: Wei Liu 
---
Cc: "Hao, Xudong" 
Cc: Ian Campbell 

Please pull from
  git://xenbits.xen.org/osstest/ovmf.git xen-tested-master
and push the said commit to
  git://xenbits.xen.org/ovmf.git master

It should be a fast-forward push.
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 5db7ca5..1392575 100644
--- a/Config.mk
+++ b/Config.mk
@@ -253,7 +253,7 @@ QEMU_TRADITIONAL_URL ?= 
git://xenbits.xen.org/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
 endif
-OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
+OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= 256035e01a1aa5739e34f245f3b1e9e8ee204210
 # Thu Jul 23 11:08:38 2015 +0100
-- 
2.1.4


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

Re: [Xen-devel] Regression building HVM domains following "x86: add bitmap of enabled emulated devices"

[Roger Pau Monné]

El 11/11/15 a les 20.22, Andrew Cooper ha escrit:
> Actually CC-ing xen-devel this time.
> 
> On 11/11/15 19:13, Andrew Cooper wrote:
>> Hello,
>>
>> Xapi uses the Ocaml stub_xc_domain_create() which uses
>> xc_domain_create().  xc_domain_create() itself zeros the arch
>> configuration but passes flags straight through.
>>
>> As a result of c/s 171946ab "x86: add bitmap of enabled emulated
>> devices", xc_domain_create() can no longer be used to construct HVM
>> domains, failing the hypervisor-side sanity check.
>>
>> Needless to say, this has put a dent in XenServer's automated testing.
>>
>>
>> There are a couple of options, but neither of them are fantastic.
>>
>> 1) Have xc_domain_create() fill in XEN_X86_EMU_ALL based on
>> XEN_DOMCTL_CDF_hvm_guest and XEN_DOMCTL_CDF_pvh_guest
>>
>> or
>>
>> 2) Mandate that all callers provide a valid arch configuration,
>> essentially turning xc_domain_create() into xc_domain_create_config()
>>
>>
>> Longterm, what is the plan wrt guest construction?  With my x86
>> maintainership hat on, I don't want to keep XEN_DOMCTL_CDF_pvh_guest in
>> the interface, so I do not like 1) as an option.
>>
>> `git grep` indicates that the 3 users of xc_domain_create() are the
>> Ocaml/Python stubs and init-xenstore-domain.c which only constructs a PV
>> guest (which bypasses the issue), whereas libxl uses
>> xc_domain_create_config().  (For the python stubs, I expect this will
>> hit Oracle who are still using Xend to my knowledge).

Qemu upstream also uses xc_domain_create (see
hw/xenpv/xen_domainbuild.c:xen_domain_build_pv).

IMHO, I would just remove xc_domain_create and switch all users to
xc_domain_create_config. I can take care of this if it seems like the
best solution.

Roger.


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

Re: [Xen-devel] [PATCH] tools/libxc: Fix construction of HVM guests with non-default firmware

[Roger Pau Monné]

El 11/11/15 a les 21.18, Andrew Cooper ha escrit:
> c/s 1ee15d7 "libxl: switch HVM domain building to use xc_dom_* helpers"
> introduced a regression building HVM domains in combination with the libxl
> "firmware_override=" option.
> 
> The older HVM building code (now removed) had no 32bit ELF check, so would
> happily load ELF64 images which contained a stub to switch into long mode.
> 
> It is convenient for the ELF file to match the intended runmode rather
> than the starting runmode.  As such, don't make an arbitrary restriction.
> 
> Signed-off-by: Andrew Cooper 

Sorry for the breakage, I actually added that check to make the domain
building more sane, but didn't know there where such use cases, so:

Acked-by: Roger Pau Monné 

TBH, I though that ELF64 binaries that have a 32bit entry point would
always specify their type as ELF32 (IIRC that's what Xen itself does).

Roger.


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

[Xen-devel] [xen-4.3-testing test] 64090: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 
63212
 test-amd64-i386-xl-raw   20 guest-start/debian.repeat fail REGR. vs. 63212

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 63212
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail like 63151

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 xen  fd1e4cc4d1d100337931b6f6dc50ed0b9766968a
baseline version:
 xen  85ca813ec23c5a60680e4a13777dad530065902b

Last test of basis63212  2015-10-22 10:03:01 Z   20 days
Failing since 63360  2015-10-29 13:39:04 Z   13 days   10 attempts
Testing same since64090  2015-11-10 18:01:42 Z1 days1 attempts


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

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  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 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
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64

Re: [Xen-devel] [PATCH v4 0/9] libxc: support building large pv-domains

[Juergen Gross]

On 12/11/15 10:39, Wei Liu wrote:
> On Thu, Nov 12, 2015 at 06:09:54AM +0100, Juergen Gross wrote:
>> On 05/11/15 15:36, Juergen Gross wrote:
>>> The Xen hypervisor supports starting a dom0 with large memory (up to
>>> the TB range) by not including the initrd and p2m list in the initial
>>> kernel mapping. Especially the p2m list can grow larger than the
>>> available virtual space in the initial mapping.
>>>
>>> The started kernel is indicating the support of each feature via
>>> elf notes.
>>>
>>> This series enables the domain builder in libxc to do the same as the
>>> hypervisor. This enables starting of huge pv-domUs via xl.
>>>
>>> Unmapped initrd is supported for 64 and 32 bit domains, omitting the
>>> p2m from initial kernel mapping is possible for 64 bit domains only.
>>>
>>> Tested with:
>>> - 32 bit domU (kernel not supporting unmapped initrd)
>>> - 32 bit domU (kernel supporting unmapped initrd)
>>> - 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
>>> - 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
>>> - 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
>>> - HVM domU
>>>
>>> Changes in v4:
>>> - updated patch 1 as suggested by Wei Liu (comment and variable name)
>>> - modify comment in patch 6 as suggested by Wei Liu
>>> - rework of patch 8 reducing line count by nearly 100
>>> - added some additional plausibility checks to patch 8 as suggested by
>>>   Wei Liu
>>> - renamed round_pg() to round_pg_up() in patch 9 as suggested by Wei Liu
>>>
>>> Changes in v3:
>>> - Rebased the complete series to new staging (hvm builder patches by
>>>   Roger Pau Monne)
>>> - Removed old patch 1 as it broke stubdom build
>>> - Introduced new Patch 1 to make allocation of guest memory more clear
>>>   regarding virtual/physical memory allocation (requested by Ian Campbell)
>>> - Change name of flag to indicate support of unmapped initrd in patch 2
>>>   (requested by Ian Campbell)
>>> - Introduce new patches 3, 4, 5 ("rename domain builder count_pgtables to
>>>   alloc_pgtables", "introduce domain builder architecture specific data",
>>>   "use domain builder architecture private data for x86 pv domains") to
>>>   assist later page table work
>>> - don't fiddle with initrd virtual address in patch 6 (was patch 3 in v2),
>>>   add explicit initrd parameters for start_info in struct xc_dom_image
>>>   instead (requested by Ian Campbell)
>>> - Introduce new patch 8 ("rework of domain builder's page table handler")
>>>   to be able to use common helpers for unmapped p2m list (requested by
>>>   Ian Campbell)
>>> - use now known segment size in pages for p2m list in patch 9 (was patch
>>>   5 in v2) instead of fiddling with segment end address (requested by
>>>   Ian Campbell)
>>> - split alloc_p2m_list() in patch 9 (was patch 5 in v2) to 32/64 bit
>>>   variants (requested by Ian Campbell)
>>>
>>> Changes in v2:
>>> - patch 2 has been removed as it has been applied already
>>> - introduced new patch 2 as suggested by Ian Campbell: add a flag
>>>   indicating support of an unmapped initrd to the parsed elf data of
>>>   the elf_dom_parms structure
>>> - updated patch description of patch 3 as requested by Ian Campbell
>>>
>>>
>>> Juergen Gross (9):
>>>   libxc: reorganize domain builder guest memory allocator
>>>   xen: add generic flag to elf_dom_parms indicating support of unmapped
>>> initrd
>>>   libxc: rename domain builder count_pgtables to alloc_pgtables
>>>   libxc: introduce domain builder architecture specific data
>>>   libxc: use domain builder architecture private data for x86 pv domains
>>>   libxc: create unmapped initrd in domain builder if supported
>>>   libxc: split p2m allocation in domain builder from other magic pages
>>>   libxc: rework of domain builder's page table handler
>>>   libxc: create p2m list outside of kernel mapping if supported
>>>
>>>  stubdom/grub/kexec.c   |  12 +-
>>>  tools/libxc/include/xc_dom.h   |  34 +--
>>>  tools/libxc/xc_dom_arm.c   |   6 +-
>>>  tools/libxc/xc_dom_core.c  | 180 
>>>  tools/libxc/xc_dom_x86.c   | 563 
>>> +
>>>  tools/libxc/xg_private.h   |  39 +--
>>>  xen/arch/x86/domain_build.c|   4 +-
>>>  xen/common/libelf/libelf-dominfo.c |   3 +
>>>  xen/include/xen/libelf.h   |   1 +
>>>  9 files changed, 490 insertions(+), 352 deletions(-)
>>
>> Could someone please comment on patches 1, 8 and 9?
>>
> 
> It's on my radar. I haven't got to this yet. I will review this series
> at some point.

Thanks.


Juergen


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

Re: [Xen-devel] Regression building HVM domains following "x86: add bitmap of enabled emulated devices"

[Ian Campbell]

On Wed, 2015-11-11 at 21:07 +, Andrew Cooper wrote:
> On 11/11/2015 20:57, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 11, 2015 at 07:13:25PM +, Andrew Cooper wrote:
> > > Hello,
> > > 
> > > Xapi uses the Ocaml stub_xc_domain_create() which uses
> > > xc_domain_create().  xc_domain_create() itself zeros the arch
> > > configuration but passes flags straight through.
> > Ooops.
> > > As a result of c/s 171946ab "x86: add bitmap of enabled emulated
> > > devices", xc_domain_create() can no longer be used to construct HVM
> > > domains, failing the hypervisor-side sanity check.
> > > 
> > > Needless to say, this has put a dent in XenServer's automated
> > > testing.
> > > 
> > > 
> > > There are a couple of options, but neither of them are fantastic.
> > > 
> > > 1) Have xc_domain_create() fill in XEN_X86_EMU_ALL based on
> > > XEN_DOMCTL_CDF_hvm_guest and XEN_DOMCTL_CDF_pvh_guest
> > > 
> > > or
> > > 
> > > 2) Mandate that all callers provide a valid arch configuration,
> > > essentially turning xc_domain_create() into xc_domain_create_config()
> > > 
> > > 
> > > Longterm, what is the plan wrt guest construction?  With my x86
> > > maintainership hat on, I don't want to keep XEN_DOMCTL_CDF_pvh_guest
> > > in
> > > the interface, so I do not like 1) as an option.
> > > 
> > > `git grep` indicates that the 3 users of xc_domain_create() are the
> > > Ocaml/Python stubs and init-xenstore-domain.c which only constructs a
> > > PV
> > > guest (which bypasses the issue), whereas libxl uses
> > > xc_domain_create_config().  (For the python stubs, I expect this will
> > > hit Oracle who are still using Xend to my knowledge).
> > We are moving to 'xl'.. and there are no Xend bits anymore.
> > > Option 2) is a better alternative, but will have a knock-on effect
> > > for
> > > downstream consumers of the stubs.
> > But aren't xc_* calls not-release-stable?
> 
> They are indeed not, which offers the option to change the API.
> 
> > 
> > Here is a third idea::
> > 
> >  Make 'xc_domain_create' call 'xc_domain_create_config'. The
> > xc_domain_create
> >  would synthesis the flags and we would put an 'deprecated' flag on it
> >  (whatever that means?) and remove 'xc_domain_create' in 4.7?
> 
> This is option 1.  xc_domain_create() already calls
> xc_domain_create_config() but with a zeroed arch configuration.
> 
> The issue is that modifying xc_domain_create() will preclude their
> construction of DMLite domains.

I think that's ok, we would essentially be declaring that
xc_domain_create_config() is the formally supported interface which can do
everything while xc_domain_create() is essentially a compat shim which can
only do things up to a certain point.

Users who want more would need to switch to the _config variant.

I'm half considering suggesting removing xc_domain_create(), renaming
xc_domain_create_config() without the _config() and having it do some
compat thing if the passed config==NULL, such that existing callers of
xc_domain_create() just need to add NULL to retain their current behaviour.

Ian.


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

Re: [Xen-devel] Regression building HVM domains following "x86: add bitmap of enabled emulated devices"

[Andrew Cooper]

On 12/11/15 09:25, Ian Campbell wrote:
> On Wed, 2015-11-11 at 21:07 +, Andrew Cooper wrote:
>> On 11/11/2015 20:57, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 11, 2015 at 07:13:25PM +, Andrew Cooper wrote:
 Hello,

 Xapi uses the Ocaml stub_xc_domain_create() which uses
 xc_domain_create().  xc_domain_create() itself zeros the arch
 configuration but passes flags straight through.
>>> Ooops.
 As a result of c/s 171946ab "x86: add bitmap of enabled emulated
 devices", xc_domain_create() can no longer be used to construct HVM
 domains, failing the hypervisor-side sanity check.

 Needless to say, this has put a dent in XenServer's automated
 testing.


 There are a couple of options, but neither of them are fantastic.

 1) Have xc_domain_create() fill in XEN_X86_EMU_ALL based on
 XEN_DOMCTL_CDF_hvm_guest and XEN_DOMCTL_CDF_pvh_guest

 or

 2) Mandate that all callers provide a valid arch configuration,
 essentially turning xc_domain_create() into xc_domain_create_config()


 Longterm, what is the plan wrt guest construction?  With my x86
 maintainership hat on, I don't want to keep XEN_DOMCTL_CDF_pvh_guest
 in
 the interface, so I do not like 1) as an option.

 `git grep` indicates that the 3 users of xc_domain_create() are the
 Ocaml/Python stubs and init-xenstore-domain.c which only constructs a
 PV
 guest (which bypasses the issue), whereas libxl uses
 xc_domain_create_config().  (For the python stubs, I expect this will
 hit Oracle who are still using Xend to my knowledge).
>>> We are moving to 'xl'.. and there are no Xend bits anymore.
 Option 2) is a better alternative, but will have a knock-on effect
 for
 downstream consumers of the stubs.
>>> But aren't xc_* calls not-release-stable?
>> They are indeed not, which offers the option to change the API.
>>
>>> Here is a third idea::
>>>
>>>  Make 'xc_domain_create' call 'xc_domain_create_config'. The
>>> xc_domain_create
>>>  would synthesis the flags and we would put an 'deprecated' flag on it
>>>  (whatever that means?) and remove 'xc_domain_create' in 4.7?
>> This is option 1.  xc_domain_create() already calls
>> xc_domain_create_config() but with a zeroed arch configuration.
>>
>> The issue is that modifying xc_domain_create() will preclude their
>> construction of DMLite domains.
> I think that's ok, we would essentially be declaring that
> xc_domain_create_config() is the formally supported interface which can do
> everything while xc_domain_create() is essentially a compat shim which can
> only do things up to a certain point.
>
> Users who want more would need to switch to the _config variant.
>
> I'm half considering suggesting removing xc_domain_create(), renaming
> xc_domain_create_config() without the _config() and having it do some
> compat thing if the passed config==NULL, such that existing callers of
> xc_domain_create() just need to add NULL to retain their current behaviour.

That sounds best, with one modification.

In the case that NULL is passed, there should be some default filled in
locally (as currently done for ARM).  For x86, this should now be flags
& hvm => X86_EMU_ALL, so they retain their ability to build HMV guests
by passing a NULL config.

~Andrew

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

Re: [Xen-devel] [PATCH] tools/libxc: Fix construction of HVM guests with non-default firmware

[Ian Campbell]

On Wed, 2015-11-11 at 20:18 +, Andrew Cooper wrote:
> c/s 1ee15d7 "libxl: switch HVM domain building to use xc_dom_* helpers"
> introduced a regression building HVM domains in combination with the
> libxl
> "firmware_override=" option.
> 
> The older HVM building code (now removed) had no 32bit ELF check, so would
> happily load ELF64 images which contained a stub to switch into long mode.

IOW a ELF64 with 32-bit code at its entry point? Is that entry point the
ELF entry point or the special Xen entry point located via the notes?

I think you likely mean the latter, in which case I'm ok with this change
if that entry point is explicitly documented to be 32-bit irrespective of
the containing ELF file (either the commit message should mention this is 
already the case or the patch should update the docs to make it so). 

I'm sure I saw this getting documented in patches at some point but I can't
actually find them. All I found was docs/misc/pvh-readme.txt which
discusses original pvh and not dmlite, so I'm pretty sure that is the wrong
place to be looking.

In any case I think for the purposes of supporting users who have done
something odd by accident rather than design it would be worthwhile to log
the type of ELF file somewhere, perhaps we already do, but I couldn't find
it if so.

> It is convenient for the ELF file to match the intended runmode rather
> than the starting runmode.  As such, don't make an arbitrary restriction.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> 
> My Xen Test Framework (which is almost ready to be formally presented on
> xen-devel) uses ELF32/ELF64 for the intended runmode to make
> compiling/disassembling easier.
> 
> At the point that the developer is specifying firmware_override, they are into
> "just do what I tell you" territory, and can keep both pieces if they have
> actually passed a broken firmware.
> 
> This change has actually regressed XenServers automated testing against
> xen-upstream, which does make use of the Test Framework.
> ---
>  tools/libxc/xc_dom_hvmloader.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/tools/libxc/xc_dom_hvmloader.c
> b/tools/libxc/xc_dom_hvmloader.c
> index 79a3b99..0cf9887 100644
> --- a/tools/libxc/xc_dom_hvmloader.c
> +++ b/tools/libxc/xc_dom_hvmloader.c
> @@ -107,13 +107,6 @@ static elf_errorstatus
> xc_dom_parse_hvm_kernel(struct xc_dom_image *dom)
>  return rc;
>  }
>  
> -if ( !elf_32bit(elf) )
> -{
> -xc_dom_panic(dom->xch, XC_INVALID_KERNEL, "%s: ELF image is not
> 32bit",
> - __func__);
> -return -EINVAL;
> -}
> -
>  /* parse binary and get xen meta info */
>  elf_parse_binary(elf);
>  

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

[Xen-devel] [distros-debian-wheezy test] 38270: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38249

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



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

Re: [Xen-devel] Regression building HVM domains following "x86: add bitmap of enabled emulated devices"

[Ian Campbell]

On Thu, 2015-11-12 at 10:07 +, Andrew Cooper wrote:
> On 12/11/15 09:25, Ian Campbell wrote:
> > On Wed, 2015-11-11 at 21:07 +, Andrew Cooper wrote:
> > > On 11/11/2015 20:57, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Nov 11, 2015 at 07:13:25PM +, Andrew Cooper wrote:
> > > > > Hello,
> > > > > 
> > > > > Xapi uses the Ocaml stub_xc_domain_create() which uses
> > > > > xc_domain_create().  xc_domain_create() itself zeros the arch
> > > > > configuration but passes flags straight through.
> > > > Ooops.
> > > > > As a result of c/s 171946ab "x86: add bitmap of enabled emulated
> > > > > devices", xc_domain_create() can no longer be used to construct
> > > > > HVM
> > > > > domains, failing the hypervisor-side sanity check.
> > > > > 
> > > > > Needless to say, this has put a dent in XenServer's automated
> > > > > testing.
> > > > > 
> > > > > 
> > > > > There are a couple of options, but neither of them are fantastic.
> > > > > 
> > > > > 1) Have xc_domain_create() fill in XEN_X86_EMU_ALL based on
> > > > > XEN_DOMCTL_CDF_hvm_guest and XEN_DOMCTL_CDF_pvh_guest
> > > > > 
> > > > > or
> > > > > 
> > > > > 2) Mandate that all callers provide a valid arch configuration,
> > > > > essentially turning xc_domain_create() into
> > > > > xc_domain_create_config()
> > > > > 
> > > > > 
> > > > > Longterm, what is the plan wrt guest construction?  With my x86
> > > > > maintainership hat on, I don't want to keep
> > > > > XEN_DOMCTL_CDF_pvh_guest
> > > > > in
> > > > > the interface, so I do not like 1) as an option.
> > > > > 
> > > > > `git grep` indicates that the 3 users of xc_domain_create() are
> > > > > the
> > > > > Ocaml/Python stubs and init-xenstore-domain.c which only
> > > > > constructs a
> > > > > PV
> > > > > guest (which bypasses the issue), whereas libxl uses
> > > > > xc_domain_create_config().  (For the python stubs, I expect this
> > > > > will
> > > > > hit Oracle who are still using Xend to my knowledge).
> > > > We are moving to 'xl'.. and there are no Xend bits anymore.
> > > > > Option 2) is a better alternative, but will have a knock-on
> > > > > effect
> > > > > for
> > > > > downstream consumers of the stubs.
> > > > But aren't xc_* calls not-release-stable?
> > > They are indeed not, which offers the option to change the API.
> > > 
> > > > Here is a third idea::
> > > > 
> > > >  Make 'xc_domain_create' call 'xc_domain_create_config'. The
> > > > xc_domain_create
> > > >  would synthesis the flags and we would put an 'deprecated' flag on
> > > > it
> > > >  (whatever that means?) and remove 'xc_domain_create' in 4.7?
> > > This is option 1.  xc_domain_create() already calls
> > > xc_domain_create_config() but with a zeroed arch configuration.
> > > 
> > > The issue is that modifying xc_domain_create() will preclude their
> > > construction of DMLite domains.
> > I think that's ok, we would essentially be declaring that
> > xc_domain_create_config() is the formally supported interface which can
> > do
> > everything while xc_domain_create() is essentially a compat shim which
> > can
> > only do things up to a certain point.
> > 
> > Users who want more would need to switch to the _config variant.
> > 
> > I'm half considering suggesting removing xc_domain_create(), renaming
> > xc_domain_create_config() without the _config() and having it do some
> > compat thing if the passed config==NULL, such that existing callers of
> > xc_domain_create() just need to add NULL to retain their current
> > behaviour.
> 
> That sounds best, with one modification.
> 
> In the case that NULL is passed, there should be some default filled in
> locally (as currently done for ARM).  For x86, this should now be flags
> & hvm => X86_EMU_ALL, so they retain their ability to build HMV guests
> by passing a NULL config.

Yes, that was the "some compat thing" I was thinking of.

Ian.


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

[Xen-devel] [seabios test] 64145: tolerable FAIL - PUSHED

[osstest service owner]

flight 64145 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64145/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63602

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 seabios  fa7545ab2de9f81fed1a156a39778b138fb80bd5
baseline version:
 seabios  cfc17bd88ea4902f129f91c59785e5da19fc96f9

Last test of basis63602  2015-11-04 13:11:51 Z8 days
Testing same since64145  2015-11-11 16:23:43 Z1 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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=seabios
+ revision=fa7545ab2de9f81fed1a156a39778b138fb80bd5
+ . ./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 seabios 
fa7545ab2de9f81fed1a156a39778b138fb80bd5
+ branch=seabios
+ revision=fa7545ab2de9f81fed1a156a39778b138fb80bd5
+ . ./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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' xfa7545ab2de9f81fed1a156a39778b138fb80bd5 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common

[Xen-devel] [V10 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen

[Shuai Ruan]

This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
to perform the xsave_area switching so that xen itself
can benefit from them when available.

For xsaves/xrstors/xsavec only use compact format. Add format conversion
support when perform guest os migration.Also, pv guest will not support
xsaves/xrstors.

Add two new macros to handle alternative asm with fixup.

Signed-off-by: Shuai Ruan 
---
 xen/arch/x86/domain.c |   8 ++
 xen/arch/x86/domctl.c |  30 -
 xen/arch/x86/hvm/hvm.c|  18 ++-
 xen/arch/x86/i387.c   |   4 +
 xen/arch/x86/traps.c  |   6 +-
 xen/arch/x86/xstate.c | 242 +-
 xen/include/asm-x86/alternative.h |   8 ++
 xen/include/asm-x86/xstate.h  |   2 +
 8 files changed, 274 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3f9e5d2..9476869 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -910,7 +910,12 @@ int arch_set_info_guest(
 {
 memcpy(v->arch.fpu_ctxt, >fpu_ctxt, sizeof(c.nat->fpu_ctxt));
 if ( v->arch.xsave_area )
+{
  v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
+ if ( cpu_has_xsaves || cpu_has_xsavec )
+  v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
+   
XSTATE_COMPACTION_ENABLED;
+}
 }
 
 if ( !compat )
@@ -1594,6 +1599,9 @@ static void __context_switch(void)
 
 if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) )
 BUG();
+
+if ( cpu_has_xsaves && has_hvm_container_vcpu(n) )
+set_msr_xss(n->arch.hvm_vcpu.msr_xss);
 }
 vcpu_restore_fpu_eager(n);
 n->arch.ctxt_switch_to(n);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 0f6fdb9..95b0747 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -897,9 +897,29 @@ long arch_do_domctl(
 ret = -EFAULT;
 
 offset += sizeof(v->arch.xcr0_accum);
-if ( !ret && copy_to_guest_offset(evc->buffer, offset,
-  (void *)v->arch.xsave_area,
-  size - 2 * sizeof(uint64_t)) )
+if ( !ret && (cpu_has_xsaves || cpu_has_xsavec) )
+{
+void *xsave_area;
+
+xsave_area = xmalloc_bytes(size);
+if ( !xsave_area )
+{
+ret = -ENOMEM;
+vcpu_unpause(v);
+goto vcpuextstate_out;
+}
+
+expand_xsave_states(v, xsave_area,
+size - 2 * sizeof(uint64_t));
+
+if ( copy_to_guest_offset(evc->buffer, offset, xsave_area,
+  size - 2 * sizeof(uint64_t)) )
+ ret = -EFAULT;
+xfree(xsave_area);
+   }
+   else if ( !ret && copy_to_guest_offset(evc->buffer, offset,
+  (void *)v->arch.xsave_area,
+  size - 2 * sizeof(uint64_t)) 
)
 ret = -EFAULT;
 
 vcpu_unpause(v);
@@ -955,8 +975,8 @@ long arch_do_domctl(
 v->arch.xcr0_accum = _xcr0_accum;
 if ( _xcr0_accum & XSTATE_NONLAZY )
 v->arch.nonlazy_xstate_used = 1;
-memcpy(v->arch.xsave_area, _xsave_area,
-   evc->size - 2 * sizeof(uint64_t));
+compress_xsave_states(v, _xsave_area,
+  evc->size - 2 * sizeof(uint64_t));
 vcpu_unpause(v);
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4490e9d..5fb4455 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2089,6 +2089,9 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
 xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
+if ( cpu_has_xsaves || cpu_has_xsavec )
+xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
+ XSTATE_COMPACTION_ENABLED;
 }
 else
 memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
@@ -2158,8 +2161,8 @@ static int hvm_save_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 ctxt->xfeature_mask = xfeature_mask;
 ctxt->xcr0 = v->arch.xcr0;
 ctxt->xcr0_accum = v->arch.xcr0_accum;
-memcpy(>save_area, v->arch.xsave_area,
-   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
+expand_xsave_states(v, >save_area,
+size - 

[Xen-devel] [V10 0/3] add xsaves/xrstors support

[Shuai Ruan]

From: Shuai Ruan 

Changes in v10:
* Address comments from Jan:
* Add two new macros to handle alternative asm with fixup code in patch1.
* Fix a coding style error in patch2.

Changes in v9:
* Address comments from Jan:
* Add msr_ia32_xss save/restor support in patch2.
* Change xrstor to alternative asm in patch1.
* Use memcpy() copy the save header to avoid one ugly cast in patch1.
* Fix coding style errors.

Changes in v8:
* Address comments from Jan/Andrew:
* Add optimisation in set_msr_xss in patch1.
* Change from black listing feature to white listing in pv_cpuid in patch2.
* Add MSR_IA32_XSS save/restore support in patch2.
* Fix some code errors and coding style errors.

Changes in v7:
* Address comments from Jan/Andrew:
* Move macro XSTATE_FIXUP into patch3.
* Change lazy write to xss_msr in patch1.
* Drop inner set of brackets and stray cast in patch2.
* Move the condition and memcpy() wouldn't into the new called functions in 
patch2.
* Rebase patch4 base on Andrew's"tools/libxc: Improve efficiency of 
xc_cpuid_apply_policy()".
* For no XSS features are currently supported.For leaf 2...63,ecx remain zero 
at 
  the moment in patch4.

Changes in v6:
* Address comments from Jan.
* Rebase the code based on Andrew'patch "xen/x86: Record xsave features in 
c->x86_capabilities".
* Re-split the patch to avoid building errors. Move some func definitions from 
patch1 to patch2.
* Change func name load/save_xsave_states to compress/expand_xsave_states in 
patch2.  
* Add macro to handle redundancy in xrstor.
* Fix some code errors and coding style errors.
* Add some descriptions in commit message.

Changes in v5:
* Address comments from Andrew/Jan,mainly:
* Add lazy writes of the xss_msr.
* Add xsave_area check when save/restore guest.
* Add xsavec support.
* Use word 2 in xen/include/asm-x86/cpufeature.h.
* Fix some code errors.

Changes in v4:
* Address comments from Andrew, mainly:
* No xsaves suporting for pv guest.
* Using xstate_sizes instead of domain_cpuid in hvm_cupid in patch 3.
* Add support for format translation when perform pv guest migration in patch 
2. 
* Fix some code errors.

Changes in v3:
* Address comments from Jan/Konrad
* Change the bits of eax/ebx/ecx/edx passed to guest in patch 4.
* Add code to verify whether host supports xsaves or not in patch 1.

Changes in v2:
* Address comments from Andrew/chao/Jan, mainly:
* Add details information of xsaves/xrstors feature.
* Test migration between xsaves-support machine and none-xsaves-support machine 
* Remove XGETBV1/XSAVEC/XSAVEOPT out of 'else' in patch 3.
* Change macro name XGETBV to XGETBV1 in patch 4.

This patchset enable xsaves/xrstors feature which will be available on 
Intel Skylake and later platform. Like xsave/xrstor, xsaves/xrstors 
feature will save and load processor state from a region of memory called 
XSAVE area. While unlike xsave/xrstor, xsaves/xrstors:

a) use the compacted format only for the extended region 
   of the XSAVE area which saves memory for you;
b) can operate on supervisor state components so the feature
   is prerequisite to support new supervisor state components;
c) execute only if CPL=0. 

Detail hardware spec can be found in chapter 13 (section 13.11 13.12) of the 
Intel SDM [1].


[1] Intel SDM 
(http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf)

Shuai Ruan (3):
  x86/xsaves: enable xsaves/xrstors/xsavec in xen
  x86/xsaves: enable xsaves/xrstors for hvm guest
  libxc: expose xsaves/xgetbv1/xsavec to hvm guest

 tools/libxc/xc_cpuid_x86.c |  10 +-
 xen/arch/x86/domain.c  |   8 ++
 xen/arch/x86/domctl.c  |  30 -
 xen/arch/x86/hvm/hvm.c |  45 ++-
 xen/arch/x86/hvm/vmx/vmcs.c|   5 +-
 xen/arch/x86/hvm/vmx/vmx.c |  35 +-
 xen/arch/x86/i387.c|   4 +
 xen/arch/x86/traps.c   |   6 +-
 xen/arch/x86/xstate.c  | 242 -
 xen/include/asm-x86/alternative.h  |   8 ++
 xen/include/asm-x86/hvm/vmx/vmcs.h |   4 +
 xen/include/asm-x86/hvm/vmx/vmx.h  |   2 +
 xen/include/asm-x86/xstate.h   |   3 +
 13 files changed, 354 insertions(+), 48 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)

[Hu, Robert]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, November 13, 2015 12:10 AM
> To: Hu, Robert 
> Cc: Ian Campbell ; Jin, Gordon
> ; xen-de...@lists.xenproject.org
> Subject: RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
> 
> Hu, Robert writes ("RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH
> v14 PART 2 10-26/26] Nested HVM testing)"):
> > Here is detail logs
> 
> Thanks.  Most of this is fine.
> 
> > 2015-11-12 03:21:43 Z serial: collecting logs for l1.guest.osstest
> > Use of uninitialized value in concatenation (.) or string at
> Osstest/Serial/guest.pm line 91.
> > Use of uninitialized value in concatenation (.) or string at
> Osstest/Serial/guest.pm line 91.
> 
> This is me being idiotic.  I have a patch below which I'm pretty sure
> will fix it.  Anyway, I don't think I need it retested for this reason
> because this is just a wrong log message, which we can fix in-tree if
> necessary.
> 
> What I want to know is whether the l1 serial console logfile was
> collected, and contains the debug output.
> 
> I think you should find this in the output of the ts-logs-capture for
> the host (L0).  Something like
> 
> 2015-11-12 03:21:48 Z fetching
> /var/log/xen/osstest-serial-l1.guest.osstest.log to
> MYHOSTNAME---var-log-xen-osstest-serial-l1.guest.osstest.log
[Hu, Robert] 

Yes. In last test step, ts-logs-capture host, I can see

2015-11-12 03:22:06 Z fetching /var/log/xen/osstest-serial-l1.guest.osstest.log 
to osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
2015-11-12 03:22:06 Z executing scp ... 
root@192.168.199.70:/var/log/xen/osstest-serial-l1.guest.osstest.log 
logs/standalone/test-amd64-amd64-qemuu-nested/osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log


> 
> If you look in the logs directory, do you have a file matching
> *-serial-l1.* ?  If so, can you send it to me ?  I think (hope)! it
> will have the debug keys.
[Hu, Robert] 

See attached. Seems no debug keys in it.

> 
> Thanks,
> Ian.
> 
> diff --git a/Osstest/Serial/guest.pm b/Osstest/Serial/guest.pm
> index 286773d..2511556 100644
> --- a/Osstest/Serial/guest.pm
> +++ b/Osstest/Serial/guest.pm
> @@ -86,7 +86,7 @@ sub keys_shutdown {
>  }
> 
>  sub fetch_logs {
> -my ($mo);
> +my ($mo) = @_;
> 
>  logm("$mo->{Target}{Name} (nested host) serial console logs".
>" will be found in guest logs from $mo->{Parent}{Name} (parent)");


osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
Description: osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [V10 3/3] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

[Shuai Ruan]

From: Shuai Ruan 

This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
The reserved bits of eax/ebx/ecx/edx must be cleaned up
when call cpuid(0dh) with leaf 1 or 2..63.

According to the spec the following bits must be reserved:
For leaf 1, bits 03-04/08-31 of ecx is reserved. Edx is reserved.
For leaf 2...63, bits 01-31 of ecx is reserved, Edx is reserved.

But as no XSS festures are currently supported, even in HVM guests,
for leaf 2...63, ecx should be zero at the moment.

Signed-off-by: Shuai Ruan 
Acked-by: Ian Campbell 
---
 tools/libxc/xc_cpuid_x86.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 031c848..8882c01 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -282,6 +282,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
 }
 
 #define XSAVEOPT(1 << 0)
+#define XSAVEC  (1 << 1)
+#define XGETBV1 (1 << 2)
+#define XSAVES  (1 << 3)
 /* Configure extended state enumeration leaves (0x000D for xsave) */
 static void xc_cpuid_config_xsave(xc_interface *xch,
   const struct cpuid_domain_info *info,
@@ -318,8 +321,11 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
 regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
 break;
 case 1: /* leaf 1 */
-regs[0] &= XSAVEOPT;
-regs[1] = regs[2] = regs[3] = 0;
+regs[0] &= (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES);
+if ( !info->hvm )
+regs[0] &= ~XSAVES;
+regs[2] &= info->xfeature_mask;
+regs[3] = 0;
 break;
 case 2 ... 63: /* sub-leaves */
 if ( !(info->xfeature_mask & (1ULL << input[1])) )
-- 
1.9.1


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

[Xen-devel] [V10 2/3] x86/xsaves: enable xsaves/xrstors for hvm guest

[Shuai Ruan]

This patch enables xsaves for hvm guest, includes:
1.handle xsaves vmcs init and vmexit.
2.add logic to write/read the XSS msr.

Add IA32_XSS_MSR save/rstore support.

Signed-off-by: Shuai Ruan 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c | 27 +++
 xen/arch/x86/hvm/vmx/vmcs.c|  5 -
 xen/arch/x86/hvm/vmx/vmx.c | 35 ++-
 xen/arch/x86/xstate.c  |  2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |  4 
 xen/include/asm-x86/hvm/vmx/vmx.h  |  2 ++
 xen/include/asm-x86/xstate.h   |  1 +
 7 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5fb4455..86c9abd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4603,6 +4603,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 *ebx = _eax + _ebx;
 }
 }
+if ( count == 1 )
+{
+if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
+{
+*ebx = XSTATE_AREA_MIN_SIZE;
+if ( v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss )
+for ( sub_leaf = 2; sub_leaf < 63; sub_leaf++ )
+if ( (v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss) &
+ (1ULL << sub_leaf) )
+*ebx += xstate_sizes[sub_leaf];
+}
+else
+*ebx = *ecx = *edx = 0;
+}
 break;
 
 case 0x8001:
@@ -4702,6 +4716,12 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 *msr_content = v->arch.hvm_vcpu.guest_efer;
 break;
 
+case MSR_IA32_XSS:
+if ( !cpu_has_xsaves )
+goto gp_fault;
+*msr_content = v->arch.hvm_vcpu.msr_xss;
+break;
+
 case MSR_IA32_TSC:
 *msr_content = _hvm_rdtsc_intercept();
 break;
@@ -4834,6 +4854,13 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
return X86EMUL_EXCEPTION;
 break;
 
+case MSR_IA32_XSS:
+/* No XSS features currently supported for guests. */
+if ( !cpu_has_xsaves || msr_content != 0 )
+goto gp_fault;
+v->arch.hvm_vcpu.msr_xss = msr_content;
+break;
+
 case MSR_IA32_TSC:
 hvm_set_guest_tsc(v, msr_content);
 break;
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 53207e6..cf9c14d 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -240,7 +240,8 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_PAUSE_LOOP_EXITING |
SECONDARY_EXEC_ENABLE_INVPCID |
SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
-   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
+   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
+   SECONDARY_EXEC_XSAVES);
 rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
 if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
 opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
@@ -1249,6 +1250,8 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(HOST_PAT, host_pat);
 __vmwrite(GUEST_PAT, guest_pat);
 }
+if ( cpu_has_vmx_xsaves )
+__vmwrite(XSS_EXIT_BITMAP, 0);
 
 vmx_vmcs_exit(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1eb6aab..d27f0d2 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -625,7 +625,7 @@ static int vmx_load_vmcs_ctxt(struct vcpu *v, struct 
hvm_hw_cpu *ctxt)
 
 static unsigned int __init vmx_init_msr(void)
 {
-return !!cpu_has_mpx;
+return !!cpu_has_mpx + !!cpu_has_xsaves;
 }
 
 static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt)
@@ -640,6 +640,13 @@ static void vmx_save_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 }
 
 vmx_vmcs_exit(v);
+
+if ( cpu_has_xsaves )
+{
+ctxt->msr[ctxt->count].val = v->arch.hvm_vcpu.msr_xss;
+if ( ctxt->msr[ctxt->count].val )
+ctxt->msr[ctxt->count++].index = MSR_IA32_XSS;
+}
 }
 
 static int vmx_load_msr(struct vcpu *v, struct hvm_msr *ctxt)
@@ -659,6 +666,12 @@ static int vmx_load_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 else
 err = -ENXIO;
 break;
+case MSR_IA32_XSS:
+if ( cpu_has_xsaves )
+v->arch.hvm_vcpu.msr_xss = ctxt->msr[i].val;
+else
+err = -ENXIO;
+break;
 default:
 continue;
 }
@@ -2846,6 +2859,18 @@ static void vmx_idtv_reinject(unsigned long idtv_info)
 }
 }
 
+static void vmx_handle_xsaves(void)
+{
+gdprintk(XENLOG_ERR, "xsaves should not cause vmexit\n");
+domain_crash(current->domain);
+}
+
+static void vmx_handle_xrstors(void)
+{
+gdprintk(XENLOG_ERR, "xrstors should not cause 

Re: [Xen-devel] [xen-unstable baseline-only test] 38269: regressions - FAIL

[Dario Faggioli]

On Thu, 2015-11-12 at 03:43 +, Platform Team regression test user
wrote:
> This run is configured for baseline tests only.
> 
> flight 38269 xen-unstable real [real]
> http://osstest.xs.citrite.net/~osstest/testlogs/logs/38269/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:

>  test-amd64-amd64-xl-credit2  21 guest-start/debian.repeat fail REGR.
> vs. 38255
> 
Unless there is a reason not to (e.g., some known issue in this
flight/configuration that I'm not aware of or not recalling), I'll try
to have a look at what happened here (tomorrow).

Regards,
Dario

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



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCHv3] 08/28] build: convert HAS_IOPORTS use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_IOPORTS defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk   |  1 -
 xen/arch/x86/Kconfig   |  1 +
 xen/arch/x86/Rules.mk  |  1 -
 xen/drivers/char/Kconfig   |  5 +
 xen/drivers/char/ns16550.c | 10 +-
 5 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index fb270f6..870c548 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -61,7 +61,6 @@ CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
-CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index d363b45..4002139 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_IOPORTS
select HAS_PASSTHROUGH
select HAS_PCI
select HAS_NS16550
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index f6b9d28..8dcdb72 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,7 +1,6 @@
 
 # x86-specific definitions
 
-HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_VGA  := y
 HAS_VIDEO  := y
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index ca7924f..09cb79f 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -2,3 +2,8 @@
 # Select HAS_NS16550 if a 16550 UART is supported
 config HAS_NS16550
bool
+
+# Select HAS_IOPORTS if 16550 has I/O ports
+config HAS_IOPORTS
+   bool
+   depends on HAS_NS16550
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 615124c..98b660a 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -348,7 +348,7 @@ static void ns16550_delayed_resume(void *data);
 static char ns_read_reg(struct ns16550 *uart, int reg)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 if ( uart->remapped_io_base == NULL )
 return inb(uart->io_base + reg);
 #endif
@@ -366,7 +366,7 @@ static char ns_read_reg(struct ns16550 *uart, int reg)
 static void ns_write_reg(struct ns16550 *uart, int reg, char c)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 if ( uart->remapped_io_base == NULL )
 return outb(c, uart->io_base + reg);
 #endif
@@ -546,7 +546,7 @@ static void __init ns16550_init_preirq(struct serial_port 
*port)
 {
 struct ns16550 *uart = port->uart;
 
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 /* I/O ports are distinguished by their size (16 bits). */
 if ( uart->io_base >= 0x1 )
 #endif
@@ -716,7 +716,7 @@ static void ns16550_resume(struct serial_port *port)
 
 static void __init ns16550_endboot(struct serial_port *port)
 {
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 struct ns16550 *uart = port->uart;
 int rv;
 
@@ -780,7 +780,7 @@ static int __init check_existence(struct ns16550 *uart)
 {
 unsigned char status, scratch, scratch2, scratch3;
 
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 /*
  * We can't poke MMIO UARTs until they get I/O remapped later. Assume that
  * if we're getting MMIO UARTs, the arch code knows what it's doing.
-- 
2.4.10


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

[Xen-devel] [PATCHv3] 28/28] build: convert kexec options to CONFIG_KEXEC

[Doug Goldstein]

Replace kexec := y in Rules.mk with a Kconfig option called CONFIG_KEXEC

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
---
 xen/Rules.mk   |  6 --
 xen/common/Kconfig | 12 
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 1999ff5..e31be35 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -10,7 +10,6 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto   ?= n
-kexec ?= y
 
 -include $(BASEDIR)/include/config/auto.conf
 
@@ -65,11 +64,6 @@ ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
 endif
 
-CONFIG_KEXEC-$(CONFIG_HAS_KEXEC) := $(kexec)
-CONFIG_KEXEC  := $(CONFIG_KEXEC-y)
-
-CFLAGS-$(CONFIG_KEXEC)  += -DCONFIG_KEXEC
-
 AFLAGS-y+= -D__ASSEMBLY__ -include 
$(BASEDIR)/include/xen/config.h
 
 # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 58858d2..d46f95f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -29,4 +29,16 @@ config HAS_KEXEC
 config HAS_GDBSX
bool
 
+# Enable/Disable kexec support
+config KEXEC
+   bool "kexec support"
+   default y
+   depends on HAS_KEXEC
+   ---help---
+ Allows a running Xen hypervisor to be replaced with another OS
+ without rebooting. This is primarily used to execute a crash
+ environment to collect information on a Xen hypervisor or dom0 crash.
+
+ If unsure, say Y.
+
 endmenu
-- 
2.4.10


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

[Xen-devel] [PATCHv3] 17/28] build: convert HAS_CADENCE_UART use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_CADENCE_UART defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
---
 xen/drivers/char/Kconfig  | 4 
 xen/drivers/char/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 09cb79f..a79af08 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -7,3 +7,7 @@ config HAS_NS16550
 config HAS_IOPORTS
bool
depends on HAS_NS16550
+
+# Select HAS_CADENCE_UART if a Cadence UART is supported
+config HAS_CADENCE_UART
+   bool
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 5e9d271..e86ba6f 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,6 +1,6 @@
 obj-y += console.o
 obj-$(CONFIG_HAS_NS16550) += ns16550.o
-obj-$(HAS_CADENCE_UART) += cadence-uart.o
+obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
-- 
2.4.10


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

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

[Atom2]

Am 12.11.15 um 17:43 schrieb Andrew Cooper:

On 12/11/15 14:29, Atom2 wrote:

Hi Andrew,
thanks for your reply. Answers are inline further down.

Am 12.11.15 um 14:01 schrieb Andrew Cooper:

On 12/11/15 12:52, Jan Beulich wrote:

On 12.11.15 at 02:08,  wrote:

After the upgrade HVM domUs appear to no longer work - regardless
of the
dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
domUs, however, work just fine as before on both dom0 kernels.

xl dmesg shows the following information after the first crashed HVM
domU which is started as part of the machine booting up:
[...]
(XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest
state (0).
(XEN) * VMCS Area **
(XEN) *** Guest State ***
(XEN) CR0: actual=0x0039, shadow=0x0011,
gh_mask=
(XEN) CR4: actual=0x2050, shadow=0x,
gh_mask=
(XEN) CR3: actual=0x0080, target_count=0
(XEN)  target0=, target1=
(XEN)  target2=, target3=
(XEN) RSP = 0x6fdc (0x6fdc)  RIP =
0x0001 (0x0001)

Other than RIP looking odd for a guest still in non-paged protected
mode I can't seem to spot anything wrong with guest state.

odd? That will be the source of the failure.

Out of long mode, the upper 32bit of %rip should all be zero, and it
should not be possible to set any of them.

I suspect that the guest has exited for emulation, and there has been a
bad update to %rip.  The alternative (which I hope is not the case) is
that there is a hardware errata which allows the guest to accidentally
get it self into this condition.

Are you able to rerun with a debug build of the hypervisor?

[snip]
Another question is whether prior to enabling the debug USE flag it
might make sense to re-compile with gcc-4.8.5 (please see my previous
list reply) to rule out any compiler related issues. Jan, Andrew -
what are your thoughts?

First of all, check whether the compiler makes a difference on 4.5.2

Hi Andrew,
I changed the compiler and there was no change to the better: 
Unfortunately the HVM domU is still crashing with a similar error 
message as soon as it is being started.

If both compiles result in a guest crashing in that manner, test a debug
Xen to see if any assertions/errors are encountered just before the
guest crashes.

As the compiler did not make any difference, I enabled the debug USE 
flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console 
to capture output. Unfortunately I did not get very far and things 
become even stranger: This time the system did not even finnish the boot 
process, but rather hard-stopped pretty early with a message reading 
"Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile 
is attached as "serial log.txt".


As this happened immediately after the CPU microcode update, I thought 
there might be a connection and disabled the microcode update. After the 
next reboot it seemed as if the boot process got a bit further as 
evidenced by a few more lines in the log file (those between lines 136 
and 197 in the second log file named "serial log no ucode.txt"), but in 
the end it finnished off with an identical error message (only the CPU # 
was different this time, but that number seems to change between boots 
anyways).


I hope that makes some sense to you.

Many thanks for your support and best regards Atom2
 Xen 4.5.2
(XEN) Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo 
Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=y Thu Nov 12 21:30:05 CET 2015
(XEN) Latest ChangeSet: 
(XEN) Bootloader: GRUB 2.00
(XEN) Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all 
com1=115200,8n1,0x3f8,4 console=com1,vga dom0_mem=4G,max:4G tmem=1 
tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen 
cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009d800 (usable)
(XEN)  0009d800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 2000 (usable)
(XEN)  2000 - 2020 (reserved)
(XEN)  2020 - 4000 (usable)
(XEN)  4000 - 4020 (reserved)
(XEN)  4020 - db9f (usable)
(XEN)  db9f - dc0da000 (reserved)
(XEN)  dc0da000 - dc1f9000 (ACPI NVS)
(XEN)  dc1f9000 - dc651000 (reserved)
(XEN)  dc651000 - dc652000 (usable)
(XEN)  dc652000 - dc695000 (ACPI NVS)
(XEN)  

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Olaf Hering]

On Wed, Oct 21, Chunyan Liu wrote:

> Add pvusb APIs, including:

Some comments below.

After a quick look I miss the proposed ctrl/device separation for pvscsi
(what handles "state" changes?). But, I have to read all the other
dozen+ threads about that topic first.


> +flexarray_append_pair(back, "state", "1");

4.6+ has macros for "state" values, like
flexarray_append_pair(back, "state", GCSPRINTF("%d", XenbusStateInitialising));


> +flexarray_append_pair(front, "state", "1");

4.6+ has macros for "state" values.

> +LOG(DEBUG, "Adding new usb device to xenstore");

Which one? Perhaps print also details.

> +LOG(DEBUG, "Removing USB device from xenstore");

Which one? Perhaps print also details.

> +/* check if the USB interface is already bound to "usbbcak" */

Typo.


Olaf

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

[Xen-devel] [PATCH 2/2] x86/IO-APIC: make SET_DEST() easier to use

[Jan Beulich]

There has been quite a bit of redundancy between the various use sites.
Eliminate that. No change of generated code.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -958,8 +958,12 @@ static hw_irq_controller ioapic_edge_typ
 #define IOAPIC_EDGE0
 #define IOAPIC_LEVEL   1
 
-#define SET_DEST(x, y, value) \
-do { if ( x2apic_enabled ) x = value; else y = value; } while(0)
+#define SET_DEST(ent, mode, val) do { \
+if (x2apic_enabled) \
+(ent).dest.dest32 = (val); \
+else \
+(ent).dest.mode.mode##_dest = (val); \
+} while (0)
 
 static inline void ioapic_register_intr(int irq, unsigned long trigger)
 {
@@ -1035,8 +1039,7 @@ static void __init setup_IO_APIC_irqs(vo
 disable_8259A_irq(irq_to_desc(irq));
 
 desc = irq_to_desc(irq);
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
- cpu_mask_to_apicid(desc->arch.cpu_mask));
+SET_DEST(entry, logical, cpu_mask_to_apicid(desc->arch.cpu_mask));
 spin_lock_irqsave(_lock, flags);
 __ioapic_write_entry(apic, pin, 0, entry);
 set_native_irq_info(irq, TARGET_CPUS);
@@ -1068,8 +1071,7 @@ static void __init setup_ExtINT_IRQ0_pin
  */
 entry.dest_mode = INT_DEST_MODE;
 entry.mask = 0;/* unmask IRQ now */
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
-cpu_mask_to_apicid(TARGET_CPUS));
+SET_DEST(entry, logical, cpu_mask_to_apicid(TARGET_CPUS));
 entry.delivery_mode = INT_DELIVERY_MODE;
 entry.polarity = 0;
 entry.trigger = 0;
@@ -1349,8 +1351,7 @@ void disable_IO_APIC(void)
 entry.dest_mode   = 0; /* Physical */
 entry.delivery_mode   = dest_ExtINT; /* ExtInt */
 entry.vector  = 0;
-SET_DEST(entry.dest.dest32, entry.dest.physical.physical_dest,
-get_apic_id());
+SET_DEST(entry, physical, get_apic_id());
 
 /*
  * Add it to the IO-APIC irq-routing table:
@@ -1842,8 +1843,7 @@ static void __init unlock_ExtINT_logic(v
 
 entry1.dest_mode = 0;  /* physical delivery */
 entry1.mask = 0;   /* unmask IRQ now */
-SET_DEST(entry1.dest.dest32, entry1.dest.physical.physical_dest,
-hard_smp_processor_id());
+SET_DEST(entry1, physical, hard_smp_processor_id());
 entry1.delivery_mode = dest_ExtINT;
 entry1.polarity = entry0.polarity;
 entry1.trigger = 0;
@@ -2240,8 +2240,7 @@ int io_apic_set_pci_routing (int ioapic,
 entry.vector = vector;
 
 cpumask_and(, desc->arch.cpu_mask, TARGET_CPUS);
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
- cpu_mask_to_apicid());
+SET_DEST(entry, logical, cpu_mask_to_apicid());
 
 apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry "
"(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
@@ -2434,8 +2433,7 @@ int ioapic_guest_write(unsigned long phy
 /* Set the vector field to the real vector! */
 rte.vector = desc->arch.vector;
 
-SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,
- cpu_mask_to_apicid(desc->arch.cpu_mask));
+SET_DEST(rte, logical, cpu_mask_to_apicid(desc->arch.cpu_mask));
 
 __ioapic_write_entry(apic, pin, 0, rte);
 



x86/IO-APIC: make SET_DEST() easier to use

There has been quite a bit of redundancy between the various use sites.
Eliminate that. No change of generated code.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -958,8 +958,12 @@ static hw_irq_controller ioapic_edge_typ
 #define IOAPIC_EDGE0
 #define IOAPIC_LEVEL   1
 
-#define SET_DEST(x, y, value) \
-do { if ( x2apic_enabled ) x = value; else y = value; } while(0)
+#define SET_DEST(ent, mode, val) do { \
+if (x2apic_enabled) \
+(ent).dest.dest32 = (val); \
+else \
+(ent).dest.mode.mode##_dest = (val); \
+} while (0)
 
 static inline void ioapic_register_intr(int irq, unsigned long trigger)
 {
@@ -1035,8 +1039,7 @@ static void __init setup_IO_APIC_irqs(vo
 disable_8259A_irq(irq_to_desc(irq));
 
 desc = irq_to_desc(irq);
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
- cpu_mask_to_apicid(desc->arch.cpu_mask));
+SET_DEST(entry, logical, cpu_mask_to_apicid(desc->arch.cpu_mask));
 spin_lock_irqsave(_lock, flags);
 __ioapic_write_entry(apic, pin, 0, entry);
 set_native_irq_info(irq, TARGET_CPUS);
@@ -1068,8 +1071,7 @@ static void __init setup_ExtINT_IRQ0_pin
  */
 entry.dest_mode = INT_DEST_MODE;
 entry.mask = 0;/* unmask IRQ now */
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
-cpu_mask_to_apicid(TARGET_CPUS));
+

[Xen-devel] [PATCH 1/2] x86/IO-APIC: fix setup of Xen internally used IRQs

[Jan Beulich]

..., i.e. namely that of a PCI serial card with an IRQ above the
legacy range. This had got broken by the switch to cpumask_any() in
cpu_mask_to_apicid_phys(). Fix this by allowing all CPUs for that IRQ
(such that __setup_vector_irq() will properly update a booting CPU's
vector_irq[], avoiding "No irq handler for vector" messages and the
interrupt not working).

While doing this I also noticed that io_apic_set_pci_routing() can't
be quite right: It sets up the destination _before_ getting a vector
allocated (which on other than systems using the flat APIC mode
affects the possible destinations), and also didn't restrict affinity
to ->arch.cpu_mask (as established by assign_irq_vector()).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2204,6 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,
 {
 struct irq_desc *desc = irq_to_desc(irq);
 struct IO_APIC_route_entry entry;
+cpumask_t mask;
 unsigned long flags;
 int vector;
 
@@ -2223,8 +2224,6 @@ int io_apic_set_pci_routing (int ioapic,
 
 entry.delivery_mode = INT_DELIVERY_MODE;
 entry.dest_mode = INT_DEST_MODE;
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
-cpu_mask_to_apicid(TARGET_CPUS));
 entry.trigger = edge_level;
 entry.polarity = active_high_low;
 entry.mask  = 1;
@@ -2240,6 +2239,10 @@ int io_apic_set_pci_routing (int ioapic,
 return vector;
 entry.vector = vector;
 
+cpumask_and(, desc->arch.cpu_mask, TARGET_CPUS);
+SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
+ cpu_mask_to_apicid());
+
 apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry "
"(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
mp_ioapics[ioapic].mpc_apicid, pin, entry.vector, irq,
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1084,7 +1084,7 @@ void __init smp_intr_init(void)
 vector = alloc_hipriority_vector();
 per_cpu(vector_irq, cpu)[vector] = irq;
 irq_to_desc(irq)->arch.vector = vector;
-cpumask_copy(irq_to_desc(irq)->arch.cpu_mask, _online_map);
+cpumask_setall(irq_to_desc(irq)->arch.cpu_mask);
 }
 
 /* Direct IPI vectors. */



x86/IO-APIC: fix setup of Xen internally used IRQs

..., i.e. namely that of a PCI serial card with an IRQ above the
legacy range. This had got broken by the switch to cpumask_any() in
cpu_mask_to_apicid_phys(). Fix this by allowing all CPUs for that IRQ
(such that __setup_vector_irq() will properly update a booting CPU's
vector_irq[], avoiding "No irq handler for vector" messages and the
interrupt not working).

While doing this I also noticed that io_apic_set_pci_routing() can't
be quite right: It sets up the destination _before_ getting a vector
allocated (which on other than systems using the flat APIC mode
affects the possible destinations), and also didn't restrict affinity
to ->arch.cpu_mask (as established by assign_irq_vector()).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2204,6 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,
 {
 struct irq_desc *desc = irq_to_desc(irq);
 struct IO_APIC_route_entry entry;
+cpumask_t mask;
 unsigned long flags;
 int vector;
 
@@ -2223,8 +2224,6 @@ int io_apic_set_pci_routing (int ioapic,
 
 entry.delivery_mode = INT_DELIVERY_MODE;
 entry.dest_mode = INT_DEST_MODE;
-SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
-cpu_mask_to_apicid(TARGET_CPUS));
 entry.trigger = edge_level;
 entry.polarity = active_high_low;
 entry.mask  = 1;
@@ -2240,6 +2239,10 @@ int io_apic_set_pci_routing (int ioapic,
 return vector;
 entry.vector = vector;
 
+cpumask_and(, desc->arch.cpu_mask, TARGET_CPUS);
+SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
+ cpu_mask_to_apicid());
+
 apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry "
"(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
mp_ioapics[ioapic].mpc_apicid, pin, entry.vector, irq,
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1084,7 +1084,7 @@ void __init smp_intr_init(void)
 vector = alloc_hipriority_vector();
 per_cpu(vector_irq, cpu)[vector] = irq;
 irq_to_desc(irq)->arch.vector = vector;
-cpumask_copy(irq_to_desc(irq)->arch.cpu_mask, _online_map);
+cpumask_setall(irq_to_desc(irq)->arch.cpu_mask);
 }
 
 /* Direct IPI vectors. */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about Xen reboot on panic

[Andrew Cooper]

On 12/11/15 02:10, Meng Xu wrote:
> Hi Andrew,
>
> 2015-11-11 18:34 GMT-05:00 Andrew Cooper :
>> On 11/11/2015 23:21, Meng Xu wrote:
 Finally, I can't tell from your paste below, but ensure that you are
 always using a debug hypervisor.
>>> The source file Config.mk under the xen folder has
>>> debug ?= y
>>>
>>> In addition,  "xl dmesg |grep debug" gives me:
>>>
>>> (XEN) Xen version 4.6-unstable (root@) (gcc (Ubuntu/Linaro
>>> 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Nov 11 17:06:30 EST 2015
>>>
>>> So I guess I'm using the debug hypervisor.
>> You are
>>
>>> I reboot the system after removing all of those useless options (that
>>> is, no more "reboot=k panic=2 panic_on_oops=1" in the Xen boot command
>>> line.)
>>>
>>> Is there anything else I can do to force Xen always reboot at panic or oops?
>> Unless you specify noreboot, Xen will try its hardest to reboot the
>> system.  It is possible that you have a dodgy firmware which interacts
>> poorly with the default methods.
>>
>> Does normal reboot from dom0 work as intended?
> Yes. Before Xen crashes, I can reboot the machine dom0 or from a serial port.
>
>> If not, debug in the following order:
>>
>> * `reboot` from the dom0 shell
>> * `echo b > /proc/sysrq-trigger` from the dom0 shell
>> * `xl debug-keys R` from the dom0 shell
> All of these three approaches can reboot the machine successfully.
>
>
>> * CTRL-A x3, R from the serial console
> I think "Ctrl-A" means that I should press "Ctrl + A" three times. Am I 
> correct?
> When I press Ctrl-A twice, it shows "No other window"; after I press
> "Ctrl-A" for three consecutive times, and press R (or r), it shows
> "+wrap" in the serial port.

In which case the program you are using locally to connect to the serial
console (Minicom / screen/ putty?) is intercepting CTRL-a for its own
purposes.

In screen for example, you need to send CTRL-a a to send a "CTRL-a" on
the serial.

>
> From the serial console, I can press "Ctrl+o, b" to reboot the machine
> when Xen hasn't crashed. But when Xen crashed, serial port won't work.

Ctrl-o b is exactly the same as `echo b > /proc/sysrq-trigger`.

>
> BTW, the serial port is an PCI serial port instead of the legacy
> serial port on the motherboard. Is the PCI serial port a problem? On
> another machine with the legacy serial port, I can use "Ctrl - o, b"
> to reboot even when system crashes. :-(

Once dom0 stops responding to its console, CTRL-o won't help you at all.

>
>> Those are the reboot options.  It is also possible that a kexec kernel
>> is being loaded and that is getting stuck.
>>
>> The crash options are:
>> * `kexec -p`
>> * `echo c > /proc/sysrq-trigger`
>> * `xl debug-keys C`
> The "xl debug-keys c" will not reboot the system, but it will print
> out the crash message in the serial console.

Right - in which case there is a problem on the crash path, rather than
the reboot path.

Are you (or rather, your dom0) loading a crash kernel?

>
>> If those don't work then you will need to start instrumenting Xen to
>> work out where stuff is going wrong.
> It seems all of the above commands work on my machine (except for the
> Ctrl-A x3, R). Is there anything else I can do to force the system
> reboot at panic?

Get CTRL-A working first.  That is simply a configuration interaction
with the software you are using to connect to the serial console.

Once you get that working, you will be able to use debug keys from the
serial console itself, rather than via `xl debug-keys`.

After that, you should start putting printk()s in machine_restart() to
see where execution is actually getting to.

~Andrew

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

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

[Jan Beulich]

>>> On 12.11.15 at 02:08,  wrote:
> After the upgrade HVM domUs appear to no longer work - regardless of the 
> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV 
> domUs, however, work just fine as before on both dom0 kernels.
> 
> xl dmesg shows the following information after the first crashed HVM 
> domU which is started as part of the machine booting up:
>[...]
> (XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest 
> state (0).
> (XEN) * VMCS Area **
> (XEN) *** Guest State ***
> (XEN) CR0: actual=0x0039, shadow=0x0011, 
> gh_mask=
> (XEN) CR4: actual=0x2050, shadow=0x, 
> gh_mask=
> (XEN) CR3: actual=0x0080, target_count=0
> (XEN)  target0=, target1=
> (XEN)  target2=, target3=
> (XEN) RSP = 0x6fdc (0x6fdc)  RIP = 
> 0x0001 (0x0001)

Other than RIP looking odd for a guest still in non-paged protected
mode I can't seem to spot anything wrong with guest state.
Considering that there was just a single HVM-related commit
between the two releases (which looks completely unrelated) I
wonder whether you're observing a problem that's a side effect
of something else, e.g. a build system change (compiler update or
alike). If that can be ruled out, I guess the only chance would be
for you to bisect for the offending commit.

Are you observing this on more than one kind of system?

Jan


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

Re: [Xen-devel] Runtime services support for Xen on ARM

[Shannon Zhao]

On 2015/11/12 19:04, Jan Beulich wrote:

On 12.11.15 at 10:06,  wrote:

Today I try the way you suggested. Set USE_SET_VIRTUAL_ADDRESS_MAP on
ARM and make a fake efi_rs_enter() and efi_rs_leave(). But when calling
efi_init_memory, it fails with below log:


You can't just #define that constant and assume things will work: This
code is there so far only for documentation purposes. You need to go
look what parts of it may have bitrotted.


It fails at below line:

 efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size,
  mdesc_ver, efi_memmap);


Quite obviously because efi_exit_boot() now sets efi_bs to NULL.

I see in efi_start() there is below code setting efi_bs to NULL. But 
here it calls efi_rs not efi_bs. I don't understand the relation of them.


   status = SystemTable->BootServices->ExitBootServices(ImageHandle,
 map_key);
efi_bs = NULL;


--
Shannon

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

Re: [Xen-devel] Question about Xen reboot on panic

[Wei Liu]

On Thu, Nov 12, 2015 at 12:52:56PM +, Andrew Cooper wrote:
> On 12/11/15 02:10, Meng Xu wrote:
> > Hi Andrew,
> >
> > 2015-11-11 18:34 GMT-05:00 Andrew Cooper :
> >> On 11/11/2015 23:21, Meng Xu wrote:
>  Finally, I can't tell from your paste below, but ensure that you are
>  always using a debug hypervisor.
> >>> The source file Config.mk under the xen folder has
> >>> debug ?= y
> >>>
> >>> In addition,  "xl dmesg |grep debug" gives me:
> >>>
> >>> (XEN) Xen version 4.6-unstable (root@) (gcc (Ubuntu/Linaro
> >>> 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Nov 11 17:06:30 EST 2015
> >>>
> >>> So I guess I'm using the debug hypervisor.
> >> You are
> >>
> >>> I reboot the system after removing all of those useless options (that
> >>> is, no more "reboot=k panic=2 panic_on_oops=1" in the Xen boot command
> >>> line.)
> >>>
> >>> Is there anything else I can do to force Xen always reboot at panic or 
> >>> oops?
> >> Unless you specify noreboot, Xen will try its hardest to reboot the
> >> system.  It is possible that you have a dodgy firmware which interacts
> >> poorly with the default methods.
> >>
> >> Does normal reboot from dom0 work as intended?
> > Yes. Before Xen crashes, I can reboot the machine dom0 or from a serial 
> > port.
> >
> >> If not, debug in the following order:
> >>
> >> * `reboot` from the dom0 shell
> >> * `echo b > /proc/sysrq-trigger` from the dom0 shell
> >> * `xl debug-keys R` from the dom0 shell
> > All of these three approaches can reboot the machine successfully.
> >
> >
> >> * CTRL-A x3, R from the serial console
> > I think "Ctrl-A" means that I should press "Ctrl + A" three times. Am I 
> > correct?
> > When I press Ctrl-A twice, it shows "No other window"; after I press
> > "Ctrl-A" for three consecutive times, and press R (or r), it shows
> > "+wrap" in the serial port.
> 
> In which case the program you are using locally to connect to the serial
> console (Minicom / screen/ putty?) is intercepting CTRL-a for its own
> purposes.
> 
> In screen for example, you need to send CTRL-a a to send a "CTRL-a" on
> the serial.
> 

And for minicom it is "Ctrl-a Ctrl-a" to send "Ctrl-a".

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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 12, 2015 at 12:21:24PM +0100, Juergen Gross wrote:
> On 12/11/15 12:14, Wei Liu wrote:
> > On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
> >> Guest memory allocation in the domain builder of libxc is done via
> >> virtual addresses only. In order to be able to support preallocated
> >> areas not virtually mapped reorganize the memory allocator to keep
> >> track of allocated pages globally and in allocated segments.
> >>
> >> This requires an interface change of the allocate callback of the
> >> domain builder which currently is using the last mapped virtual
> >> address as a parameter. This is no problem as the only user of this
> >> callback is stubdom/grub/kexec.c using this virtual address to
> >> calculate the last used pfn.
> >>
> >> Signed-off-by: Juergen Gross 
> > 
> > One question: did you test building with pygrub after this change? I
> > think the code is correct but we'd better be sure it doesn't break
> > pygrub.
> 
> Yes, pygrub is being built in my environment.
> 

Sorry. I meant pvgrub.

You should be able to test it according to

  http://wiki.xenproject.org/wiki/PvGrub

The test is to make sure the change to stubdom/grub/* doesn't break
things.

Wei.

> 
> Juergen
> 

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

Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments

[Andrew Cooper]

On 12/11/15 12:10, Ian Campbell wrote:
> On Thu, 2015-11-12 at 04:52 -0700, Jan Beulich wrote:
>
 @@ -530,7 +531,8 @@ static void ns16550_setup_preirq(struct
  /* Baud rate already set: read it out from the divisor
 latch. */
  divisor  = ns_read_reg(uart, UART_DLL);
  divisor |= ns_read_reg(uart, UART_DLM) << 8;
 -uart->baud = uart->clock_hz / (divisor << 4);
 +if ( divisor )
 +uart->baud = uart->clock_hz / (divisor << 4);
>>> Will following code cope with uart->baud == BAUD_AUTO? Or should we
>>> pick a
>>> static fallback rate (115200?) and set the divisor appropriately?
>> The device won't work with it left as BAUD_AUTO. Setting a guessed
>> baud rate alone won't help, as we'd then also have to write it into the
>> respective registers. And I don't think anyway we should do any
>> guessing here - if the command line option was wrong (regardless of
>> whether due to using auto or just a wrong baud rate), communication
>> won't work. All I think we should really care about is to not crash, the
>> more in a way not diagnosable over serial console.
> BAUD_AUTO is the default in device-tree based situations, so it isn't
> necessarily the case that the command line is wrong. For the non-DT case I
> think it also ends up with an implicit BAUD_AUTO in some cases?
>
> That said I don't think it is worth going to the effort to distinguish
> implicit from explicit-auto configuration, and your argument about not
> writing to the registers certainly applies to the latter, so lets just
> worry about not crashing as you say.
>
> Is a printk worthwhile, due to the fact there might be a second console
> present?

Yes.  Even if there isn't a second serial console, the system might boot
and `xl dmesg` should contain a record.

~Andrew

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

[Xen-devel] [qemu-mainline test] 64095: tolerable FAIL - PUSHED

[osstest service owner]

flight 64095 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64095/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 63705

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-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-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-libvirt-xsm 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-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 qemuua1a88589dc982f9f8b6c717c2ac98dd71dd4353d
baseline version:
 qemuu496c1b19facc7b850fa0c09899fcc07a0702fbfd

Last test of basis63705  2015-11-05 20:52:41 Z6 days
Failing since 63741  2015-11-07 01:13:47 Z5 days4 attempts
Testing same since64095  2015-11-10 19:48:22 Z1 days1 attempts


People who touched revisions under test:
  Andrew Jones 
  Cao jin 
  Daniel P. Berrange 
  Denis V. Lunev 
  Ed Maste 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Gonglei 
  Igor Mammedov 
  John Snow 
  Julio Guerra 
  Kevin Wolf 
  Marc-André Lureau 
  Mark Cave-Ayland 
  Markus Armbruster 
  Michael S. Tsirkin 
  Michael Tokarev 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Crosthwaite 
  Peter Crosthwaite 
  Peter Maydell 
  Roger Pau Monné 
  Sergey Fedorov 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth 
  Wei Huang 
  Xiao Guangrong 

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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 12, 2015 at 11:20:47AM +, Ian Campbell wrote:
> On Thu, 2015-11-12 at 11:14 +, Wei Liu wrote:
> > On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
> > > Guest memory allocation in the domain builder of libxc is done via
> > > virtual addresses only. In order to be able to support preallocated
> > > areas not virtually mapped reorganize the memory allocator to keep
> > > track of allocated pages globally and in allocated segments.
> > > 
> > > This requires an interface change of the allocate callback of the
> > > domain builder which currently is using the last mapped virtual
> > > address as a parameter. This is no problem as the only user of this
> > > callback is stubdom/grub/kexec.c using this virtual address to
> > > calculate the last used pfn.
> > > 
> > > Signed-off-by: Juergen Gross 
> > 
> > One question: did you test building with pygrub after this change? I
> > think the code is correct but we'd better be sure it doesn't break
> > pygrub.
> 
> Did you mean pvgrub? (with a Vee)
> 

Yes. p*V*grub. Sorry for the typo. :-)

> pygrub (with a Why) runs way before the libxc domain builder gets in on the
> act, doesn't it.
> 
> Ian.

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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 12, 2015 at 12:29:06PM +0100, Juergen Gross wrote:
> On 12/11/15 12:20, Ian Campbell wrote:
> > On Thu, 2015-11-12 at 11:14 +, Wei Liu wrote:
> >> On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
> >>> Guest memory allocation in the domain builder of libxc is done via
> >>> virtual addresses only. In order to be able to support preallocated
> >>> areas not virtually mapped reorganize the memory allocator to keep
> >>> track of allocated pages globally and in allocated segments.
> >>>
> >>> This requires an interface change of the allocate callback of the
> >>> domain builder which currently is using the last mapped virtual
> >>> address as a parameter. This is no problem as the only user of this
> >>> callback is stubdom/grub/kexec.c using this virtual address to
> >>> calculate the last used pfn.
> >>>
> >>> Signed-off-by: Juergen Gross 
> >>
> >> One question: did you test building with pygrub after this change? I
> >> think the code is correct but we'd better be sure it doesn't break
> >> pygrub.
> > 
> > Did you mean pvgrub? (with a Vee)
> > 
> > pygrub (with a Why) runs way before the libxc domain builder gets in on the
> > act, doesn't it.
> 
> Yep.
> 
> To be clear: we have:
> 
> - pygrub: running on dom0, mounts the root disk and analyzes the grub
>   configuration found, selects kernel and initrd and loads those via
>   libxl.
> 
> - pvgrub: based on grub2, is started via libxl as paravirtualized kernel
>   in the new domain. pvgrub is reading the grub configuration and starts
>   the appropriate kernel via it's own mechanisms (patches for support of
>   huge domains are sent, no comments up to now).
> 
> - stubdom based grub: subject to the patch we are discussing here. It is
>   being built in my environment, but not tested up to now.
> 
> 

I think we use pvgrub to denote the third case (according to our wiki).
The second case is just ... upstream grub2 with pv capability ?

(So many grubs...)

> Juergen
> 

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

Re: [Xen-devel] [PATCH v3 2/2] arm: export platform_op XENPF_settime64

[Julien Grall]

On 12/11/15 11:32, Stefano Stabellini wrote:
> On Wed, 11 Nov 2015, Julien Grall wrote:
>> On 11/11/15 18:14, Stefano Stabellini wrote:
>>> On Wed, 11 Nov 2015, Julien Grall wrote:
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 1418092..aa0fde6 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -22,13 +22,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> -extern s_time_t ticks_to_ns(uint64_t ticks);

 If it's a valid change you should mention it in the commit message
 because it's not related to this patch.

 Otherwise it looks spurious...
>>>
>>> Sorry, that's not a valid change anymore, I meant to remove it. Thanks
>>> for checking.
>>
>> If it wasn't clear, I think this change is valid. Defining the prototype
>> in the C file is a call to have the prototype not matching the declaration.
>>
>> Any prototypes should be declared in the header and not that way.
>>
>> I'm fine with this, but it should be mentioned in the commit message.
> 
> It might be a decent change to have, but it is not needed by this patch
> anymore, so if anything it should go in on its own.

I'm fine with that.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/2] arm: export platform_op XENPF_settime64

[Stefano Stabellini]

On Wed, 11 Nov 2015, Julien Grall wrote:
> On 11/11/15 18:14, Stefano Stabellini wrote:
> > On Wed, 11 Nov 2015, Julien Grall wrote:
> >>> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> >>> index 1418092..aa0fde6 100644
> >>> --- a/xen/arch/arm/vtimer.c
> >>> +++ b/xen/arch/arm/vtimer.c
> >>> @@ -22,13 +22,13 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>>  
> >>> -extern s_time_t ticks_to_ns(uint64_t ticks);
> >>
> >> If it's a valid change you should mention it in the commit message
> >> because it's not related to this patch.
> >>
> >> Otherwise it looks spurious...
> > 
> > Sorry, that's not a valid change anymore, I meant to remove it. Thanks
> > for checking.
> 
> If it wasn't clear, I think this change is valid. Defining the prototype
> in the C file is a call to have the prototype not matching the declaration.
> 
> Any prototypes should be declared in the header and not that way.
> 
> I'm fine with this, but it should be mentioned in the commit message.

It might be a decent change to have, but it is not needed by this patch
anymore, so if anything it should go in on its own.

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

Re: [Xen-devel] [PATCH V8 5/7] xl: add pvusb commands

[George Dunlap]

On Wed, Oct 21, 2015 at 10:08 AM, Chunyan Liu  wrote:
> Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
> usb-attach and usb-detach.
>
> To attach a usb device to guest through pvusb, one could follow
> following example:
>
>  #xl usbctrl-attach test_vm version=1 ports=8
>
>  #xl usb-list test_vm
>  will show the usb controllers and port usage under the domain.
>
>  #xl usbattach test_vm hostbus=1 hostaddr=2

Nit: usb-attach (missing a '-')

>  will find the first usable controller:port, and attach usb
>  device whose busnum is 1 and devnum is 6.
>  One could also specify which  and which .
>
>  #xl usb-detach test_vm 0 1
>  will detach USB device under controller 0 port 1.
>
>  #xl usbctrl-detach test_vm dev_id
>  will destroy the controller with specified dev_id. Dev_id
>  can be traced in usb-list info.
>
> Signed-off-by: Chunyan Liu 
> Signed-off-by: Simon Cao 
>
> ---
> Changes:
>   - change usb-attach parameter from hostbus.hostaddr to
> hostbus=xx hostaddr=
>   - since we get rid of libxl_device_usb_getinfo, so adjust usb-list
> information a little bit.
>   - parse_usb_config and parse_usbctrl_config following parse_nic_config
> way, put in this patch, and shared domcreate routine.
>
>  docs/man/xl.pod.1 |  40 
>  tools/libxl/xl.h  |   5 +
>  tools/libxl/xl_cmdimpl.c  | 250 
> ++
>  tools/libxl/xl_cmdtable.c |  25 +
>  4 files changed, 320 insertions(+)
>
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index d0cd612..f09a872 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -1345,6 +1345,46 @@ List pass-through pci devices for a domain.
>
>  =back
>
> +=head1 USB PASS-THROUGH
> +
> +=over 4
> +
> +=item B I 

Re: [Xen-devel] [RFC] libxl: relax readonly check introduced by XSA-142 fix

[Stefano Stabellini]

On Wed, 11 Nov 2015, Jim Fehlig wrote:

> Hi All,
> 
> Apologies for only noticing the fix for XSA-142 as it starting flowing to our
> various downstreams. The current fix seems like quite a big hammer IMO. qemu
> doesn't support readonly IDE/SATA disks
> 
> # /usr/lib/xen/bin/qemu-system-i386 -drive
> file=/tmp/disk.raw,if=ide,media=disk,format=raw,readonly=on
> qemu-system-i386: Can't use a read-only drive
> 
> But it does support readonly SCSI disks
> 
> # /usr/lib/xen/bin/qemu-system-i386 -drive
> file=/tmp/disk.raw,if=scsi,media=disk,format=raw,readonly=on
> [ok]
> 
> Inside a guest using such a disk, the SCSI kernel driver sees write protect on
> 
> [   7.339232] sd 2:0:1:0: [sdb] Write Protect is on
> 
> Also, PV drivers support readonly, but the patch rejects such configuration 
> even
> when PV drivers (vdev=xvd*) have been explicitly specified and creation of an
> emulated twin is skipped.
> 
> The attached follow-up loosens the restriction to reject readonly when 
> creating
> and emulated IDE disk, but allows it when the backend is known to support 
> readonly.
> 
> Regards,
> Jim

Hi Jim,

thanks for the patch, I think is good.  Just one question below:


> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 9c9eaa3..ccfc827 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1152,12 +1152,6 @@ static int 
> libxl__build_device_model_args_new(libxl__gc *gc,
>  (gc, 
> "file=%s,if=ide,index=%d,readonly=%s,media=cdrom,format=%s,cache=writeback,id=ide-%i",
>   disks[i].pdev_path, disk, disks[i].readwrite ? 
> "off" : "on", format, dev_number);
>  } else {
> -if (!disks[i].readwrite) {
> -LOG(ERROR,
> -"qemu-xen doesn't support read-only disk drivers");
> -return ERROR_INVAL;
> -}
> -
>  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
>  LOG(WARN, "cannot support"" empty disk format for %s",
>  disks[i].vdev);
> @@ -1185,29 +1179,34 @@ static int 
> libxl__build_device_model_args_new(libxl__gc *gc,
>   * For other disks we translate devices 0..3 into
>   * hd[a-d] and ignore the rest.
>   */
> -if (strncmp(disks[i].vdev, "sd", 2) == 0)
> +if (strncmp(disks[i].vdev, "sd", 2) == 0) {
>  drive = libxl__sprintf
> -(gc, 
> "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
> - pdev_path, disk, format);
> -else if (strncmp(disks[i].vdev, "xvd", 3) == 0)
> +(gc, 
> "file=%s,if=scsi,bus=0,unit=%d,format=%s,readonly=%s,cache=writeback",
> + pdev_path, disk, format, disks[i].readwrite ? "off" 
> : "on");
> +} else if (strncmp(disks[i].vdev, "xvd", 3) == 0) {
>  /*
>   * Do not add any emulated disk when PV disk are
>   * explicitly asked for.
>   */
>  continue;
> -else if (disk < 6 && b_info->u.hvm.hdtype == 
> LIBXL_HDTYPE_AHCI) {
> +} else if (disk < 6 && b_info->u.hvm.hdtype == 
> LIBXL_HDTYPE_AHCI) {
>  flexarray_vappend(dm_args, "-drive",
> -
> GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback",
> -pdev_path, disk, format),
> +
> GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,readonly=%s,cache=writeback",
> +  pdev_path, disk, format, 
> disks[i].readwrite ? "off" : "on"),
>  "-device", 
> GCSPRINTF("ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d",
>  disk, disk), NULL);

The commit message doesn't say anything about AHCI. Are AHCI disks
actually emulated correctly by QEMU with readonly=on?


>  continue;
> -} else if (disk < 4)
> +} else if (disk < 4) {
> +if (!disks[i].readwrite) {
> +LOG(ERROR, "qemu-xen doesn't support read-only IDE 
> disk drivers");
> +return ERROR_INVAL;
> +}
>  drive = libxl__sprintf
>  (gc, 
> "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
>   pdev_path, disk, format);
> -else
> +} else {
>  continue; /* Do not emulate this disk */
> +}

I don't think that libxl CODING_STYLE requires brackets for one statement
blocks. But I won't enforce it.


>  }
>  
>  flexarray_append(dm_args, "-drive");
> -- 
> 1.8.0.1
> 

___

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

On 12/11/15 12:32, Wei Liu wrote:
> On Thu, Nov 12, 2015 at 12:29:06PM +0100, Juergen Gross wrote:
>> On 12/11/15 12:20, Ian Campbell wrote:
>>> On Thu, 2015-11-12 at 11:14 +, Wei Liu wrote:
 On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
> Guest memory allocation in the domain builder of libxc is done via
> virtual addresses only. In order to be able to support preallocated
> areas not virtually mapped reorganize the memory allocator to keep
> track of allocated pages globally and in allocated segments.
>
> This requires an interface change of the allocate callback of the
> domain builder which currently is using the last mapped virtual
> address as a parameter. This is no problem as the only user of this
> callback is stubdom/grub/kexec.c using this virtual address to
> calculate the last used pfn.
>
> Signed-off-by: Juergen Gross 

 One question: did you test building with pygrub after this change? I
 think the code is correct but we'd better be sure it doesn't break
 pygrub.
>>>
>>> Did you mean pvgrub? (with a Vee)
>>>
>>> pygrub (with a Why) runs way before the libxc domain builder gets in on the
>>> act, doesn't it.
>>
>> Yep.
>>
>> To be clear: we have:
>>
>> - pygrub: running on dom0, mounts the root disk and analyzes the grub
>>   configuration found, selects kernel and initrd and loads those via
>>   libxl.
>>
>> - pvgrub: based on grub2, is started via libxl as paravirtualized kernel
>>   in the new domain. pvgrub is reading the grub configuration and starts
>>   the appropriate kernel via it's own mechanisms (patches for support of
>>   huge domains are sent, no comments up to now).
>>
>> - stubdom based grub: subject to the patch we are discussing here. It is
>>   being built in my environment, but not tested up to now.
>>
>>
> 
> I think we use pvgrub to denote the third case (according to our wiki).
> The second case is just ... upstream grub2 with pv capability ?

Urgs. Okay. Nevertheless: I've built it. :-)

> (So many grubs...)

I'm particularly happy you didn't come up with a variant I wasn't aware
of. :-)


Juergen


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

Re: [Xen-devel] [PATCH v4 8/9] libxc: rework of domain builder's page table handler

[Juergen Gross]

On 12/11/15 13:39, Wei Liu wrote:
> On Thu, Nov 05, 2015 at 03:36:34PM +0100, Juergen Gross wrote:
>> In order to prepare a p2m list outside of the initial kernel mapping
>> do a rework of the domain builder's page table handler. The goal is
>> to be able to use common helpers for page table allocation and setup
>> for initial kernel page tables and page tables mapping the p2m list.
>> This is achieved by supporting multiple mapping areas. The mapped
>> virtual addresses of the single areas must not overlap, while the
>> page tables of a new area added might already be partially present.
>> Especially the top level page table is existing only once, of course.
>>
>> Currently restrict the number of mappings to 1 because the only mapping
>> now is the initial mapping created by toolstack. There should not be
>> behaviour change and guest visible change introduced.
>>
>> Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Wei Liu 
> 
> Some comments below.

Okay, will fix them all.


Thanks,

Juergen

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

Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments

[Ian Campbell]

On Thu, 2015-11-12 at 03:31 -0700, Jan Beulich wrote:
> First and foremost: fix documentation: The use of "clock_hz", when
> "base_baud" was meant, has taken me several hours (suspecting a more
> complicated problem with the PCIe card I've been trying to get
> working). At once correct the "gdb" option, which is more like
> "console", not like "com".
> 
> Next, fix the types of ns_{read,write}_reg(): Especially the former
> having had a signed return type so far caused quite interesting effects
> when determining to baud rate if "auto" was specified. In that same
> code, also avoid dividing by zero when in fact the baud rate was not
> previously set up.
> 
> Further, accept I/O port based serial PCI cards with a port range wider
> than 8 bytes.
> 
> Finally, slightly rearrange struct ns16550 to reduce holes.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -277,13 +277,13 @@ Flag to indicate whether to probe for a
>  ACPI indicating none to be there.
>  
>  ### com1,com2
> -> `= [/][,[DPS][,[|pci|amt][,[][,[ bdf>][,[]]`
> +> `= [/][,[DPS][,[|pci|amt][,[][,[ bdf>][,[]]`
>  
>  Both option `com1` and `com2` follow the same format.
>  
>  * `` may be either an integer baud rate, or the string `auto` if
>    the bootloader or other earlier firmware has already set it up.
> -* Optionally, a clock speed measured in hz can be specified.
> +* Optionally, the base baud rate can be specified.

I do wonder if everyone trying to use this (which will include less-savy
users who are trying to produce a useful bug report by our request) will
know what this means?

On the other hand I'm not exactly sure how to better describe it other than
as the "basic baud rate, i.e. the one you get with divisor == 1", which is
no more likely to enlighten anyone who didn't already know that.

Is it true (enough) to say something like "typically the fastest baud rate
supported by the device"?

> @@ -530,7 +531,8 @@ static void ns16550_setup_preirq(struct
>  /* Baud rate already set: read it out from the divisor latch. */
>  divisor  = ns_read_reg(uart, UART_DLL);
>  divisor |= ns_read_reg(uart, UART_DLM) << 8;
> -uart->baud = uart->clock_hz / (divisor << 4);
> +if ( divisor )
> +uart->baud = uart->clock_hz / (divisor << 4);

Will following code cope with uart->baud == BAUD_AUTO? Or should we pick a
static fallback rate (115200?) and set the divisor appropriately?

Ian.

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

Re: [Xen-devel] [PATCH v3 5/6] xen/arm: introduce xen_read_wallclock

[Stefano Stabellini]

On Wed, 11 Nov 2015, Arnd Bergmann wrote:
> On Wednesday 11 November 2015 16:51:35 Stefano Stabellini wrote:
> > +static void xen_read_wallclock(struct timespec64 *ts)
> > +{
> > +   u32 version;
> > +   u64 delta;
> > +   struct timespec64 now;
> > +   struct shared_info *s = HYPERVISOR_shared_info;
> > +   struct pvclock_wall_clock *wall_clock = &(s->wc);
> > +
> > +   /* get wallclock at system boot */
> > +   do {
> > +   version = wall_clock->version;
> > +   rmb();  /* fetch version before time */
> > +   now.tv_sec  = ((uint64_t)wall_clock->sec_hi << 32) | 
> > wall_clock->sec;
> > +   now.tv_nsec = wall_clock->nsec;
> > +   rmb();  /* fetch time before checking version */
> > +   } while ((wall_clock->version & 1) || (version != 
> > wall_clock->version));
> > +
> > +   /* time since system boot */
> > +   delta = ktime_get_ns();
> > +   delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
> > +
> > +   *ts = ns_to_timespec64(delta);
> > +}
> 
> Looks correct to me and better than the previous versions, but you are still
> converting from timespec64 to nanoseconds and back. While I previously
> recommended going all the way to nanoseconds here, I guess this you
> can even avoid the ns_to_timespec64() if you stay within timespec64
> domain and replace the last lines with
> 
>   ktime_get_ts64(_monotonic);
>   *ts = timespec64_add(now, ts_monotonic);
> 
> which avoids both the multiplication and division.

Much better, I'll do that.  Thanks for the suggestion!

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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

On 12/11/15 12:20, Ian Campbell wrote:
> On Thu, 2015-11-12 at 11:14 +, Wei Liu wrote:
>> On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
>>> Guest memory allocation in the domain builder of libxc is done via
>>> virtual addresses only. In order to be able to support preallocated
>>> areas not virtually mapped reorganize the memory allocator to keep
>>> track of allocated pages globally and in allocated segments.
>>>
>>> This requires an interface change of the allocate callback of the
>>> domain builder which currently is using the last mapped virtual
>>> address as a parameter. This is no problem as the only user of this
>>> callback is stubdom/grub/kexec.c using this virtual address to
>>> calculate the last used pfn.
>>>
>>> Signed-off-by: Juergen Gross 
>>
>> One question: did you test building with pygrub after this change? I
>> think the code is correct but we'd better be sure it doesn't break
>> pygrub.
> 
> Did you mean pvgrub? (with a Vee)
> 
> pygrub (with a Why) runs way before the libxc domain builder gets in on the
> act, doesn't it.

Yep.

To be clear: we have:

- pygrub: running on dom0, mounts the root disk and analyzes the grub
  configuration found, selects kernel and initrd and loads those via
  libxl.

- pvgrub: based on grub2, is started via libxl as paravirtualized kernel
  in the new domain. pvgrub is reading the grub configuration and starts
  the appropriate kernel via it's own mechanisms (patches for support of
  huge domains are sent, no comments up to now).

- stubdom based grub: subject to the patch we are discussing here. It is
  being built in my environment, but not tested up to now.


Juergen


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

Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments

[Jan Beulich]

>>> On 12.11.15 at 13:10,  wrote:
> Is a printk worthwhile, due to the fact there might be a second console
> present?

As Andrew also asks for it, I'll add one.

Jan


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

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

[Andrew Cooper]

On 12/11/15 12:52, Jan Beulich wrote:
 On 12.11.15 at 02:08,  wrote:
>> After the upgrade HVM domUs appear to no longer work - regardless of the 
>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV 
>> domUs, however, work just fine as before on both dom0 kernels.
>>
>> xl dmesg shows the following information after the first crashed HVM 
>> domU which is started as part of the machine booting up:
>> [...]
>> (XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest 
>> state (0).
>> (XEN) * VMCS Area **
>> (XEN) *** Guest State ***
>> (XEN) CR0: actual=0x0039, shadow=0x0011, 
>> gh_mask=
>> (XEN) CR4: actual=0x2050, shadow=0x, 
>> gh_mask=
>> (XEN) CR3: actual=0x0080, target_count=0
>> (XEN)  target0=, target1=
>> (XEN)  target2=, target3=
>> (XEN) RSP = 0x6fdc (0x6fdc)  RIP = 
>> 0x0001 (0x0001)
> Other than RIP looking odd for a guest still in non-paged protected
> mode I can't seem to spot anything wrong with guest state.

odd? That will be the source of the failure.

Out of long mode, the upper 32bit of %rip should all be zero, and it
should not be possible to set any of them.

I suspect that the guest has exited for emulation, and there has been a
bad update to %rip.  The alternative (which I hope is not the case) is
that there is a hardware errata which allows the guest to accidentally
get it self into this condition.

Are you able to rerun with a debug build of the hypervisor?

~Andrew

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

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Wei Liu]

On Mon, Nov 09, 2015 at 04:19:24PM +0100, Juergen Gross wrote:
> On 10/23/2015 03:04 PM, Juergen Gross wrote:
> >This series is a combination of my previous patches:
> >
> >"libxc: remove most of tools/libxc/xc_dom_compat_linux.c"
> >"tools: remove unused wrappers for python"
> >
> >I have split it up as requested by Ian Campbell, thus it consists of
> >13 patches instead just of 2, but the functionality is roughly the
> >same. I have just kept more python bindings compared to the first
> >version, as there have been reports of some out of tree uses. Asking
> >for more such use case on xen-devel and xen-user didn't result in
> >requests for more interfaces to be kept, so I delete them.
> 
> There have been acks and critical responses regarding this series.
> 
> What should we do?
> 
> - drop them all
> - apply the first two patches only to get rid of the extra interfaces
>   to the domain builder as requested by Ian Campbell

I would go for this.

Wei.

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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
> Guest memory allocation in the domain builder of libxc is done via
> virtual addresses only. In order to be able to support preallocated
> areas not virtually mapped reorganize the memory allocator to keep
> track of allocated pages globally and in allocated segments.
> 
> This requires an interface change of the allocate callback of the
> domain builder which currently is using the last mapped virtual
> address as a parameter. This is no problem as the only user of this
> callback is stubdom/grub/kexec.c using this virtual address to
> calculate the last used pfn.
> 
> Signed-off-by: Juergen Gross 

One question: did you test building with pygrub after this change? I
think the code is correct but we'd better be sure it doesn't break
pygrub.

Wei.

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

Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments

[Jan Beulich]

>>> On 12.11.15 at 12:07,  wrote:
> On Thu, 2015-11-12 at 03:31 -0700, Jan Beulich wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -277,13 +277,13 @@ Flag to indicate whether to probe for a
>>  ACPI indicating none to be there.
>>  
>>  ### com1,com2
>> -> `= [/][,[DPS][,[|pci|amt][,[][,[> bdf>][,[]]`
>> +> `= [/][,[DPS][,[|pci|amt][,[][,[> bdf>][,[]]`
>>  
>>  Both option `com1` and `com2` follow the same format.
>>  
>>  * `` may be either an integer baud rate, or the string `auto` if
>>the bootloader or other earlier firmware has already set it up.
>> -* Optionally, a clock speed measured in hz can be specified.
>> +* Optionally, the base baud rate can be specified.
> 
> I do wonder if everyone trying to use this (which will include less-savy
> users who are trying to produce a useful bug report by our request) will
> know what this means?
> 
> On the other hand I'm not exactly sure how to better describe it other than
> as the "basic baud rate, i.e. the one you get with divisor == 1", which is
> no more likely to enlighten anyone who didn't already know that.
> 
> Is it true (enough) to say something like "typically the fastest baud rate
> supported by the device"?

Yes, I think so.

>> @@ -530,7 +531,8 @@ static void ns16550_setup_preirq(struct
>>  /* Baud rate already set: read it out from the divisor latch. */
>>  divisor  = ns_read_reg(uart, UART_DLL);
>>  divisor |= ns_read_reg(uart, UART_DLM) << 8;
>> -uart->baud = uart->clock_hz / (divisor << 4);
>> +if ( divisor )
>> +uart->baud = uart->clock_hz / (divisor << 4);
> 
> Will following code cope with uart->baud == BAUD_AUTO? Or should we pick a
> static fallback rate (115200?) and set the divisor appropriately?

The device won't work with it left as BAUD_AUTO. Setting a guessed
baud rate alone won't help, as we'd then also have to write it into the
respective registers. And I don't think anyway we should do any
guessing here - if the command line option was wrong (regardless of
whether due to using auto or just a wrong baud rate), communication
won't work. All I think we should really care about is to not crash, the
more in a way not diagnosable over serial console.

Jan


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

Re: [Xen-devel] [raisin][PATCHv2] Handle unsupported distros with a prettier message

[Stefano Stabellini]

On Wed, 11 Nov 2015, Doug Goldstein wrote:
> Handle unknown distros by saying "unknown" instead of an empty string
> and for Gentoo users actually mention it.
> 
> Signed-off-by: Doug Goldstein 

Thanks for the patch.


>  lib/common-functions.sh | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index 27f6434..a0b8431 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -150,8 +150,16 @@ function get_distro() {
>   sed -r 's/\"|\(|\)//g' | awk '{print $2}'`
>  os_RELEASE=`awk '/VERSION_ID=/' /etc/os-release | sed 
> 's/VERSION_ID=//' \
>  | sed 's/\"//g'`
> +elif [[ -f /etc/gentoo-release ]]
> +then
> +os_VENDOR="Gentoo"
>  fi
>  
> +if [[ -z $os_VENDOR ]]
> + then
> + os_VENDOR="unknown"
> + fi

Spaces no tabs, please :-)

If you are going to resend, I would prefer to set os_VENDOR to "unknown"
at the beginning of the function and avoid the if.



>  # Simply distro version string
>  case "$os_VENDOR" in
>  "Debian"* | "Ubuntu"* | "LinuxMint"* )
> -- 
> 2.4.10
> 

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

Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments

[Ian Campbell]

On Thu, 2015-11-12 at 04:52 -0700, Jan Beulich wrote:

> > > @@ -530,7 +531,8 @@ static void ns16550_setup_preirq(struct
> > >  /* Baud rate already set: read it out from the divisor
> > > latch. */
> > >  divisor  = ns_read_reg(uart, UART_DLL);
> > >  divisor |= ns_read_reg(uart, UART_DLM) << 8;
> > > -uart->baud = uart->clock_hz / (divisor << 4);
> > > +if ( divisor )
> > > +uart->baud = uart->clock_hz / (divisor << 4);
> > 
> > Will following code cope with uart->baud == BAUD_AUTO? Or should we
> > pick a
> > static fallback rate (115200?) and set the divisor appropriately?
> 
> The device won't work with it left as BAUD_AUTO. Setting a guessed
> baud rate alone won't help, as we'd then also have to write it into the
> respective registers. And I don't think anyway we should do any
> guessing here - if the command line option was wrong (regardless of
> whether due to using auto or just a wrong baud rate), communication
> won't work. All I think we should really care about is to not crash, the
> more in a way not diagnosable over serial console.

BAUD_AUTO is the default in device-tree based situations, so it isn't
necessarily the case that the command line is wrong. For the non-DT case I
think it also ends up with an implicit BAUD_AUTO in some cases?

That said I don't think it is worth going to the effort to distinguish
implicit from explicit-auto configuration, and your argument about not
writing to the registers certainly applies to the latter, so lets just
worry about not crashing as you say.

Is a printk worthwhile, due to the fact there might be a second console
present?

Ian.

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

Re: [Xen-devel] [PATCH] tools/libxc: Fix construction of HVM guests with non-default firmware

[Andrew Cooper]

On 12/11/15 09:41, Ian Campbell wrote:
> On Wed, 2015-11-11 at 20:18 +, Andrew Cooper wrote:
>> c/s 1ee15d7 "libxl: switch HVM domain building to use xc_dom_* helpers"
>> introduced a regression building HVM domains in combination with the
>> libxl
>> "firmware_override=" option.
>>
>> The older HVM building code (now removed) had no 32bit ELF check, so would
>> happily load ELF64 images which contained a stub to switch into long mode.
> IOW a ELF64 with 32-bit code at its entry point? Is that entry point the
> ELF entry point or the special Xen entry point located via the notes?
>
> I think you likely mean the latter, in which case I'm ok with this change
> if that entry point is explicitly documented to be 32-bit irrespective of
> the containing ELF file (either the commit message should mention this is 
> already the case or the patch should update the docs to make it so).

I mean the former.  This has nothing to do with DMLite guests, so no
elfnotes are involved.

I realise that strictly speaking the elf check should match.  However,
it always used to work, and is sufficiently convenient for development
purposes that I feel the check is more problematic than helpful. 
(Postprocessing the linked binary from 64bit to 32bit elf is an extra
step which also makes it harder to disassemble.)

~Andrew

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

Re: [Xen-devel] [PATCH v4 9/9] libxc: create p2m list outside of kernel mapping if supported

[Wei Liu]

On Thu, Nov 05, 2015 at 03:36:35PM +0100, Juergen Gross wrote:
> In case the kernel of a new pv-domU indicates it is supporting a p2m
> list outside the initial kernel mapping by specifying INIT_P2M, let
> the domain builder allocate the memory for the p2m list from physical
> guest memory only and map it to the address the kernel is expecting.
> 
> This will enable loading pv-domUs larger than 512 GB.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH] ns16550: misc minor adjustments

[Jan Beulich]

First and foremost: fix documentation: The use of "clock_hz", when
"base_baud" was meant, has taken me several hours (suspecting a more
complicated problem with the PCIe card I've been trying to get
working). At once correct the "gdb" option, which is more like
"console", not like "com".

Next, fix the types of ns_{read,write}_reg(): Especially the former
having had a signed return type so far caused quite interesting effects
when determining to baud rate if "auto" was specified. In that same
code, also avoid dividing by zero when in fact the baud rate was not
previously set up.

Further, accept I/O port based serial PCI cards with a port range wider
than 8 bytes.

Finally, slightly rearrange struct ns16550 to reduce holes.

Signed-off-by: Jan Beulich 

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -277,13 +277,13 @@ Flag to indicate whether to probe for a
 ACPI indicating none to be there.
 
 ### com1,com2
-> `= 
[/][,[DPS][,[|pci|amt][,[][,[][,[]]`
+> `= 
[/][,[DPS][,[|pci|amt][,[][,[][,[]]`
 
 Both option `com1` and `com2` follow the same format.
 
 * `` may be either an integer baud rate, or the string `auto` if
   the bootloader or other earlier firmware has already set it up.
-* Optionally, a clock speed measured in hz can be specified.
+* Optionally, the base baud rate can be specified.
 * `DPS` represents the number of data bits, the parity, and the number
   of stop bits.
   * `D` is an integer between 5 and 8 for the number of data bits.
@@ -730,9 +730,11 @@ Controls EPT related features.
 >> Have hardware keep accessed/dirty (A/D) bits updated.
 
 ### gdb
-> `= [/][,DPS[,[,[,[, 
| pci | amt ] `
+> `= com1[H,L] | com2[H,L] | dbgp`
 
-Specify the serial parameters for the GDB stub.
+> Default: ``
+
+Specify which console gdbstub should use. See `console`.
 
 ### gnttab\_max\_frames
 > `= `
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -33,7 +33,7 @@
 
 /*
  * Configure serial port with a string:
- *   [/][,DPS[,[,[,[,].
+ *   
[/][,DPS[,[,[,[,].
  * The tail of the string can be omitted if platform defaults are sufficient.
  * If the baud rate is pre-configured, perhaps by a bootloader, then 'auto'
  * can be specified in place of a numeric baud rate. Polled mode is specified
@@ -66,10 +66,10 @@ static struct ns16550 {
 bool_t dw_usr_bsy;
 #ifdef HAS_PCI
 /* PCI card parameters. */
-unsigned int pb_bdf[3]; /* pci bridge BDF */
-unsigned int ps_bdf[3]; /* pci serial port BDF */
 bool_t pb_bdf_enable;   /* if =1, pb-bdf effective, port behind bridge */
 bool_t ps_bdf_enable;   /* if =1, ps_bdf effective, port on pci card */
+unsigned int pb_bdf[3]; /* pci bridge BDF */
+unsigned int ps_bdf[3]; /* pci serial port BDF */
 u32 bar;
 u32 bar64;
 u16 cr;
@@ -345,7 +345,7 @@ static const struct ns16550_config_mmio
 
 static void ns16550_delayed_resume(void *data);
 
-static char ns_read_reg(struct ns16550 *uart, int reg)
+static u8 ns_read_reg(struct ns16550 *uart, unsigned int reg)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
 #ifdef HAS_IOPORTS
@@ -363,7 +363,7 @@ static char ns_read_reg(struct ns16550 *
 }
 }
 
-static void ns_write_reg(struct ns16550 *uart, int reg, char c)
+static void ns_write_reg(struct ns16550 *uart, unsigned int reg, u8 c)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
 #ifdef HAS_IOPORTS
@@ -386,7 +386,7 @@ static void ns_write_reg(struct ns16550
 
 static int ns16550_ioport_invalid(struct ns16550 *uart)
 {
-return (unsigned char)ns_read_reg(uart, UART_IER) == 0xff;
+return ns_read_reg(uart, UART_IER) == 0xff;
 }
 
 static void ns16550_interrupt(
@@ -399,7 +399,8 @@ static void ns16550_interrupt(
 
 while ( !(ns_read_reg(uart, UART_IIR) & UART_IIR_NOINT) )
 {
-char lsr = ns_read_reg(uart, UART_LSR);
+u8 lsr = ns_read_reg(uart, UART_LSR);
+
 if ( (lsr & uart->lsr_mask) == uart->lsr_mask )
 serial_tx_interrupt(port, regs);
 if ( lsr & UART_LSR_DR )
@@ -530,7 +531,8 @@ static void ns16550_setup_preirq(struct
 /* Baud rate already set: read it out from the divisor latch. */
 divisor  = ns_read_reg(uart, UART_DLL);
 divisor |= ns_read_reg(uart, UART_DLM) << 8;
-uart->baud = uart->clock_hz / (divisor << 4);
+if ( divisor )
+uart->baud = uart->clock_hz / (divisor << 4);
 }
 ns_write_reg(uart, UART_LCR, lcr);
 
@@ -945,8 +947,8 @@ pci_uart_config (struct ns16550 *uart, i
 size = len & PCI_BASE_ADDRESS_IO_MASK;
 size &= -size;
 
-/* Not 8 bytes */
-if ( size != 0x8 )
+/* Not at least 8 bytes */
+if ( size < 8 )
 continue;
 
 uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;


ns16550: misc 

Re: [Xen-devel] Runtime services support for Xen on ARM

[Jan Beulich]

>>> On 12.11.15 at 10:06,  wrote:
> Today I try the way you suggested. Set USE_SET_VIRTUAL_ADDRESS_MAP on
> ARM and make a fake efi_rs_enter() and efi_rs_leave(). But when calling
> efi_init_memory, it fails with below log:

You can't just #define that constant and assume things will work: This
code is there so far only for documentation purposes. You need to go
look what parts of it may have bitrotted.

> It fails at below line:
> 
> efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size,
>  mdesc_ver, efi_memmap);

Quite obviously because efi_exit_boot() now sets efi_bs to NULL.

Jan


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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

On 12/11/15 12:14, Wei Liu wrote:
> On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
>> Guest memory allocation in the domain builder of libxc is done via
>> virtual addresses only. In order to be able to support preallocated
>> areas not virtually mapped reorganize the memory allocator to keep
>> track of allocated pages globally and in allocated segments.
>>
>> This requires an interface change of the allocate callback of the
>> domain builder which currently is using the last mapped virtual
>> address as a parameter. This is no problem as the only user of this
>> callback is stubdom/grub/kexec.c using this virtual address to
>> calculate the last used pfn.
>>
>> Signed-off-by: Juergen Gross 
> 
> One question: did you test building with pygrub after this change? I
> think the code is correct but we'd better be sure it doesn't break
> pygrub.

Yes, pygrub is being built in my environment.


Juergen


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

Re: [Xen-devel] [PATCH v4 1/9] libxc: reorganize domain builder guest memory allocator

[Ian Campbell]

On Thu, 2015-11-12 at 11:14 +, Wei Liu wrote:
> On Thu, Nov 05, 2015 at 03:36:27PM +0100, Juergen Gross wrote:
> > Guest memory allocation in the domain builder of libxc is done via
> > virtual addresses only. In order to be able to support preallocated
> > areas not virtually mapped reorganize the memory allocator to keep
> > track of allocated pages globally and in allocated segments.
> > 
> > This requires an interface change of the allocate callback of the
> > domain builder which currently is using the last mapped virtual
> > address as a parameter. This is no problem as the only user of this
> > callback is stubdom/grub/kexec.c using this virtual address to
> > calculate the last used pfn.
> > 
> > Signed-off-by: Juergen Gross 
> 
> One question: did you test building with pygrub after this change? I
> think the code is correct but we'd better be sure it doesn't break
> pygrub.

Did you mean pvgrub? (with a Vee)

pygrub (with a Why) runs way before the libxc domain builder gets in on the
act, doesn't it.

Ian.

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

[Xen-devel] [PATCH 0/2] x86/IO-APIC: adjust setting interrupt destination

[Jan Beulich]

1: fix setup of Xen internally used IRQs
2: make SET_DEST() easier to use

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 0/2] x86/IO-APIC: adjust setting interrupt destination

[Andrew Cooper]

On 12/11/15 11:39, Jan Beulich wrote:
> 1: fix setup of Xen internally used IRQs
> 2: make SET_DEST() easier to use
>
> Signed-off-by: Jan Beulich 
>

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v4 8/9] libxc: rework of domain builder's page table handler

[Wei Liu]

On Thu, Nov 05, 2015 at 03:36:34PM +0100, Juergen Gross wrote:
> In order to prepare a p2m list outside of the initial kernel mapping
> do a rework of the domain builder's page table handler. The goal is
> to be able to use common helpers for page table allocation and setup
> for initial kernel page tables and page tables mapping the p2m list.
> This is achieved by supporting multiple mapping areas. The mapped
> virtual addresses of the single areas must not overlap, while the
> page tables of a new area added might already be partially present.
> Especially the top level page table is existing only once, of course.
> 
> Currently restrict the number of mappings to 1 because the only mapping
> now is the initial mapping created by toolstack. There should not be
> behaviour change and guest visible change introduced.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

Some comments below.

[...]
>  
> -static unsigned long
> -nr_page_tables(struct xc_dom_image *dom,
> -   xen_vaddr_t start, xen_vaddr_t end, unsigned long bits)
> +static int count_pgtables(struct xc_dom_image *dom, xen_vaddr_t from,
> +  xen_vaddr_t to, xen_pfn_t pfn)
>  {
> -xen_vaddr_t mask = bits_to_mask(bits);
> -int tables;
> +struct xc_dom_image_x86 *domx86 = dom->arch_private;
> +struct xc_dom_x86_mapping *map, *map_cmp;
> +xen_pfn_t pfn_end;
> +xen_vaddr_t mask;
> +unsigned bits;
> +int l, m;
>  
> -if ( bits == 0 )
> -return 0;  /* unused */
> +if ( domx86->n_mappings == MAPPING_MAX )
> +{
> +xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
> + "%s: too many mappings\n", __FUNCTION__);
> +return -ENOMEM;
> +}
> +map = domx86->maps + domx86->n_mappings;
>  
> -if ( bits == (8 * sizeof(unsigned long)) )
> +pfn_end = pfn + ((to - from) >> PAGE_SHIFT_X86);
> +if ( pfn_end >= dom->p2m_size )
>  {
> -/* must be pgd, need one */
> -start = 0;
> -end = -1;
> -tables = 1;
> +xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
> + "%s: not enough memory for initial mapping (%#"PRIpfn" 
> > %#"PRIpfn")",
> + __FUNCTION__, pfn_end, dom->p2m_size);
> +return -ENOMEM;
>  }
> -else
> +for ( m = 0; m < domx86->n_mappings; m++ )
>  {
> -start = round_down(start, mask);
> -end = round_up(end, mask);
> -tables = ((end - start) >> bits) + 1;
> +map_cmp = domx86->maps + m;
> +if ( from < map_cmp->area.to && to > map_cmp->area.from )
> +{
> +xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> + "%s: overlapping mappings\n", __FUNCTION__);
> +return -1;

Please use -EINVAL.

> +}
>  }
>  
> -DOMPRINTF("%s: 0x%016" PRIx64 "/%ld: 0x%016" PRIx64
> -  " -> 0x%016" PRIx64 ", %d table(s)",
> -  __FUNCTION__, mask, bits, start, end, tables);
> -return tables;
> +memset(map, 0, sizeof(*map));
> +map->area.from = from & domx86->params->vaddr_mask;
> +map->area.to = to & domx86->params->vaddr_mask;
> +
> +for ( l = domx86->params->levels - 1; l >= 0; l-- )
> +{
> +map->lvls[l].pfn = pfn + map->area.pgtables;
> +if ( l == domx86->params->levels - 1 )
> +{
> +if ( domx86->n_mappings == 0 )
> +{
> +map->lvls[l].from = 0;
> +map->lvls[l].to = domx86->params->vaddr_mask;
> +map->lvls[l].pgtables = 1;
> +map->area.pgtables++;
> +}
> +continue;
> +}

Could use some comments before this hunk. Like "only one top-level
mapping is required".

> +
> +bits = PAGE_SHIFT_X86 + (l + 1) * PGTBL_LEVEL_SHIFT_X86;
> +mask = bits_to_mask(bits);
> +map->lvls[l].from = map->area.from & ~mask;
> +map->lvls[l].to = map->area.to | mask;
> +
> +if ( domx86->params->levels == 3 && domx86->n_mappings == 0 &&

Please use PGTBL_LEVELS_I386.

> + to < 0xc000 && l == 1 )
> +{
> +DOMPRINTF("%s: PAE: extra l2 page table for l3#3", __FUNCTION__);
> +map->lvls[l].to = domx86->params->vaddr_mask;
> +}
> +
> +for ( m = 0; m < domx86->n_mappings; m++ )
> +{
> +map_cmp = domx86->maps + m;
> +if ( map_cmp->lvls[l].from == map_cmp->lvls[l].to )
> +continue;
> +if ( map->lvls[l].from >= map_cmp->lvls[l].from &&
> + map->lvls[l].to <= map_cmp->lvls[l].to )
> +{
> +map->lvls[l].from = 0;
> +map->lvls[l].to = 0;
> +break;
> +}
> +assert(map->lvls[l].from >= map_cmp->lvls[l].from ||
> +   map->lvls[l].to <= map_cmp->lvls[l].to);
> +if ( map->lvls[l].from >= 

Re: [Xen-devel] [PATCH] tools/libxc: Fix construction of HVM guests with non-default firmware

[Ian Campbell]

On Thu, 2015-11-12 at 12:37 +, Andrew Cooper wrote:
> On 12/11/15 09:41, Ian Campbell wrote:
> > On Wed, 2015-11-11 at 20:18 +, Andrew Cooper wrote:
> > > c/s 1ee15d7 "libxl: switch HVM domain building to use xc_dom_*
> > > helpers"
> > > introduced a regression building HVM domains in combination with the
> > > libxl
> > > "firmware_override=" option.
> > > 
> > > The older HVM building code (now removed) had no 32bit ELF check, so
> > > would
> > > happily load ELF64 images which contained a stub to switch into long
> > > mode.
> > IOW a ELF64 with 32-bit code at its entry point? Is that entry point
> > the
> > ELF entry point or the special Xen entry point located via the notes?
> > 
> > I think you likely mean the latter, in which case I'm ok with this
> > change
> > if that entry point is explicitly documented to be 32-bit irrespective
> > of
> > the containing ELF file (either the commit message should mention this
> > is 
> > already the case or the patch should update the docs to make it so).
> 
> I mean the former.  This has nothing to do with DMLite guests, so no
> elfnotes are involved.
> 
> I realise that strictly speaking the elf check should match.  However,
> it always used to work, and is sufficiently convenient for development
> purposes that I feel the check is more problematic than helpful. 
> (Postprocessing the linked binary from 64bit to 32bit elf is an extra
> step which also makes it harder to disassemble.)

An ELF file which says it is class ELF32 but has 64bit code at the entry
point is IMHO malformed.

I think that the fact this used to work is a misfeature, however convenient
you may have found it.

Kernels which wish to do this should IMHO do as Xen does and have a
mkelf32.c step. You can still run gdb or whatever using the original ELF
file.

Ian.

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

[Xen-devel] [ovmf test] 64148: all pass - PUSHED

[osstest service owner]

flight 64148 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64148/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf d6cc284e6f9d2e303a81b3ee8a167eb7252ca54c
baseline version:
 ovmf 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d

Last test of basis64047  2015-11-10 10:05:22 Z2 days
Testing same since64148  2015-11-11 18:17:22 Z1 days1 attempts


People who touched revisions under test:
  Andrew Fish 
  Dandan Bi 
  Eugene Cohen 
  Liming Gao 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=d6cc284e6f9d2e303a81b3ee8a167eb7252ca54c
+ . ./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 ovmf 
d6cc284e6f9d2e303a81b3ee8a167eb7252ca54c
+ branch=ovmf
+ revision=d6cc284e6f9d2e303a81b3ee8a167eb7252ca54c
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' xd6cc284e6f9d2e303a81b3ee8a167eb7252ca54c = 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"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

[Xen-devel] [ovmf baseline-only test] 38273: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38273 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38273/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf d6cc284e6f9d2e303a81b3ee8a167eb7252ca54c
baseline version:
 ovmf 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d

Last test of basis38268  2015-11-11 18:20:43 Z1 days
Testing same since38273  2015-11-13 05:20:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Fish 
  Dandan Bi 
  Eugene Cohen 
  Liming Gao 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit d6cc284e6f9d2e303a81b3ee8a167eb7252ca54c
Author: Dandan Bi 
Date:   Wed Nov 11 08:34:04 2015 +

MdeModulePkg:Modify the pointer type.

Previously the pointer type is EFI_IFR_FORM_SET, it is incorrect when
do pointer addition without conversion.Now change it to UINT8 type.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18768 
6f19259b-4bc3-4df7-8a09-765794883524

commit 30fbfcc92995c9103ec4357d313a566a7a6a6d92
Author: Yonghong Zhu 
Date:   Wed Nov 11 06:30:42 2015 +

BaseTools/GenFw: add new option to not zero PE/COFF optional header fields

Add new option --keepoptionalheader and that flag does not zero PE/COFF
optional header fields including the version fields. It can support the
case that the PE/COFF optional header would be kept.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18767 
6f19259b-4bc3-4df7-8a09-765794883524

commit 9a12358cbe3b31441596a4eb36ebe9e6c94a130a
Author: Andrew Fish 
Date:   Wed Nov 11 02:28:51 2015 +

MdePkg: BaseLib don't require NASM with Xcode

Don't require NASM for simple edk2 Xcode projects.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18766 
6f19259b-4bc3-4df7-8a09-765794883524

commit 661c306ceb674213cc30189cd84e92a8f77a29a4
Author: Liming Gao 
Date:   Wed Nov 11 02:16:35 2015 +

MdePkg: Add more DataBits support to Port80 output

The BasePostCodeLibPort80 instance just prints UINT8 to IoPort 80. Some 
boards
may support 16bit or 32bit. To support them, new PCD PcdPort80DataWidth is
introduced to specify the width of data bits to Port80.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Star Zeng 
Reviewed-by: Jiewen Yao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18765 
6f19259b-4bc3-4df7-8a09-765794883524

commit 9ddd7d7aec0eb25e078c9ca95329df06b4410169
Author: Eugene Cohen 
Date:   Tue Nov 10 10:02:24 2015 +

MdeModulePkg PeiCore: Fix issue AuthenticationStatus is not propagated 
correctly

This patch fixes an issue in PEI with encapsulated FV images where the
AuthenticationStatus is not correctly propagated down to child FV
handles.  The PEI core registers for callbacks for both FvInfo and
FvInfo2 

Re: [Xen-devel] Question about Xen reboot on panic

[Jan Beulich]

>>> On 12.11.15 at 20:54,  wrote:
> However, the line after that if statement is:
> smp_send_stop();
> 
> which is not in the if ( get_apic_id() != boot_cpu_physical_apicid ) 
> statement.
> 
> So P0 may run this code, and from what I read from this
> smp_send_stop(), it has the following code:
> 
> local_irq_disable();
> 
> __stop_this_cpu();
> 
> disable_IO_APIC();
> 
> hpet_disable();
> 
> local_irq_enable();
> 
> I'm guessing at __stop_this_cpu() when it is on P0, P0 will be
> stopped. That's why P0 will never have the chance to proceed to the
> rest of logic in the machine_restart(). Therefore, the machine won't
> restart.

The code is quite clear in this regard - smp_send_stop() stops all other
CPUs, but calls only __stop_this_cpu() (not stop_this_cpu()) for itself.
I.e. execution is at least supposed to make it back to the caller. Also
please don't forget that this is working for most everyone else, so
what you're looking for is more likely some oddity on your system, not
some general issue.

(Btw - are you doing this on master, which is what I'd expect you to?
I ask because the sequence of calls you quote above doesn't match
with what I see on there. I'd really like to avoid hunting a problem
long fixed.)

> If I move this  smp_send_stop(void) into the if statement, Xen will reboot.
> 
> Do you think this could be a fix?

Definitely not.

Jan


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

[Xen-devel] [PATCH V2] libxl: relax readonly check introduced by XSA-142 fix

[Jim Fehlig]

The fix for XSA-142 is quite a big hammer, rejecting readonly
disk configuration even when the requested backend is known to
support readonly. While it is true that qemu doesn't support
readonly for emulated IDE or AHCI disks

$ /usr/lib/xen/bin/qemu-system-i386 \
 -drive file=/tmp/disk.raw,if=ide,media=disk,format=raw,readonly=on
qemu-system-i386: Can't use a read-only drive

$ /usr/lib/xen/bin/qemu-system-i386 -device ahci,id=ahci0 \
 -drive file=/tmp/disk.raw,if=none,id=ahcidisk-0,format=raw,readonly=on \
 -device ide-hd,bus=ahci0.0,unit=0,drive=ahcidisk-0
qemu-system-i386: -device ide-hd,bus=ahci0.0,unit=0,drive=ahcidisk-0:
Can't use a read-only drive

It does support readonly SCSI disks

$ /usr/lib/xen/bin/qemu-system-i386 \
 -drive file=/tmp/disk.raw,if=scsi,media=disk,format=raw,readonly=on
[ok]

Inside a guest using such a disk, the SCSI kernel driver sees write
protect on

[   7.339232] sd 2:0:1:0: [sdb] Write Protect is on

Also, PV drivers support readonly, but the patch rejects such
configuration even when PV drivers (vdev=xvd*) have been explicitly
specified and creation of an emulated twin is skiped.

This follow-up patch loosens the restriction to reject readonly when
creating and emulated IDE or AHCI disk, but allows it when the backend
is known to support readonly.

Signed-off-by: Jim Fehlig 
---

V2: Along with IDE+readonly, blacklist AHCI+readonly since it is not
supported by qemu either.

 tools/libxl/libxl_dm.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 9c9eaa3..cb6deec 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1152,12 +1152,6 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 (gc, 
"file=%s,if=ide,index=%d,readonly=%s,media=cdrom,format=%s,cache=writeback,id=ide-%i",
  disks[i].pdev_path, disk, disks[i].readwrite ? "off" 
: "on", format, dev_number);
 } else {
-if (!disks[i].readwrite) {
-LOG(ERROR,
-"qemu-xen doesn't support read-only disk drivers");
-return ERROR_INVAL;
-}
-
 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
 LOG(WARN, "cannot support"" empty disk format for %s",
 disks[i].vdev);
@@ -1185,29 +1179,38 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
  * For other disks we translate devices 0..3 into
  * hd[a-d] and ignore the rest.
  */
-if (strncmp(disks[i].vdev, "sd", 2) == 0)
+if (strncmp(disks[i].vdev, "sd", 2) == 0) {
 drive = libxl__sprintf
-(gc, 
"file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
- pdev_path, disk, format);
-else if (strncmp(disks[i].vdev, "xvd", 3) == 0)
+(gc, 
"file=%s,if=scsi,bus=0,unit=%d,format=%s,readonly=%s,cache=writeback",
+ pdev_path, disk, format, disks[i].readwrite ? "off" : 
"on");
+} else if (strncmp(disks[i].vdev, "xvd", 3) == 0) {
 /*
  * Do not add any emulated disk when PV disk are
  * explicitly asked for.
  */
 continue;
-else if (disk < 6 && b_info->u.hvm.hdtype == 
LIBXL_HDTYPE_AHCI) {
+} else if (disk < 6 && b_info->u.hvm.hdtype == 
LIBXL_HDTYPE_AHCI) {
+if (!disks[i].readwrite) {
+LOG(ERROR, "qemu-xen doesn't support read-only AHCI 
disk drivers");
+return ERROR_INVAL;
+}
 flexarray_vappend(dm_args, "-drive",
 
GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback",
 pdev_path, disk, format),
 "-device", 
GCSPRINTF("ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d",
 disk, disk), NULL);
 continue;
-} else if (disk < 4)
+} else if (disk < 4) {
+if (!disks[i].readwrite) {
+LOG(ERROR, "qemu-xen doesn't support read-only IDE 
disk drivers");
+return ERROR_INVAL;
+}
 drive = libxl__sprintf
 (gc, 
"file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
  pdev_path, disk, format);
-else
+} else {
 continue; /* Do not emulate this disk */
+}
 }
 
 flexarray_append(dm_args, "-drive");
-- 
1.8.0.1


___
Xen-devel 

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/13/2015 at 01:27 AM, in message
, George
Dunlap  wrote: 
> On Wed, Oct 21, 2015 at 10:08 AM, Chunyan Liu  wrote: 
> > +static int 
> > +get_assigned_devices(libxl__gc *gc, 
> > + libxl_device_usb **list, int *num) 
> > +{ 
> > +char **domlist; 
> > +unsigned int nd = 0, i, j, k; 
> > +int rc; 
> > + 
> > +*list = NULL; 
> > +*num = 0; 
> > + 
> > +domlist = libxl__xs_directory(gc, XBT_NULL, "/local/domain", ); 
> > +for (i = 0; i < nd; i++) { 
> > +char *path, **ctrl_list; 
> > +unsigned int nc = 0; 
> > + 
> > +path = GCSPRINTF("/local/domain/%s/device/vusb", domlist[i]); 
> > +ctrl_list = libxl__xs_directory(gc, XBT_NULL, path, ); 
> > + 
> > +for (j = 0; j < nc; j++) { 
> > +const char *be_path, *num_ports; 
> > +int nport; 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +  GCSPRINTF("%s/%s/backend", path, ctrl_list[j]), 
> > +  _path); 
> > +if (rc) goto out; 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +GCSPRINTF("%s/num-ports", 
> > be_path), 
> > +_ports); 
> > +if (rc) goto out; 
> > + 
> > +nport = atoi(num_ports); 
> > +for (k = 0; k < nport; k++) { 
> > +libxl_device_usb *usb; 
> > +const char *portpath, *busid; 
> > + 
> > +portpath = GCSPRINTF("%s/port/%d", be_path, k + 1); 
> > +busid = libxl__xs_read(gc, XBT_NULL, portpath); 
> > +/* If there is USB device attached, add it to list */ 
> > +if (busid && strcmp(busid, "")) { 
> > +GCREALLOC_ARRAY(*list, *num + 1); 
> > +usb = *list + *num; 
> > +(*num)++; 
> > +libxl_device_usb_init(usb); 
> > +usb->ctrl = atoi(ctrl_list[j]); 
> > +usb->port = k + 1; 
> > +rc = usb_busaddr_from_busid(gc, busid, 
> > +>u.hostdev.hostbus, 
> > +>u.hostdev.hostaddr); 
>  
> You should probably set usb->devtype to HOSTDEV here, even though this 
> function is internal. 
>  
> > +if (rc) goto out; 
> > +} 
> > +} 
> > +} 
> > +} 
> > + 
> > +rc = 0; 
> > + 
> > +out: 
> > +if (rc) { 
> > +*list = NULL; 
> > +*num = 0; 
> > +} 
> > +return rc; 
> > +} 
> > + 
> > +static bool is_usbdev_in_array(libxl_device_usb *usbs, int num, 
> > +   libxl_device_usb *usb) 
> > +{ 
> > +int i; 
> > + 
> > +for (i = 0; i < num; i++) { 
> > +if (usbs[i].u.hostdev.hostbus == usb->u.hostdev.hostbus && 
> > +usbs[i].u.hostdev.hostaddr == usb->u.hostdev.hostaddr) 
> > +return true; 
> > +} 
> > + 
> > +return false; 
> > +} 
> > + 
> > +/* check if USB device is already assigned to a domain */ 
> > +/* check if USB device type is assignable */ 
> > +static bool is_usb_assignable(libxl__gc *gc, libxl_device_usb *usb) 
> > +{ 
> > +int classcode; 
> > +char *filename; 
> > +void *buf = NULL; 
> > +char *busid = NULL; 
> > + 
> > +busid = usb_busaddr_to_busid(gc, usb->u.hostdev.hostbus, 
> > + usb->u.hostdev.hostaddr); 
> > +if (!busid) return false; 
> > + 
> > +filename = GCSPRINTF(SYSFS_USB_DEV"/%s/bDeviceClass", busid); 
> > +if (libxl__read_sysfs_file_contents(gc, filename, , NULL)) 
> > +return false; 
> > + 
> > +classcode = atoi(buf); 
> > +return classcode != USBHUB_CLASS_CODE; 
> > +} 
> > + 
> > +/* get usb devices under certain usb controller */ 
> > +static int 
> > +libxl__device_usb_list_for_usbctrl(libxl__gc *gc, uint32_t domid, 
> > +   libxl_devid usbctrl, 
> > +   libxl_device_usb **usbs, int *num) 
> > +{ 
> > +const char *fe_path, *be_path, *num_devs; 
> > +int n, i, rc; 
> > + 
> > +*usbs = NULL; 
> > +*num = 0; 
> > + 
> > +fe_path = GCSPRINTF("%s/device/vusb/%d", 
> > +libxl__xs_get_dompath(gc, domid), usbctrl); 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +GCSPRINTF("%s/backend", fe_path), 
> > +_path); 
> > +if (rc) return rc; 
> > + 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, 
> > +GCSPRINTF("%s/num-ports", be_path), 
> > +_devs); 
> > +if (rc) return rc; 
> > + 
> > +

Re: [Xen-devel] [PATCH V8 7/7] domcreate: support pvusb in configuration file

[Chun Yan Liu]

>>> On 11/13/2015 at 12:10 AM, in message
, George
Dunlap  wrote: 
> On Wed, Oct 21, 2015 at 10:08 AM, Chunyan Liu  wrote: 
> > Add code to support pvusb in domain config file. One could specify 
> > usbctrl and usb in domain's configuration file and create domain, 
> > then usb controllers will be created and usb device would be attached 
> > to guest automatically. 
> > 
> > One could specify usb controllers and usb devices in config file 
> > like this: 
> > usbctrl=['version=2,ports=4', 'version=1, ports=4', ] 
> > usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ] 
> > 
> > Signed-off-by: Chunyan Liu  
> > Signed-off-by: Simon Cao  
> > 
> > --- 
> > changes: 
> >   - change parse_usb_config and parse_usbctrl_config, following 
> > parse_nic_config way, and move to previous patch 
> >   - update user interface to specify hostbus, hostaddr instead of 
> > hostbus.hostaddr for future extension 
> > 
> >  docs/man/xl.cfg.pod.5| 81  
>  
> >  tools/libxl/libxl_create.c   | 73 +-- 
> >  tools/libxl/libxl_device.c   |  4 +++ 
> >  tools/libxl/libxl_internal.h |  8 + 
> >  tools/libxl/xl_cmdimpl.c | 54 - 
> >  5 files changed, 216 insertions(+), 4 deletions(-) 
> > 
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 
> > index b63846a..f24c008 100644 
> > --- a/docs/man/xl.cfg.pod.5 
> > +++ b/docs/man/xl.cfg.pod.5 
> > @@ -722,6 +722,87 @@ Note this may be overridden by rdm_policy option in 
> > PCI  
> device configuration. 
> > 
> >  =back 
> > 
> > +=item 

[Xen-devel] [linux-3.10 test] 64136: regressions - FAIL

[osstest service owner]

flight 64136 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64136/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 64001 pass in 64136
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail pass in 64001

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62642
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62642

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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxbdf8cfb859e9cd265ec1696d9e007fac66e7aea7
baseline version:
 linuxf5552cd830e58c46dffae3617b3ce0c839771981

Last test of basis62642  2015-10-03 17:59:45 Z   40 days
Failing since 63224  2015-10-22 22:20:05 Z   21 days   16 attempts
Testing same since64001  2015-11-10 00:11:01 Z3 days2 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Al Viro 
  Alexander Couzens 
  Alexey Klimov 
  Andi Kleen 
  Andreas Schwab 
  Andrew Morton 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Ben Skeggs 
  Cathy Avery 
  Charles Keepax 
  Christoph Biedl 
  Christoph Hellwig 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Ding Tianhong 
  dingtianhong 
  Dirk Mueller 
  Dirk Müller 
  Doron Tsur 
  Doug Ledford 
  Dāvis Mosāns 
  Eric Dumazet 
  Eric W. Biederman 
  Felix Fietkau 
  G. Richard Bellamy 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Peter Anvin 
  Herbert Xu 
  Ian Abbott 
  Ilia Mirkin 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jes Sorensen 
  Jiri Slaby 
  Joe Perches 
  Joe Stringer 
  Joe Thornber 
  Joe Thornber 
  Joerg Roedel 
  Johan Hovold 
  Johannes Berg 
  John Covici 
  Julian Anastasov 
  Kalle Valo 
  Kees Cook 
  Konrad Rzeszutek Wilk 
  Linus Torvalds 
 

[Xen-devel] Reproducible hang with cstate disabled

[Sarah Newman]

I saw xen hang after

(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(

The line that's supposed to be there is

(XEN) Brought up 24 CPUs

After power cycling I went into the BIOS. In the BIOS, C-STATE was disabled. I 
changed it to

* Intel(R) C-STATE tech  [Enabled]
* C3 State   [ACPI C2]
* C6 State   [Enabled]
* C State package limit setting  [Auto]
* C1 Auto Demotion   [Disabled]
* C3 Auto Demotion   [Disabled]

After making the above changes it booted up correctly.
I turned C-STATE off again and it hung at the same place.
I turned C-STATE back on and it worked again.
I have not tested on another machine yet, but I expect the same behavior.

I'm using the latest official version from Xen4CentOS for CentOS 6:

xen_major : 4
xen_minor : 4
xen_extra : .3-3.el6
xen_version : 4.4.3-3.el6
cc_compiler : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
cc_compile_by : mockbuild
cc_compile_domain : centos.org
cc_compile_date : Thu Oct 29 12:18:52 UTC 2015

Here are the rest of the CPU BIOS settings (left unchanged)

* CPU Ratio  [Auto]
* C1E Support[Enabled]
* Hardware Prefetcher[Enabled]
* Adjacent Cache Line Prefetch   [Enabled]
* DCU Prefetcher [Enabled]
* Data Reuse Optimization[Enabled]
* MPS and ACPI MADT ordering [Modern ordering]
* Intel(R) Virtualization Tech   [Enabled]
* Execute-Disable Bit Capability [Enabled]
* Intel AES-NI   [Enabled]
* Simultaneous Multi-Threading   [Enabled]
* Active Processor Cores [All]
* Intel(R) EIST Technology   [Enabled]
* Intel(R) Turbo Boost   [Disabled]

This is the CPU:
Intel(R) Xeon(R) CPU L5640
CPUID :206C2
Microcode Rev :14
flags   : fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi 
mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc
pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor 
lahf_lm ida arat epb dtherm

Is this something that should be or has been fixed? If this was already fixed, 
can I have the commit ID so I can check if it's in the Xen4CentOS
commit history?

We have an idle machine with the same hardware if that helps with testing.

Thanks, Sarah

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

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

[Jan Beulich]

>>> On 13.11.15 at 00:00,  wrote:
> Am 12.11.15 um 17:43 schrieb Andrew Cooper:
>> On 12/11/15 14:29, Atom2 wrote:
>>> Hi Andrew,
>>> thanks for your reply. Answers are inline further down.
>>>
>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper:
 On 12/11/15 12:52, Jan Beulich wrote:
 On 12.11.15 at 02:08,  wrote:
>> After the upgrade HVM domUs appear to no longer work - regardless
>> of the
>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
>> domUs, however, work just fine as before on both dom0 kernels.
>>
>> xl dmesg shows the following information after the first crashed HVM
>> domU which is started as part of the machine booting up:
>> [...]
>> (XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest
>> state (0).
>> (XEN) * VMCS Area **
>> (XEN) *** Guest State ***
>> (XEN) CR0: actual=0x0039, shadow=0x0011,
>> gh_mask=
>> (XEN) CR4: actual=0x2050, shadow=0x,
>> gh_mask=
>> (XEN) CR3: actual=0x0080, target_count=0
>> (XEN)  target0=, target1=
>> (XEN)  target2=, target3=
>> (XEN) RSP = 0x6fdc (0x6fdc)  RIP =
>> 0x0001 (0x0001)
> Other than RIP looking odd for a guest still in non-paged protected
> mode I can't seem to spot anything wrong with guest state.
 odd? That will be the source of the failure.

 Out of long mode, the upper 32bit of %rip should all be zero, and it
 should not be possible to set any of them.

 I suspect that the guest has exited for emulation, and there has been a
 bad update to %rip.  The alternative (which I hope is not the case) is
 that there is a hardware errata which allows the guest to accidentally
 get it self into this condition.

 Are you able to rerun with a debug build of the hypervisor?
>>> [snip]
>>> Another question is whether prior to enabling the debug USE flag it
>>> might make sense to re-compile with gcc-4.8.5 (please see my previous
>>> list reply) to rule out any compiler related issues. Jan, Andrew -
>>> what are your thoughts?
>> First of all, check whether the compiler makes a difference on 4.5.2
> Hi Andrew,
> I changed the compiler and there was no change to the better: 
> Unfortunately the HVM domU is still crashing with a similar error 
> message as soon as it is being started.
>> If both compiles result in a guest crashing in that manner, test a debug
>> Xen to see if any assertions/errors are encountered just before the
>> guest crashes.
>>
> As the compiler did not make any difference, I enabled the debug USE 
> flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console 
> to capture output. Unfortunately I did not get very far and things 
> become even stranger: This time the system did not even finnish the boot 
> process, but rather hard-stopped pretty early with a message reading 
> "Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile 
> is attached as "serial log.txt".
> 
> As this happened immediately after the CPU microcode update, I thought 
> there might be a connection and disabled the microcode update. After the 
> next reboot it seemed as if the boot process got a bit further as 
> evidenced by a few more lines in the log file (those between lines 136 
> and 197 in the second log file named "serial log no ucode.txt"), but in 
> the end it finnished off with an identical error message (only the CPU # 
> was different this time, but that number seems to change between boots 
> anyways).
> 
> I hope that makes some sense to you.

Not really, other than now even more suspecting bad hardware or
something fundamentally wrong with your build. Did you retry with
a freshly built 4.5.1? Could you alternatively try with a known good
build of 4.5.2 (e.g. from osstest)?

Jan

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

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

[Jan Beulich]

>>> On 12.11.15 at 18:09,  wrote:
> On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
>> > > > On 12.11.15 at 14:41,  wrote:
>> > Hello, all. I'd like to have set of commands that would boot xen on all
>> > platforms. I thought of following set:
>> > 
>> > xen_hypervisor FILE XEN_OPTIONS
>> > xen_kernel FILE KERNEL_OPTIONS
>> > xen_initrd INITRD INITRD INITRD
>> > all initrds are concatenated.
>> > xen_xsm ???
>> 
>> xen_ucode (and we might add more going forward). I don't see
>> why the multiboot mechanism (kernel plus any number of modules)
>> can't be used, without adding any Xen-specific directives.
> 
> You likely aren't aware that on ARM Xen doesn't boot via multiboot, but via
> a protocol which involves passing modules in an fdt[0].
> 
> I had originally hoped that this would use the same command names in the
> grub cfg, such that things would just work, however the grub maintainers
> didn't like that (and I appreciate why).
> 
> Hence on grub/ARM we already have xen_{hypervisor,kernel,initrd,...}.
> 
> The question then is what grub-mkconfig (or more precisely
> /etc/grub.d/20_linux_xen) ought to emit so that things just work on all
> architectures.
> 
> The author of the grub/ARM/Xen patches initially made it generate the xen_*
> namas for arm and the multiboot names for x86, here is Vladimir's feedback
> on that: http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00133.html 
> 
> Which I think gets us to approximately today and Vladimir's question.

Now that makes the situation really ugly (and supports my
reservations regarding grub2 as a uniform solution for everything).
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?

I think any architecture following a well defined, cross-arch
protocol (like multiboot) should not require any special xen_*
directives. If ARM64 needs Xen to be treated specially, special
directives are maybe warranted for this particular case, but I don't
see why all architectures supporting Xen should then automatically
have to use those too. But yes, it's not my call decide this...

Jan


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

[Xen-devel] [linux-3.14 test] 64127: regressions - FAIL

[osstest service owner]

flight 64127 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64127/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62648
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62648
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62648

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 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-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux769b79eb206ad5b0249a08665fefb913c3d1998e
baseline version:
 linux1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9

Last test of basis62648  2015-10-03 22:43:24 Z   39 days
Failing since 63225  2015-10-22 22:20:24 Z   20 days   16 attempts
Testing same since64002  2015-11-10 00:16:25 Z2 days2 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Adrian Hunter 
  Al Viro 
  Alex Deucher 
  Alexander Couzens 
  Alexandre Belloni 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Vagin 
  Andy Lutomirski 
  Andy Shevchenko 
  Antoine Tenart 
  Antoine Ténart 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Dooks 
  Ben Hutchings 
  Ben Skeggs 
  Brian Norris 
  Cathy Avery 
  Charles Keepax 
  Chris Mason 
  Christoph Biedl 
  Christoph Hellwig 
  Christoph Lameter 
  cov...@ccs.covici.com 
  Dan Carpenter 
  Daniel Vetter 
  Daniel Vetter 
  Dann Frazier 
  Dave Airlie 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Dirk Mueller 
  Dirk Müller 
  Doron Tsur 

Re: [Xen-devel] [PATCH v2 5/6] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Thu, Nov 12, 2015 at 02:26:21PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 12.11.2015 14:15, Daniel Kiper wrote:
> > On Tue, Nov 10, 2015 at 04:23:46PM +0100, Vladimir 'phcoder' Serbinenko 
> > wrote:
> >> Le 10 nov. 2015 3:52 PM, "Daniel Kiper"  a écrit :
> >>> On Mon, Nov 09, 2015 at 09:08:35PM +0100, Vladimir 'φ-coder/phcoder'
> >> Serbinenko wrote:
>  On 20.07.2015 16:35, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper 
>  What is handling the actual relocation?
> >>>
> >>> In Xen we get image offset from GRUB2 and using this value we calculate
> >>> relative addresses. We are using %fs for it.
> >>>
>  Why doesn't this patch include support for ELF relocations?
> >>>
> >>> This is another option. We considered it too. However, in our case
> >>> relative addressing looks simpler then ELF relocations.
> >> How is it simpler than to have a fully relocated binary when you start?
> >
> > Xen ELF file does not have relocations.
> >
> >> How do you pass the offset?
> >
> > Via MULTIBOOT_TAG_TYPE_BASE_ADDR tag.
> >
> >> Does xen have any relocation entries?
> >
> > No.
> >
> Can we then settle on using your interface but saying that bootloader
> has to execute all ELF relocations? Since you don't have them, you
> wouldn't be affected by the change but it would allow easy creation of
> relocatable binaries. Feel free in the first patch just to have a check
> for absence of relocation entries. x86-64 has only about 5 relocations
> we care about so should be easy to implement. We can reuse code in dl.c.

Granted!

Daniel

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

Re: [Xen-devel] [PATCH v5 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

On 12/11/15 14:48, Wei Liu wrote:
> On Thu, Nov 12, 2015 at 02:43:28PM +0100, Juergen Gross wrote:
>> Guest memory allocation in the domain builder of libxc is done via
>> virtual addresses only. In order to be able to support preallocated
>> areas not virtually mapped reorganize the memory allocator to keep
>> track of allocated pages globally and in allocated segments.
>>
>> This requires an interface change of the allocate callback of the
>> domain builder which currently is using the last mapped virtual
>> address as a parameter. This is no problem as the only user of this
>> callback is stubdom/grub/kexec.c using this virtual address to
>> calculate the last used pfn.
>>
>> Signed-off-by: Juergen Gross 
> 
> If you've tested and confirmed pvgrub (stubdom based grub) doesn't
> break:
> 
> Acked-by: Wei Liu 
> 

Hmm, difficult. Is this ever tested automatically? I just tried and
it died:

...
vbd 51712 is hd0
*** BLKFRONT for device/vbd/51712 **
backend at /local/domain/0/backend/qdisk/3/51712
Failed to read /local/domain/0/backend/qdisk/3/51712/feature-barrier.
16777216 sectors of 0 bytes
**

I guess I need a special setup to make it work. :-(


Juergen

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

Re: [Xen-devel] [PATCH v5 1/9] libxc: reorganize domain builder guest memory allocator

[Ian Campbell]

On Thu, 2015-11-12 at 15:03 +0100, Juergen Gross wrote:
> On 12/11/15 14:48, Wei Liu wrote:
> > On Thu, Nov 12, 2015 at 02:43:28PM +0100, Juergen Gross wrote:
> > > Guest memory allocation in the domain builder of libxc is done via
> > > virtual addresses only. In order to be able to support preallocated
> > > areas not virtually mapped reorganize the memory allocator to keep
> > > track of allocated pages globally and in allocated segments.
> > > 
> > > This requires an interface change of the allocate callback of the
> > > domain builder which currently is using the last mapped virtual
> > > address as a parameter. This is no problem as the only user of this
> > > callback is stubdom/grub/kexec.c using this virtual address to
> > > calculate the last used pfn.
> > > 
> > > Signed-off-by: Juergen Gross 
> > 
> > If you've tested and confirmed pvgrub (stubdom based grub) doesn't
> > break:
> > 
> > Acked-by: Wei Liu 
> > 
> 
> Hmm, difficult. Is this ever tested automatically?

Yes, see the test-amd64-amd64-amd64-pvgrub and test-amd64-amd64-i386-pvgrub 
jobs in any recent osstest flight (it was added a couple of months back.

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-amd64-pvgrub/xen-unstable.html

suggests it works ok in general.

Ian.


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

[Xen-devel] [PATCH GRUB] Allow initrd concatenation on ARM64

[Vladimir 'φ-coder/phcoder' Serbinenko]

While on it also change "xen_linux" to "xen_kernel" to be vendor-neutral
Could someone test please? I only compile-tested it
diff --git a/docs/grub.texi b/docs/grub.texi
index 1df3db2..112b42b 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3859,7 +3859,7 @@ you forget a command, you can run the command @command{help}
 * videoinfo::   List available video modes
 @comment * xen_*::  Xen boot commands
 * xen_hypervisor::  Load xen hypervisor binary
-* xen_linux::   Load dom0 kernel for xen hypervisor
+* xen_kernel::  Load dom0 kernel for xen hypervisor
 * xen_initrd::  Load dom0 initrd for dom0 kernel
 * xen_xsm:: Load xen security module for xen hypervisor
 @end menu
@@ -5134,10 +5134,10 @@ verbatim as the @dfn{kernel command-line}. Any other binaries must be
 reloaded after using this command.
 @end deffn
 
-@node xen_linux
-@subsection xen_linux
+@node xen_kernel
+@subsection xen_kernel
 
-@deffn Command xen_linux file [arguments]
+@deffn Command xen_kernel file [arguments]
 Load a dom0 kernel image for xen hypervisor at the booting process of xen.
 The rest of the line is passed verbatim as the module command line.
 @end deffn
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index d9fa0e3..34f7b61 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1641,6 +1642,7 @@ module = {
 module = {
   name = xen_boot;
   common = lib/cmdline.c;
+  common = loader/linux.c;
   arm64 = loader/arm64/xen_boot.c;
   enable = arm64;
 };
diff --git a/grub-core/loader/arm64/xen_boot.c b/grub-core/loader/arm64/xen_boot.c
index d1a2189..e4a12bc 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -33,6 +33,7 @@
 #include 	/* required by struct xen_hypervisor_header */
 #include 
 #include 
+#include 
 
 GRUB_MOD_LICENSE ("GPLv3+");
 
@@ -137,17 +138,53 @@ xen_boot_address_align (grub_addr_t start, grub_size_t align)
 }
 
 /* set module type according to command name. */
-static grub_err_t
-set_module_type (grub_command_t cmd, struct xen_boot_binary *module)
+static struct xen_boot_binary *
+allocate_module (module_type_t type)
 {
-  if (!grub_strcmp (cmd->name, "xen_linux"))
-module->node_info.type = MODULE_IMAGE;
-  else if (!grub_strcmp (cmd->name, "xen_initrd"))
-module->node_info.type = MODULE_INITRD;
-  else if (!grub_strcmp (cmd->name, "xen_xsm"))
-module->node_info.type = MODULE_XSM;
+  struct xen_boot_binary *module;
 
-  return GRUB_ERR_NONE;
+  if (!loaded)
+{
+  grub_error (GRUB_ERR_BAD_ARGUMENT,
+		  N_("you need to load the Xen Hypervisor first"));
+  return NULL;
+}
+
+  module =
+(struct xen_boot_binary *) grub_zalloc (sizeof (struct xen_boot_binary));
+  if (!module)
+return NULL;
+
+  module->node_info.type = type;
+
+  switch (module->node_info.type)
+{
+case MODULE_IMAGE:
+case MODULE_INITRD:
+case MODULE_XSM:
+  module->node_info.compat_string =
+	default_compat_string[module->node_info.type].compat_string;
+  module->node_info.compat_string_size =
+	default_compat_string[module->node_info.type].size;
+  break;
+
+case MODULE_CUSTOM:
+  /* we have set the node_info in set_module_type */
+  break;
+
+default:
+  grub_error (GRUB_ERR_BAD_ARGUMENT, N_("invalid argument"));
+  return NULL;
+}
+  module->name = module->node_info.compat_string;
+  module->align = module_default_align[module->node_info.type];
+
+  grub_dprintf ("xen_loader", "Init %s module and node info:\n"
+		"compatible %s\ncompat_string_size 0x%lx\n",
+		module->name, module->node_info.compat_string,
+		module->node_info.compat_string_size);
+
+  return module;
 }
 
 static grub_err_t
@@ -372,11 +409,11 @@ xen_unload (void)
   return GRUB_ERR_NONE;
 }
 
-static void
-xen_boot_binary_load (struct xen_boot_binary *binary, grub_file_t file,
-		  int argc, char *argv[])
+static grub_err_t
+xen_boot_binary_allocate (struct xen_boot_binary *binary,
+			  grub_size_t size)
 {
-  binary->size = grub_file_size (file);
+  binary->size = size;
   grub_dprintf ("xen_loader", "Xen_boot %s file size: 0x%lx\n",
 		binary->name, binary->size);
 
@@ -386,13 +423,21 @@ xen_boot_binary_load (struct xen_boot_binary *binary, grub_file_t file,
 	 (binary->size +
 	  binary->align));
   if (!binary->start)
-{
-  grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
-  return;
-}
+return grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
 
   grub_dprintf ("xen_loader", "Xen_boot %s numpages: 0x%lx\n",
 		binary->name, GRUB_EFI_BYTES_TO_PAGES (binary->size + binary->align));
+  return GRUB_ERR_NONE;
+}
+
+static void
+xen_boot_binary_load (struct xen_boot_binary *binary, grub_file_t file,
+		  int argc, char *argv[])
+{
+  if (xen_boot_binary_allocate(binary, grub_file_size(file)))
+{
+  return;
+}
 
   if 

Re: [Xen-devel] Question about Xen reboot on panic

[Ian Campbell]

On Thu, 2015-11-12 at 12:57 +, Wei Liu wrote:
> On Thu, Nov 12, 2015 at 12:52:56PM +, Andrew Cooper wrote:
> > 
> > In screen for example, you need to send CTRL-a a to send a "CTRL-a" on
> > the serial.
> > 
> 
> And for minicom it is "Ctrl-a Ctrl-a" to send "Ctrl-a".

Now run minicom in screen ;-) (Ctrl-a a ?)

I recommend using conswitch=x (for any letter x you like, although x is
often good) on your hypervisor command line to change the Xen debug key to
something which doesn't clash with things.

> 
> ___
> 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] [PATCH GRUB] Allow initrd concatenation on ARM64

[Fu Wei]

Hi Vladimir,

OK, I will test it.

On 12 November 2015 at 21:08, Vladimir 'φ-coder/phcoder' Serbinenko
 wrote:
> While on it also change "xen_linux" to "xen_kernel" to be vendor-neutral
> Could someone test please? I only compile-tested it



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

[Xen-devel] Uniform commands for booting xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I'd like to have set of commands that would boot xen on all
platforms. I thought of following set:

xen_hypervisor FILE XEN_OPTIONS
xen_kernel FILE KERNEL_OPTIONS
xen_initrd INITRD INITRD INITRD
all initrds are concatenated.
xen_xsm ???

On arm64 it would use the arm64 xen FDT protocol but on x86 should we
use multiboot2 if multiboot2 header is present and multiboot otherwise?
Or do xen devs have other preferences?



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

Re: [Xen-devel] Re 6ab1e4a932 ("serial: Seperate the PCI device ids and parameters (v1)")

[Konrad Rzeszutek Wilk]

On Wed, Nov 11, 2015 at 07:29:41AM -0700, Jan Beulich wrote:
> Konrad,
> 
> in that change you give bar_idx a second purpose: Originally it was
> what its name say - an index into the BARs of the device. In that
> change, however, you also use it to index into an individual BAR.
> IOW right now we can use
> - BAR0 + first_offset
> - BAR1 + uart_offset + first_offset
> - BAR2+ 2*uart_offset + first_offset
> etc, which doesn't seem to be what we want. But of course I may
> be overlooking something, assuming you tested the 2nd port of a
> 2-port Oxford card (the only one having .max_bars > 1).

Looking at the card and the machine the serial cable is attached to
COM1, and I *think* I would have tested COM2 since it was such an
unusual card. But that was years ago..

Here is what the lspci tells me:
-bash-4.1# lspci -s 01:00.0 -v
01:00.0 Serial controller: Oxford Semiconductor Ltd Device c158 (prog-if 02 
[16550])
Subsystem: Oxford Semiconductor Ltd Device c158
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fe00 (32-bit, non-prefetchable) [size=16K]
Memory at fde0 (32-bit, non-prefetchable) [size=2M]
Memory at fdc0 (32-bit, non-prefetchable) [size=2M]
Capabilities: [40] Power Management version 3
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [b0] MSI-X: Enable- Count=16 Masked-
Capabilities: [100] Device Serial Number 00-30-e0-11-11-00-01-50
Capabilities: [110] Power Budgeting 
Kernel driver in use: serial

-bash-4.1# dmesg | grep tty
[9.507453] ttyS0: detected caps 0700 should be 0500
[9.507466] :01:00.0: ttyS0 at MMIO 0xfe001000 (irq = 16, base_baud = 
400) is a 16C950/954
[9.509614] ttyS1: detected caps 0700 should be 0500
[9.509626] :01:00.0: ttyS1 at MMIO 0xfe001200 (irq = 16, base_baud = 
400) is a 16C950/954
[9.959747] tty ptyq8: hash matches


> 
> I'm asking in the context of wanting to enable a card I have in a
> new box of mine. While a single port one, it has 2-, 4-, and 8-port
> siblings, with each port using the same (IO) BAR. Just like Linux
> we'd need a flag indicating whether only BAR0 is to be used,
> giving bar_idx back the meaning it had originally, and introducing
> a more generic idx which (depending on the flag) means either.

/me nods.

> But I'd need to know which value to give the flag for that 2-port
> card. (And I'd hope you're still in possession of the card, so that
> I could later ask you to test the resulting patch there.)

Of course. Not this week - next week I can muck in the lab.
> 
> At the same time I noticed that the size check can't be quite right
> in the MMIO path: It doesn't account for {first,uart}_offset. If
> you agree, I could fix this along with the generalization of the
> current logic to cover both MMIO and IO cases.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH v5 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 12, 2015 at 02:47:24PM +, Ian Campbell wrote:
> On Thu, 2015-11-12 at 15:03 +0100, Juergen Gross wrote:
> > On 12/11/15 14:48, Wei Liu wrote:
> > > On Thu, Nov 12, 2015 at 02:43:28PM +0100, Juergen Gross wrote:
> > > > Guest memory allocation in the domain builder of libxc is done via
> > > > virtual addresses only. In order to be able to support preallocated
> > > > areas not virtually mapped reorganize the memory allocator to keep
> > > > track of allocated pages globally and in allocated segments.
> > > > 
> > > > This requires an interface change of the allocate callback of the
> > > > domain builder which currently is using the last mapped virtual
> > > > address as a parameter. This is no problem as the only user of this
> > > > callback is stubdom/grub/kexec.c using this virtual address to
> > > > calculate the last used pfn.
> > > > 
> > > > Signed-off-by: Juergen Gross 
> > > 
> > > If you've tested and confirmed pvgrub (stubdom based grub) doesn't
> > > break:
> > > 
> > > Acked-by: Wei Liu 
> > > 
> > 
> > Hmm, difficult. Is this ever tested automatically?
> 
> Yes, see the test-amd64-amd64-amd64-pvgrub and test-amd64-amd64-i386-pvgrub 
> jobs in any recent osstest flight (it was added a couple of months back.
> 
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-amd64-pvgrub/xen-unstable.html
> 
> suggests it works ok in general.
> 

Ah, so I was wrong. Thanks for correction.

Wei.

> Ian.
> 

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

Re: [Xen-devel] [PATCH V8 5/7] xl: add pvusb commands

[George Dunlap]

On Thu, Nov 12, 2015 at 2:42 PM, Olaf Hering  wrote:
> On Wed, Oct 21, Chunyan Liu wrote:
>
>> Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
>> usb-attach and usb-detach.
>
> How is this supposed to be handled in libvirt? It looks like libvirt has
> to copy what is done here. If thats true the logic should be in libxlu
> so that both xl and libvirt can call the same functions.

What logic are you talking about?  The usb code in xl mirrors all the
other code (nic, disk, ).

In any case, I think it would be the person writing the libvirt
bindings who would be responsible for abstracting things like that
(just as I will have to do a bit of re-work to get the HVM usb stuff
implemented).

 -George

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

Re: [Xen-devel] [PATCH v5 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 12, 2015 at 03:03:32PM +0100, Juergen Gross wrote:
> On 12/11/15 14:48, Wei Liu wrote:
> > On Thu, Nov 12, 2015 at 02:43:28PM +0100, Juergen Gross wrote:
> >> Guest memory allocation in the domain builder of libxc is done via
> >> virtual addresses only. In order to be able to support preallocated
> >> areas not virtually mapped reorganize the memory allocator to keep
> >> track of allocated pages globally and in allocated segments.
> >>
> >> This requires an interface change of the allocate callback of the
> >> domain builder which currently is using the last mapped virtual
> >> address as a parameter. This is no problem as the only user of this
> >> callback is stubdom/grub/kexec.c using this virtual address to
> >> calculate the last used pfn.
> >>
> >> Signed-off-by: Juergen Gross 
> > 
> > If you've tested and confirmed pvgrub (stubdom based grub) doesn't
> > break:
> > 
> > Acked-by: Wei Liu 
> > 
> 
> Hmm, difficult. Is this ever tested automatically? I just tried and
> it died:
> 

Unfortunately it is not tested in osstest.

> ...
> vbd 51712 is hd0
> *** BLKFRONT for device/vbd/51712 **
> backend at /local/domain/0/backend/qdisk/3/51712
> Failed to read /local/domain/0/backend/qdisk/3/51712/feature-barrier.
> 16777216 sectors of 0 bytes
> **
> 
> I guess I need a special setup to make it work. :-(
> 

Can you paste in your guest config here?


Wei.

> 
> Juergen

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

Re: [Xen-devel] [PATCH v2 5/6] multiboot2: Add support for relocatable images

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.11.2015 14:15, Daniel Kiper wrote:
> On Tue, Nov 10, 2015 at 04:23:46PM +0100, Vladimir 'phcoder' Serbinenko wrote:
>> Le 10 nov. 2015 3:52 PM, "Daniel Kiper"  a écrit :
>>> On Mon, Nov 09, 2015 at 09:08:35PM +0100, Vladimir 'φ-coder/phcoder'
>> Serbinenko wrote:
 On 20.07.2015 16:35, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper 
 What is handling the actual relocation?
>>>
>>> In Xen we get image offset from GRUB2 and using this value we calculate
>>> relative addresses. We are using %fs for it.
>>>
 Why doesn't this patch include support for ELF relocations?
>>>
>>> This is another option. We considered it too. However, in our case
>>> relative addressing looks simpler then ELF relocations.
>> How is it simpler than to have a fully relocated binary when you start?
> 
> Xen ELF file does not have relocations.
> 
>> How do you pass the offset?
> 
> Via MULTIBOOT_TAG_TYPE_BASE_ADDR tag.
> 
>> Does xen have any relocation entries?
> 
> No.
> 
Can we then settle on using your interface but saying that bootloader
has to execute all ELF relocations? Since you don't have them, you
wouldn't be affected by the change but it would allow easy creation of
relocatable binaries. Feel free in the first patch just to have a check
for absence of relocation entries. x86-64 has only about 5 relocations
we care about so should be easy to implement. We can reuse code in dl.c.
>> Was such xen already released? Just looking for how it should
>> be in perspective and how to get there
> 
> We agreed (in Xen community) that we would like to have multiboot2 protocol
> with additional features set in stone at first. So, this patch series just
> propose some changes which are required by Xen but they are not used by any
> Xen release yet. Additionally, we want that these extensions are quite generic
> and could be used by other projects if they need them too.
> 
> Daniel
> 




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 v2 3/6] i386/relocator: Add grub_relocator64_efi relocator

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.11.2015 15:38, Daniel Kiper wrote:
>>> -  if (entry_specified)
>>> > > +  if (keep_bs && efi_entry_specified)
>>> > > +grub_multiboot_payload_eip = efi_entry;
>>> > > +  else if (entry_specified)
>>> > >  grub_multiboot_payload_eip = entry;
>>> > >
>> > This seems redundant.
> What is wrong here?
I just mean that if we use a single structure this code could go away



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 v5 1/9] libxc: reorganize domain builder guest memory allocator

[Wei Liu]

On Thu, Nov 12, 2015 at 02:43:28PM +0100, Juergen Gross wrote:
> Guest memory allocation in the domain builder of libxc is done via
> virtual addresses only. In order to be able to support preallocated
> areas not virtually mapped reorganize the memory allocator to keep
> track of allocated pages globally and in allocated segments.
> 
> This requires an interface change of the allocate callback of the
> domain builder which currently is using the last mapped virtual
> address as a parameter. This is no problem as the only user of this
> callback is stubdom/grub/kexec.c using this virtual address to
> calculate the last used pfn.
> 
> Signed-off-by: Juergen Gross 

If you've tested and confirmed pvgrub (stubdom based grub) doesn't
break:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

[Wei Liu]

On Thu, Nov 12, 2015 at 02:43:35PM +0100, Juergen Gross wrote:
> In order to prepare a p2m list outside of the initial kernel mapping
> do a rework of the domain builder's page table handler. The goal is
> to be able to use common helpers for page table allocation and setup
> for initial kernel page tables and page tables mapping the p2m list.
> This is achieved by supporting multiple mapping areas. The mapped
> virtual addresses of the single areas must not overlap, while the
> page tables of a new area added might already be partially present.
> Especially the top level page table is existing only once, of course.
> 
> Currently restrict the number of mappings to 1 because the only mapping
> now is the initial mapping created by toolstack. There should not be
> behaviour change and guest visible change introduced.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Wei Liu ". :-)

I don't think you need to resend though.

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

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

[Atom2]

Hi Andrew,
thanks for your reply. Answers are inline further down.

Am 12.11.15 um 14:01 schrieb Andrew Cooper:

On 12/11/15 12:52, Jan Beulich wrote:

On 12.11.15 at 02:08,  wrote:

After the upgrade HVM domUs appear to no longer work - regardless of the
dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
domUs, however, work just fine as before on both dom0 kernels.

xl dmesg shows the following information after the first crashed HVM
domU which is started as part of the machine booting up:
[...]
(XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest
state (0).
(XEN) * VMCS Area **
(XEN) *** Guest State ***
(XEN) CR0: actual=0x0039, shadow=0x0011,
gh_mask=
(XEN) CR4: actual=0x2050, shadow=0x,
gh_mask=
(XEN) CR3: actual=0x0080, target_count=0
(XEN)  target0=, target1=
(XEN)  target2=, target3=
(XEN) RSP = 0x6fdc (0x6fdc)  RIP =
0x0001 (0x0001)

Other than RIP looking odd for a guest still in non-paged protected
mode I can't seem to spot anything wrong with guest state.

odd? That will be the source of the failure.

Out of long mode, the upper 32bit of %rip should all be zero, and it
should not be possible to set any of them.

I suspect that the guest has exited for emulation, and there has been a
bad update to %rip.  The alternative (which I hope is not the case) is
that there is a hardware errata which allows the guest to accidentally
get it self into this condition.

Are you able to rerun with a debug build of the hypervisor?
Given that I am compiling from source under gentoo and provided you lend 
me a helping hand in case I get stuck, I am confident that this is possible.


gentoo has three xen packages (they call those ebuilds) as follows
app-emulation/xen
app-emulation/xen-tools
app-emulation/pvgrub
all of which are installed on my system. The former two offer a debug 
USE-flag and I assume that debug code for the latter is not required as 
this is for (the still working) PV domUs only. Furthermore as you are 
talking about the hypervisor, I guess it is safe to assume that it is 
app-emulation/xen and not xen-tools. Right?


BTW: The description of the debug USE flag reads as follows:
Enable extra debug codepaths, like asserts and extra output. If you want 
to get meaningful backtraces see 
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces

I assume that backtraces are probably not required to get things moving.

Another question is whether prior to enabling the debug USE flag it 
might make sense to re-compile with gcc-4.8.5 (please see my previous 
list reply) to rule out any compiler related issues. Jan, Andrew - what 
are your thoughts?


Many thanks Atom2

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

[Xen-devel] [libvirt test] 64130: regressions - FAIL

[osstest service owner]

flight 64130 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64130/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 63340

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 libvirt  db92aee2b477355759351889e37a365379b43bf6
baseline version:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis63340  2015-10-28 04:19:47 Z   15 days
Failing since 63352  2015-10-29 04:20:29 Z   14 days   12 attempts
Testing same since64130  2015-11-11 11:26:37 Z1 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Daniel Veillard 
  Jiri Denemark 
  John Ferlan 
  Laine Stump 
  Luyao Huang 
  Maxim Perevedentsev 
  Michal Privoznik 
  Michel Normand 
  Nikolay Shirokovskiy 
  Peter Krempa 
  Roman Bogorodskiy 

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  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd 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


Not pushing.

(No revision log; it would be 779 lines long.)

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

[Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

[Juergen Gross]

In order to prepare a p2m list outside of the initial kernel mapping
do a rework of the domain builder's page table handler. The goal is
to be able to use common helpers for page table allocation and setup
for initial kernel page tables and page tables mapping the p2m list.
This is achieved by supporting multiple mapping areas. The mapped
virtual addresses of the single areas must not overlap, while the
page tables of a new area added might already be partially present.
Especially the top level page table is existing only once, of course.

Currently restrict the number of mappings to 1 because the only mapping
now is the initial mapping created by toolstack. There should not be
behaviour change and guest visible change introduced.

Signed-off-by: Juergen Gross 
Reviewed-by: Wei Liu arch_private;
+struct xc_dom_x86_mapping *map, *map_cmp;
+xen_pfn_t pfn_end;
+xen_vaddr_t mask;
+unsigned bits;
+int l, m;
 
-if ( bits == 0 )
-return 0;  /* unused */
+if ( domx86->n_mappings == MAPPING_MAX )
+{
+xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
+ "%s: too many mappings\n", __FUNCTION__);
+return -ENOMEM;
+}
+map = domx86->maps + domx86->n_mappings;
 
-if ( bits == (8 * sizeof(unsigned long)) )
+pfn_end = pfn + ((to - from) >> PAGE_SHIFT_X86);
+if ( pfn_end >= dom->p2m_size )
 {
-/* must be pgd, need one */
-start = 0;
-end = -1;
-tables = 1;
+xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
+ "%s: not enough memory for initial mapping (%#"PRIpfn" > 
%#"PRIpfn")",
+ __FUNCTION__, pfn_end, dom->p2m_size);
+return -ENOMEM;
 }
-else
+for ( m = 0; m < domx86->n_mappings; m++ )
+{
+map_cmp = domx86->maps + m;
+if ( from < map_cmp->area.to && to > map_cmp->area.from )
+{
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: overlapping mappings\n", __FUNCTION__);
+return -EINVAL;
+}
+}
+
+memset(map, 0, sizeof(*map));
+map->area.from = from & domx86->params->vaddr_mask;
+map->area.to = to & domx86->params->vaddr_mask;
+
+for ( l = domx86->params->levels - 1; l >= 0; l-- )
 {
-start = round_down(start, mask);
-end = round_up(end, mask);
-tables = ((end - start) >> bits) + 1;
+map->lvls[l].pfn = pfn + map->area.pgtables;
+if ( l == domx86->params->levels - 1 )
+{
+/* Top level page table in first mapping only. */
+if ( domx86->n_mappings == 0 )
+{
+map->lvls[l].from = 0;
+map->lvls[l].to = domx86->params->vaddr_mask;
+map->lvls[l].pgtables = 1;
+map->area.pgtables++;
+}
+continue;
+}
+
+bits = PAGE_SHIFT_X86 + (l + 1) * PGTBL_LEVEL_SHIFT_X86;
+mask = bits_to_mask(bits);
+map->lvls[l].from = map->area.from & ~mask;
+map->lvls[l].to = map->area.to | mask;
+
+if ( domx86->params->levels == PGTBL_LEVELS_I386 &&
+ domx86->n_mappings == 0 && to < 0xc000 

[Xen-devel] [PATCH v5 5/9] libxc: use domain builder architecture private data for x86 pv domains

[Juergen Gross]

Move some data private to the x86 domain builder to the private data
section. Remove extra_pages as they are used nowhere.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
 tools/libxc/include/xc_dom.h |  8 
 tools/libxc/xc_dom_x86.c | 48 +---
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 09f73cd..0ba9821 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,15 +94,7 @@ struct xc_dom_image {
 xen_pfn_t pfn_alloc_end;
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
-
-/* initial page tables */
-unsigned int pgtables;
-unsigned int pg_l4;
-unsigned int pg_l3;
-unsigned int pg_l2;
-unsigned int pg_l1;
 unsigned int alloc_bootstack;
-unsigned int extra_pages;
 xen_vaddr_t virt_pgtab_end;
 
 /* other state info */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index ea32b00..aba50df 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -69,6 +69,15 @@
 #define round_down(addr, mask)   ((addr) & ~(mask))
 #define round_up(addr, mask) ((addr) | (mask))
 
+struct xc_dom_image_x86 {
+/* initial page tables */
+unsigned int pgtables;
+unsigned int pg_l4;
+unsigned int pg_l3;
+unsigned int pg_l2;
+unsigned int pg_l1;
+};
+
 /* get guest IO ABI protocol */
 const char *xc_domain_get_native_protocol(xc_interface *xch,
   uint32_t domid)
@@ -132,9 +141,9 @@ static int alloc_pgtables(struct xc_dom_image *dom, int pae,
 int pages, extra_pages;
 xen_vaddr_t try_virt_end;
 xen_pfn_t try_pfn_end;
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 
 extra_pages = dom->alloc_bootstack ? 1 : 0;
-extra_pages += dom->extra_pages;
 extra_pages += 128; /* 512kB padding */
 pages = extra_pages;
 for ( ; ; )
@@ -152,29 +161,30 @@ static int alloc_pgtables(struct xc_dom_image *dom, int 
pae,
 return -ENOMEM;
 }
 
-dom->pg_l4 =
+domx86->pg_l4 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l4_bits);
-dom->pg_l3 =
+domx86->pg_l3 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l3_bits);
-dom->pg_l2 =
+domx86->pg_l2 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l2_bits);
-dom->pg_l1 =
+domx86->pg_l1 =
 nr_page_tables(dom, dom->parms.virt_base, try_virt_end, l1_bits);
 if (pae && try_virt_end < 0xc000)
 {
 DOMPRINTF("%s: PAE: extra l2 page table for l3#3",
   __FUNCTION__);
-dom->pg_l2++;
+domx86->pg_l2++;
 }
-dom->pgtables = dom->pg_l4 + dom->pg_l3 + dom->pg_l2 + dom->pg_l1;
-pages = dom->pgtables + extra_pages;
+domx86->pgtables = domx86->pg_l4 + domx86->pg_l3 +
+   domx86->pg_l2 + domx86->pg_l1;
+pages = domx86->pgtables + extra_pages;
 if ( dom->virt_alloc_end + pages * PAGE_SIZE_X86 <= try_virt_end + 1 )
 break;
 }
 dom->virt_pgtab_end = try_virt_end + 1;
 
 return xc_dom_alloc_segment(dom, >pgtables_seg, "page tables", 0,
-dom->pgtables * PAGE_SIZE_X86);
+domx86->pgtables * PAGE_SIZE_X86);
 }
 
 /*  */
@@ -262,9 +272,10 @@ static xen_pfn_t move_l3_below_4G(struct xc_dom_image *dom,
 
 static int setup_pgtables_x86_32_pae(struct xc_dom_image *dom)
 {
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 xen_pfn_t l3pfn = dom->pgtables_seg.pfn;
-xen_pfn_t l2pfn = l3pfn + dom->pg_l3;
-xen_pfn_t l1pfn = l2pfn + dom->pg_l2;
+xen_pfn_t l2pfn = l3pfn + domx86->pg_l3;
+xen_pfn_t l1pfn = l2pfn + domx86->pg_l2;
 l3_pgentry_64_t *l3tab;
 l2_pgentry_64_t *l2tab = NULL;
 l1_pgentry_64_t *l1tab = NULL;
@@ -373,10 +384,11 @@ static int alloc_pgtables_x86_64(struct xc_dom_image *dom)
 
 static int setup_pgtables_x86_64(struct xc_dom_image *dom)
 {
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
 xen_pfn_t l4pfn = dom->pgtables_seg.pfn;
-xen_pfn_t l3pfn = l4pfn + dom->pg_l4;
-xen_pfn_t l2pfn = l3pfn + dom->pg_l3;
-xen_pfn_t l1pfn = l2pfn + dom->pg_l2;
+xen_pfn_t l3pfn = l4pfn + domx86->pg_l4;
+xen_pfn_t l2pfn = l3pfn + domx86->pg_l3;
+xen_pfn_t l1pfn = l2pfn + domx86->pg_l2;
 l4_pgentry_64_t *l4tab = xc_dom_pfn_to_ptr(dom, l4pfn, 1);
 l3_pgentry_64_t *l3tab = NULL;
 l2_pgentry_64_t *l2tab = NULL;
@@ -619,6 +631,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 
 static int start_info_x86_32(struct xc_dom_image *dom)
 {
+struct xc_dom_image_x86 *domx86 = 

[Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
 tools/libxc/include/xc_dom.h |  5 +
 tools/libxc/xc_dom_core.c| 19 +--
 tools/libxc/xc_dom_x86.c |  8 
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 0ba9821..2358012 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,6 +94,11 @@ struct xc_dom_image {
 xen_pfn_t pfn_alloc_end;
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
+
+/* initrd parameters as specified in start_info page */
+unsigned long initrd_start;
+unsigned long initrd_len;
+
 unsigned int alloc_bootstack;
 xen_vaddr_t virt_pgtab_end;
 
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 3a31222..7b48b1f 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1041,6 +1041,7 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
 int xc_dom_build_image(struct xc_dom_image *dom)
 {
 unsigned int page_size;
+bool unmapped_initrd;
 
 DOMPRINTF_CALLED(dom->xch);
 
@@ -1064,11 +1065,15 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 if ( dom->kernel_loader->loader(dom) != 0 )
 goto err;
 
-/* load ramdisk */
-if ( dom->ramdisk_blob )
+/* Don't load ramdisk now if no initial mapping required. */
+unmapped_initrd = dom->parms.unmapped_initrd && !dom->ramdisk_seg.vstart;
+
+if ( dom->ramdisk_blob && !unmapped_initrd )
 {
 if ( xc_dom_build_ramdisk(dom) != 0 )
 goto err;
+dom->initrd_start = dom->ramdisk_seg.vstart;
+dom->initrd_len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
 }
 
 /* load devicetree */
@@ -1106,6 +,16 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 if ( dom->virt_pgtab_end && xc_dom_alloc_pad(dom, dom->virt_pgtab_end) )
 return -1;
 
+/* Load ramdisk if no initial mapping required. */
+if ( dom->ramdisk_blob && unmapped_initrd )
+{
+if ( xc_dom_build_ramdisk(dom) != 0 )
+goto err;
+dom->flags |= SIF_MOD_START_PFN;
+dom->initrd_start = dom->ramdisk_seg.pfn;
+dom->initrd_len = page_size * dom->ramdisk_seg.pages;
+}
+
 return 0;
 
  err:
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index aba50df..3c6bb9c 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -663,8 +663,8 @@ static int start_info_x86_32(struct xc_dom_image *dom)
 
 if ( dom->ramdisk_blob )
 {
-start_info->mod_start = dom->ramdisk_seg.vstart;
-start_info->mod_len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->mod_start = dom->initrd_start;
+start_info->mod_len = dom->initrd_len;
 }
 
 if ( dom->cmdline )
@@ -710,8 +710,8 @@ static int start_info_x86_64(struct xc_dom_image *dom)
 
 if ( dom->ramdisk_blob )
 {
-start_info->mod_start = dom->ramdisk_seg.vstart;
-start_info->mod_len = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
+start_info->mod_start = dom->initrd_start;
+start_info->mod_len = dom->initrd_len;
 }
 
 if ( dom->cmdline )
-- 
2.6.2


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

[Xen-devel] [PATCH v5 0/9] libxc: support building large pv-domains

[Juergen Gross]

The Xen hypervisor supports starting a dom0 with large memory (up to
the TB range) by not including the initrd and p2m list in the initial
kernel mapping. Especially the p2m list can grow larger than the
available virtual space in the initial mapping.

The started kernel is indicating the support of each feature via
elf notes.

This series enables the domain builder in libxc to do the same as the
hypervisor. This enables starting of huge pv-domUs via xl.

Unmapped initrd is supported for 64 and 32 bit domains, omitting the
p2m from initial kernel mapping is possible for 64 bit domains only.

Tested with:
- 32 bit domU (kernel not supporting unmapped initrd)
- 32 bit domU (kernel supporting unmapped initrd)
- 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
- 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
- 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
- HVM domU

Changes in V5:
- minor modifications in patch 8 as suggested by Wei Liu

Changes in v4:
- updated patch 1 as suggested by Wei Liu (comment and variable name)
- modify comment in patch 6 as suggested by Wei Liu
- rework of patch 8 reducing line count by nearly 100
- added some additional plausibility checks to patch 8 as suggested by
  Wei Liu
- renamed round_pg() to round_pg_up() in patch 9 as suggested by Wei Liu

Changes in v3:
- Rebased the complete series to new staging (hvm builder patches by
  Roger Pau Monne)
- Removed old patch 1 as it broke stubdom build
- Introduced new Patch 1 to make allocation of guest memory more clear
  regarding virtual/physical memory allocation (requested by Ian Campbell)
- Change name of flag to indicate support of unmapped initrd in patch 2
  (requested by Ian Campbell)
- Introduce new patches 3, 4, 5 ("rename domain builder count_pgtables to
  alloc_pgtables", "introduce domain builder architecture specific data",
  "use domain builder architecture private data for x86 pv domains") to
  assist later page table work
- don't fiddle with initrd virtual address in patch 6 (was patch 3 in v2),
  add explicit initrd parameters for start_info in struct xc_dom_image
  instead (requested by Ian Campbell)
- Introduce new patch 8 ("rework of domain builder's page table handler")
  to be able to use common helpers for unmapped p2m list (requested by
  Ian Campbell)
- use now known segment size in pages for p2m list in patch 9 (was patch
  5 in v2) instead of fiddling with segment end address (requested by
  Ian Campbell)
- split alloc_p2m_list() in patch 9 (was patch 5 in v2) to 32/64 bit
  variants (requested by Ian Campbell)

Changes in v2:
- patch 2 has been removed as it has been applied already
- introduced new patch 2 as suggested by Ian Campbell: add a flag
  indicating support of an unmapped initrd to the parsed elf data of
  the elf_dom_parms structure
- updated patch description of patch 3 as requested by Ian Campbell


Juergen Gross (9):
  libxc: reorganize domain builder guest memory allocator
  xen: add generic flag to elf_dom_parms indicating support of unmapped
initrd
  libxc: rename domain builder count_pgtables to alloc_pgtables
  libxc: introduce domain builder architecture specific data
  libxc: use domain builder architecture private data for x86 pv domains
  libxc: create unmapped initrd in domain builder if supported
  libxc: split p2m allocation in domain builder from other magic pages
  libxc: rework of domain builder's page table handler
  libxc: create p2m list outside of kernel mapping if supported

 stubdom/grub/kexec.c   |  12 +-
 tools/libxc/include/xc_dom.h   |  34 +--
 tools/libxc/xc_dom_arm.c   |   6 +-
 tools/libxc/xc_dom_core.c  | 180 
 tools/libxc/xc_dom_x86.c   | 564 +
 tools/libxc/xg_private.h   |  39 +--
 xen/arch/x86/domain_build.c|   4 +-
 xen/common/libelf/libelf-dominfo.c |   3 +
 xen/include/xen/libelf.h   |   1 +
 9 files changed, 491 insertions(+), 352 deletions(-)

-- 
2.6.2


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

[Xen-devel] [PATCH v5 9/9] libxc: create p2m list outside of kernel mapping if supported

[Juergen Gross]

In case the kernel of a new pv-domU indicates it is supporting a p2m
list outside the initial kernel mapping by specifying INIT_P2M, let
the domain builder allocate the memory for the p2m list from physical
guest memory only and map it to the address the kernel is expecting.

This will enable loading pv-domUs larger than 512 GB.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
 tools/libxc/include/xc_dom.h |  1 +
 tools/libxc/xc_dom_core.c| 15 +++-
 tools/libxc/xc_dom_x86.c | 56 ++--
 3 files changed, 64 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 7c157c3..ad8e47e 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -238,6 +238,7 @@ struct xc_dom_arch {
 char *native_protocol;
 int page_shift;
 int sizeof_pfn;
+int p2m_base_supported;
 int arch_private_size;
 
 struct xc_dom_arch *next;
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ad91b35..5d6c3ba 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -777,6 +777,7 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 dom->parms.virt_hypercall = UNSET_ADDR;
 dom->parms.virt_hv_start_low = UNSET_ADDR;
 dom->parms.elf_paddr_offset = UNSET_ADDR;
+dom->parms.p2m_base = UNSET_ADDR;
 
 dom->alloc_malloc += sizeof(*dom);
 return dom;
@@ -1096,7 +1097,11 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 }
 
 /* allocate other pages */
-if ( dom->arch_hooks->alloc_p2m_list &&
+if ( !dom->arch_hooks->p2m_base_supported ||
+ dom->parms.p2m_base >= dom->parms.virt_base ||
+ (dom->parms.p2m_base & (XC_DOM_PAGE_SIZE(dom) - 1)) )
+dom->parms.p2m_base = UNSET_ADDR;
+if ( dom->arch_hooks->alloc_p2m_list && dom->parms.p2m_base == UNSET_ADDR 
&&
  dom->arch_hooks->alloc_p2m_list(dom) != 0 )
 goto err;
 if ( dom->arch_hooks->alloc_magic_pages(dom) != 0 )
@@ -1124,6 +1129,14 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 dom->initrd_len = page_size * dom->ramdisk_seg.pages;
 }
 
+/* Allocate p2m list if outside of initial kernel mapping. */
+if ( dom->arch_hooks->alloc_p2m_list && dom->parms.p2m_base != UNSET_ADDR )
+{
+if ( dom->arch_hooks->alloc_p2m_list(dom) != 0 )
+goto err;
+dom->p2m_seg.vstart = dom->parms.p2m_base;
+}
+
 return 0;
 
  err:
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 1614354..7279fa2 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -69,6 +69,7 @@
 #define bits_to_mask(bits)   (((xen_vaddr_t)1 << (bits))-1)
 #define round_down(addr, mask)   ((addr) & ~(mask))
 #define round_up(addr, mask) ((addr) | (mask))
+#define round_pg_up(addr)  (((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 - 
1))
 
 struct xc_dom_params {
 unsigned levels;
@@ -90,7 +91,7 @@ struct xc_dom_x86_mapping {
 
 struct xc_dom_image_x86 {
 unsigned n_mappings;
-#define MAPPING_MAX 1
+#define MAPPING_MAX 2
 struct xc_dom_x86_mapping maps[MAPPING_MAX];
 struct xc_dom_params *params;
 };
@@ -484,11 +485,8 @@ static int setup_pgtables_x86_64(struct xc_dom_image *dom)
 
 /*  */
 
-static int alloc_p2m_list(struct xc_dom_image *dom)
+static int alloc_p2m_list(struct xc_dom_image *dom, size_t p2m_alloc_size)
 {
-size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
-
-/* allocate phys2mach table */
 if ( xc_dom_alloc_segment(dom, >p2m_seg, "phys2mach",
   0, p2m_alloc_size) )
 return -1;
@@ -499,6 +497,40 @@ static int alloc_p2m_list(struct xc_dom_image *dom)
 return 0;
 }
 
+static int alloc_p2m_list_x86_32(struct xc_dom_image *dom)
+{
+size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
+
+p2m_alloc_size = round_pg_up(p2m_alloc_size);
+return alloc_p2m_list(dom, p2m_alloc_size);
+}
+
+static int alloc_p2m_list_x86_64(struct xc_dom_image *dom)
+{
+struct xc_dom_image_x86 *domx86 = dom->arch_private;
+struct xc_dom_x86_mapping *map = domx86->maps + domx86->n_mappings;
+size_t p2m_alloc_size = dom->p2m_size * dom->arch_hooks->sizeof_pfn;
+xen_vaddr_t from, to;
+unsigned lvl;
+
+p2m_alloc_size = round_pg_up(p2m_alloc_size);
+if ( dom->parms.p2m_base != UNSET_ADDR )
+{
+from = dom->parms.p2m_base;
+to = from + p2m_alloc_size - 1;
+if ( count_pgtables(dom, from, to, dom->pfn_alloc_end) )
+return -1;
+
+map->area.pfn = dom->pfn_alloc_end;
+for ( lvl = 0; lvl < 4; lvl++ )
+map->lvls[lvl].pfn += p2m_alloc_size >> PAGE_SHIFT_X86;
+domx86->n_mappings++;
+p2m_alloc_size += map->area.pgtables << PAGE_SHIFT_X86;
+}
+
+return 

[Xen-devel] [PATCH v5 1/9] libxc: reorganize domain builder guest memory allocator

[Juergen Gross]

Guest memory allocation in the domain builder of libxc is done via
virtual addresses only. In order to be able to support preallocated
areas not virtually mapped reorganize the memory allocator to keep
track of allocated pages globally and in allocated segments.

This requires an interface change of the allocate callback of the
domain builder which currently is using the last mapped virtual
address as a parameter. This is no problem as the only user of this
callback is stubdom/grub/kexec.c using this virtual address to
calculate the last used pfn.

Signed-off-by: Juergen Gross 
---
 stubdom/grub/kexec.c |   6 +--
 tools/libxc/include/xc_dom.h |  13 +++---
 tools/libxc/xc_dom_core.c| 107 ---
 3 files changed, 79 insertions(+), 47 deletions(-)

diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 0b2f4f3..2300318 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -100,9 +100,9 @@ static void do_exchange(struct xc_dom_image *dom, xen_pfn_t 
target_pfn, xen_pfn_
 dom->p2m_host[target_pfn] = source_mfn;
 }
 
-int kexec_allocate(struct xc_dom_image *dom, xen_vaddr_t up_to)
+int kexec_allocate(struct xc_dom_image *dom)
 {
-unsigned long new_allocated = (up_to - dom->parms.virt_base) / PAGE_SIZE;
+unsigned long new_allocated = dom->pfn_alloc_end - dom->rambase_pfn;
 unsigned long i;
 
 pages = realloc(pages, new_allocated * sizeof(*pages));
@@ -319,8 +319,6 @@ void kexec(void *kernel, long kernel_size, void *module, 
long module_size, char
 
 /* Make sure the bootstrap page table does not RW-map any of our current
  * page table frames */
-kexec_allocate(dom, dom->virt_pgtab_end);
-
 if ( (rc = xc_dom_update_guest_p2m(dom))) {
 grub_printf("xc_dom_update_guest_p2m returned %d\n", rc);
 errnum = ERR_BOOT_FAILURE;
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ccc5926..68d6848 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -29,6 +29,7 @@ struct xc_dom_seg {
 xen_vaddr_t vstart;
 xen_vaddr_t vend;
 xen_pfn_t pfn;
+xen_pfn_t pages;
 };
 
 struct xc_dom_mem {
@@ -90,6 +91,7 @@ struct xc_dom_image {
 xen_pfn_t xenstore_pfn;
 xen_pfn_t shared_info_pfn;
 xen_pfn_t bootstack_pfn;
+xen_pfn_t pfn_alloc_end;
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
 
@@ -175,8 +177,8 @@ struct xc_dom_image {
 
 /* kernel loader */
 struct xc_dom_arch *arch_hooks;
-/* allocate up to virt_alloc_end */
-int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+/* allocate up to pfn_alloc_end */
+int (*allocate) (struct xc_dom_image * dom);
 
 /* Container type (HVM or PV). */
 enum {
@@ -360,14 +362,11 @@ static inline void *xc_dom_seg_to_ptr_pages(struct 
xc_dom_image *dom,
   struct xc_dom_seg *seg,
   xen_pfn_t *pages_out)
 {
-xen_vaddr_t segsize = seg->vend - seg->vstart;
-unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
-xen_pfn_t pages = (segsize + page_size - 1) / page_size;
 void *retval;
 
-retval = xc_dom_pfn_to_ptr(dom, seg->pfn, pages);
+retval = xc_dom_pfn_to_ptr(dom, seg->pfn, seg->pages);
 
-*pages_out = retval ? pages : 0;
+*pages_out = retval ? seg->pages : 0;
 return retval;
 }
 
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fbe4464..a14d477 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -535,56 +535,75 @@ void *xc_dom_pfn_to_ptr_retcount(struct xc_dom_image 
*dom, xen_pfn_t pfn,
 return phys->ptr;
 }
 
-int xc_dom_alloc_segment(struct xc_dom_image *dom,
- struct xc_dom_seg *seg, char *name,
- xen_vaddr_t start, xen_vaddr_t size)
+static int xc_dom_chk_alloc_pages(struct xc_dom_image *dom, char *name,
+  xen_pfn_t pages)
 {
 unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
-xen_pfn_t pages = (size + page_size - 1) / page_size;
-xen_pfn_t pfn;
-void *ptr;
 
-if ( start == 0 )
-start = dom->virt_alloc_end;
+if ( pages > dom->total_pages || /* multiple test avoids overflow probs */
+ dom->pfn_alloc_end - dom->rambase_pfn > dom->total_pages ||
+ pages > dom->total_pages - dom->pfn_alloc_end + dom->rambase_pfn )
+{
+xc_dom_panic(dom->xch, XC_OUT_OF_MEMORY,
+ "%s: segment %s too large (0x%"PRIpfn" > "
+ "0x%"PRIpfn" - 0x%"PRIpfn" pages)", __FUNCTION__, name,
+ pages, dom->total_pages,
+ dom->pfn_alloc_end - dom->rambase_pfn);
+return -1;
+}
+
+dom->pfn_alloc_end += pages;
+dom->virt_alloc_end += pages * page_size;
+
+return 0;
+}
 
-if ( start & (page_size - 1) )
+static int xc_dom_alloc_pad(struct xc_dom_image *dom,