flight 85731 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85731/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 3 host-install(3) broken pass in 85673
test-amd64-amd64-xl-qemuu-win7-amd
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, March 4, 2016 7:28 PM
> To: xen-devel
> Cc: Andrew Cooper ; Wu, Feng
> ; Keir Fraser
> Subject: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> guest code
>
> Since such guests' kernel
> >> +/* This mustn't modify registers other than %rax. */
> >> +ENTRY(cr4_smep_smap_restore)
> >> +mov %cr4, %rax
> >> +test $X86_CR4_SMEP|X86_CR4_SMAP,%eax
> >> +jnz 0f
If we clear every place where we are back to 32bit pv guest,
X86_CR4_SMEP and X86_CR4_SMAP bit sho
Hi,
On 08/03/2016 23:37, Fu Wei wrote:
On 8 March 2016 at 14:54, Andrei Borzenkov wrote:
So speaking of loading additional modules/lack of initrd on ARM, I thinks that
will (only) affect loading XSM.
For this, I have discussed of that with Julien, I think :
(1) the first module must be kernel
(
flight 44234 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44234/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 3 host-install(3) broken RE
Hi Julien,
On 9 March 2016 at 15:10, Julien Grall wrote:
> Hi,
>
> On 08/03/2016 23:37, Fu Wei wrote:
>>
>> On 8 March 2016 at 14:54, Andrei Borzenkov wrote:
>> So speaking of loading additional modules/lack of initrd on ARM, I thinks
>> that
>> will (only) affect loading XSM.
>> For this, I hav
Signed-off-by: Wen Congyang
---
tools/libxc/include/xenguest.h | 4 ++--
tools/libxc/xc_nomigrate.c | 4 ++--
tools/libxc/xc_sr_restore.c | 2 +-
tools/libxc/xc_sr_save.c| 2 +-
tools/libxl/libxl_save_helper.c | 38 +++---
5 files changed, 25
xc_domain_save() and xc_domain_restore's parameter will use this type,
so it should be public.
Signed-off-by: Wen Congyang
---
tools/libxc/include/xenguest.h | 5 +
tools/libxc/xc_sr_common.h | 10 --
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/tools/libxc/in
On Tue, Mar 08, 2016 at 03:16:29AM -0700, Jan Beulich wrote:
> >>> On 08.03.16 at 08:19, wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -922,7 +922,7 @@ long arch_do_domctl(
> > ret = -EFAULT;
> >
> > offset += sizeof(v->arch.xcr0_accu
>>> "Xu, Quan" 03/09/16 8:32 AM >>>
>On March 09, 2016 1:19pm, wrote:
>> > Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls to
>> > pci_get_pdev(), which does not require interrupts to be disabled
>> > during its execution. In fact, pcidevs_lock is always (except for this
>> >
On Wed, 2016-03-09 at 07:31 +, Xu, Quan wrote:
> On March 09, 2016 1:19pm, wrote:
> >
> > > When iommu_setup() is called in __start_xen(), interrupts have
> > > already
> > > been enabled, and nothing disables (without reenabling) them
> > > again in
> > > the path that leads to calling set_i
>>> Shuai Ruan 03/09/16 10:49 AM >>>
>On Tue, Mar 08, 2016 at 03:16:29AM -0700, Jan Beulich wrote:
>> >>> On 08.03.16 at 08:19, wrote:
>> > --- a/xen/arch/x86/domctl.c
>> > +++ b/xen/arch/x86/domctl.c
>> > @@ -922,7 +922,7 @@ long arch_do_domctl(
>> > ret = -EFAULT;
>> >
>> >
Add pci = [ '$VF_BDF1', '$VF_BDF2', '$VF_BDF3'] in hvm guest configuration
file.
After the guest boot up, detach the VFs in sequence by
"xl pci-detach $DOMID $VF_BDF1"
"xl pci-detach $DOMID $VF_BDF2"
"xl pci-detach $DOMID $VF_BDF3"
and reattach the VFs in sequence by
"xl pci-attach $DOM
flight 85794 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85794/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 0aa1330aac92fd75f185c9b354396014178fe95d
baseline version:
xen 1bd52e1fd66c47af69
On 09/03/16 08:09, Wu, Feng wrote:
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -434,6 +434,7 @@ ENTRY(dom_crash_sync_extable)
>>
>> ENTRY(common_interrupt)
>> SAVE_ALL CLAC
>> +SMEP_SMAP_RESTORE
>> movq %rsp,%rdi
>> callq do_I
On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> Hi,
>
> This patch series:
> - enables EFI boot services usage in loaded images
> by multiboot2 protocol,
> - add support for multiboot2 protocol compatible
> relocatable images.
>
> Earlier versions of this patch series ar
On 08/03/16 20:51, Ben Sanda wrote:
> George,
>
>> FWIW, on my "to-do" list for xenalyze for years has been to have the xentrace
>> process query something (either Xen or Linux) to find the hz rate, and then
>> write that at the beginning of the xentrace file, so that xenalyze could just
>> pick t
flight 85746 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On 08/03/16 07:57, Jan Beulich wrote:
>
>>> @@ -174,10 +174,43 @@ compat_bad_hypercall:
>>> /* %rbx: struct vcpu, interrupts disabled */
>>> ENTRY(compat_restore_all_guest)
>>> ASSERT_INTERRUPTS_DISABLED
>>> +.Lcr4_orig:
>>> +ASM_NOP3 /* mov %cr4, %rax */
>>> +ASM_NOP6
On Tue, 2016-03-08 at 18:32 +, Andrew Cooper wrote:
> On 08/03/16 18:28, Paul Sujkov wrote:
> > Regarding ARM build, I'm using xenalyze as both host tool (x86
> > build, e.g. for gnuplot scatterplot graphs) and target tool (ARM,
> > for fast summary check); but since we're working with Xen 4.5,
On 09/03/16 05:22, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: George Dunlap [mailto:george.dun...@citrix.com]
>> Sent: Wednesday, March 9, 2016 1:06 AM
>> To: Jan Beulich ; George Dunlap
>> ; Wu, Feng
>> Cc: Andrew Cooper ; Dario Faggioli
>> ; Tian, Kevin ; xen-
>> de...@lists.xe
Hi Ben,
see the patch attached. It's a bit dirty still (that's why it wasn't
upstreamed long time ago), but you can obviously look through it and gain
some information.
On 8 March 2016 at 22:51, Ben Sanda wrote:
> George,
>
> >FWIW, on my "to-do" list for xenalyze for years has been to have the
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Wednesday, March 9, 2016 7:25 PM
> To: Wu, Feng ; Jan Beulich ; George
> Dunlap
> Cc: Andrew Cooper ; Dario Faggioli
> ; Tian, Kevin ; xen-
> de...@lists.xen.org; Konrad Rzeszutek Wilk ; Keir
> Fraser
>
On 07/03/16 18:12, Andrew Cooper wrote:
> If an architecture does not provide a custom page_list_entry, default
> page_list_* helpers are provided, wrapping list_head as an underlying type for
> page_list_head.
>
> The two declarations of the page_list_* helpers differ between defines and
> static
flight 85752 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
build-armhf
On March 09, 2016 6:10pm, wrote:
> >>> "Xu, Quan" 03/09/16 8:32 AM >>>
> >On March 09, 2016 1:19pm, wrote:
> >> > Inside set_iommu_interrupt_handler(), pcidevs_lock serializes calls
> >> > to pci_get_pdev(), which does not require interrupts to be disabled
> >> > during its execution. In fact, p
On 03/08/16 02:27, Jan Beulich wrote:
> >>> On 08.03.16 at 10:15, wrote:
> > More thoughts on reserving NVDIMM space for per-page structures
> >
> > Currently, a per-page struct for managing mapping of NVDIMM pages may
> > include following fields:
> >
> > struct nvdimm_page
> > {
> > uint64
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, March 9, 2016 6:46 PM
> To: Wu, Feng ; Jan Beulich ; xen-
> devel
> Cc: Keir Fraser
> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> guest code
>
> On 09/03/
On 09/03/16 12:27, Wu, Feng wrote:
>
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, March 9, 2016 6:46 PM
>> To: Wu, Feng ; Jan Beulich ; xen-
>> devel
>> Cc: Keir Fraser
>> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while run
On Wed, Mar 09, 2016 at 03:25:58AM -0700, Jan Beulich wrote:
> Btw., one more thing: Can't the exclusion of FP and SSE states in the logic
> determining which state set to save be extended to also include YMM? If saved,
> YMM will also always live at a fixed place (an ASSERT() or BUG_ON() to verify
Andrew Cooper 03/09/16 1:33 PM >>>
>On 09/03/16 12:27, Wu, Feng wrote:
>> Oh, thanks for the clarification! Do you know how "An NMI or #MC may occur
>> between clearing CR4.SMEP and CR4.SMAP in compat_restore_all_guest and
>> it actually returning to guest context, in which case the guest wou
On March 09, 2016 6:25pm, wrote:
> On Wed, 2016-03-09 at 07:31 +, Xu, Quan wrote:
> > On March 09, 2016 1:19pm, wrote:
> > >
> > > > When iommu_setup() is called in __start_xen(), interrupts have
> > > > already been enabled, and nothing disables (without reenabling)
> > > > them again in the
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, March 9, 2016 8:37 PM
> To: andrew.coop...@citrix.com; Wu, Feng ; xen-
> de...@lists.xenproject.org
> Cc: k...@xen.org
> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> gu
common/page_alloc.c references d->arch.relmem_list, which only exists on x86.
This only compiles on ARM because page_list_del2() discards its second
argument.
Introduce a new common arch_free_heap_page() which only uses common lists in
struct domain, and allow an architecture to override this with
If an architecture does not provide a custom page_list_entry, default
page_list_* helpers are provided, wrapping list_head as an underlying type for
page_list_head.
The two declarations of the page_list_* helpers differ between defines and
static inline functions, where the defines discard some of
flight 85775 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
pcidevs_lock should be held with interrupt enabled. However there remains
an exception in AMD IOMMU code, where the lock is acquired with interrupt
disabled. This inconsistency might lead to deadlock.
The fix is straightforward to use spin_lock instead. Also interrupt has been
enabled when this fu
On Wed, 2016-03-09 at 12:52 +, Xu, Quan wrote:
> On March 09, 2016 6:25pm, wrote:
> > On Wed, 2016-03-09 at 07:31 +, Xu, Quan wrote:
> > > On March 09, 2016 1:19pm, wrote:
> > > >
> > If we are absolutely sure that they are enabled, i.e., there is no
> > _risk_ that they
> > are disabled
This patch set makes the pcidevs_lock a recursive one. It is a prereq
patch set for Patch:'VT-d Device-TLB flush issue', as the pcidevs_lock
may be recursively held for hiding the ATS device, when VT-d Device-TLB
flush timed out.
In detail:
1. Fix a bug found in AMD IOMMU initialization.
pcid
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Feng Wu
CC: Kevin Tian
CC: Dario Faggioli
---
xen/arch/x86/domctl.c | 8 +--
xen/arch/x86/hvm/vmsi.c | 4 +-
xen/arch/x86
On 09/03/16 01:51, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I was wondering if it we should change the default flask_bootparam
> option from permissive to disabled?
>
> The reason being is that I was startled to see that my xSplice
> code was able to patch the hypervisor from within an PV guest!
>
>
Processing commands for x...@bugs.xenproject.org:
> create ^
Created new bug #53 rooted at
`<1457311127.3237075.541322218.485cf...@webmail.messagingengine.com>'
Title: `Re: [Xen-users] Error compiling Xen in configuring stubdom/gmp with
glibc-2.23 on Arch Linux'
> thanks
Finished processing.
Mo
Hello
On Tue, Mar 08, 2016 at 03:22:32PM +, Jason Long wrote:
> Hello.
> How can I test Xen and report bug? Can it need programming?
>
Thanks for you enthusiasm. I don't think knowing how to program is a
must-have for testing Xen (or any software in general). What is needed
is the ability to
Obviously the subject should not have contained an internal ticket
reference.
Please remove before committing or, if preferred, I can resend.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
graft 53 !
thanks
Post this message to xen-devel so that bug tracker can pick it up.
On Mon, Mar 07, 2016 at 10:38:47AM +1000, John Thomson wrote:
> Hi,
>
> I am encountering an error compiling Xen (4.6.1) in configuring
> stubdom/gmp on x86_64 Arch Linux.
> I think it may be due to the system's
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, March 9, 2016 8:37 PM
> To: andrew.coop...@citrix.com; Wu, Feng ; xen-
> de...@lists.xenproject.org
> Cc: k...@xen.org
> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> gu
CC ARM maintainers
On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
> Hi All,
>
> I'm working on a research project with IBM, and I want to run Xen on Nvidia
> Tegra Jetson-tk1 board.
> I looked at a post on this mailing list (http://lists.xenproject.org/archives/
> html/xen-deve
>>> On 08.03.16 at 19:38, wrote:
> Still -- I have a hard time constructing in my mind a scenario where
> huge numbers of idle vcpus for some reason decide to congregate on a
> single pcpu.
>
> Suppose we had 1024 pcpus, and 1023 VMs each with 5 vcpus, of which 1
> was spinning at 100% and the ot
>>> On 09.03.16 at 13:33, wrote:
> On Wed, Mar 09, 2016 at 03:25:58AM -0700, Jan Beulich wrote:
>> Btw., one more thing: Can't the exclusion of FP and SSE states in the logic
>> determining which state set to save be extended to also include YMM? If
> saved,
>> YMM will also always live at a fixe
On 09/03/16 13:35, Wu, Feng wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, March 9, 2016 8:37 PM
>> To: andrew.coop...@citrix.com; Wu, Feng ; xen-
>> de...@lists.xenproject.org
>> Cc: k...@xen.org
>> Subject: Re: [PATCH 2/4] x86: suppress
flight 85777 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 85689
test-armhf-armhf-libvirt
Processing commands for x...@bugs.xenproject.org:
> graft 53 !
Graft `<20160309133517.gc2...@citrix.com>' onto #53
> thanks
Finished processing.
Modified/created Bugs:
- 53: http://bugs.xenproject.org/xen/bug/53
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, March 09, 2016 9:20 PM
> To: Xu, Quan
> Cc: Suravee Suthikulpanit; xen-devel@lists.xen.org; Jan Beulich; Tian, Kevin
> Subject: Re: [Xen-devel] [PATCH v2 1/2] IOMMU/spinlock: Fix a bug found
>>> On 09.03.16 at 14:46, wrote:
> Now I am still not clear for this point- "this inconsistency might lead to
> deadlock".
> I think it is similar to 'mixing interrupt disabled and enabled spinlocks is
> something we disallow'.
> I hope you can give me an example about how to lead to deadlock.
>>> On 08.03.16 at 19:44, wrote:
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
> if ( order < (BITS_PER_LONG - PAGE_SHIFT) )
> sz = 1UL << (order + PAGE_SHIFT);
>
>
On Tue, Mar 08, 2016 at 03:24:35PM -0600, Chong Li wrote:
[...]
> >> +case 'v':
> >> +if (!strcmp(optarg, "all")) { /* get or set all vcpus of a domain
> >> */
> >> +opt_all = 1;
> >> +break;
> >> +}
> >> +if (v_index >= v_size) { /* vcpus array
On Tue, Mar 08, 2016 at 06:38:54PM -0600, Chong Li wrote:
> >> +if (scinfo->num_vcpus > 0) {
> >> +num_vcpus = scinfo->num_vcpus;
> >> +GCNEW_ARRAY(vcpus, num_vcpus);
> >> +for (i = 0; i < num_vcpus; i++) {
> >> +if (scinfo->vcpus[i].vcpuid < 0 ||
> >> +
>>> On 09.03.16 at 11:45, wrote:
> On 09/03/16 08:09, Wu, Feng wrote:
>
>>> --- a/xen/arch/x86/x86_64/entry.S
>>> +++ b/xen/arch/x86/x86_64/entry.S
>>> @@ -434,6 +434,7 @@ ENTRY(dom_crash_sync_extable)
>>>
>>> ENTRY(common_interrupt)
>>> SAVE_ALL CLAC
>>> +SMEP_SMAP_RESTORE
>>>
>>> On 09.03.16 at 09:09, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, March 4, 2016 7:28 PM
>> @@ -1471,7 +1475,10 @@ void __init noreturn __start_xen(unsigne
>> * copy_from_user().
>> */
>> if ( cpu_has_smap )
>> +{
>> +cr4_smep_smap_mask &
flight 85763 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
I saw quite a few coding style issues. Please fix them in next
iteration.
On Sun, Mar 06, 2016 at 11:55:58AM -0600, Chong Li wrote:
[...]
>
> -if (cpupool && (dom || opt_p || opt_b)) {
> +if (cpupool && (dom || opt_p || opt_b || opt_v || opt_all)) {
> fprintf(stderr, "Specifying
>>> On 09.03.16 at 09:09, wrote:
>> >> +/* This mustn't modify registers other than %rax. */
>> >> +ENTRY(cr4_smep_smap_restore)
>> >> +mov %cr4, %rax
>> >> +test $X86_CR4_SMEP|X86_CR4_SMAP,%eax
>> >> +jnz 0f
>
> If we clear every place where we are back to 32bit pv g
>>> On 09.03.16 at 12:19, wrote:
> On 08/03/16 07:57, Jan Beulich wrote:
@@ -174,10 +174,43 @@ compat_bad_hypercall:
/* %rbx: struct vcpu, interrupts disabled */
ENTRY(compat_restore_all_guest)
ASSERT_INTERRUPTS_DISABLED
+.Lcr4_orig:
+ASM_NOP3 /* mo
On 09/03/16 14:01, Jan Beulich wrote:
On 08.03.16 at 19:44, wrote:
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>> if ( order < (BITS_PER_LONG - PAGE_SHIFT) )
>>
On Wed, 2016-03-09 at 06:55 -0700, Jan Beulich wrote:
> >
> > > > On 09.03.16 at 14:46, wrote:
> > Now I am still not clear for this point- "this inconsistency might
> > lead to
> > deadlock".
> > I think it is similar to 'mixing interrupt disabled and enabled
> > spinlocks is
> > something we
>>> On 09.03.16 at 15:36, wrote:
> On 09/03/16 14:01, Jan Beulich wrote:
> On 08.03.16 at 19:44, wrote:
>>> --- a/xen/arch/x86/flushtlb.c
>>> +++ b/xen/arch/x86/flushtlb.c
>>> @@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
>>> if ( order < (B
On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> pcidevs_lock should be held with interrupt enabled.
>
There's a message from Jan when he says:
<>
:-O
> However there remains
> an exception in AMD IOMMU code, where the lock is acquired with
> interrupt
> disabled. This inconsistency might lea
Thank you so much but it need programming?
On Wednesday, March 9, 2016 5:02 PM, Wei Liu wrote:
Hello
On Tue, Mar 08, 2016 at 03:22:32PM +, Jason Long wrote:
> Hello.
> How can I test Xen and report bug? Can it need programming?
>
Thanks for you enthusiasm. I don't think knowing how to pr
>>> On 09.03.16 at 15:52, wrote:
On 09.03.16 at 15:36, wrote:
>> On 09/03/16 14:01, Jan Beulich wrote:
>> On 08.03.16 at 19:44, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5641,7 +5641,7 @@ int map_pages_to_xen(
flush_flags |= FLUSH_TLB_GLOBAL
Hi,
> +/* Here we just expose minimal host bridge offset subset. */
> +static const IGDHostInfo igd_host_bridge_infos[] = {
> +{0x08, 2}, /* revision id */
> +{0x2c, 2}, /* sybsystem vendor id */
> +{0x2e, 2}, /* sybsystem id */
Can anyone clarify where this comes from?
Setting
flight 85758 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85758/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 85694 pass
in 85758
test-amd64-i386-xl-qemuu-
On Tue, 2016-03-08 at 23:33 -0500, Meng Xu wrote:
> I didn't mark out all repeated style issues. I think you can correct
> all of the style issues, such as the spaces in the code, in the next
> version.
>
Yes, please. At v7, style issues shouldn't definitely be there any
longer.
Have another look
On 09/03/16 13:39, Jan Beulich wrote:
On 08.03.16 at 19:38, wrote:
>> Still -- I have a hard time constructing in my mind a scenario where
>> huge numbers of idle vcpus for some reason decide to congregate on a
>> single pcpu.
>>
>> Suppose we had 1024 pcpus, and 1023 VMs each with 5 vcpus, o
On Tue, 2016-03-08 at 19:09 +, Wei Liu wrote:
> On Sun, Mar 06, 2016 at 11:55:55AM -0600, Chong Li wrote:
>
> > +spin_lock_irqsave(&prv->lock, flags);
> > +svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
> > +svc->period = period;
> > +svc->budget =
>>> On 09.03.16 at 13:22, wrote:
> On 03/08/16 02:27, Jan Beulich wrote:
>> >>> On 08.03.16 at 10:15, wrote:
>> > More thoughts on reserving NVDIMM space for per-page structures
>> >
>> > Currently, a per-page struct for managing mapping of NVDIMM pages may
>> > include following fields:
>> >
>
[Changing the subject and CC'ing more people]
On 09/03/16 13:39, Jan Beulich wrote:
On 08.03.16 at 19:38, wrote:
>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>> about with "Something bad may happen" being difficult to work with.
>> Rather than you spelling out
Hi all
I picked up Ian Campbell's work on introducing a set of stable
libraries that can be used by user space programs. The latest one is
libxendevicemodel which is designed to be used by, well, device model.
The last obstacle for it (without PCI passthrough support) is
video ram handling.
I tho
Paul,
>see the patch attached. It's a bit dirty still (that's why it wasn't
>upstreamed
>long time ago), but you can obviously look through it and gain some
>information.
Thanks, I’ll take a look and compare it against
mine to make sure we capture everything.
Ben
On 08/03/16 15:30, Malcolm Crossley wrote:
> Nested hap code assumed implict bitmask semantics of the p2m_access_t
> enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
>
> The change to the enum ordering broke this assumption and caused functional
> problems for the nested hap code. As it
George,
Thank you for all the information. I'll take a dive in and see what I can see.
I'd at least like to get the CPU core frequency detection in as that will
make things a lot easier for us as we port to multiple platforms with
different cores. Then we don't have to keep looking up core speeds.
>>> On 09.03.16 at 17:01, wrote:
> On 09/03/16 13:39, Jan Beulich wrote:
> On 08.03.16 at 19:38, wrote:
>>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>>> about with "Something bad may happen" being difficult to work with.
>>> Rather than you spelling out exactly
>>> On 09.03.16 at 17:10, wrote:
> On Tue, 2016-03-08 at 19:09 +, Wei Liu wrote:
>> On Sun, Mar 06, 2016 at 11:55:55AM -0600, Chong Li wrote:
>>
>> > +spin_lock_irqsave(&prv->lock, flags);
>> > +svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
>> > +svc->period
On Tue, Mar 08, 2016 at 01:48:05AM -0700, Jan Beulich wrote:
> >>> On 07.03.16 at 23:04, wrote:
> >> +[param_pericom_4port] = {
> >> +.base_baud = 921600,
> >> +.uart_offset = 8,
> >> +.reg_width = 1,
> >> +.fifo_size = 16,
> >> +.lsr_mask = UART_LSR_TH
On Tue, Mar 08, 2016 at 09:09:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > Furthermore, I think coming up with a story for PV-aware guests (PVHVM,
> > PV and PVH) is also non-trivial. For one the disk replication logic is
>
> Pls keep in mind that PV guests can use QEMU qdisk if they wish.
>
Oh
>>> On 09.03.16 at 17:52, wrote:
> On Tue, Mar 08, 2016 at 01:48:05AM -0700, Jan Beulich wrote:
>> >>> On 07.03.16 at 23:04, wrote:
>> > Hmm, if it was some other PCI based serial card like:
>> >
>> > 01:05.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O
>> > Controller (rev 01) (prog-
>>> On 09.03.16 at 17:23, wrote:
> [Changing the subject and CC'ing more people]
>
> On 09/03/16 13:39, Jan Beulich wrote:
> On 08.03.16 at 19:38, wrote:
>>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>>> about with "Something bad may happen" being difficult to
On 03/03/16 19:55, Lars Kurth wrote:
Daniel, (added Jan - search for @Jan)
thanks for the feedback
On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote:
On 01/03/16 18:04, Lars Kurth wrote:
Daniel, Jesus,
I am going to break my comments down into different sections to make this more
consumable
On 02/03/16 23:45, Daniel Izquierdo wrote:
[...]
Given, that the Xen-A1.A2.A3 dash board is quite busy, we should keep
that separate.
I still have to upload this, sorry for the delay!
This is a summary of the actions unless extra comments are provided:
* Balance should be calculated as
On the whole series, you are Cc-ing ian.campb...@eu.citrix.com, which
is no longer a tools maintainer.
Please, double check by looking at MAINTAINERS and/or with
./scripts/get_maintainer.pl.
While fiddling with the Cc-list, can you please try to arrange things
in such a way that each person is Cc
On Wed, 2016-03-09 at 18:09 +0100, Dario Faggioli wrote:
> While fiddling with the Cc-list, can you please try to arrange things
> in such a way that each person is Cc-ed only to the subset of the
> series that he would reasonably care about.
>
> For instance, Jan is likely not going to look at li
flight 85819 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85661
Tests which di
On Tue, 2016-03-08 at 19:12 +, Wei Liu wrote:
> Overall I think the patch is moving towards the right direction.
>
I also think so. Thanks a lot Wei for the review, BTW.
> Just
> that there are too many places where indentation need fixing. Please
> fix them in the next iteration. I really
On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
>
Reviewed-by: Dario Faggioli
And I've applied and build tested it, against current staging, and this
time, it worked. :-)
Regards,
Dario
--
<> (Raistlin Majere)
-
On 09/03/16 16:23, George Dunlap wrote:
>
> I don't know why this is controversial -- this seems obvious to me.
> What do other committers / maintainers think?
I started on a reply to this but then I went back and read the original
thread...
+/*
+ * XXX: The length of the list depends on
On 09/03/16 15:23, Jan Beulich wrote:
>
> And there's a second issue here: map_pages_to_xen() updates
> the idle page tables, only part of which is actually in use on a
> huge machine in the context of a PV guest, so the above is also
> risking a #PF on a guest address for the CLFLUSH. Setting the
Introduce the FLUSH_CACHE_BY_VA flag to flush_area_mask() and friends
to say that it is safe to use CLFLUSH (i.e., the virtual address is
still valid).
Use this when changing the cachability of the Xen direct mappings (in
response to the guest changing the cachability of its mappings). This
signif
The foreign header generation blindly replaces 'uint64_t' with '__align8__
uint64_t', to get correct alignment when built as 32bit. This is correct in
most circumstances, but Clang objects to two specific uses.
* Inside a sizeof() expression
* As part of a typecast
An example error looks like:
Fixes a build failure with Clang.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
New in v2
---
tools/misc/gtracestat.c | 4
1 file changed, 4 deletions(-)
diff --git a/tools/misc/gtracestat.c b/tools/misc/gtracestat.c
index 3c2bd2c..67cb003 100644
--- a/tools/misc/gtracest
flight 85827 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85661
Tests which di
On Wed, Mar 09, 2016 at 07:03:15PM +, Andrew Cooper wrote:
> The foreign header generation blindly replaces 'uint64_t' with '__align8__
> uint64_t', to get correct alignment when built as 32bit. This is correct in
> most circumstances, but Clang objects to two specific uses.
>
> * Inside a s
1 - 100 of 132 matches
Mail list logo
