flight 79068 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254
test-armhf-armhf-xl-x
On Jan 26, 2016 23:51, "Peter Zijlstra" wrote:
>
> So for a moment it looked like MIPS wanted to equal or surpass Alpha in
> this respect.
If there is an architecture that I'd expect to try to take the "sucks more"
crown, MIPS would be it. They've already done the "worst cache award"
thing, and a
>>> On 27.01.16 at 08:35, wrote:
> 1: xstate: don't unintentionally clear compaction bit
> 2: adjust xsave structure attributes
> 3: xstate: fix fault behavior on XRSTORS
>
> Signed-off-by: Jan Beulich
Actually - no, let me see whether I can figure out the further
#GP that is apparently occurri
>>> On 26.01.16 at 19:02, wrote:
> Last time, I did absolutely nothing. System was idle
> and it crashed just after the login. Now, I booted the
> system again and this time, there is no reset. But,
> performance of the system is very slow. Browser
> (Mozilla Firefox) freezes a lot. Also, before a
Hi Shannon,
On 2016/1/23 11:19, Shannon Zhao wrote:
From: Shannon Zhao
When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.
Signed-off-by: Shannon Zhao
---
CC: Hanjun Guo
---
arch/arm64/kernel/acpi.c | 12 ++
Changes in v7:
*Add static for pkey_fault.
*Add a comment for page present check and adjust indentation.
*Init pkru_ad and pkru_wd.
*Delete l3e_get_pkey the outer parentheses.
*The first parameter of read_pkru_* use uint32_t type.
Protection keys define a new 4-bit protection key field(PKEY)
Changes in v7:
*Rebase in the latest tree.
*Add a comment for cpu_has_xsave adjustment.
*Adjust indentation.
---
This patch adds pkeys support for cpuid handing.
Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.P
Changes in v7:
*Add static for pkey_fault.
*Add a comment for page present check and adjust indentation.
*Init pkru_ad and pkru_wd.
*Delete l3e_get_pkey the outer parentheses.
*The first parameter of read_pkru_* use uint32_t type.
*Use EOPNOTSUPP instead of EINVAL as return value on is_pv_vcpu cond
From: George Dunlap
Changes in v7:
*Update SDM chapter comments.
*Add hvm_vcpu check in sh_gva_to_gfn.
---
At the moment, the pfec argument to gva_to_gfn has two functions:
* To inform guest_walk what kind of access is happenind
* As a value to pass back into the guest in the event of a fault.
Changes in v7:
*Use EOPNOTSUPP instead of EINVAL as return value on is_pv_vcpu condition.
---
The XSAVE feature set can operate on PKRU state only if the feature set is
enabled (CR4.OSXSAVE = 1) and has been configured to manage PKRU state
(XCR0[9] = 1). And XCR0.PKRU is disabled on PV mode withou
Changes in v7:
no changes.
This patch disables pkeys for guest in non-paging mode, However XEN always uses
paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys
needs to be manually disabled when guest switches to non-paging mode.
Signed-off-by: Huaitong Han
Reviewed
On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote:
> So Peter, would you like to update your patch to include yourself
> and Will as authors?
Sure, here goes.
---
Subject: documentation: Add disclaimer
It appears people are reading this document as a requirements list for
building
On Tue, Jan 26, 2016 at 12:13:39PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 11:19:27AM +0100, Peter Zijlstra wrote:
> > So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would
> > not someone trying to implement RCsc locks using locally transitive
> > RELEASE/ACQUIR
On 2016/1/27 16:27, Hanjun Guo wrote:
> Hi Shannon,
>
> On 2016/1/23 11:19, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
>> a /hypervisor node in DT. So check if it needs to enable ACPI.
>>
>> Signed-off-by: Shannon Zhao
On Tue, 2016-01-26 at 18:18 +, osstest service owner wrote:
> flight 79027 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/79027/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-rumpuser
On Tue, Jan 26, 2016 at 5:26 PM, Doug Goldstein wrote:
>> If forking the repo significantly easier than just creating an empty one of
>> your own and pushing to it? Is the parent repo "important" in some way in
>> the GH world? (Given that, as George says, we are unlikely to accept
>> contribution
Hi,
At 07:22 + on 27 Jan (1453879344), Han, Huaitong wrote:
> On Tue, 2016-01-26 at 14:30 +, Tim Deegan wrote:
> > This seems OK. But can you please:
> > - Add this new adjustment once, in paging_gva_to_gfn(), instead of
> >adding it to each implementation; and
> > - Adjust the comm
On Wed, 2016-01-27 at 09:34 +, George Dunlap wrote:
> Ian, how hard would it be to modify your xenbugs daemon to make
> another webpage containing git am's of series, with the 0/N in the
> title?
Someone would need to clone https://git.hellion.org.uk/?p=emesinae.git;a=su
mmary and make contrib
On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
> On 1/26/16 10:55 AM, Ian Campbell wrote:
> > On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
> > > All,
> > >
> > > Now I'll start off by saying that "no" is a perfectly acceptable answer
> > > to this suggestion. Basically I reme
Ian Campbell writes ("Re: [xen-unstable test] 79027: regressions - FAIL"):
...
> Given the status of the rumpkernel push gate (needs significant
> reworking in osstest to match upstream developments, gate is currently
> disabled) I think we should just force push this.
I agree.
Ian.
On Tue, 2016-01-26 at 17:15 +, Stefano Stabellini wrote:
> It is sufficient to create an empty save file, as returned by
> libxl__device_model_savefile, with the right owner, at domain creation
> time. Something like below:
>
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> ind
On Tue, 2016-01-26 at 14:47 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 04:19:54PM +, Ian Campbell wrote:
> > On Mon, 2016-01-25 at 16:06 -0500, Konrad Rzeszutek Wilk wrote:
> > > To hopefully clarify what it meant.
> > >
> > > Signed-off-by: Konrad Rzeszutek Wilk
> > > ---
On Wed, 2016-01-27 at 10:20 +0800, Dongli Zhang wrote:
> Hi,
>
> There was a patch
> (http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00285.htm
> l) in
> 2015 to support multicast packet filter in Xen netback. I found that this
> feature "feature-multicast-control" is currently not
On Wed, 2016-01-27 at 15:12 +0800, Wen Congyang wrote:
> On 01/27/2016 04:44 AM, Konrad Rzeszutek Wilk wrote:
> > > + 0x000F: DIRTY_PFN_LIST
> > > +
> >
> > Perhaps make it part of the optional and prefix it with CHECKPOINT?
>
> IIUC, optional record can be ignored, but this recor
On Fri, Nov 13, Olaf Hering wrote:
> Port pvscsi support from xend to libxl:
How should code which converts devices from xenstore to json handle
devices which got marked as "to be removed"?
In my pvscsi code I set XenbusStateClosing in the vscsidev, then
XenbusStateReconfiguring in vscsictrl. Th
On Wed, 2016-01-27 at 09:46 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [xen-unstable test] 79027: regressions -
> FAIL"):
> ...
> > Given the status of the rumpkernel push gate (needs significant
> > reworking in osstest to match upstream developments, gate is currently
> > disabled) I t
On Wed, Jan 27, 2016 at 09:35:46AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote:
> > So Peter, would you like to update your patch to include yourself
> > and Will as authors?
>
> Sure, here goes.
>
> ---
> Subject: documentation: Add disclaimer
On Wed, 2016-01-27 at 09:34 +, Tim Deegan wrote:
> Hi,
>
> At 07:22 + on 27 Jan (1453879344), Han, Huaitong wrote:
> > On Tue, 2016-01-26 at 14:30 +, Tim Deegan wrote:
> > > This seems OK. But can you please:
> > > - Add this new adjustment once, in paging_gva_to_gfn(), instead
> > >
>>> On 26.01.16 at 20:32, wrote:
> On Tue, Jan 26, 2016 at 09:34:13AM -0700, Jan Beulich wrote:
>> >>> On 26.01.16 at 16:57, wrote:
>> > On 01/26/16 08:37, Jan Beulich wrote:
>> >> >>> On 26.01.16 at 15:44, wrote:
>> >> >> Last year at Linux Plumbers Conference I attended a session dedicated
>>
>>> On 27.01.16 at 04:18, wrote:
> On Mon, 2016-01-25 at 08:46 -0700, Jan Beulich wrote:
>
>> > > > On 19.01.16 at 08:30, wrote:
>>
>>
>> > +write_cr4(cr4 | X86_CR4_PKE);
>> > +asm volatile (".byte 0x0f,0x01,0xee"
>> > +: "=a" (pkru) : "c" (0) : "dx");
>> > +write_cr4(cr4);
On Tue, Jan 26, 2016 at 03:37:33PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:10:10PM +, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote:
> > > PPC WRCnf+addrs
> > > ""
> > > {
> > > 0:r2=x; 0:r3=y;
> > > 1:r2=x; 1:r3=y;
> > > 2:r2=x; 2:r
>>> On 26.01.16 at 23:35, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, January 26, 2016 12:19 AM
>>
>> When mapping large BARs (e.g. the frame buffer of a graphics card) the
>> overhead of establishing such mappings using only 4k pages has,
>> particularly after the X
On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote:
> > > > On Fri, Jan 15, 2016 at 0
>>> On 27.01.16 at 08:01, wrote:
>
> On 1/26/2016 7:00 PM, Jan Beulich wrote:
> On 26.01.16 at 08:32, wrote:
>>> On 1/22/2016 4:01 PM, Jan Beulich wrote:
>>> On 22.01.16 at 04:20, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -940,6 +940,10 @@ st
>>> On 27.01.16 at 08:02, wrote:
>
> On 1/26/2016 7:24 PM, Jan Beulich wrote:
> On 26.01.16 at 08:59, wrote:
>>
>>>
>>> On 1/22/2016 7:43 PM, Jan Beulich wrote:
>>> On 22.01.16 at 04:20, wrote:
> @@ -2601,6 +2605,16 @@ struct hvm_ioreq_server
>>> *hvm_select_ioreq_server(struct dom
On 27/01/16 10:22, Jan Beulich wrote:
On 26.01.16 at 23:35, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Tuesday, January 26, 2016 12:19 AM
>>>
>>> When mapping large BARs (e.g. the frame buffer of a graphics card) the
>>> overhead of establishing such mappings using onl
On Thu, Jan 14, 2016 at 04:47:53PM -0800, Paul E. McKenney wrote:
> So you need to build a different kernel for some types of MIPS systems?
Yes. We can't really do without. Classic MIPS code is not relocatable
without the complexity of PIC code as used by ELF DSOs - and their
performanc penalty
On Tue, Jan 26, 2016 at 4:34 PM, Jan Beulich wrote:
On 26.01.16 at 16:57, wrote:
>> On 01/26/16 08:37, Jan Beulich wrote:
>>> >>> On 26.01.16 at 15:44, wrote:
>>> >> Last year at Linux Plumbers Conference I attended a session dedicated
>>> >> to NVDIMM support. I asked the very same questi
Hello.
I look at below article :
http://xenserver.org/blog/entry/a-new-year-a-new-way-to-build-for-xenserver.html
What does it mean? I guess Containers like Docker are a competitor for
virtualization platform and can't mean a fail for Xen?
Tnx.
___
X
On 27/01/16 06:47, Wen Congyang wrote:
> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
>>> It is the negotiation record for COLO.
>>> Primary->Secondary:
>>> control_id 0x: Secondary VM is out of sync, start a new
On 27/01/16 09:45, Ian Campbell wrote:
> On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
>> On 1/26/16 10:55 AM, Ian Campbell wrote:
>>> On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
All,
Now I'll start off by saying that "no" is a perfectly acceptable answer
On 27/01/16 10:00, Ian Campbell wrote:
> On Wed, 2016-01-27 at 15:12 +0800, Wen Congyang wrote:
>> On 01/27/2016 04:44 AM, Konrad Rzeszutek Wilk wrote:
+ 0x000F: DIRTY_PFN_LIST
+
>>> Perhaps make it part of the optional and prefix it with CHECKPOINT?
>> IIUC, optional reco
> On January 27, 2016 at 6:48am, wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Tuesday, January 26, 2016 11:53 PM
> > Once again: Before getting started, please assess which route is going
> > to be the better one. Remember that we had already discussed and put
> > aside some
flight 79090 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79090/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 78925
REGR. vs. 66399
test-armhf-
On Wed, 2016-01-27 at 11:01 +, Jason Long wrote:
> Hello.
> I look at below article :
>
> http://xenserver.org/blog/entry/a-new-year-a-new-way-to-build-for-xenserver.html
>
> What does it mean?
xenserver != xenproject (xenserver is a downstream project of xenproject).
If this discussion bel
On Tue, 2016-01-26 at 13:11 +, osstest service owner wrote:
> flight 79008 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/79008/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl-cre
>>> On 27.01.16 at 12:09, wrote:
>> On January 27, 2016 at 6:48am, wrote:
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Tuesday, January 26, 2016 11:53 PM
>
>
>> > Once again: Before getting started, please assess which route is going
>> > to be the better one. Remember that we
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
> > So you need to build a different kernel for some types of MIPS systems?
> > Or do you do boot-time rewriting, like a number of other arches do?
>
> I don't know. I would like to have responses. Ralf asked Maciej about old
> systems and that came now
On Wed, Jan 27, 2016 at 10:55 AM, Andrew Cooper
wrote:
> On 27/01/16 09:45, Ian Campbell wrote:
>> On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
>>> On 1/26/16 10:55 AM, Ian Campbell wrote:
On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
> All,
>
> Now I'll sta
This run is configured for baseline tests only.
flight 38706 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 19 guest-start/debia
(we went offlist by mistake without noticing, resending my last reply which
I think has sufficient context/quoting to make sense)
On Wed, 2016-01-27 at 11:51 +0200, CORNELIU ZUZU wrote:
> On 1/26/2016 6:14 PM, Ian Campbell wrote:
> > On Tue, 2016-01-26 at 13:46 +0200, Corneliu ZUZU wrote:
> > > Wh
On Wed, 2016-01-27 at 11:18 +, Ian Campbell wrote:
> On Tue, 2016-01-26 at 13:11 +, osstest service owner wrote:
> > flight 79008 linux-4.1 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/79008/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
On Wed, 27 Jan 2016, Ralf Baechle wrote:
> > So you need to build a different kernel for some types of MIPS systems?
>
> Yes. We can't really do without. Classic MIPS code is not relocatable
> without the complexity of PIC code as used by ELF DSOs - and their
> performanc penalty. Plus we have
flight 38707 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38707/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38672
jobs:
build-amd64 pass
build-armhf
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Refactor gic-v3 related functions into dt and generic parts. This will be
> helpful when adding acpi support for gic-v3.
>
> Signed-off-by: Shannon Zhao
> ---
> v5: none
> v4: Use INVALID_PADDR and move ioremap to common init fun
When __p2m_get_mem_access gets called, the p2m lock is already taken
by either get_page_from_gva or p2m_get_mem_access.
Possible code paths:
1) -> get_page_from_gva
-> p2m_mem_access_check_and_get_page
-> __p2m_get_mem_access
2) -> p2m_get_mem_acce
On 25/01/16 16:18, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2491,7 +2491,7 @@ static int vmx_alloc_vlapic_mapping(stru
> share_xen_page_with_guest(pg, d, XENSHARE_writable);
> d->arch.hvm_domain.vmx.apic_access_mfn = mfn;
> set_mm
> On January 27, 2016 at 7:24pm, wrote:
> >>> On 27.01.16 at 12:09, wrote:
> >> On January 27, 2016 at 6:48am, wrote:
> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> > Sent: Tuesday, January 26, 2016 11:53 PM
> >
> >
> >> > Once again: Before getting started, please assess which route
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add macros to emulate x86 style ports for arm. This avoids modification in
> common code for acpi. Here just print a warning on ARM.
>
> Signed-off-by: Shannon Zhao
> ---
> V4: print warning
> ---
> xen/include/asm-arm/arm64/io.
flight 79101 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79101/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
On 2016/1/27 20:18, Stefano Stabellini wrote:
On Sat, 23 Jan 2016, Shannon Zhao wrote:
>From: Shannon Zhao
>
>Refactor gic-v3 related functions into dt and generic parts. This will be
>helpful when adding acpi support for gic-v3.
>
>Signed-off-by: Shannon Zhao
>---
>v5: none
>v4: Use INVALID_P
>>> On 26.01.16 at 19:02, wrote:
> Last time, I did absolutely nothing. System was idle
> and it crashed just after the login. Now, I booted the
> system again and this time, there is no reset. But,
> performance of the system is very slow. Browser
> (Mozilla Firefox) freezes a lot. Also, before a
>>> On 27.01.16 at 13:38, wrote:
>> On January 27, 2016 at 7:24pm, wrote:
>> >>> On 27.01.16 at 12:09, wrote:
>> >> On January 27, 2016 at 6:48am, wrote:
>> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> > Sent: Tuesday, January 26, 2016 11:53 PM
>> >
>> >
>> >> > Once again: Before
I tried to apply your patches but it seems
to have some merge conflicts with latest
staging branch.
~/xen$ git apply ~/Downloads/x86-xsaves-init.patch
error: patch failed: xen/arch/x86/hvm/hvm.c:2094
error: xen/arch/x86/hvm/hvm.c: patch does not apply
Do you mind having a look ?
Regards,
Harmand
>>> On 27.01.16 at 13:32, wrote:
> On 25/01/16 16:18, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2491,7 +2491,7 @@ static int vmx_alloc_vlapic_mapping(stru
>> share_xen_page_with_guest(pg, d, XENSHARE_writable);
>> d->arch.hvm_domain
On Wed, 27 Jan 2016, Shannon Zhao wrote:
> On 2016/1/27 20:18, Stefano Stabellini wrote:
> > On Sat, 23 Jan 2016, Shannon Zhao wrote:
> > > >From: Shannon Zhao
> > > >
> > > >Refactor gic-v3 related functions into dt and generic parts. This will be
> > > >helpful when adding acpi support for gic-v3
Hi again,
any thoughts on this topic? Questions, suggestions, criticism? I can make
patches to discuss code, but it would rather be handly if I'd be on the
same page with everyone here to make something generically useful.
Suikov Pavlo
GlobalLogic
P +x.xxx.xxx. M +38.066.667.1296 S psujkov
> On January 27, 2016 at 9:15pm, wrote:
> >>> On 27.01.16 at 13:38, wrote:
> >> On January 27, 2016 at 7:24pm, wrote:
> >> >>> On 27.01.16 at 12:09, wrote:
> >> >> On January 27, 2016 at 6:48am, wrote:
> >> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> > Sent: Tuesday, January 26
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 26 January 2016 16:51
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Ian Jackson; Jan Beulich; Keir (Xen.org);
> Tim (Xen.org); Wei Liu; Roger Pau Monne
> Subject: Re: [PATCH] public/io/netif.h: cha
On 1/27/2016 6:27 PM, Jan Beulich wrote:
On 27.01.16 at 08:01, wrote:
On 1/26/2016 7:00 PM, Jan Beulich wrote:
On 26.01.16 at 08:32, wrote:
On 1/22/2016 4:01 PM, Jan Beulich wrote:
On 22.01.16 at 04:20, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -940,6 +940,1
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 27 January 2016 09:57
> To: Dongli Zhang; xen-de...@lists.xenproject.org
> Cc: Paul Durrant
> Subject: Re: [Xen-devel] Is "feature-multicast-control" supported by xen-
> netfront?
>
> On Wed, 2016-01-27 at 1
On Fri, 2016-01-22 at 11:54 -0500, Elena Ufimtseva wrote:
> Hello all!
>
Hey, here I am again,
> Konrad came up with a workaround that was setting the flag for domain
> scheduler in linux
> As the guest is not aware of SMT-related topology, it has a flat
> topology initialized.
> Kernel has domai
On Tue, 2016-01-26 at 11:21 +, George Dunlap wrote:
> On 22/01/16 16:54, Elena Ufimtseva wrote:
> >
> Regarding placement wrt topology: If two threads are doing a large
> amount of communication, then putting them close in the topology will
> increase perfomance, because they share cache, and
On 27/01/16 13:37, Jan Beulich wrote:
On 27.01.16 at 13:32, wrote:
>> On 25/01/16 16:18, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -2491,7 +2491,7 @@ static int vmx_alloc_vlapic_mapping(stru
>>> share_xen_page_with_guest(pg, d, XE
>>> On 27.01.16 at 14:28, wrote:
> I tried to apply your patches but it seems
> to have some merge conflicts with latest
> staging branch.
>
> ~/xen$ git apply ~/Downloads/x86-xsaves-init.patch
> error: patch failed: xen/arch/x86/hvm/hvm.c:2094
> error: xen/arch/x86/hvm/hvm.c: patch does not appl
>>> On 27.01.16 at 15:13, wrote:
>> On January 27, 2016 at 9:15pm, wrote:
>> >>> On 27.01.16 at 13:38, wrote:
>> >> On January 27, 2016 at 7:24pm, wrote:
>> >> >>> On 27.01.16 at 12:09, wrote:
>> >> >> On January 27, 2016 at 6:48am, wrote:
>> >> >> > From: Jan Beulich [mailto:jbeul...@suse
On Mon, 2016-01-25 at 15:38 +0200, Pavlo Suikov wrote:
> Hi everyone,
>
> I want to bring domain restart question for a discussion. It originates
> from DomD restart, but the solution I am about to offer can be quite
> generic.
>
> Problem is, domain specification currently holds only frontend in
On 1/25/16 5:27 AM, Ian Campbell wrote:
> On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
>> This consolidates some of the different variables used for the ARM
>> builds. This change was prompted by the Kconfig changes but looking back
>> in time the CONFIG_ARM_{32,64} variables existed be
>>> On 27.01.16 at 15:13, wrote:
> About the default value:
>You are right. :) For XenGT, MAX_NR_IO_RANGES may only work under
> limited conditions. Having it default to zero means XenGT users must
> manually configure this option. Since we have plans to push other XenGT
> tool stack parameter
On Tue, Jan 26, 2016 at 11:21:36AM +, George Dunlap wrote:
> On 22/01/16 16:54, Elena Ufimtseva wrote:
> > Hello all!
> >
> > Dario, Gerorge or anyone else, your help will be appreciated.
> >
> > Let me put some intro to our findings. I may forget something or put
> > something
> > not too
> On January 27, 2016 10:29pm, wrote:
> >>> On 27.01.16 at 15:13, wrote:
> >> On January 27, 2016 at 9:15pm, wrote:
> >> >>> On 27.01.16 at 13:38, wrote:
> >> >> On January 27, 2016 at 7:24pm, wrote:
> >> >> >>> On 27.01.16 at 12:09, wrote:
> >> >> >> On January 27, 2016 at 6:48am, wrote:
graft 34 ^
close it
thanks
On 12/1/15 1:27 PM, Doug Goldstein wrote:
> Prefer using the character device over the proc file if the character
> device exists. This follows similar conversions of xenbus to avoid
> issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer.
>
> CC: Ian Jackson
> CC
>>> On 27.01.16 at 15:28, wrote:
> On 27/01/16 13:37, Jan Beulich wrote:
> On 27.01.16 at 13:32, wrote:
>>> On 25/01/16 16:18, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2491,7 +2491,7 @@ static int vmx_alloc_vlapic_mapping(stru
>>>
Processing commands for x...@bugs.xenproject.org:
> graft 34 ^
Graft `<1448998075-23878-1-git-send-email-car...@cardoe.com>' onto #34
> close it
Command failed: No previous bug found at
/srv/xen-devel-bugs/lib/emesinae/control.pl line 273, line 2.
Stop processing here.
Modified/created Bugs:
-
>>> On 27.01.16 at 15:30, wrote:
> On 1/25/16 5:27 AM, Ian Campbell wrote:
>> On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
>>> @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o $(ALL_OBJS)
>>>
>>> $(TARGET): $(TARGET)-syms $(TARGET).axf
>>> $(OBJCOPY) -O binary -S $< $@
>>>
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
>> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
>>>
>>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
>> wrote:
You go:
hvmlite_start_xen() -->
On Wed, Jan 27, 2016 at 03:16:59AM -0700, Jan Beulich wrote:
> >>> On 26.01.16 at 20:32, wrote:
> > On Tue, Jan 26, 2016 at 09:34:13AM -0700, Jan Beulich wrote:
> >> >>> On 26.01.16 at 16:57, wrote:
> >> > On 01/26/16 08:37, Jan Beulich wrote:
> >> >> >>> On 26.01.16 at 15:44, wrote:
> >> >> >>
On 27/01/16 14:40, Jan Beulich wrote:
>
> int set_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn,
> - p2m_access_t access)
> + unsigned int order, p2m_access_t access)
> {
> -return set_typed_p2m_entry(d, gfn, mfn,
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
> >
> > On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
> wrote:
> > > You go:
> > >
> > > hvmlite_start_xen() -->
> > > HVM stub
> > > startup_64() | (start
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> If ACPI is initialized after the boot allocator has ended(the system
> state is not early boot), assert happens in acpi_os_zalloc_memory and
> acpi_boot_table_init will fail. So it needs to move end_boot_allocator
> after acpi_boot
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> acpi_boot_table_init() will be called in start_xen to get the RSDP and
> all the table pointers. With this patch, we can get ACPI boot-time
> tables from firmware on ARM64.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Di
Peter Zijlstra wrote:
> +==
> +DISCLAIMER
> +==
> +
> +This document is not a specification; it is intentionally (for the sake of
> +brevity) and unintentionally (due to being human) incomplete. This document
> is
> +meant as a guide to using the various memory barriers provided
Processing commands for x...@bugs.xenproject.org:
> close 34
Closing bug #34
> thanks
Finished processing.
Modified/created Bugs:
- 34: http://bugs.xenproject.org/xen/bug/34
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on
reporting bugs
On 01/27/2016 09:50 AM, David Vrabel wrote:
On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote:
On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote:
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote:
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez
wrote:
You go:
hvmlite_star
On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
> > > > On 27.01.16 at 15:30, wrote:
> > On 1/25/16 5:27 AM, Ian Campbell wrote:
> > > On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
> > > > @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o $(ALL_OBJS)
> > > >
> > > > $(TARG
On 1/27/2016 10:32 PM, Jan Beulich wrote:
On 27.01.16 at 15:13, wrote:
About the default value:
You are right. :) For XenGT, MAX_NR_IO_RANGES may only work under
limited conditions. Having it default to zero means XenGT users must
manually configure this option. Since we have plans to pus
>>> On 27.01.16 at 15:56, wrote:
> On 1/27/2016 10:32 PM, Jan Beulich wrote:
> On 27.01.16 at 15:13, wrote:
>>> About the truncation issue:
>>> I do not quite follow. Will this hurt if the value configured does
>>> not exceed 4G? What about a type cast?
>>
>> A typecast would not alter be
On 1/27/16 9:05 AM, Ian Campbell wrote:
> On Wed, 2016-01-27 at 07:44 -0700, Jan Beulich wrote:
> On 27.01.16 at 15:30, wrote:
>>> On 1/25/16 5:27 AM, Ian Campbell wrote:
On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
> @@ -52,7 +52,7 @@ ALL_OBJS := $(TARGET_SUBARCH)/head.o
On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
> On 27/01/16 06:47, Wen Congyang wrote:
> > On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
> >>> It is the negotiation record for COLO.
> >>> Primary->Secondary:
On 27/01/16 15:11, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2016 at 11:00:24AM +, Andrew Cooper wrote:
>> On 27/01/16 06:47, Wen Congyang wrote:
>>> On 01/27/2016 04:40 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Dec 30, 2015 at 10:37:32AM +0800, Wen Congyang wrote:
> It is the nego
1 - 100 of 183 matches
Mail list logo
