>>> On 05.02.15 at 20:02, wrote:
> On 02/03/15 09:58, Jan Beulich wrote:
> On 02.02.15 at 16:22, wrote:
> Ok, will be working on a much better commit message. Do you want the
> new commit message copied here (in the summary of the changes), or just
> that fact that there is a new commit mess
flight 34178 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34178/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488
test-amd64
Hello Folks.
I want to become a Xen developer and I don't have any knowledge about
development. Can you tell me what programming language is needed? How can I
start and etc?
Tnx.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/
On 2015/2/6 3:26, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 05, 2015 at 11:04:37AM +0800, Liuqiming (John) wrote:
> On 2015/2/5 10:57, Liuqiming (John) wrote:
>> sorry for late replay
>>
>> On 2015/2/3 23:32, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Feb 03, 2015 at 10:24:08AM +0800, Liuqiming (Joh
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-freebsd10-amd64
test guest-localmigrate
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu
The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
While in different platform and different requirements this seems improper.
So modifing the IO_TLB_SEGSIZE to io_tlb_segsize which can
configure by kernel cmdline.
Signed-off-by: Chuansheng Liu
Signed-off-by: Zhang Dongxing
Signed-off-by: Wa
On Wed, Feb 4, 2015 at 6:57 AM, Stefano Stabellini
wrote:
> On Wed, 4 Feb 2015, David Vrabel wrote:
>> On 16/12/14 16:21, Juergen Gross wrote:
>> > Hi,
>> >
>> > This is a design proposal for a rework of the config options on the
>> > Linux kernel which are related to Xen.
>> >
>> > The need to do
On Wed, Feb 4, 2015 at 12:29 AM, Jan Beulich wrote:
On 04.02.15 at 01:48, wrote:
>> So as I see it XEN_BALLOON should depend on XEN_PV || XEN_PVH -- not
>> sure how ballooning would be used on HVM only domains although right
>> now ballooning would indeed be initialized in such situations, s
On 2015/2/5 17:52, Ian Campbell wrote:
On Thu, 2015-02-05 at 09:22 +0800, Chen, Tiejun wrote:
Indeed this is not something workaround, and I think in any type of VGA
devices, we'd like to diminish this sort of thing gradually, right?
This mightn't come true in real world :)
It's not really so
Hi Stefano,
On 06/02/2015 01:36, Stefano Stabellini wrote:
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
From: Parth Dixit
xen environment table contains the grant table address,size and event
channel interrupt information required by dom0.
Signed-off-by: Parth Dixit
---
xen/arch/arm/
On 06/02/2015 01:39, Stefano Stabellini wrote:
On Thu, 5 Feb 2015, Julien Grall wrote:
Hi Parth,
On 05/02/2015 18:57, Parth Dixit wrote:
On 5 February 2015 at 10:54, Julien Grall wrote:
On 04/02/2015 14:02, parth.di...@linaro.org wrote:
+stao->header.length = sizeof(struct acpi_table_
On Thu, Feb 5, 2015 at 4:41 AM, David Vrabel wrote:
> Hypercalls submitted by user space tools via the privcmd driver can
> take a long time (potentially many 10s of seconds) if the hypercall
> has many sub-operations.
>
> +
> +void xen_maybe_preempt_hcall(void)
I think this should be asmlinkage
Hi Parth,
On 06/02/2015 01:12, Stefano Stabellini wrote:
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
From: Parth Dixit
Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
boot vcpu's
Signed-off-by: Parth Dixit
---
xen/arch/arm/arm64/acpi/arm-core.c | 16 +++
On 06/02/2015 03:40, Parth Dixit wrote:
+static int map_acpi_regions(struct domain *d)
+{
+int res;
+
+res = acpi_map_mmio(d);
+if ( res )
+return res;
+
+return 0;
+}
I don't think that splitting the code in two functions is useful. Just
implement the remapping here.
o
On 06/02/2015 00:34, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 93c8a8a..930746b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -50,6 +50,7 @@
#include
struct bootinfo __initdata bootinfo;
+struct meminfo __initdata acpi_mmio;
On 06/02/2015 00:21, Stefano Stabellini wrote:
On Thu, 5 Feb 2015, Julien Grall wrote:
Hi parth,
Title: this is not acpi specific.
On 04/02/2015 14:02, parth.di...@linaro.org wrote:
From: Parth Dixit
For passing ACPI tables to dom0, UEFI memory needs to be mapped
by xen in dom0 address sp
Hi Stefano,
On 06/02/2015 00:09, Stefano Stabellini wrote:
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
From: Naresh Bhat
Create a chosen node for DOM0 with
- bootargs
- rsdp
Signed-off-by: Naresh Bhat
Signed-off-by: Parth Dixit
---
xen/arch/arm/domain_build.c | 41 +
On Thu, Feb 5, 2015 at 3:59 PM, Luis R. Rodriguez
wrote:
> On Tue, Feb 3, 2015 at 8:58 PM, Juergen Gross wrote:
>> On 02/04/2015 01:48 AM, Luis R. Rodriguez wrote:
>XEN_MAX_DOMAIN_MEMORY(x86)
which depends on XEN_PV
>>>
>>>
>>> Adjusted, but so far that's the only XEN_PV al
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Friday, February 6, 2015 3:33 AM
> To: Wang, Xiaoming
> Cc: r...@linux-mips.org; boris.ostrov...@oracle.com;
> david.vra...@citrix.com; linux-m...@linux-mips.org; linux-
> ker...@vger.kernel.org; xe
From: Lad Prabhakar
Date: Thu, 5 Feb 2015 13:38:07 +
> From: "Lad, Prabhakar"
>
> this patch fixes following sparse warning:
>
> interface.c:83:5: warning: symbol 'xenvif_poll' was not declared. Should it
> be static?
>
> Signed-off-by: Lad, Prabhakar
Applied.
___
On Tue, Feb 3, 2015 at 8:58 PM, Juergen Gross wrote:
> On 02/04/2015 01:48 AM, Luis R. Rodriguez wrote:
XEN_MAX_DOMAIN_MEMORY(x86)
>>>
>>>
>>> which depends on XEN_PV
>>
>>
>> Adjusted, but so far that's the only XEN_PV alone-dependent option.
>> Are you sure ? This defines MAX_DOMAIN_PAGE
On Mon, Feb 2, 2015 at 10:22 AM, Don Slutz wrote:
> The 1st item is not data, but the port (address).
> The 2nd item is the data.
>
> Signed-off-by: Don Slutz
Thanks:
Acked-by: George Dunlap
> ---
> tools/xentrace/formats | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> di
On 05/02/15 21:16, D'Mita Levy wrote:
> Hello,
>
> I am trying to compile a xen build that will simply print all the
> hypercalls as they come into the hypervisor. Specifically, I'm looking
> for the hypercall handler function so that I can insert a simple
> printk statement.
The logging rate will
Hello,
I am trying to compile a xen build that will simply print all the
hypercalls as they come into the hypervisor. Specifically, I'm looking for
the hypercall handler function so that I can insert a simple printk
statement. I'm having trouble because I can't find a doc that describes
what most
Instead of manual calls of device_create_file() and
device_remove_file(), assign the static attribute groups to the device
to register. The conditional build of sysfs is done in is_visible
callback instead.
Signed-off-by: Takashi Iwai
---
drivers/xen/pcpu.c | 44
Hi,
this is a couple of patchset to clean up the sysfs entry creation /
removal in xen driver codes. They are relatively straightforward
conversion patches, where manual function calls are replaced with
static attribute groups.
Takashi
===
Takashi Iwai (2):
xen: pcpu: Use static attribute g
flight 34171 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 33815
test-amd64-amd64-xl-w
Instead of manual calls of device_create_file(), device_remove_file()
and sysfs_create_group(), assign static attribute groups to the device
to register. This simplifies the code and avoids possible races.
Signed-off-by: Takashi Iwai
---
drivers/xen/xen-balloon.c | 45 --
On 05/02/15 15:51, Ian Jackson wrote:
It looks to be some sort of Heisenbug in the rump kernel stuff.
I agree. We had a failure on the 16th of January which looked like
some kind of race:
(Subject: Re: [Xen-devel] [rumpuserxen test] 33416: regressions - FAIL)
Aha! I told you I don't belie
On Thu, Feb 05, 2015 at 03:47:11PM +0100, Sander Eikelenboom wrote:
>
> Thursday, February 5, 2015, 3:22:49 PM, you wrote:
>
> > Hey David,
>
> > after just being in that pain, I thought I might as well give a summary to
> > you/the list. Maybe helpful to not forget which piece should go to whic
Hi all,
First of all I would like to say that:
- I am happy that PV audio is finding its way into xen and there is active
development on it
- Defining a flexible and future proof PV audio protocol is very hard and will
probably take a bit of trial and error in the beginning.
- I hope I will be a
On Thu, Feb 05, 2015 at 05:09:56PM +, David Vrabel wrote:
> Prior to the existance of 64-bit backends using the X86_64 ABI,
> frontends used the X86_32 ABI. These old frontends do not specify the
> ABI and when used with a 64-bit backend do not work.
Whoa. How old are we talking? I had been u
On 5 February 2015 at 22:19, Stefano Stabellini
wrote:
> On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
>> From: Parth Dixit
>>
>> map mmio regions described in uefi tables to dom0 address space
>>
>> Signed-off-by: Parth Dixit
>> ---
>> xen/arch/arm/domain_build.c | 54
>> +
On Thu, Feb 05, 2015 at 03:07:59PM +, David Vrabel wrote:
> On 05/02/15 15:02, David Vrabel wrote:
> > From: Jennifer Herbert
> >
> > If Xenstore sends back a XS_ERROR for TRANSACTION_END, the driver BUGs
> > because it cannot find the matching transaction in the list. For
> > TRANSACTION_ST
On 5 February 2015 at 22:25, Stefano Stabellini
wrote:
> On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
>> From: Parth Dixit
>>
>> map acpi tables described in uefi table to dom0 address space
>>
>> Signed-off-by: Parth Dixit
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 43
>>
On Thu, Feb 05, 2015 at 03:33:02PM +0100, Stefan Bader wrote:
> While experimenting/testing various kernel versions I discovered that trying
> to
> boot a Haswell based hosts will always crash when booting as Xen dom0
> (Xen-4.4.1). The same crash happens since v3.19-rc1 and still does happen with
On Fri, Feb 06, 2015 at 07:01:14AM +0800, xiaomin1 wrote:
> The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
> While in different platform and different requirements this seems improper.
> So modify the IO_TLB_SEGSIZE to io_tlb_segsize as configurable is make sense.
More details please. What
On Thu, Feb 05, 2015 at 11:39:21AM +, Lad Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> this patch fixes following sparse warning:
>
> xen-acpi-processor.c:505:23: warning: symbol 'xen_acpi_processor_resume_nb'
> was not declared. Should it be static?
Not sure if it is worth fixing it - as
On 5 February 2015 at 23:18, Stefano Stabellini
wrote:
> On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
>> From: Parth Dixit
>>
>> Some bugs are identified in edk2 and some of the functionality is not
>> yet merged. This patch contains workarounds for them
>
> A patch with a few workarounds le
On Thu, Feb 05, 2015 at 11:04:37AM +0800, Liuqiming (John) wrote:
> On 2015/2/5 10:57, Liuqiming (John) wrote:
> >sorry for late replay
> >
> >On 2015/2/3 23:32, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Feb 03, 2015 at 10:24:08AM +0800, Liuqiming (John) wrote:
> >> > On 2015/2/2 22:59, Konrad Rzes
On 02/03/15 09:58, Jan Beulich wrote:
On 02.02.15 at 16:22, wrote:
>> Jan Beulich:
>> The change on what to do when hvm_send_assist_req() fails is bad.
>> That is correct. Made hvm_has_dm() do full checking so
>> that the extra VMEXIT and VMENTRY can be skipped.
>> hvm_
On Thu, Feb 5, 2015 at 10:23 AM, Andrew Cooper
wrote:
> On 05/02/15 18:14, Luis R. Rodriguez wrote:
>> On Thu, Feb 05, 2015 at 12:41:17PM +, David Vrabel wrote:
>>> diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
>>> new file mode 100644
>>> index 000..e2bcc01
>>> --- /dev/null
On 05/02/15 18:14, Luis R. Rodriguez wrote:
> On Thu, Feb 05, 2015 at 12:41:17PM +, David Vrabel wrote:
>> --- a/arch/x86/kernel/entry_32.S
>> +++ b/arch/x86/kernel/entry_32.S
>> @@ -982,6 +982,9 @@ ENTRY(xen_hypervisor_callback)
>> ENTRY(xen_do_upcall)
>> 1: mov %esp, %eax
>> call xen_
On Thu, Feb 05, 2015 at 12:47:15PM +, David Vrabel wrote:
> On 27/01/15 01:51, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > This v5 nukes tracing as David said it was useless, it also
> > only adds support for 64-bit as its the only thing I can test,
> > and slightly modifie
On Thu, Feb 05, 2015 at 12:41:17PM +, David Vrabel wrote:
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,6 +982,9 @@ ENTRY(xen_hypervisor_callback)
> ENTRY(xen_do_upcall)
> 1: mov %esp, %eax
> call xen_evtchn_do_upcall
> +#ifndef CONFIG_PREEMPT
> +
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> Some bugs are identified in edk2 and some of the functionality is not
> yet merged. This patch contains workarounds for them
A patch with a few workarounds left is OK, but you should explain
exactly what they are and why y
Hi Bob,
Can you elaborate on the environment where you measured such an improvement?
I'm particularly interested in:
What workload were you issuing? (e.g. 4K seq reads?)
What backend were you using? (e.g. null driver? what parameters? some specific
disk/array?)
What was the host configuration fo
On Thu, 5 Feb 2015, Julien Grall wrote:
> Hi Parth,
>
> On 05/02/2015 18:57, Parth Dixit wrote:
> > On 5 February 2015 at 10:54, Julien Grall wrote:
> > > On 04/02/2015 14:02, parth.di...@linaro.org wrote:
> > > > +stao->header.length = sizeof(struct acpi_table_header) + 1;
> > > > +stao-
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> xen environment table contains the grant table address,size and event
> channel interrupt information required by dom0.
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 52
> ++
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> hide UART used by xen by indicating it in STAO table
> and map it to dom0
>
> Signed-off-by: Parth Dixit
Please check CODING_STYLE
> xen/arch/arm/arm64/acpi/arm-core.c | 50
> ++
>
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> XSDT table cannot be passed as is to dom0 because new tables specific to xen
> need to be added to its table entries
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 65
> +
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
> boot vcpu's
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 16
> 1 file changed, 16 insertions(+)
>
> dif
Prior to the existance of 64-bit backends using the X86_64 ABI,
frontends used the X86_32 ABI. These old frontends do not specify the
ABI and when used with a 64-bit backend do not work.
On x86, default to the X86_32 ABI if one is not specified. Backends
on ARM continue to default to their NATIV
>>> On 05.02.15 at 17:56, wrote:
>> > --- a/tools/Rules.mk
>> > +++ b/tools/Rules.mk
>> > @@ -56,7 +56,7 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN)
>> >
>> > ifeq ($(debug),y)
>> > # Disable optimizations and enable debugging information for macros
>> > -CFLAGS += -O0 -g3
>> > +CF
Jan Beulich writes ("Re: [PATCH] tools: work around collision of -O0 and
-D_FORTIFY_SOURCE"):
> On 05.02.15 at 17:36, wrote:
> > +AC_DEFUN([AX_CHECK_PYTHON_FORTIFY_NOOPT], [
> > +AC_CACHE_CHECK([whether Python setup.py brokenly enables
> > -D_FORTIFY_SOURCE],
>
> I guess the people having a
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> map acpi tables described in uefi table to dom0 address space
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 43
> ++
> xen/arch/arm/domain_build.c
>>> On 05.02.15 at 17:36, wrote:
> Some systems have python-config include -D_FORTIFY_SOURCE in the
> CFLAGS. But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
> -O0 is enabled in debug builds (since 1166ecf781). As a result, on
> those systems, debug builds fail.
>
> Work around th
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> map mmio regions described in uefi tables to dom0 address space
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/domain_build.c | 54
> +
> 1 file changed, 54 insertions(+)
Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS. But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781). As a result, on
those systems, debug builds fail.
Work around this problem as follows:
* In configure, detect
On Thu, Feb 5, 2015 at 5:24 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
>
> On 05/02/2015 21:49, Oleksandr Tyshchenko wrote:
>>
>> On Thu, Feb 5, 2015 at 3:12 PM, Ian Campbell
>> wrote:
>>>
>>> On Wed, 2015-02-04 at 18:47 +0200, Oleksandr Tyshchenko wrote:
Hi, all.
We
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
#
> From: Parth Dixit
>
> For ACPI on arm device initialization is done by dom0 after parsing DSDT.
> xen requires mmio region information described in uefi tables
> for mapping it to dom0.
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/e
On Thu, 5 Feb 2015, Julien Grall wrote:
> Hi parth,
>
> Title: this is not acpi specific.
>
> On 04/02/2015 14:02, parth.di...@linaro.org wrote:
> > From: Parth Dixit
> >
> > For passing ACPI tables to dom0, UEFI memory needs to be mapped
> > by xen in dom0 address space. This patch adds helper
On 02/05/2015 11:14 AM, David Vrabel wrote:
On 05/02/15 16:11, Boris Ostrovsky wrote:
On 02/05/2015 07:41 AM, David Vrabel wrote:
+
+void xen_maybe_preempt_hcall(void)
+{
+if (__this_cpu_read(xen_in_preemptible_hcall)) {
Can you check should_resched() here?
_cond_resched() already does th
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> Xen environment table is ACPI table that is used to pass grant table
> and event channel interrupt information to dom0.
>
> Signed-off-by: Parth Dixit
> ---
> xen/include/acpi/actbl2.h | 16
> 1 file cha
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> Status override table is used to hide devices from DOM0
> that are used by xen
>
> Signed-off-by: Parth Dixit
> ---
> xen/include/acpi/actbl2.h | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/xe
On 05/02/15 16:11, Boris Ostrovsky wrote:
> On 02/05/2015 07:41 AM, David Vrabel wrote:
>> +
>> +void xen_maybe_preempt_hcall(void)
>> +{
>> +if (__this_cpu_read(xen_in_preemptible_hcall)) {
>
> Can you check should_resched() here?
_cond_resched() already does this.
David
__
On 02/05/2015 07:41 AM, David Vrabel wrote:
+
+void xen_maybe_preempt_hcall(void)
+{
+ if (__this_cpu_read(xen_in_preemptible_hcall)) {
Can you check should_resched() here?
-boris
+ /*
+* Clear flag as we may be rescheduled on a different
+
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Create a chosen node for DOM0 with
> - bootargs
> - rsdp
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/domain_build.c | 41 +
> 1 file changed
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Create a memory node for DOM0.
>
> Signed-off-by: Naresh Bhat
> ---
> xen/arch/arm/domain_build.c | 48
> +
> 1 file changed, 48 insertions(+)
>
> diff --git a/xen/arch/arm/d
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> This patch prepare a DT from scratch for DOM0 for
> ACPI-case only. Basically the DT contains minmal
> required informations such as DOM0 bootargs, memory
> and ACPI RSDP informations only.
>
> Signed-off-by: Naresh Bhat
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
> It needs to parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
>
Ian Campbell writes ("Re: [Xen-devel] [xen-4.5-testing test] 34157: regressions
- FAIL"):
> > > > http://www.chiark.greenend.org.uk/~xensrcts/logs/34157/
...
> > > > test-amd64-amd64-rumpuserxen-amd64 11
> > > > rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 34088
Guest console contains
> -Original Message-
> From: Jiang Liu [mailto:jiang@linux.intel.com]
> Sent: Wednesday, February 4, 2015 9:44 PM
> To: Rafael J. Wysocki; Thomas Gleixner; Bjorn Helgaas; Yinghai Lu; Borislav
> Petkov; Lv Zheng; Tony Luck; Fenghua Yu; Ingo Molnar; H. Peter Anvin;
> x...@kernel.org; Le
On Thu, Feb 05, 2015 at 03:26:00PM +, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] tools: work around collision of -O0 and
> -D_FORTIFY_SOURCE"):
> > For one, PY_XCFLAGS='' wouldn't help, as we get -O0 from the
> > incoming CFLAGS.
>
> Sorry, I meant PY_XCFLAGS='' or -O1 (as appropri
>>> On 05.02.15 at 16:26, wrote:
> Jan Beulich writes ("Re: [PATCH] tools: work around collision of -O0 and
>> And then I'm not really intending to fiddle with
>> the configure scripts (albeit, having done the patch in the presented
>> form, I expected you to want it done that way) - this and ali
On 05/02/15 15:37, Boris Ostrovsky wrote:
> On 02/05/2015 07:41 AM, David Vrabel wrote:
>> Hypercalls submitted by user space tools via the privcmd driver can
>> take a long time (potentially many 10s of seconds) if the hypercall
>> has many sub-operations.
>>
>> A fully preemptible kernel may desc
On 02/05/2015 07:41 AM, David Vrabel wrote:
Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.
A fully preemptible kernel may deschedule such as task in any upcall
called from a hypercal
On Thu, 2015-02-05 at 22:01 +0800, Julien Grall wrote:
> If the user requests a xenheap of 0MB, we will use the default size,
> right? It may be worth to explain this case.
I think it's pretty generally understood that 0 generally means the
default, unless otherwise specified.
> Also with the al
On Thu, 2015-02-05 at 15:27 +, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> > From: Naresh Bhat
> >
> > Parse ACPI SPCR (Serial Port Console Redirection table) table and
> > initialize the serial port pl011.
> >
> > Signed-off-by: Naresh Bhat
> > Signed-of
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Parth Dixit
>
> set edge/level type information for an interrupt
>
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/irq.c| 19 +++
> xen/include/asm-arm/irq.h | 4
> 2 files changed, 23 insertions(+)
>
>
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Parse ACPI SPCR (Serial Port Console Redirection table) table and
> initialize the serial port pl011.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> ---
> xen/arch/arm/setup.c | 6 +
> xen/drive
Jan Beulich writes ("Re: [PATCH] tools: work around collision of -O0 and
-D_FORTIFY_SOURCE"):
> For one, PY_XCFLAGS='' wouldn't help, as we get -O0 from the
> incoming CFLAGS.
Sorry, I meant PY_XCFLAGS='' or -O1 (as appropriate).
> And then I'm not really intending to fiddle with
> the configure
Hi Oleksandr,
On 05/02/2015 21:49, Oleksandr Tyshchenko wrote:
On Thu, Feb 5, 2015 at 3:12 PM, Ian Campbell wrote:
On Wed, 2015-02-04 at 18:47 +0200, Oleksandr Tyshchenko wrote:
Hi, all.
We have begun to use the driver domain on OMAP5 platform.
To make driver domain running on OMAP5 platform
On 05/02/15 15:02, David Vrabel wrote:
> From: Jennifer Herbert
>
> If Xenstore sends back a XS_ERROR for TRANSACTION_END, the driver BUGs
> because it cannot find the matching transaction in the list. For
> TRANSACTION_START, it leaks memory.
>
> Check the message as returned from xenbus_dev_r
From: Jennifer Herbert
If Xenstore sends back a XS_ERROR for TRANSACTION_END, the driver BUGs
because it cannot find the matching transaction in the list. For
TRANSACTION_START, it leaks memory.
Check the message as returned from xenbus_dev_request_and_reply(), and
clean up for TRANSACTION_STAR
Hi Parth,
On 05/02/2015 18:30, Parth Dixit wrote:
On 5 February 2015 at 11:08, Julien Grall wrote:
Hi Parth,
On 04/02/2015 14:02, parth.di...@linaro.org wrote:
From: Parth Dixit
Some bugs are identified in edk2 and some of the functionality is not
yet merged. This patch contains workaroun
On Thu, 2015-02-05 at 14:51 +, Stefano Stabellini wrote:
> On Thu, 5 Feb 2015, Ian Campbell wrote:
> > On Wed, 2015-02-04 at 21:51 +, Julien Grall wrote:
> > > > +res = platform_init_time();
> > >
> > > The platform code is DT-centrict.
> >
> > This is an interesting point. Given the
On 02/05/15 05:17, Jan Beulich wrote:
On 05.02.15 at 00:33, wrote:
>> On 02/04/15 12:01, Jan Beulich wrote:
>>> The former gets enforced by our debug builds, the latter appears to be
>>> not uncommon for certain distros' Python packages. Newer glibc warns on
>>> uses of _FORTIFY_SOURCE withou
On Thu, 5 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-04 at 21:51 +, Julien Grall wrote:
> > > +res = platform_init_time();
> >
> > The platform code is DT-centrict.
>
> This is an interesting point. Given the stated goals and reasons for
> having ACPI on ARM it seems to me that in ge
On Thu, 2015-02-05 at 22:29 +0800, Julien Grall wrote:
> Hi Ian,
>
> On 05/02/2015 19:42, Ian Campbell wrote:
> > On Wed, 2015-02-04 at 21:57 +, Julien Grall wrote:
> >
> >> I believe that most of the SPCR parsing should be generic, so maybe you
> >> could extend the DEVICE interface to handle
Thursday, February 5, 2015, 3:22:49 PM, you wrote:
> Hey David,
> after just being in that pain, I thought I might as well give a summary to
> you/the list. Maybe helpful to not forget which piece should go to which
> stable...
> So:
> v3.16...v3.17.8: Somewhen in between those, the acpi irq s
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
> Using the information presented by GTDT to initialize the arch
> timer (not momery-mapped).
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
>
Jim,
Thought you might like to know that we are now testing actually starting
a guest with libvirt in osstest and this is the first pass.
Currently we don't test migration (which is why that appears to have
failed), but Wei is working on addressing that.
Ian.
On Thu, 2015-02-05 at 14:40 +,
On Thu, 2015-02-05 at 13:00 +, Ian Campbell wrote:
> On Thu, 2015-02-05 at 12:53 +, Jan Beulich wrote:
> > >>> On 05.02.15 at 10:53, wrote:
> > > flight 34157 xen-4.5-testing real [real]
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/34157/
> > >
> > > Regressions :-(
> > >
> >
flight 34168 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34168/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 10 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 10 migrate-sup
Hi Parth,
On 05/02/2015 18:57, Parth Dixit wrote:
On 5 February 2015 at 10:54, Julien Grall wrote:
On 04/02/2015 14:02, parth.di...@linaro.org wrote:
+stao->header.length = sizeof(struct acpi_table_header) + 1;
+stao->header.checksum = 0;
+ACPI_MEMCPY(stao->header.oem_id, "LINARO
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Needed because ARM64 uses GIC which is defined in ACPI 5.0 spec.
>
> Signed-off-by: Al Stone
> Signed-off-by: Hanjun Guo
> Signed-off-by: Naresh Bhat
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 6 ++-
> xen/drivers/a
While experimenting/testing various kernel versions I discovered that trying to
boot a Haswell based hosts will always crash when booting as Xen dom0
(Xen-4.4.1). The same crash happens since v3.19-rc1 and still does happen with
v3.19-rc7. A bare metal boot is having no issues and also an Opteron b
From: "Lad, Prabhakar"
this patch fixes following sparse warning:
interface.c:83:5: warning: symbol 'xenvif_poll' was not declared. Should it be
static?
Signed-off-by: Lad, Prabhakar
---
Found this issue on linux-next (gcc version 4.9.2,
sparse version 0.4.5-rc1)and applies on top linux-n
Hey David,
after just being in that pain, I thought I might as well give a summary to
you/the list. Maybe helpful to not forget which piece should go to which
stable...
So:
v3.16...v3.17.8: Somewhen in between those, the acpi irq seems to have broken.
I have not yet verified tha
1 - 100 of 173 matches
Mail list logo
