flight 63327 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 63211
test-amd64-i386-qemu
Hello,
We have noticed that the memory balloon feature on Citrix XenServer 6.5 does
not work for guest RHEL/CentOS 6.X with default kernel 2.6.32.XX.
A bugzilla ticket has beeb opened with RedHat but they have come with a
answer as Citrix XenServer is not a certified hypervisor for RHEL6.
http
On 2015年10月28日 00:26, Konrad Rzeszutek Wilk wrote:
Hey,
Way back in Shenghai we had a chat about what needs to be done
in tmem for the 4.6 release. Things got done, but there are other
things that need to be done:
a) Migration v2 support
b) Fix the toolstack (cleanup)
c) tmem tze, dedup,
we have created a RHEL6 guest with 4 VCPUS then memory static min as 4
GB and memory static as 8 GB and memory target as 6 GB. In this case we
can change the balloon target to 5 GB which works but if we change the
balloon target to 7 GB, it balloon memory only till initial startup
value which i
>>> On 27.10.15 at 18:41, wrote:
> On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich wrote:
> On 27.10.15 at 16:39, wrote:
>>> I'd like to have some input to know whether turning on -Wshadow would be
>>> sensible in the future.
>>
>> I think there are cases where using a shadowed variable might m
This run is configured for baseline tests only.
flight 38216 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38216/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf f40577c3563fcad7fc512617925d0574a7c64e2f
baseline version:
ovm
>>> On 28.10.15 at 03:58, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, October 27, 2015 5:52 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper ; Dario Faggioli
>> ; GeorgeDunlap ;
>> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>>
>> Subj
Hi Jan,
On 28/10/2015 08:53, Jan Beulich wrote:
On 27.10.15 at 18:41, wrote:
On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich wrote:
On 27.10.15 at 16:39, wrote:
I'd like to have some input to know whether turning on -Wshadow would be
sensible in the future.
I think there are cases where usi
Guys,
given that you "concur [that] the Xen elf note documentation is in a poor
state", I was wondering whether we could fix this based on this discussion.
Lars
> On 27 Oct 2015, at 16:17, Andrew Cooper wrote:
>
> On 27/10/15 16:03, Carl Patenaude Poulin wrote:
>> Hi Andrew,
>>
>> Thank you s
On 10/28/2015 09:53 AM, Jan Beulich wrote:
On 27.10.15 at 18:41, wrote:
On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich wrote:
On 27.10.15 at 16:39, wrote:
I'd like to have some input to know whether turning on -Wshadow would be
sensible in the future.
I think there are cases where using a s
>>> On 28.10.15 at 10:10, wrote:
> On 28/10/2015 08:53, Jan Beulich wrote:
>> First of all - macros using the ({}) gcc extension. And second variables
>> whose name is kind of natural (e.g. "d" for struct domain * instances)
>> but which are intentionally shadowing a larger scope one in order to
>
>>> On 28.10.15 at 10:12, wrote:
> On 10/28/2015 09:53 AM, Jan Beulich wrote:
>> And second variables
>> whose name is kind of natural (e.g. "d" for struct domain * instances)
>> but which are intentionally shadowing a larger scope one in order to
>> not clobber that one's value.
>
> Hmm, wouldn'
On 10/28/2015 10:31 AM, Jan Beulich wrote:
On 28.10.15 at 10:12, wrote:
On 10/28/2015 09:53 AM, Jan Beulich wrote:
And second variables
whose name is kind of natural (e.g. "d" for struct domain * instances)
but which are intentionally shadowing a larger scope one in order to
not clobber that o
flight 38217 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38217/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38186
jobs:
build-amd64 pass
build-armhf
[CC'ing xs-devel, xen-devel to BCC]
On 28/10/15 08:07, Kiran Aher wrote:
> Hello,
>
> We have noticed that the memory balloon feature on Citrix XenServer 6.5
> does
> not work for guest RHEL/CentOS 6.X with default kernel 2.6.32.XX.
This is a bug in the guest kernel. It does not allow it to inc
flight 63329 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63329/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 3 host-install(3)broken REGR. vs. 630
On Wed, Oct 28, 2015 at 8:53 AM, Jan Beulich wrote:
On 27.10.15 at 18:41, wrote:
>> On Tue, Oct 27, 2015 at 4:03 PM, Jan Beulich wrote:
>> On 27.10.15 at 16:39, wrote:
I'd like to have some input to know whether turning on -Wshadow would be
sensible in the future.
>>>
>>> I t
On Wed, Oct 28, 2015 at 6:08 AM, Dario Faggioli
wrote:
> On Wed, 2015-10-28 at 07:01 +0100, Juergen Gross wrote:
>> On 10/28/2015 06:54 AM, Dario Faggioli wrote:
>
>> > Yeah, well, sorry, but even if we both (me and George) encouraged
>> > you
>> > to try Credit2, that wasn't a great idea. :-( In
On Wed, Oct 28, 2015 at 11:21:17AM +0800, Wei Wang wrote:
> Add support in the pmstat.c so that the xenpm tool can request to
> access the intel_pstate driver.
>
> Signed-off-by: Wei Wang
> ---
> changes in v6:
> 1) add the NON_INTERNAL_GOV macro to replace literal 0;
> 2) code consolidation (
On Wed, Oct 28, 2015 at 11:21:18AM +0800, Wei Wang wrote:
> The intel_pstate driver receives percentage values to set the
> performance limits. This patch adds interfaces to support the
> input of percentage values to control the intel_pstate driver.
> The "get-cpufreq-para" is modified to show per
>>> On 28.10.15 at 11:50, wrote:
> On Wed, Oct 28, 2015 at 8:53 AM, Jan Beulich wrote:
> On 27.10.15 at 18:41, wrote:
>>> And in line with my response to Andrew -- could we enable -Wshadow
>>> until we find a use for shadowing whose value outweighs the risks of
>>> building without it?
>>
>>
Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation failure"):
> Now another issue: after attach lvm to L1, cannot see it inside.
> vgdisplay shows nothing.
>
> My manual test like this:
> xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
>
> xl block-list can see it, wh
Hu, Robert writes ("OSSTest nested patch PART2 -- L1 host has no 'Suite'
property"):
> Now the patch has been refined to get whole 'test-amd64-amd64-qemuu-nested'
> pass.
How exciting :-).
> But still one trivial issue I observed in the test log: L1 host has no
> 'Suite' property.
> Any sugges
On 27/10/15 19:42, Carl Patenaude Poulin wrote:
> Hi all,
>
> Thanks to Andrew Cooper's priceless help, I've managed to put
> together a Xen PV kernel that does nothing except loop forever. I'm
> going to try making it print "Hello, world!".
>
> I was hoping someone could fact-check my research. Wh
> Begin forwarded message:
>
> From: Mikey Ariel
> Subject: [devroom-managers] Virtualization & IaaS Devroom CFP
> Date: 27 October 2015 23:23:50 GMT
> To: fos...@lists.fosdem.org, devroom-manag...@lists.fosdem.org,
> iaas-virt-devr...@lists.fosdem.org
>
> **Please forward to any project or i
flight 63330 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63330/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3)broken REGR. vs. 63304
On 26/10/15 11:49, Jan Beulich wrote:
> This requires adjustments to the tool generating the symbol table and
> its as well as nm's invocation.
>
> Note: Not warning about duplicate symbols in the EFI case for now, as
> a binutils bug causes misnamed file name entries to appear in EFI
> binaries' s
On 26/10/15 11:50, Jan Beulich wrote:
> To make it possible to tell apart the static symbols in files built a
> second for compat guest support, arrange for their source file names to
> be prefixed by a suitable path. We can't do this without explicit .file
> directives, since gcc has always been s
On 10/27/2015 07:50 AM, David Vrabel wrote:
Mapping a large range of foreign GFNs can take a long time, add a
reschedule point after each batch of 16 GFNs.
Signed-off-by: David Vrabel
---
arch/x86/xen/mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen
>>> On 28.10.15 at 13:55, wrote:
> On 26/10/15 11:49, Jan Beulich wrote:
>> This requires adjustments to the tool generating the symbol table and
>> its as well as nm's invocation.
>>
>> Note: Not warning about duplicate symbols in the EFI case for now, as
>> a binutils bug causes misnamed file na
On Wed, Oct 28, 2015 at 04:18:56PM +0800, Yang Hongyang wrote:
> On 2015年10月28日 00:26, Konrad Rzeszutek Wilk wrote:
> >Hey,
> >
> >Way back in Shenghai we had a chat about what needs to be done
> >in tmem for the 4.6 release. Things got done, but there are other
> >things that need to be done:
> >
> On 27 Oct 2015, at 17:31, Andrew Cooper wrote:
>
> On 27/10/15 17:28, Samuel Thibault wrote:
>> Andrew Cooper, le Tue 27 Oct 2015 17:21:39 +, a écrit :
>>> as the second attempted write could return short as well.
>> That is fine. The second attempt will only return a short write if there
Mapping a large range of foreign GFNs can take a long time, add a
reschedule point after each batch of 16 GFNs.
Signed-off-by: David Vrabel
---
v2:
- Move cond_resched() to outer loop.
---
arch/x86/xen/mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mm
On 28/10/15 13:25, Jan Beulich wrote:
On 28.10.15 at 13:55, wrote:
>> On 26/10/15 11:49, Jan Beulich wrote:
>>> This requires adjustments to the tool generating the symbol table and
>>> its as well as nm's invocation.
>>>
>>> Note: Not warning about duplicate symbols in the EFI case for now,
David Scott, le Wed 28 Oct 2015 13:34:10 +, a écrit :
> However I believe the ‘suspicious’ OCaml patch fixes the specific issue (— or
> have I missed something?).
It does.
> Does anyone have time to prototype what a C-level fix would look like?
Here is a try, untested though.
Signed-off-by
On 10/28/2015 09:39 AM, David Vrabel wrote:
Mapping a large range of foreign GFNs can take a long time, add a
reschedule point after each batch of 16 GFNs.
Signed-off-by: David Vrabel
---
v2:
- Move cond_resched() to outer loop.
---
arch/x86/xen/mmu.c | 1 +
1 file changed, 1 insertion(+)
d
On 28/10/15 13:34, David Scott wrote:
>
>> On 27 Oct 2015, at 17:31, Andrew Cooper wrote:
>>
>> On 27/10/15 17:28, Samuel Thibault wrote:
>>> Andrew Cooper, le Tue 27 Oct 2015 17:21:39 +, a écrit :
as the second attempted write could return short as well.
>>> That is fine. The second atte
On 27/10/15 17:10, Wei Liu wrote:
> When oxenstored wrote to the ring, it wrote a chunk of contiguous data.
> Originally when it tried to write across ring boundary, it returned a
> short-write when there is still room. That led to stalling mini-os's
> xenstore thread at times.
>
> Fix this by ca
flight 63332 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63332/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 62642
build-armhf-pvops
>>> On 28.10.15 at 14:42, wrote:
> On 28/10/15 13:25, Jan Beulich wrote:
> On 28.10.15 at 13:55, wrote:
>>> On 26/10/15 11:49, Jan Beulich wrote:
This requires adjustments to the tool generating the symbol table and
its as well as nm's invocation.
Note: Not warning about d
At 09:10 -0600 on 27 Oct (1445937057), Jan Beulich wrote:
> >>> On 15.10.15 at 11:39, wrote:
> > At 02:56 -0600 on 15 Oct (144484), Jan Beulich wrote:
> >> what's the reason that these aren't in struct shadow_paging_mode
> >> instead? They're only being used by shadow code, and I can't see
> >
On Tue, Oct 13, 2015 at 03:11:12PM +0200, Juergen Gross wrote:
> Rename the count_pgtables hook of the domain builder to alloc_pgtables
> and do the allocation of the guest memory for page tables inside this
> hook. This will remove the need for accessing the x86 specific pgtables
> member of struc
On Tue, Oct 13, 2015 at 03:11:13PM +0200, Juergen Gross wrote:
> Reorganize struct xc_dom_image to contain a pointer to domain builder
> architecture specific private data. This will abstract the architecture
> or domain type specific data from the general used data.
>
> The new area is allocated
On Tue, Oct 13, 2015 at 03:11:14PM +0200, Juergen Gross wrote:
> 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
___
Xen-d
CC HV maintainers
On Tue, Oct 13, 2015 at 03:11:11PM +0200, Juergen Gross wrote:
> Support of an unmapped initrd is indicated by the kernel of the domain
> via elf notes. In order not to have to use raw elf data in the tools
> for support of an unmapped initrd add a flag to the parsed data area
>
On Tue, Oct 13, 2015 at 03:11:10PM +0200, 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 g
On Fri, Oct 09, 2015 at 09:14:00AM -0600, Jan Beulich wrote:
> >>> On 09.10.15 at 15:25, wrote:
> > On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> >> On 09/10/15 09:17, Jan Beulich wrote:
> >> On 09.10.15 at 04:56, wrote:
> >> >> However they also change the behavior of the
On 27/10/15 08:05, Jan Beulich wrote:
On 26.10.15 at 19:08, wrote:
>> However, IIUC, the get_xen_guest_handle is only exposed to the tools and
>> therefore possible to modify it in order to pass the type. Am I wrong?
>> FWIW, I haven't seen any usage in the tools directory.
>
> Indeed. Rathe
On 10/28/2015 04:32 PM, Wei Liu wrote:
On Tue, Oct 13, 2015 at 03:11:10PM +0200, 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
>>> On 28.10.15 at 16:44, wrote:
> On 27/10/15 08:05, Jan Beulich wrote:
> On 26.10.15 at 19:08, wrote:
>>> However, IIUC, the get_xen_guest_handle is only exposed to the tools and
>>> therefore possible to modify it in order to pass the type. Am I wrong?
>>> FWIW, I haven't seen any usage in
>>> On 13.10.15 at 15:11, wrote:
> Support of an unmapped initrd is indicated by the kernel of the domain
> via elf notes. In order not to have to use raw elf data in the tools
> for support of an unmapped initrd add a flag to the parsed data area
> to indicate the kernel supporting this feature.
No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
598e97f "tools/python: remove broken xl binding"
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/python/Makefile | 7 +-
tools/python/genwrap.py | 332 -
On 28/10/15 15:55, Andrew Cooper wrote:
> No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
> 598e97f "tools/python: remove broken xl binding"
In fact, this fixes a build error introduced with 598e97f
make -C python all
make[2]: Entering directory '/local/xen.git/tools/python'
>>> On 27.10.15 at 21:36, wrote:
> +static void __init add_extra_rmrr(void)
> +{
> +struct acpi_rmrr_unit *acpi_rmrr;
> +struct acpi_rmrr_unit *rmrru;
> +unsigned int dev, seg, i;
> +unsigned long pfn;
> +bool_t overlap;
> +
> +for ( i = 0; i < nr_rmrr; i++ )
> +{
> +
flight 6 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/6/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63266
Tests which did not succeed, but a
On Tue, Oct 13, 2015 at 03:11:15PM +0200, Juergen Gross wrote:
> 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
> ---
> tool
ml_interface_{read,write}() would miscalculate the quantity of
data/space in the ring if it crossed the ring boundary, and incorrectly
return a short read/write.
This causes a protocol stall, as either side of the ring ends up waiting
for what they believe to be the other side needing to take the
On Tue, Oct 13, 2015 at 03:11:16PM +0200, Juergen Gross wrote:
> Carve out the p2m list allocation from the .alloc_magic_pages hook of
> the domain builder in order to prepare allocating the p2m list outside
> of the initial kernel mapping. This will be needed to support loading
> domains with huge
Andrew Cooper, le Wed 28 Oct 2015 16:05:36 +, a écrit :
> @@ -62,22 +62,32 @@ CAMLprim value ml_interface_read(value ml_interface,
>
> xen_mb();
>
> - if ((prod - cons) > XENSTORE_RING_SIZE)
> + if (((prod - cons) > XENSTORE_RING_SIZE) ||
> +((cons - prod) < -XENST
On Wed, Oct 28, 2015 at 04:51:05PM +0100, Juergen Gross wrote:
[...]
> >>+static int xc_dom_alloc_pad(struct xc_dom_image *dom, xen_vaddr_t end)
> >>+{
> >>+unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
> >>+xen_pfn_t pages;
> >>+
> >>+if ( end & (page_size - 1) )
> >> {
> >>
On Wed, Oct 28, 2015 at 03:55:43PM +, Andrew Cooper wrote:
> No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
> 598e97f "tools/python: remove broken xl binding"
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel
In fact, right now, failing at destroying a cpupool is just
not reported to the user in any explicit way.
Let's log an error, as it is customary for xl in these cases.
Signed-off-by: Dario Faggioli
Reviewed-by: Juergen Gross
---
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei
On Wed, 2015-10-28 at 03:03 -0600, Jan Beulich wrote:
> > > > On 28.10.15 at 03:58, wrote:
> > We still call arch_vcpu_block() in vcpu_block(), but we don't need
> > to
> > call arch_vcpu_block_cancel(v) when local_events_need_delivery()
> > returns true. Then before VM-Entry, we can check if 'NV
On 28/10/15 16:18, Samuel Thibault wrote:
> Andrew Cooper, le Wed 28 Oct 2015 16:05:36 +, a écrit :
>> @@ -62,22 +62,32 @@ CAMLprim value ml_interface_read(value ml_interface,
>>
>> xen_mb();
>>
>> -if ((prod - cons) > XENSTORE_RING_SIZE)
>> +if (((prod - cons) > XENSTORE_RING_
Andrew Cooper, le Wed 28 Oct 2015 16:43:54 +, a écrit :
> > IIRC the test is not bogus even when prod wraps around, (prod - cons)
> > will still correctly be the difference between both, modulo 2^32.
>
> (prod - cons) >= XENSTORE_RING_SIZE checks for the prod getting more
> than a ring's worth
On Wed, Oct 28, 2015 at 05:43:51PM +0100, Dario Faggioli wrote:
> In fact, right now, failing at destroying a cpupool is just
> not reported to the user in any explicit way.
>
> Let's log an error, as it is customary for xl in these cases.
>
> Signed-off-by: Dario Faggioli
> Reviewed-by: Juergen
On 10/28/2015 05:21 PM, Wei Liu wrote:
On Wed, Oct 28, 2015 at 04:51:05PM +0100, Juergen Gross wrote:
[...]
+static int xc_dom_alloc_pad(struct xc_dom_image *dom, xen_vaddr_t end)
+{
+unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
+xen_pfn_t pages;
+
+if ( end & (page_size - 1) )
On Tue, Oct 27, 2015 at 11:41 PM, Dario Faggioli
wrote:
> On Tue, 2015-10-27 at 14:32 -0600, suokun wrote:
>> On Tue, Oct 27, 2015 at 4:44 AM, Dario Faggioli
>> wrote:
>
>> Hi, Dario,
>> Thank you for your reply.
>>
> Hi,
>
>> Here are my two VMs running on the same physical CPU.
>> VM-IO: 1-vCPU
On 10/28/2015 05:11 PM, Wei Liu wrote:
On Tue, Oct 13, 2015 at 03:11:15PM +0200, Juergen Gross wrote:
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-
On 28/10/15 16:56, Samuel Thibault wrote:
> Andrew Cooper, le Wed 28 Oct 2015 16:43:54 +, a écrit :
>>> IIRC the test is not bogus even when prod wraps around, (prod - cons)
>>> will still correctly be the difference between both, modulo 2^32.
>> (prod - cons) >= XENSTORE_RING_SIZE checks for t
flight 63336 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63336/
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
(Adding David and Daniel)
On 23/10/15 16:45, Ian Campbell wrote:
> On Fri, 2015-10-23 at 15:58 +0100, Julien Grall wrote:
>> Is there any way we could register the IO region used on ARM without
>> having to enforce it in all the drivers?
>
> This seems like an uphill battle to me.
I agree about
On Fri, Oct 09, 2015 at 08:38:34AM -0600, Jan Beulich wrote:
> >>> On 09.10.15 at 14:46, wrote:
> > On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
> >> On 09/10/15 09:25, Jan Beulich wrote:
> >> > > > > On 09.10.15 at 04:56, wrote:
> >> > > All existing commands ignore the parameter so t
Hi,
On 28/10/15 17:31, osstest service owner wrote:
> flight 63336 linux-3.14 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/63336/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf-pvops 5 k
On 28/10/15 17:55, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 08:38:34AM -0600, Jan Beulich wrote:
> On 09.10.15 at 14:46, wrote:
>>> On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
On 09/10/15 09:25, Jan Beulich wrote:
On 09.10.15 at 04:56, wrote:
>> All
Is it possible to create a domain that has increased privilege levels that
are similar to dom0? I am interested in installing a VM and have it perform
certain tasks that will require it to have a higher privilege level than
domU guests.
--
D'Mita Levy
Cyber Fellow, Applied Research Center
Florida
On Wed, Oct 28, 2015 at 06:34:37PM +, Andrew Cooper wrote:
> On 28/10/15 17:55, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 09, 2015 at 08:38:34AM -0600, Jan Beulich wrote:
> > On 09.10.15 at 14:46, wrote:
> >>> On Fri, 2015-10-09 at 13:29 +0100, Andrew Cooper wrote:
> On 09/10/15 09
On Wed, Oct 28, 2015 at 11:42:41AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 09:14:00AM -0600, Jan Beulich wrote:
> > >>> On 09.10.15 at 15:25, wrote:
> > > On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> > >> On 09/10/15 09:17, Jan Beulich wrote:
> > >> O
On 28 October 2015 at 06:30, Dario Faggioli
wrote:
> On Wed, 2015-10-28 at 05:42 +0530, Lasya wrote:
> > xc_dom_allocate function in build function in init-xenstore-domain.c
> > returns NULL on failure.
> > In that case, variable rv is set to ENOMEM and directed to failure
> > path err.
> >
> >
>
flight 63349 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63349/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 10/28/2015 08:57 PM, D'Mita Levy wrote:
> Is it possible to create a domain that has increased privilege levels
> that are similar to dom0? I am interested in installing a VM and have it
> perform certain tasks that will require it to have a higher privilege
> level than domU guests.
It is, tak
flight 63337 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63337/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684
test-amd64
.snip..
> > @@ -481,6 +489,8 @@ int pt_irq_destroy_bind(
> > pirq = pirq_info(d, machine_gsi);
> > pirq_dpci = pirq_dpci(pirq);
> >
> > +spin_lock(&pirq_dpci->lock);
>
> Considering that code further down in this function checks
> pirq_dpci to be non-NULL, this doesn't look safe (o
This run is configured for baseline tests only.
flight 38218 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38218/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install
On Fri, Oct 23, 2015 at 12:05:22PM +0100, David Vrabel wrote:
> radix_tree_gang_lookup() only requires a RCU read lock, not the
> per-domain event_lock.
Don't you need to make some form of 'spin_lock_init' call?
>
> Introduce a new RCU read lock and take the per-interrupt lock before
> calling t
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, October 19, 2015 10:52 PM
>
> Signed-off-by: Jan Beulich
>
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, October 24, 2015 1:53 AM
>
> Combine the almost identical vm_launch_fail() and vm_resume_fail() into
> a single vmx_vmentry_failure().
>
> Re-save all GPRs so that domain_crash() prints the real register values,
> rather t
flight 63340 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63340/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-i
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, October 28, 2015 7:53 PM
> To: Hu, Robert
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: RE: OSSTest nested patch PART2 -- L2 installation failure [and 1 more
> messages]
>
> Hu, Robe
Document the multi-queue/ring feature in terms of XenStore keys to be written
by the backend and by the frontend.
Signed-off-by: Bob Liu
---
xen/include/public/io/blkif.h | 48 +
1 file changed, 48 insertions(+)
diff --git a/xen/include/public/io/blkif.
Hi Stefano,
Sorry for late response, I will try to test my latest patch ASAP. but
I don't see this problem before.
will let you know the result , thanks for your testing
On 2 October 2015 at 00:19, Stefano Stabellini
wrote:
> On Wed, 30 Sep 2015, Stefano Stabellini wrote:
>> Hi Fu,
>>
>> I backp
flight 63338 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63338/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 62277
test-amd64-amd64-xl-xsm
flight 63339 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs. 59254
tes
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, October 28, 2015 7:58 PM
> To: Hu, Robert
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: Re: OSSTest nested patch PART2 -- L1 host has no 'Suite' property
>
> Hu, Robert writes ("OSST
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Thursday, October 29, 2015 12:37 AM
> To: Jan Beulich ; Wu, Feng
> Cc: Tian, Kevin ; Keir Fraser ;
> GeorgeDunlap ; Andrew Cooper
> ; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v8 15/17]
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson
> Subject: [OSSTEST PATCH 23/26] Nested HVM: Provide test-nested recipe
>
> From: R
flight 63344 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build fail REGR. vs. 63240
build-i386-rumpuserxen
Hi Stefano,
I have tried my grub on Foundation model, but I did not get this
error, I guess that is the UEFI problem ?
On 1 October 2015 at 00:00, Stefano Stabellini
wrote:
> Hi Fu,
>
> I backported your patches to the CentOS aarch64 grub2 rpm. I am testing
> it on X-Gene with EFI firmware. It
flight 63342 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63342/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf ae658d9163afd6053db7d37d46f54388e33a0052
baseline version:
ovmf f40577c3563fcad7fc512617925d0574a7c
flight 63341 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63341/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63223
test-amd64-amd64-xl-qemuu-win7-a
100 matches
Mail list logo
