On 2015年02月05日 01:45, Stefano Stabellini wrote:
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
From: Naresh Bhat
There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for P
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.
Signed-off-by: Chuansheng Liu
Signed-off-by: Zhang Dongxing
Signed-off-by: xiaomin1
--
From: Takashi Iwai
Date: Wed, 4 Feb 2015 14:38:55 +0100
> Instead of manual calls of device_create_file() and
> device_remove_files(), assign the static attribute groups to netdev
> groups array. This simplifies the code and avoids the possible
> races.
>
> Signed-off-by: Takashi Iwai
Applie
flight 34163 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 33686
build-amd64
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 something we can control, the h/w gu
flight 34157 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels
fail REGR. vs. 3408
On 4 February 2015 at 21:10, Jordan Justen wrote:
> On 2015-02-03 11:20:06, Ard Biesheuvel wrote:
>> This patch adds support to XenBusDxe for executing on ARM and AArch64
>> machines (the former only when built with GCC).
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-
On 05/02/15 05:44, Jiang Liu wrote:
>
> --- a/drivers/xen/xen-acpi-memhotplug.c
> +++ b/drivers/xen/xen-acpi-memhotplug.c
> @@ -117,8 +117,8 @@ acpi_memory_get_resource(struct acpi_resource *resource,
> void *context)
> list_for_each_entry(info, &mem_device->res_list, list) {
>
On Wed, 2015-02-04 at 22:39 -0500, Jintack Lim wrote:
> On Wed, Feb 4, 2015 at 9:55 PM, Jintack Lim wrote:
> > On Wed, Feb 4, 2015 at 11:41 AM, Ian Campbell
> > wrote:
> >>
> >> Patch for all this below. Jan, I don't think there is any (possibly
> >> historical on x86_32) x86 option we should be
On Wed, 2015-02-04 at 16:51 +, Jan Beulich wrote:
> >>> On 04.02.15 at 17:41, wrote:
> > I originally used to think that domheap allocations would fall back to
> > the xenheap if the domheap was exhausted, but I think I was mistaken in
> > that.
>
> That's an arch choice actually - there are
>>> 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 without optimization being enabled, which with
>>
Yes, it does. I waiting for the patches to land upstream before
backporting them. Please ping me about it, if I forget :-)
On Wed, 4 Feb 2015, Don Slutz wrote:
> This looks like:
>
> https://bugs.launchpad.net/qemu/+bug/1414222
>
> Patch "fix qemu crash about vnc" is still pending.
>-Don Slu
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Initialization of cpu_logical_map(0) before acpi_boot_init()
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Naresh Bhat
> ---
> xen/arch/arm/setup.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/xen/arc
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> Introduce acpi_parse_entries
>
> Signed-off-by: Naresh Bhat
> ---
> xen/drivers/acpi/tables.c | 64
> +++
> xen/include/xen/acpi.h| 4 +++
> 2 files changed, 68 insertion
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 workarounds for them
>
>
> While I understand
On 5 February 2015 at 11:01, Julien Grall wrote:
> Hi Parth,
>
> On 04/02/2015 14:02, parth.di...@linaro.org wrote:
>>
>> From: Parth Dixit
>>
>> efi should be enabled to fetch the root pointer from uefi
>>
>> Signed-off-by: Parth Dixit
>> ---
>> xen/common/efi/runtime.c | 6 ++
>> 1 file
On Tue, 2015-01-20 at 13:47 +0100, Roger Pau Monné wrote:
> Hello,
>
> I should probably have done this earlier because I've been aware of this
> issue for a long time (since I've started dealing with the PV blk protocol).
>
> The current way to describe PV protocols in Xen is very inefficient
>
On 5 February 2015 at 10:59, Julien Grall wrote:
> Hi Parth,
>
> As for the STAO table, this is not only mapping but also creating the table.
>
> On 04/02/2015 14:02, parth.di...@linaro.org wrote:
>>
>> From: Parth Dixit
>>
>> xen environment table contains the grant table address,size and event
... and make it tunable via the command line.
1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
which is a lot. 1/32 of RAM seems more reasonable. Also drop the
minimum to 32M.
Leave the maximum at 1GB.
Signed-off-by: Ian Campbell
Cc: Jintack Lim
Cc: Jan Beulich
---
v2:
- Use
On 5 February 2015 at 10:54, Julien Grall wrote:
> Hi Parth,
>
> You don't only map the status override table. You also create it.
> I would update the commit title to reflect it.
>
Sure, will take care in next patchset
> On 04/02/2015 14:02, parth.di...@linaro.org wrote:
>>
>> From: Parth Dixit
On 04/02/15 09:51, Jan Beulich wrote:
On 04.02.15 at 10:04, wrote:
>> On 03/02/2015 17:14, Daniel Kiper wrote:
>>> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
>>> On 30.01.15 at 18:54, wrote:
> - xen.efi build will not so strongly depend
> on a given GCC an
On Wed, 2015-02-04 at 17:36 +, Julien Grall wrote:
> I remembered to have a discussion about this change with Naresh few
> month ago.
>
> __va should only be used when the memory is direct-mapped to Xen (i.e
> accessible directly). On ARM64, this only the case for the RAM. Can you
> confirm
> -Original Message-
> From: Don Slutz [mailto:dsl...@verizon.com]
> Sent: 04 February 2015 21:42
> To: Paul Durrant; Ian Campbell
> Cc: Wei Liu; Andrew Cooper; xen-devel@lists.xen.org; Stefano Stabellini; Jan
> Beulich; Ian Jackson
> Subject: Re: [Xen-devel] Stubdom breakage in 4.5
>
> On
On Wed, 2015-02-04 at 21:03 +, Julien Grall wrote:
> > -/* Masks for FADT Boot Architecture Flags (boot_flags) */
> > +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags)
> > [Vx]=Introduced in this FADT revision */
>
> What does "this FADT revision" means? Please be more specific by
Wei Liu writes ("Re: [PATCH OSSTEST v6 9/9] mfi-common, make-flight: create XSM
test jobs"):
> Here is the updated version:
> ---8<---
> >From 5b40b06a62ef51ad511e36bf6eb12f3e9e88a647 Mon Sep 17 00:00:00 2001
> From: Wei Liu
> Date: Mon, 2 Feb 2015 19:57:13 +
> Subject: [PATCH OSSTEST v6] mfi
Jan Beulich writes ("[PATCH] tools: work around collision of -O0 and
-D_FORTIFY_SOURCE"):
> 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 without optimization being enabled,
On Wed, 2015-02-04 at 17:45 +, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> > From: Naresh Bhat
> >
> > There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> > the former signals to the OS that the hardware is PSCI compliant.
> > The latter selec
branch xen-unstable
xen branch xen-unstable
job build-amd64-rumpuserxen
test xen-build
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen
Tree: rumpuserxen_b
>>> On 05.02.15 at 12:08, wrote:
> Jan Beulich writes ("[PATCH] tools: work around collision of -O0 and
> -D_FORTIFY_SOURCE"):
>> 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_S
>>> On 04.02.15 at 18:36, wrote:
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size
>> size)
>> return __va(phys);
>> return __vmap(&pfn, PFN_UP(offs + size), 1, 1,
>> PA
>>> On 05.02.15 at 12:04, wrote:
> On Wed, 2015-02-04 at 17:36 +, Julien Grall wrote:
>> I would move the whole function (acpi_os_map_memory) per-architecture.
>
> That's an option too, since once the "/* The low first Mb is always
> mapped. */" bit is removed (which it should be since it is
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 general nothing under
xen/arch/arm/platforms/* should ev
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 the ACPI case.
Extending DT_DEVICE would be confusing IMHO. The answer is probably a
similar but parallel ACPI_DEVICE mec
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?
Signed-off-by: Lad, Prabhakar
---
Found this issue on linux-next (gcc version 4.9.2,
sparse version 0.4.5-rc
>>> On 04.02.15 at 19:47, wrote:
> On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
>> +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
>
> ARM already has cpu_possible_map. x86 seems to be able to cope with
> having ACPI without this map.
>
> If you want to introduce it, you s
On Thu, 2015-02-05 at 16:27 +0530, Parth Dixit wrote:
> >> +stao->header.length = sizeof(struct acpi_table_header) + 1;
> >> +stao->header.checksum = 0;
> >> +ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> >> +ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> >
> >
> > I th
Le 2015-02-04 10:51, "Jan Beulich" a écrit :
>
> >>> On 04.02.15 at 10:04, wrote:
> > On 03/02/2015 17:14, Daniel Kiper wrote:
> >> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
> >> On 30.01.15 at 18:54, wrote:
> - xen.efi build will not so strongly depend
> o
On Thu, 2015-02-05 at 11:34 +, Jan Beulich wrote:
> >> @@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port,
> >> u32 value, u32 width)
> >>
> >>return AE_OK;
> >> }
> >> +#endif
> >
> > Why only x86? Linux seems to define it also for ARM64.
>
> What is a port on ARM
On Thu, 2015-02-05 at 11:35 +, Jan Beulich wrote:
> >>> On 05.02.15 at 12:04, wrote:
> > On Wed, 2015-02-04 at 17:36 +, Julien Grall wrote:
> >> I would move the whole function (acpi_os_map_memory) per-architecture.
> >
> > That's an option too, since once the "/* The low first Mb is alwa
>>> On 05.02.15 at 06:31, wrote:
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>> #ifndef COMPAT
>>
>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>
> This comment seems irrelevant now.
>
>>
>>> On 05.02.15 at 12:50, wrote:
> Le 2015-02-04 10:51, "Jan Beulich" a écrit :
>>
>> >>> On 04.02.15 at 10:04, wrote:
>> > On 03/02/2015 17:14, Daniel Kiper wrote:
>> >> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
>> >> On 30.01.15 at 18:54, wrote:
>> - xen.efi buil
>>> On 05.02.15 at 12:57, wrote:
> On Thu, 2015-02-05 at 11:35 +, Jan Beulich wrote:
>> >>> On 05.02.15 at 12:04, wrote:
>> > On Wed, 2015-02-04 at 17:36 +, Julien Grall wrote:
>> >> I would move the whole function (acpi_os_map_memory) per-architecture.
>> >
>> > That's an option too, si
This needs
From: Wang, Xiaoming
at the top of the message to comply with real name policy for patches.
On Fri, 2015-02-06 at 07:01 +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.
> S
On Thu, 2015-02-05 at 11:58 +, Jan Beulich wrote:
> >>> On 05.02.15 at 06:31, wrote:
> >> --- a/xen/common/efi/runtime.c
> >> +++ b/xen/common/efi/runtime.c
> >> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
> >> #ifndef COMPAT
> >>
> >> #ifdef CONFIG_ARM /* Disabled until runtime s
>>> On 05.02.15 at 11:52, wrote:
> ... and make it tunable via the command line.
>
> 1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
> which is a lot. 1/32 of RAM seems more reasonable. Also drop the
> minimum to 32M.
>
> Leave the maximum at 1GB.
>
> Signed-off-by: Ian Campbel
On Mon, Feb 2, 2015 at 6:19 PM, Ian Campbell wrote:
> On Thu, 2015-01-29 at 22:46 +0100, Tamas K Lengyel wrote:
>> From: Razvan Cojocaru
>>
>> The public mem_event structures used to communicate with helper applications
>> via
>> shared rings have been used in different settings. However, the va
On Tue, Feb 3, 2015 at 10:17 AM, Jan Beulich wrote:
On 02.02.15 at 18:19, wrote:
>> On Thu, 2015-01-29 at 22:46 +0100, Tamas K Lengyel wrote:
>>> +union {
>>> +struct mem_event_paging_datamem_paging;
>>> +struct mem_event_sharing_data mem_sha
On Tue, 2015-02-03 at 12:45 +0100, Olaf Hering wrote:
> When building stubdom the mini-os objects are also linked into the
> binary. Unfortunately the linker will place them in the order found in
> the archive. Since this order is random the resulting stubdom binary
> differs when it was built from
On Thu, 2015-02-05 at 11:18 +, Jan Beulich wrote:
> >>> On 05.02.15 at 12:08, wrote:
> > Jan Beulich writes ("[PATCH] tools: work around collision of -O0 and
> > -D_FORTIFY_SOURCE"):
> >> The former gets enforced by our debug builds, the latter appears to be
> >> not uncommon for certain dist
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 34167 linux-3.16 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34167/
Failures :-/ but no
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 hypercall continuation.
However, in a kernel with vol
On Wed, 2015-02-04 at 15:05 +0200, Oleksandr Tyshchenko wrote:
All acked + applied, thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, 2015-02-02 at 08:17 -0700, Mike Latimer wrote:
> On Monday, February 02, 2015 02:35:39 PM Ian Campbell wrote:
> > On Fri, 2015-01-30 at 14:01 -0700, Mike Latimer wrote:
> > > During domain startup, all required memory ballooning must complete
> > > within a maximum window of 33 seconds (3 r
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 modifies the documentation in code as to why we
> want this. The no krobe thing i
On Wed, 2015-02-04 at 16:26 +, Wei Liu wrote:
> On Wed, Feb 04, 2015 at 04:07:48PM +, Jan Beulich wrote:
> > Both vchan_wr() and stdout_wr() should be defined with a non-empty
> > argument list (i.e. void). Additionally both of them as well as usage()
> > should be static to make clear that
On Wed, 2015-02-04 at 19:13 +0200, Denis Drozdov wrote:
> From: denys drozdov
>
> This is a requirement of the scheduler interface, violating this
> causes for example with the RT scheduler:
>
> (XEN) Assertion 'local_irq_is_enabled()' failed at spinlock.c:137
> (XEN) [ Xen-4.5.0 arm32 deb
On Thu, Feb 5, 2015 at 2:46 PM, Ian Campbell wrote:
> On Wed, 2015-02-04 at 15:05 +0200, Oleksandr Tyshchenko wrote:
>
> All acked + applied, thanks!
>
>
Thanks to you and Julien for detailed review.
--
Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com
_
>>> 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 :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-rumpuserxen-amd64 11 rumpuser
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 :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests whi
flight 34165 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
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 we need to have it
> memory 1 to 1 mapped because of lacking SMMU support on this platform.
> To satisfy this re
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
> From: Naresh Bhat
>
> With ACPI 5.0, we got per-processor timer support in GTDT,
> and ACPI 5.1 introduced the support for platform (memory-mapped)
> timers: GT Block and SBSA watchdog timer, add the code needed
> in this patch.
>
> Signed-off-
Hi, Ian
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 we need to have it
>> memory 1 to 1 mapped be
On Thu, Feb 05, 2015 at 01:38:07PM +, Lad Prabhakar wrote:
> 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
Acked-by: Wei Liu
Thanks!
>
Hi Ian,
On 05/02/2015 18:52, Ian Campbell wrote:
... and make it tunable via the command line.
1/8 of RAM is 128M on a 1GB system and 256M on a 2GB system etc,
which is a lot. 1/32 of RAM seems more reasonable. Also drop the
minimum to 32M.
Leave the maximum at 1GB.
Signed-off-by: Ian Campbel
Hi Ian,
On 05/02/2015 19:04, Ian Campbell wrote:
On Wed, 2015-02-04 at 17:36 +, Julien Grall wrote:
I remembered to have a discussion about this change with Naresh few
month ago.
__va should only be used when the memory is direct-mapped to Xen (i.e
accessible directly). On ARM64, this only
Hi all,
I just wanted to confirm that Wei has been confirmed with 4 votes in favour,
and 2 committers not having voted
Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Ian,
On 05/02/2015 19:06, Ian Campbell wrote:
On Wed, 2015-02-04 at 21:03 +, Julien Grall wrote:
-/* Masks for FADT Boot Architecture Flags (boot_flags) */
+/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced
in this FADT revision */
What does "this FADT revis
Hi Ian,
On 05/02/2015 19:06, Ian Campbell wrote:
On Wed, 2015-02-04 at 21:03 +, Julien Grall wrote:
-/* Masks for FADT Boot Architecture Flags (boot_flags) */
+/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced
in this FADT revision */
What does "this FADT revis
>> +int monitor_domctl(struct xen_domctl_monitor_op *domctl, struct domain *d)
>> +{
>> +/*
>> + * At the moment only HVM domains are supported. However, event delivery
>> + * could be extended to PV domains. See comments below.
>> + */
>> +if ( !is_hvm_domain(d) )
>> +r
On Tue, Feb 3, 2015 at 4:37 PM, Jan Beulich wrote:
On 29.01.15 at 22:46, wrote:
>> -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS2
>> +#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR2
>
> While this one looks okay, ...
>
>> -#define XEN_DOMCTL_MEM_EVENT_OP_AC
Hi Ian,
On 05/02/2015 19:39, Ian Campbell wrote:
On Wed, 2015-02-04 at 21:51 +, Julien Grall wrote:
Perhaps platform_* should all grow an "ASSERT(!in acpi mode)" (or
"ASSERT(in dt mode)") to help enforce this.
That would be good. We could also do the same for the device tree to
catch any
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 the ACPI case.
Extending DT_DEVICE would be confusing IMHO. The answer i
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
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
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
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
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
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
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 :-(
> > >
> >
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 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
>
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 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
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 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, 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
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
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
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
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
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
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
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 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 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 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 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 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
1 - 100 of 173 matches
Mail list logo
