Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 5

On 2015/8/28 23:06, Jan Beulich wrote: On 28.08.15 at 11:45, wrote: >> 2. Copy and change some EFI and ACPI tables >> --- >> a) Create EFI_SYSTEM_TABLE table >> Copy the header from the origin and change the value of FirmwareVendor. > > Careful: The

Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 5

Hi Julien, On 2015/8/28 20:55, Julien Grall wrote: > Hi Shannon, > > On 28/08/15 10:45, Shannon Zhao wrote: >> 2. Copy and change some EFI and ACPI tables >> --- > > [..] > >> All above tables will be mapped to Dom0 non-RAM space(e.g. the space >> after D

Re: [Xen-devel] DRAFT: Xen 4.4.3 released

Hi Jan, You may need to sync the last commit (update Xen version to 4.4.3) from staging-4.4 to stable-4.4. Please check. Thanks, Zhigang On 08/25/2015 08:39 AM, Jan Beulich wrote: > I'm sorry - the title should of course not have had the word "DRAFT" in it. > > Jan > On 25.08.15 at 14:0

[Xen-devel] [PATCH] python/xc: add missing Py_DECREF() to fix a memory leak

Python PyList_Append() will increase reference count of the item. We have to decrease its reference count to let it garbage collected. We missed the Py_DECREF() for 'cpuinfo_obj' here, thus we have a memory leak. The memory leak could be easily confirmed by: # python >>> import xen.lowlevel.

Re: [Xen-devel] [PATCH] x86/NUMA: don't account hotplug regions

Jan Beulich wrote: > ... except in cases where they really matter: node_memblk_range[] now > is the only place all regions get stored. nodes[] and NODE_DATA() track > present memory only. This improves the reporting when nodes have > disjoint "normal" and hotplug regions, with the hotplug region si

[Xen-devel] [linux-next test] 60948: regressions - trouble: broken/fail/pass

flight 60948 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/60948/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 60840 test-armhf-armhf-xl-ra

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

On 28/08/15 19:52, Lars Kurth wrote: > > On 28/08/2015 19:18, "Andrew Cooper" wrote: > >> On 28/08/15 18:51, Lars Kurth wrote: >>> We may need some extra tags/headings, if we were to include things such >>> as supported limits for memory, vCPUs, ... I remember, you raised the >>> point that some o

[Xen-devel] [PATCH v3 05/11] tmem: Move TMEM_CONTROL subop of tmem hypercall to sysctl.

The operations are to be used by an control domain to set parameters, list pools, clients, and to be used during migration. There is no need to have them in the tmem hypercall path. This patch moves code without adding fixes - and in fact in some cases makes the parameters soo long that they hurt

[Xen-devel] [PATCH v3 09/11] tmem: Use 'struct tmem_oid' in tmem_handle and move it to sysctl header.

Instead of the three member uint64_t structure. The structure is used by the control stack for XEN_SYSCTL_TMEM_OP_SAVE_GET_NEXT_[PAGE|INV] only so moving it to the sysctl header. Also modified tmemc_save_get_next_page to deal with the new type - and converted some of the on-stack usage of the arr

[Xen-devel] [PATCH v3 11/11] tmem: Spelling and full stop surgery.

I could not help myself. Signed-off-by: Konrad Rzeszutek Wilk --- xen/common/tmem.c | 234 -- 1 file changed, 121 insertions(+), 113 deletions(-) diff --git a/xen/common/tmem.c b/xen/common/tmem.c index 1b9c5d7..861dabd 100644 --- a/xen/common

[Xen-devel] [PATCH v3 08/11] tmem/sysctl: Use 'struct tmem_oid' for every user.

Patch "tmem: Make the uint64_t oid[3] a proper structure: tmem_oid" converted the sysctl API to use an proper structure. But it did not do it for the tmem hypercall. This expands that and converts the tmem hypercall. For this to work we define the struct in tmem.h and include it in sysctl.h. This

[Xen-devel] [PATCH v3 07/11] tmem: Make the uint64_t oid[3] a proper structure: tmem_oid

And use it almost everywhere. It is easy to use it for the sysctl since the hypervisor and toolstack are intertwined. But for the tmem hypercall we need to be dilligient (as it is guest facing) so delaying that to another patch: "tmem/sysctl: Use 'struct tmem_oid' for every user" to help with bise

[Xen-devel] [PATCH v3 10/11] tmem: Remove extra spaces at end and some hard tabbing.

My editor marks these in red glowing red so removing them to make it easier to focus on code. Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Andrew Cooper Acked-by: Wei Liu --- xen/common/tmem.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff -

[Xen-devel] [PATCH v3 06/11] tmem: Remove the old tmem control XSM checks as it is part of sysctl hypercall.

The sysctl is where the tmem control operations are done and the XSM checks are done via there. The old mechanism (to check for control tmem op XSM from do_tmem_op) is not needed anymore. Signed-off-by: Konrad Rzeszutek Wilk Acked-by: Daniel De Graaf --- xen/include/xsm/dummy.h | 6

[Xen-devel] [PATCH v3 04/11] tmem: Remove xc_tmem_control mystical arg3

It mentions it but it is never used. The hypercall interface knows nothing of this sort of thing either. Lets just remove it. Signed-off-by: Konrad Rzeszutek Wilk Acked-by: Wei Liu [release + toolstack] Reviewed-by: Andrew Cooper --- tools/libxc/include/xenctrl.h | 2 +- tools/libxc/

[Xen-devel] [PATCH v3] Tmem bug-fixes and cleanups.

>From Konrad Rzeszutek Wilk # This line is ignored. From: Konrad Rzeszutek Wilk Subject: [PATCH v3] Tmem bug-fixes and cleanups. In-Reply-To: Hey! Since v2 [http://lists.xen.org/archives/html/xen-devel/2015-08/msg02134.html]: - Addressed all (I hope?) comments. - Added 'tmem_oid' structure

[Xen-devel] [PATCH v3 01/11] tmem: Don't crash/hang/leak hypervisor when using shared pools within an guest.

This is a regression introduced by a36590e1b5040838af19d2ca712a516f07a6062b "tmem: reorg the shared pool allocate path". When we are using shared pools we have an global array (on which we put the pool), and an array of pools per domain. We also have an shared list of clients (guests) _except_ for

[Xen-devel] [PATCH v3 03/11] tmem: Remove in xc_tmem_control_oid duplicate set_xen_guest_handle call

We are doing another call to set_xen_guest_handle right after the xc_hypercall_bounce_pre (the correct place to do it). Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Andrew Cooper Acked-by: Wei Liu --- tools/libxc/xc_tmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/libxc/xc_

[Xen-devel] [PATCH v3 02/11] tmem: Add ASSERT in obj_rb_insert for pool->rwlock lock.

Manipulating the obj-> structures requires us to hold the pool->rwlock lock. Lets make that obvious in this function to catch any errant users (none found, but we may in future). Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Andrew Cooper Acked-by: Wei Liu --- xen/common/tmem.c | 3 +++ 1

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

On 28/08/2015 19:18, "Andrew Cooper" wrote: >On 28/08/15 18:51, Lars Kurth wrote: >>> >> >> We may need some extra tags/headings, if we were to include things such >>as supported limits for memory, vCPUs, ... I remember, you raised the >>point that some of the theoretical limits are not always

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

On 28/08/15 18:51, Lars Kurth wrote: >> On 28 Aug 2015, at 18:40, Andrew Cooper wrote: >> >> On 28/08/15 18:16, Lars Kurth wrote: On 27 Aug 2015, at 15:52, Ian Jackson wrote: Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"): > An issue which Xen

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

> On 28 Aug 2015, at 18:40, Andrew Cooper wrote: > > On 28/08/15 18:16, Lars Kurth wrote: >>> On 27 Aug 2015, at 15:52, Ian Jackson wrote: >>> >>> Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"): An issue which Xen has is an uncertain support statement for feat

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

On 28/08/15 18:40, Andrew Cooper wrote: > On 28/08/15 18:16, Lars Kurth wrote: >>> On 27 Aug 2015, at 15:52, Ian Jackson wrote: >>> >>> Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"): An issue which Xen has is an uncertain support statement for features. Give

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

On 28/08/15 18:16, Lars Kurth wrote: >> On 27 Aug 2015, at 15:52, Ian Jackson wrote: >> >> Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"): >>> An issue which Xen has is an uncertain support statement for features. >>> Given the success seen with docs/misc/xen-command-l

[Xen-devel] [xen 4.6 retrospective] [bad] Unclear support status of features

Again, this came up in the developer meeting. This is my last one for today. More next week = Issue / Observation = Sometimes it is difficult to find out whether a feature is supported (or in experimental or other state) This has an impact on the security team It also makes life hard for Xen con

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

> On 27 Aug 2015, at 15:52, Ian Jackson wrote: > > Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"): >> An issue which Xen has is an uncertain support statement for features. >> Given the success seen with docs/misc/xen-command-line.markdown, and in >> particular keepi

[Xen-devel] [xen 4.6 retrospective] [bad] Not enough review capacity

This also came up at the developer meeting = Issue / Observation = See https://www.youtube.com/watch?v=7XdKyykk1-8 from 35" There was also an item, called "Not enough reviewer/committer coverage" - I wasn't in the room at the time. Maybe the person w

Re: [Xen-devel] [xen 4.6 retrospective] [bad] review load near freeze point

> On 28 Aug 2015, at 17:22, Jan Beulich wrote: > On 28.08.15 at 18:04, wrote: >>> On 28 Aug 2015, at 16:21, Jan Beulich wrote: >>> B) Not enough coordination amongst committers >>> >>> Can you be more specific (perhaps with examples) about this one? >> >> A few concrete example we

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

On Fri, Aug 28, 2015 at 10:05:09AM +0800, Chen, Tiejun wrote: > On 8/27/2015 7:03 PM, Konrad Rzeszutek Wilk wrote: > >On Thu, Aug 27, 2015 at 11:06:30AM +0800, Chen, Tiejun wrote: > >>On 8/25/2015 10:43 PM, Konrad Rzeszutek Wilk wrote: > >>>On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wro

Re: [Xen-devel] [OSSTEST PATCH 1/6] Other-revision-jobs: Provide central test

Ian Jackson writes ("[OSSTEST PATCH 1/6] Other-revision-jobs: Provide central test"): > Since 75fbbc19 "Arrange to test migration from the previous Xen > version", some flights have contained additional jobs build-*-prev, > which build a different revision of xen.git. I have force pushed all thes

[Xen-devel] [OSSTEST PATCH 3/6] Other-revision-jobs: Update sg-check-tested

These changes are obvious. Signed-off-by: Ian Jackson --- sg-check-tested |3 +++ 1 file changed, 3 insertions(+) diff --git a/sg-check-tested b/sg-check-tested index 8cdc8a9..e503cf0 100755 --- a/sg-check-tested +++ b/sg-check-tested @@ -58,12 +58,14 @@ END WHERE (name = ?

[Xen-devel] [OSSTEST PATCH 2/6] Other-revision-jobs: Update report__find_test

This is straightforward. We simply don't look at the revision runvars in non-main-revision jobs, when searching for suitable flights. Signed-off-by: Ian Jackson --- Osstest/Executive.pm |1 + 1 file changed, 1 insertion(+) diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm index 9772

[Xen-devel] [OSSTEST PATCH 1/6] Other-revision-jobs: Provide central test

Since 75fbbc19 "Arrange to test migration from the previous Xen version", some flights have contained additional jobs build-*-prev, which build a different revision of xen.git. However, this violates an existing assumption in several of the automatic archaeologists, namely that a flight should con

[Xen-devel] [OSSTEST PATCH 4/6] Other-revision-jobs: Update sg-report-flight and -job-history

We need adjust only the regression analysis. The other occurrences of special treatment for revision fields are for reporting output, and are in the context of a specific job. Signed-off-by: Ian Jackson --- sg-report-flight |4 sg-report-job-history |1 + 2 files changed, 5 in

[Xen-devel] [OSSTEST PATCH 5/6] Other-revision-jobs: Provide other_revision_job_suffix

This is a string, a function of the job name, that identifies the class of `other revisions'. It is empty for main-revision jobs and currently there is only `prev' for build-*-prev. We are going to use this in the bisector. Reimplement main_revision_job_cond in terms of this. No functional chan

[Xen-devel] [OSSTEST PATCH 6/6] Other-revision-jobs: Update cs-bisection-step

This is rather more subtle. We want to be able to bisect over all the relevant inputs. What we actually want to do if one of the *prev* tests fail is to treat the "previous Xen branch" as a separate "tree" when bisecting, so each revision tuple has both "current" and "old" Xen versions. That way

Re: [Xen-devel] Xen on ARM: Read SP_usr and SP_svc in HYP mode

On 25/08/15 05:43, harry wrote: > Hi, Hello, > Now I want to implement some functions in other hypervisor, so I need to > read SP_usr and SP_svc in HYP mode. I know Xen has implemented this > function. But I use it with regs->sp_usr/svc to achieve this. But I > don't know how to achieve it. I hav

[Xen-devel] [xen 4.6 retrospective] [bad] Contributors ignoring/missing review comments (and other bad habits)

Another one from the developer meeting = Issue / Observation = New contributors are frequently ignoring review comments (not saying this is intentional). I have heard this from several reviewers. This has quite a few consequences: * it creates unnecessary extra iterations in the reviews * which

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

On 28/08/15 16:41, "Anshul Makkar anshul.makkar"@citrix.com wrote: > From: anshulma > > Sandybridge or earlier processors don't have huge page support for > IOTLB which leads to fallback on 4k pages and causes performance issues. > > Shared EPT will be disabled only if the user has not provided ex

Re: [Xen-devel] [xen 4.6 retrospective] [bad] review load near freeze point

>>> On 28.08.15 at 18:04, wrote: >> On 28 Aug 2015, at 16:21, Jan Beulich wrote: >> >>> B) Not enough coordination amongst committers >> >> Can you be more specific (perhaps with examples) about this one? > > A few concrete example were several of Vitaly's series (I will let him point > out a

Re: [Xen-devel] [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model

On 28/08/15 17:15, Jan Beulich wrote: > There's no way for Xen to know or for such a qemu to tell us. > > Signed-off-by: Jan Beulich > --- > RFC: This implies only patched qemu-trad or ioreq-server-aware > qemu-upstream get used with xen-unstable. Is this reasonable? Patched qemu-trad, yes,

[Xen-devel] [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model

There's no way for Xen to know or for such a qemu to tell us. Signed-off-by: Jan Beulich --- RFC: This implies only patched qemu-trad or ioreq-server-aware qemu-upstream get used with xen-unstable. Is this reasonable? --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1040,7 +104

Re: [Xen-devel] [PATCH] x86/mm: make {set, clear}_identity_p2m_mapping() work for PV guests

On 28/08/15 17:10, Jan Beulich wrote: > Namely Dom0 suffers from commit 5ae03990c1 ("xen/vtd: create RMRR > mapping") having removed the creation of such mappings for non- > translated guests. > > Reported-by: Malcolm Crossley > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper I will get

[Xen-devel] [PATCH] x86/mm: make {set, clear}_identity_p2m_mapping() work for PV guests

Namely Dom0 suffers from commit 5ae03990c1 ("xen/vtd: create RMRR mapping") having removed the creation of such mappings for non- translated guests. Reported-by: Malcolm Crossley Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -957,7 +957,11 @@ int set_iden

Re: [Xen-devel] [xen 4.6 retrospective] [bad] review load near freeze point

> On 28 Aug 2015, at 16:21, Jan Beulich wrote: > >> B) Not enough coordination amongst committers > > Can you be more specific (perhaps with examples) about this one? A few concrete example were several of Vitaly's series (I will let him point out a couple of examples, as he raised this one).

[Xen-devel] Xen on ARM: Read SP_usr and SP_svc in HYP mode

Hi, Now I want to implement some functions in other hypervisor, so I need to read SP_usr and SP_svc in HYP mode. I know Xen has implemented this function. But I use it with regs->sp_usr/svc to achieve this. But I don't know how to achieve it. I have read the entry.S file and get the process to

[Xen-devel] [qemu-upstream-4.3-testing test] 60903: tolerable FAIL - PUSHED

flight 60903 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60903/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-i386-xl-raw9 debian-di-install fail baseline untested test-am

[Xen-devel] [xen 4.6 retrospective] [bad] Code style checking takes up too much time

Another one from the developer meeting = Issue / Observation = Code style checking takes up too much time. This affects both reviewers who spend a significant amount commenting on style issues and also makes it harder to for contributors to focus on non-style issues. What I mean by the latter is

Re: [Xen-devel] [PATCH v3 15/20] block/xen-blkfront: Make it running on 64KB page granularity

On 20/08/15 09:10, Roger Pau Monné wrote: > Hello, Hi, > I have some comments regarding the commit message, IMHO it would be good > that a native English speaker reviews it too. > > El 07/08/15 a les 18.46, Julien Grall ha escrit: >> The PV block protocol is using 4KB page granularity. The goal

Re: [Xen-devel] [PATCH v2 qemu-trad] HVM: atomically access pointers in bufioreq handling

Jan Beulich writes ("[PATCH v2 qemu-trad] HVM: atomically access pointers in bufioreq handling"): > The number of slots per page being 511 (i.e. not a power of two) means > that the (32-bit) read and write indexes going beyond 2^32 will likely > disturb operation. The hypervisor side gets I/O req

Re: [Xen-devel] [xen 4.6 retrospective] [bad] review load near freeze point

>>> On 28.08.15 at 17:05, wrote: >> On 12 Aug 2015, at 09:00, Jan Beulich wrote: > On 04.08.15 at 14:52, wrote: >> = Issue / Observation = >> >> Maybe my memory regarding the 4.5 release has faded, but I'm >> having the impression that 4.6 was quite a bit worse. This was at >> parts due t

Re: [Xen-devel] [PATCH v3 12/20] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux

On 20/08/15 10:59, David Vrabel wrote: > On 07/08/15 17:46, Julien Grall wrote: >> For ARM64 guests, Linux is able to support either 64K or 4K page >> granularity. Although, the hypercall interface is always based on 4K >> page granularity. >> >> With 64K page granularity, a single page will be spr

Re: [Xen-devel] [xen 4.6 retrospective] [good] Feedback from developer meeting Wed 19th : What went well in 4.6

> On 28 Aug 2015, at 15:43, Jan Beulich wrote: > On 28.08.15 at 14:28, wrote: >> * Testing: staging and master being close together for most of the cycle > > This was observed or said by whom? I've certainly got - not > infrequently - a different impression. I am not sure: I stepped out

[Xen-devel] [OSSTest Nested v12 20/21] Don't lvextend if actually no more space to extend

Though passes if judgement, the overall_limit_pe(\$vg_more_free_pe); may final judge no more free_pe to extend. So, check if $vg_more_free_pe is 0, if so, we don't lvextend, otherwise lvextend will report error on nonsense operation. Signed-off-by: Robert Ho --- ts-xen-build-prep | 3 ++-

[Xen-devel] [OSSTest Nested v12 02/21] Correct a mistake in setboot_grup2() of Xen entry parsing pattern

In previous adding of 'submenu' parsing code, a mistake was made. Now restore the match pattern to original. Signed-off-by: Robert Ho --- Osstest/Debian.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm index c6b4720..74a99a3 100

[Xen-devel] [OSSTest Nested v12 11/21] Tcl: Provide lunappend

From: Ian Jackson Signed-off-by: Ian Jackson Tested-by: Robert Ho --- tcl/osstestlib.tcl | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tcl/osstestlib.tcl b/tcl/osstestlib.tcl index 61a6a09..b5a52d3 100644 --- a/tcl/osstestlib.tcl +++ b/tcl/osstestlib.tcl @@ -75,6 +75,13 @@ proc ls

[Xen-devel] [OSSTest Nested v12 05/21] Honour $xopts{ExtraConfig} and use it to enable nestedhvm

Signed-off-by: Robert Ho --- ts-debian-hvm-install | 5 + 1 file changed, 5 insertions(+) diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install index 2ec4717..e271af8 100755 --- a/ts-debian-hvm-install +++ b/ts-debian-hvm-install @@ -202,6 +202,10 @@ sub prep () { target_putfilecon

[Xen-devel] [OSSTest Nested v12 04/21] Comment out CDROM entry in HVM guest VM

Comment out CDROM entry in sources.list to make HTTP URL entry available for L1 HVM guest VM. Signed-off-by: Robert Ho --- ts-debian-hvm-install | 7 +++ 1 file changed, 7 insertions(+) diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install index f9bc5a5..2ec4717 100755 --- a/ts

[Xen-devel] [OSSTest Nested v12 21/21] await_tcp(): check_ip for each loop iteration

await_tcp usually invoked after a reboot, $ho IP may change, especially when $ho 'client name' of DHCP request changes. Therefore, await_tcp() check will fail if we don't update $ho->{IP} accordingly. But, if $ho has static IP, this won't apply. Also, this patch add $ho->{Ip} in its $what message,

[Xen-devel] [OSSTest Nested v12 19/21] Selecthost uses dynamic IP address if the host is not configured static IP.

In this patch 1. in check_ip(), we change $lstash to use {Name} key-value, rather than {Guest}, because {Name} is both usable by $ho and $gho hash. 2. $ho->{Ether} assignment: if configured in host property, good, use it; otherwise, try to see if runvar has the assignment (this is the case of neste

[Xen-devel] [OSSTest Nested v12 00/21] Introduction of netsted HVM test job

This patch set adds nested HVM test case for osstest. In this test case, a Xen hypervisor (L1) runs on top of another Xen hypervisor (L0). Upon L1 hypervisor, we will then create a nested guest (L2), and test if the Linux guest can then be installed and run well. About nested Xen virtualization, r

[Xen-devel] [OSSTest Nested v12 14/21] sg-run-job: Provide infrastructure for layers of nesting

From: Ian Jackson Provides nested-layer-descend, which can be called in an individual test job at the appropriate point (after the L1 has been set up). The inner host is a guest of the outer host; powering it off means destroying it. Putting the poweroff at this point in the loop, rather than i

[Xen-devel] [OSSTest Nested v12 08/21] Add new script to customize nested test configuration

1. In this script, make some appropriate runvars which selecthost would recognise. 2. Prepare the configurations for installing L2 guest VM. 3. Create a lv disk (and create vg inside) in L0 and hot-attach it to L1. The VG which will later be used for installing L2 gue

[Xen-devel] [OSSTest Nested v12 03/21] Allow runvars to specify guest disk and ram size (turning previous values into defaults)

1. The default disk size for guest is '1M' which is not sufficient for nested HVM guest, using larger disk size for nested guest to accommodate to nested test requirement, the specific disk_size is defined by make-flight. 2. Also, also allow ram size to be define

[Xen-devel] [OSSTest Nested v12 01/21] Optimize and re-format previous code of 'submenu' parsing

* space between ')' and '{'; and after '=' * omit unnecessary 'define' and '!defined' usage * break long '{}' into several lines Signed-off-by: Robert Ho --- Osstest/Debian.pm | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm ind

[Xen-devel] [OSSTest Nested v12 07/21] Replace 'start osstest-confirm-booted' code by function

Schedul start osstest-confirm-booted script via call `host_install_postboot_complete' fucntion; in order to avoid open code. Signed-off-by: Robert Ho --- ts-host-install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ts-host-install b/ts-host-install index f734a9

[Xen-devel] [OSSTest Nested v12 18/21] After Xen install, configure its xenbr0 interface as dhcp.

This is more idiomatic because, even if host is fixed IP in DHCP server side, client side shall still be dhcp mode, rather than fixed self. And if it is not configured fixed in DHCP server side, it shall more necessarily use dhcp mode. This applies for both nested test and other test cases. Signe

[Xen-devel] [OSSTest Nested v12 06/21] Add new function of 'host_install_postboot_complete'

This function is called to add 'osstest-confirm-booted' service in target's start up services. Previously, this was dircetly done by target_cmd_root($ho, "update-rc.d osstest-confirm-booted start 99 2 .") Here wrapper it because more than one place (ts-host-install and ts-nested-setup) will need

Re: [Xen-devel] [PATCH v3 11/20] tty/hvc: xen: Use xen page definition

Hi David, On 20/08/15 10:55, David Vrabel wrote: > On 07/08/15 17:46, Julien Grall wrote: >> The console ring is always based on the page granularity of Xen. > [...] >> --- a/drivers/tty/hvc/hvc_xen.c >> +++ b/drivers/tty/hvc/hvc_xen.c >> @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void) >

[Xen-devel] [OSSTest Nested v12 15/21] Integrate Ian J. code and small corrections.

Signed-off-by: Robert Ho --- sg-run-job | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sg-run-job b/sg-run-job index 7cb6cac..4ae651d 100755 --- a/sg-run-job +++ b/sg-run-job @@ -69,14 +69,14 @@ proc run-job {job} { per-host-ts broken host-install/@(*) ts-host-i

[Xen-devel] [OSSTest Nested v12 12/21] sg-run-job: Declare Tcl (for the benefit of Emacs)

From: Ian Jackson Signed-off-by: Ian Jackson Tested-by: Robert Ho Resolve conflicts: sg-run-job --- sg-run-job | 1 + 1 file changed, 1 insertion(+) diff --git a/sg-run-job b/sg-run-job index e4ebc22..ec03cce 100755 --- a/sg-run-job +++ b/sg-run-job @@ -1,4 +1,5 @@ #!/usr/bin/tclsh +

Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 5

>>> On 28.08.15 at 11:45, wrote: > 2. Copy and change some EFI and ACPI tables > --- > a) Create EFI_SYSTEM_TABLE table > Copy the header from the origin and change the value of FirmwareVendor. Careful: The version in the header may imply that fields are th

[Xen-devel] [OSSTest Nested v12 16/21] Add PDU power method for nested L1 and L2 guest

For nested host/guest, its power on/off method shall be its host invoke $(toolstack)->create/destroy method. --- Osstest/PDU/guest.pm | 63 ++ Osstest/TestSupport.pm | 3 +++ 2 files changed, 66 insertions(+) create mode 100755 Osstest/PDU/guest.

[Xen-devel] [OSSTest Nested v12 17/21] Compose the main recipe of nested test job

After integrated Ian J.'s code of nested infrasture changes, re- write the nested job's recipe. Signed-off-by: Robert Ho --- sg-run-job | 10 ++ 1 file changed, 10 insertions(+) diff --git a/sg-run-job b/sg-run-job index 4ae651d..3f24fd6 100755 --- a/sg-run-job +++ b/sg-run-job @@ -347,

[Xen-devel] [OSSTest Nested v12 09/21] Wrapper and use core_dump_setup() for nested host and normal host to setup coredump sysctl

This patch does these 4 things: 1. wrapper coredump setup code from original ts-host-install into TestSupport.pm 2. replace ts-host-install original code with this wrapper function 3. in debian-hvm-install, create '/var/core' in hvm host post installation. 4. in ts-nested-setup, call this function

[Xen-devel] [OSSTest Nested v12 10/21] Add test job for nest test case

1. This patch adds creation of the nested test job, when job creation procedure is invoked. 2. Set nested L1's vif model, nestedhvm feature, set specific disk size and memory size for nested test by make-flight. Changes since last version: 1. '\' right aligned 2. remove some unnecessary '' 3. no n

[Xen-devel] [OSSTest Nested v12 13/21] sg-run-job: Break out per-host-prep and per-host-finish

From: Ian Jackson No functional change. We now call the per-host-ts finish steps unconditionally, rather than only if !$need_build_host, per-host-ts is (complicated) no-op if $need_build_host, since in that case $need_xen_hosts is {}. Signed-off-by: Ian Jackson Tested by: Robert Ho --- sg-ru

Re: [Xen-devel] [xen 4.6 retrospective] [bad] review load near freeze point

Jan, I wanted to pick this one up again, as this also came up in the developer meeting (where we did a face-2-face retrospective). A few other possible solutions were bounced regarding this problem. Regards Lars > On 12 Aug 2015, at 09:00, Jan Beulich wrote: > On 04.08.15 at 14:52, wrote

[Xen-devel] [PATCH v2] x86: wrap kexec feature with CONFIG_KEXEC

Add the appropriate #if checks around the kexec code in the x86 codebase so that the feature can actually be turned off by the flag instead of always required to be enabled on x86. Signed-off-by: Jonathan Creekmore --- Changed since v1: * Reorder kexec files to be alphabetical in the makefile

Re: [Xen-devel] [xen 4.6 retrospective] [good] Feedback from developer meeting Wed 19th : What went well in 4.6

On 28/08/15 15:43, Jan Beulich wrote: On 28.08.15 at 14:28, wrote: >> * Testing: staging and master being close together for most of the cycle > This was observed or said by whom? I've certainly got - not > infrequently - a different impression. I second the query. The 4.6 development perio

Re: [Xen-devel] [PATCH] x86/NUMA: don't account hotplug regions

On 28/08/15 14:59, Jan Beulich wrote: > ... except in cases where they really matter: node_memblk_range[] now > is the only place all regions get stored. nodes[] and NODE_DATA() track > present memory only. This improves the reporting when nodes have > disjoint "normal" and hotplug regions, with th

[Xen-devel] [xen-unstable baseline test] 60957: regressions - trouble: fail/pass/preparing

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 60957 xen-unstable running [real] http://logs.test-lab.xenproject.org/osstest/logs/60957/ Regressions :-(

Re: [Xen-devel] [PATCH] x86: adjustments to memory_add()

On 28/08/15 15:29, Jan Beulich wrote: On 28.08.15 at 16:11, wrote: >> On 28/08/15 14:54, Jan Beulich wrote: >>> The function should clean up after a failed map_pages_to_xen(). >>> >>> Sharing the M2P table with Dom0 needs to happen before adding >>> the new pages to the heap. >> Why? Does thi

Re: [Xen-devel] [xen 4.6 retrospective] [good] Feedback from developer meeting Wed 19th : What went well in 4.6

>>> On 28.08.15 at 14:28, wrote: > * Testing: staging and master being close together for most of the cycle This was observed or said by whom? I've certainly got - not infrequently - a different impression. Jan ___ Xen-devel mailing list Xen-devel@li

Re: [Xen-devel] [PATCH v2 5/8] tmem: Move TMEM_CONTROL subop of tmem hypercall to sysctl.

>>> On 28.08.15 at 16:15, wrote: > Then I decided to see if I can expand that to also be part of the > 'tmem_op', which looked legit (as it is the same size and offset and > pahole wise it looks right). > > But sadly the compat layer is not happy with me: > > > In file included from > /home/ko

Re: [Xen-devel] [PATCH v3 04/20] xen/grant: Introduce helpers to split a page into grant

Hi David, On 20/08/15 10:51, David Vrabel wrote: > On 07/08/15 17:46, Julien Grall wrote: >> Currently, a grant is always based on the Xen page granularity (i.e >> 4KB). When Linux is using a different page granularity, a single page >> will be split between multiple grants. >> >> The new helpers

Re: [Xen-devel] [PATCH] x86: adjustments to memory_add()

>>> On 28.08.15 at 16:11, wrote: > On 28/08/15 14:54, Jan Beulich wrote: >> The function should clean up after a failed map_pages_to_xen(). >> >> Sharing the M2P table with Dom0 needs to happen before adding >> the new pages to the heap. > > Why? Does this not create a race where dom0 can observe

Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable

>>> On 27.08.15 at 17:29, wrote: > You're right, there's no such requirement on memory use in the spec. > But you're missing the point. Supporting grub2 on UEFI is already a > hack (ignoring all intentions EFI had from its first days). And now > you've found an environment where that hack needs an

Re: [Xen-devel] [PATCH] x86/NUMA: fix setup_node()

On 28/08/15 14:58, Jan Beulich wrote: > The function referenced an __initdata object (nodes_found). Since this > being a node mask was more complicated than needed, the variable gets > replaced by a simple counter. Check at once that the count of nodes > doesn't go beyond MAX_NUMNODES. > > Also con

Re: [Xen-devel] [PATCH v2 5/8] tmem: Move TMEM_CONTROL subop of tmem hypercall to sysctl.

> >>> +struct xen_sysctl_tmem_op { > >>> +uint32_t cmd; /* IN: XEN_SYSCTL_TMEM_OP_* . */ > >>> +int32_t pool_id;/* IN: 0 by default unless _SAVE_*, RESTORE_* .*/ > >>> +uint32_t cli_id;/* IN: client id, 0 for > >>> XEN_SYSCTL_TMEM_QUERY_FREEABLE_MB > >>> +

Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable

>>> On 28.08.15 at 15:42, wrote: > And I am not comfortable to say 'GRUB2+Xen cannot run on this hardware > because your firmware vendor is not following the EFI spec in spirit.' Well, not the least since I don't really agree with this (albeit I can see where you're coming from) ... > Now that s

Re: [Xen-devel] [PATCH] x86: adjustments to memory_add()

On 28/08/15 14:54, Jan Beulich wrote: > The function should clean up after a failed map_pages_to_xen(). > > Sharing the M2P table with Dom0 needs to happen before adding > the new pages to the heap. Why? Does this not create a race where dom0 can observe the new mfns before they are ready to use?

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: vgic: Introduce helpers to read/write/clear/set vGIC register ...

Hi Vijay, You took over this series without asking me if I was still working on it... You don't even address all the TODOs I mentioned in the cover letter of v1 [1] which you didn't bother to retain. If I didn't send a new version of the patch series it's because I was waiting reviews from the AR

[Xen-devel] [PATCH] x86/NUMA: don't account hotplug regions

... except in cases where they really matter: node_memblk_range[] now is the only place all regions get stored. nodes[] and NODE_DATA() track present memory only. This improves the reporting when nodes have disjoint "normal" and hotplug regions, with the hotplug region sitting above the highest pop

[Xen-devel] [PATCH] x86/NUMA: fix setup_node()

The function referenced an __initdata object (nodes_found). Since this being a node mask was more complicated than needed, the variable gets replaced by a simple counter. Check at once that the count of nodes doesn't go beyond MAX_NUMNODES. Also consolidate four printk()s related to the function's

[Xen-devel] [PATCH] x86: adjustments to memory_add()

The function should clean up after a failed map_pages_to_xen(). Sharing the M2P table with Dom0 needs to happen before adding the new pages to the heap. Avoid the IOMMU mapping loop whenever possible. Drop a redundant setting of 'ret'. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/mm.c

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

flight 60888 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/60888/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60761 Tests which did not succeed, but a

[Xen-devel] [ovmf test] 60904: regressions - FAIL

flight 60904 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/60904/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail REGR. vs. 60869 version targeted

Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable

On Fri, Aug 28, 2015 at 02:22:46AM -0600, Jan Beulich wrote: > >>> On 27.08.15 at 19:56, <426...@gmail.com> wrote: > >> If you advocate direct booting ( no boot loader) on production machines I > > wont argue much, as long as there is good recovery tools to deal with > > failed boots (grub does th

[Xen-devel] [PATCH v2 1/2] xen/arm: vgic: Introduce helpers to read/write/clear/set vGIC register ...

From: Julien Grall and use them in the vGIC emulation. The GIC registers may support different access sizes. Rather than open coding the access for every registers, provide a set of helpers to access them. The caller will have to call vgic_regN_* where N is the size of the emulated registers.

  1   2   >