>>> On 27.08.15 at 20:43, wrote:
> On Thu, Aug 27, 2015 at 09:11:35AM -0600, Jan Beulich wrote:
>> >>> On 27.08.15 at 13:02, wrote:
>> > --- a/xen/include/public/sysctl.h
>> > +++ b/xen/include/public/sysctl.h
>> > @@ -710,6 +710,48 @@ struct xen_sysctl_psr_cat_op {
>> > typedef struct xen_sysct
>>> On 28.08.15 at 04:01, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, August 25, 2015 3:59 PM
>>
>> >>> Tamas K Lengyel 08/25/15 1:51 AM >>>
>> >>> @@ -1768,7 +1768,7 @@ static void vmx_enable_msr_exit_interception(struct
>> domain *d)
>> >>>
>> >>> static bool_t v
flight 60882 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60882/
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. 58581
Regressions which are
Il 27/08/2015 16:46, Wei Liu ha scritto:
On Thu, Aug 27, 2015 at 04:41:46PM +0200, Fabio Fantoni wrote:
Today trying xen 4.6.0-rc2 with all things needed for future production
server I found a regression: xl create fails if domU have custom vifname.
xl create test.cfg
Parsing config from test.cf
On Fri, Aug 28, 2015 at 09:50:22AM +0200, Fabio Fantoni wrote:
> Il 27/08/2015 16:46, Wei Liu ha scritto:
> >On Thu, Aug 27, 2015 at 04:41:46PM +0200, Fabio Fantoni wrote:
> >>Today trying xen 4.6.0-rc2 with all things needed for future production
> >>server I found a regression: xl create fails if
>>> 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 this very well, I am not aware of anything
> comparable that is pure ef
>>> On 27.08.15 at 20:33, wrote:
> On Thu, Aug 27, 2015 at 04:07:36PM +0200, Roger Pau Monné wrote:
>> El 27/08/15 a les 16.01, Jan Beulich ha escrit:
>> On 27.08.15 at 13:29, wrote:
>> >> When using Intel hardware without shared page tables between the IOMMU
>> >> and EPT (I have not tried
>>> On 27.08.15 at 21:20, wrote:
>> >>> --- a/xen/include/public/tmem.h
>> >>> +++ b/xen/include/public/tmem.h
>> >>> @@ -33,7 +33,7 @@
>> >>> #define TMEM_SPEC_VERSION 1
>> >>>
>> >>> /* Commands to HYPERVISOR_tmem_op() */
>> >>> -#define TMEM_CONTROL 0
>> >>> +#define
>>> On 28.08.15 at 05:11, wrote:
> To other maintainers, do you have any question or suggestion?
I certainly intend to get to reviewing these patches, but my originally
huge backlog hasn't shrunk enough yet.
Jan
___
Xen-devel mailing list
Xen-devel@l
On Fri, Aug 28, 2015 at 12:41:15AM -0600, Jan Beulich wrote:
> >>> On 27.08.15 at 18:24, wrote:
> > On Thu, Aug 27, 2015 at 10:05:56AM -0600, Jan Beulich wrote:
> >> >>> On 27.08.15 at 17:54, wrote:
> >> > When we create a source code tarball, mini-os is extracted to
> >> > extras/mini-os directo
flight 37845 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37845/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 13 guest-saverestore fail blocked in
37840
Tests which d
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v4->v5:
* change the description of section 4 to make it more generic
* place EFI and ACPI tables at non-RAM space of Dom0
Changes v3->
>>> On 28.08.15 at 10:47, wrote:
> On Fri, Aug 28, 2015 at 12:41:15AM -0600, Jan Beulich wrote:
>> >>> On 27.08.15 at 18:24, wrote:
>> > On Thu, Aug 27, 2015 at 10:05:56AM -0600, Jan Beulich wrote:
>> >> >>> On 27.08.15 at 17:54, wrote:
>> >> > When we create a source code tarball, mini-os is ex
Andrew Cooper writes ("[DOCSDAY PATCH for-4.6] docs: Fix installation of man8
pages"):
> c/s a430436 "docs: Support for generating man(8) pages" accidentally
> failed to update to the install and clean rules for man8 pages, meaning
> that c/s 7b21214 "docs: Move xentrace.8 to docs/man/xentrace.pod
On Fri, Aug 28, 2015 at 03:49:06AM -0600, Jan Beulich wrote:
> >>> On 28.08.15 at 10:47, wrote:
> > On Fri, Aug 28, 2015 at 12:41:15AM -0600, Jan Beulich wrote:
> >> >>> On 27.08.15 at 18:24, wrote:
> >> > On Thu, Aug 27, 2015 at 10:05:56AM -0600, Jan Beulich wrote:
> >> >> >>> On 27.08.15 at 17:
On 27/08/15 19:03, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH v2] libxenstore: prefer using the
> character device"):
>> On Thu, Aug 27, 2015 at 09:04:38AM -0500, Jonathan Creekmore wrote:
>>> With the addition of FMODE_ATOMIC_POS in the Linux 3.14 kernel,
>>> concurrent blocking
Commit b1c9f169047b ("xen: split counting of extra memory pages...")
introduced an error when dom0 was started with limited memory.
The problem arises in case dom0 is started with initial memory and
maximum memory being the same and exactly a multiple of 1 GB. The
kernel must be configured withou
Commit b1c9f169047b ("xen: split counting of extra memory pages...")
introduced an error when dom0 was started with limited memory occurring
only on some hardware.
The problem arises in case dom0 is started with initial memory and
maximum memory being the same. The kernel must be configured witho
On 8/28/2015 4:38 PM, Jan Beulich wrote:
On 28.08.15 at 05:11, wrote:
To other maintainers, do you have any question or suggestion?
I certainly intend to get to reviewing these patches, but my originally
huge backlog hasn't shrunk enough yet.
Jan
Thanks for your reply, Jan. And I fully
osstest service owner writes ("[xen-unstable baseline test] 60878: regressions
- FAIL"):
> "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.
The above paragra
On 19/08/15 17:52, Juergen Gross wrote:
> Commit b1c9f169047b ("xen: split counting of extra memory pages...")
> introduced an error when dom0 was started with limited memory.
>
> The problem arises in case dom0 is started with initial memory and
> maximum memory being the same and exactly a multi
On 19/08/15 17:53, Juergen Gross wrote:
> Commit b1c9f169047b ("xen: split counting of extra memory pages...")
> introduced an error when dom0 was started with limited memory occurring
> only on some hardware.
>
> The problem arises in case dom0 is started with initial memory and
> maximum memory
On Wed, Aug 26, 2015 at 07:06:00AM -0600, Jan Beulich wrote:
> >>> On 25.08.15 at 12:54, wrote:
>
> > +++ b/xen/arch/x86/xstate.c
> > @@ -214,6 +214,11 @@ void xsave(struct vcpu *v, uint64_t mask)
> > typeof(ptr->fpu_sse.fip.sel) fcs = ptr->fpu_sse.fip.sel;
> > typeof(ptr->fpu_s
>>> On 28.08.15 at 12:54, wrote:
> On Wed, Aug 26, 2015 at 07:06:00AM -0600, Jan Beulich wrote:
>> >>> On 25.08.15 at 12:54, wrote:
>>
>> > +++ b/xen/arch/x86/xstate.c
>> > @@ -214,6 +214,11 @@ void xsave(struct vcpu *v, uint64_t mask)
>> > typeof(ptr->fpu_sse.fip.sel) fcs = ptr->fpu_ss
On 28/08/15 07:54, Jan Beulich wrote:
>
>> Therefore I am very much +1 get grub working.
> Then you kind of misunderstood: I'm not against getting grub2
> working (i.e. patches prior to this one are fine in principle). What
> I'm against is hacking around firmware+grub2 combinations not
> suitable
flight 60884 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs
Hi folks,
we did run a retrospective at the developer meeting and I am writing up some of
my notes.
Regards
Lars
So what did go well
* Best ever code quality (see Andrew Coopers mail)
* New Release Process: fewer release exceptions compared to the past
* This means that most likely the release w
Hi Andrew,
On 21/08/15 18:51, Andrew Cooper wrote:
> This essentially reverts c/s 2037f2adb "x86: introduce
> alloc_vcpu_guest_context()", including the newer arm bits, but achieves
> the same end goal by using the newer vmalloc() infrastructure.
I would keep alloc_vcpu_guest_context and replace
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 Dom0 RAM).
If I understand correctly what you are saying, you plan t
On 28/08/15 13:41, Julien Grall wrote:
> Hi Andrew,
>
> On 21/08/15 18:51, Andrew Cooper wrote:
>> This essentially reverts c/s 2037f2adb "x86: introduce
>> alloc_vcpu_guest_context()", including the newer arm bits, but achieves
>> the same end goal by using the newer vmalloc() infrastructure.
> I
On 28/08/15 13:56, Andrew Cooper wrote:
> On 28/08/15 13:41, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 21/08/15 18:51, Andrew Cooper wrote:
>>> This essentially reverts c/s 2037f2adb "x86: introduce
>>> alloc_vcpu_guest_context()", including the newer arm bits, but achieves
>>> the same end goal b
On 28/08/15 13:57, Julien Grall wrote:
> On 28/08/15 13:56, Andrew Cooper wrote:
>> On 28/08/15 13:41, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 21/08/15 18:51, Andrew Cooper wrote:
This essentially reverts c/s 2037f2adb "x86: introduce
alloc_vcpu_guest_context()", including the newer
On 28/08/15 14:07, Andrew Cooper wrote:
> On 28/08/15 13:57, Julien Grall wrote:
>> On 28/08/15 13:56, Andrew Cooper wrote:
>>> On 28/08/15 13:41, Julien Grall wrote:
Hi Andrew,
On 21/08/15 18:51, Andrew Cooper wrote:
> This essentially reverts c/s 2037f2adb "x86: introduce
>
>>> On 28.08.15 at 15:13, wrote:
> Let me explain it in a different way: allocation is usually done with
> xmalloc, but here you are using vmalloc. Why did you use vmalloc rather
> than xalloc? AFAICT there is no improvement on ARM.
>
> If we open code the allocation, one could decide to use xmal
From: Julien Grall
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulatin
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.
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
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
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
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
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
... 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
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
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?
>>> 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
> >>> +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
> >>> +
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
>>> 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
>>> 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
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
>>> 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
>>> 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
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
"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 :-(
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
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
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
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
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,
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
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
>>> 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
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.
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
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
+
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
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
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
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)
>
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
* 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
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
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
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
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
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
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
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
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
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
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,
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 ++-
> 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
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
>>> 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
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
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
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
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
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
> 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).
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
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
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
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,
>>> 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
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
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
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
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
1 - 100 of 135 matches
Mail list logo
