>>> On 17.11.15 at 18:53, wrote:
> On 17/11/15 17:39, Jan Beulich wrote:
> On 17.11.15 at 18:30, wrote:
>>> On 17/11/15 17:04, Jan Beulich wrote:
>>> On 03.11.15 at 18:58, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -178,6 +178,10 @@ struct a
Hi Arnd,
On 2015/11/17 17:50, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 17:40:03 shannon.z...@linaro.org wrote:
>> +/*
>> + * Emulate x86 io ports for arm.
>> + */
>> +#define __armio(addr) ( (void __iomem *)addr )
>> +
>> +#define inb(c) ( readb( __armio(c) ) )
>> +#define inw(c) ( readw
On 2015/11/18 0:46, David Vrabel wrote:
> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
>> scan this to get the UEFI information.
> [...]
>> --- a/Documentation/devicetree/bindings/arm/xen.txt
On 2015/11/17 20:17, Ard Biesheuvel wrote:
> On 17 November 2015 at 12:37, Mark Rutland wrote:
>> On Tue, Nov 17, 2015 at 12:25:58PM +0100, Ard Biesheuvel wrote:
>>> On 17 November 2015 at 10:57, wrote:
From: Shannon Zhao
Add a new function to parse DT parameters for Xen specific
On 2015/11/18 4:44, Rob Herring wrote:
> On Tue, Nov 17, 2015 at 05:57:05PM +0800, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
>> scan this to get the UEFI information.
>>
>> Signed-off-by: Shannon Zhao
>> ---
On 2015/11/18 0:32, David Vrabel wrote:
> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> Add a bus_notifier for platform bus device in order to map the device
>> mmio regions when DOM0 booting with ACPI.
> [...]
>> --- /dev/null
>> +++ b/drivers/xen/platform.c
>> @@
On Tue, Nov 17, 2015 at 05:57:05PM +0800, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> Signed-off-by: Shannon Zhao
> ---
> Documentation/devicetree/bindings/arm/xen.
On 2015/11/17 22:40, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:57:04PM +0800, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> Add a bus_notifier for AMBA bus device in order to map the device
>> mmio regions when DOM0 booting with ACPI.
>>
>> Signed-off-by: Shannon Zhao
>>> On 11/16/2015 at 06:01 PM, in message <5649a988.7010...@citrix.com>, George
Dunlap wrote:
> On 13/11/15 11:19, Olaf Hering wrote:
> > On Wed, Oct 21, Chunyan Liu wrote:
> >
> >> Add pvusb APIs, including:
> >
> >> @@ -635,6 +664,8 @@ libxl_domain_config = Struct("domain_config", [
>
On 2015/11/17 22:38, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:57:03PM +0800, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> Add a bus_notifier for platform bus device in order to map the device
>> mmio regions when DOM0 booting with ACPI.
>>
>> Signed-off-by: Shannon Z
On 2015/11/18 0:02, David Vrabel wrote:
> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> Move xlated_setup_gnttab_pages to common place, so it can be reused by
>> ARM to setup grant table when booting with ACPI.
> [...]
>> --- a/drivers/xen/grant-table.c
>> +++ b/dri
On 2015/11/17 20:02, Julien Grall wrote:
> I'm nearly sure I already said it, this code already exists in the tree.
> Why do you need to implement a new version?
Ok, it needs to move the functions to the public place, right? So they
can be called from other places.
Thanks,
--
Shannon
__
On 2015/11/17 19:57, Julien Grall wrote:
> Hi Shannon,
>
> On 17/11/15 09:40, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> When preparing EFI tables for Dom0, it needs the information of EFI
>> system table. Here store it in efi structure.
>
> On ARM64 the EFI stub is completely in
On 2015/11/17 22:23, Julien Grall wrote:
> Hi Shannon,
>
> On 17/11/15 12:45, Shannon Zhao wrote:
>>
>>
>> On 2015/11/17 19:58, Julien Grall wrote:
>>> Hi Shannon,
>>>
>>> On 17/11/15 09:40, shannon.z...@linaro.org wrote:
From: Shannon Zhao
EFI table, memory description table and s
flight 64483 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64483/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf bd3afeb1d62c68d8144d39e82bb188b2af3ca60c
baseline version:
ovmf a2e619821a791de5cd65cd2c757de0a8aa7
On 2015/11/17 22:25, Julien Grall wrote:
> On 17/11/15 13:21, Shannon Zhao wrote:
>>> AFAICT, it does only works for SPCR table used for UART device. For the
>>> GIC you've hardcoded the value and I can't find any version number in
>>> the table.
>>>
>> No, I didn't hardcode the GIC version. Sinc
On 2015/11/17 21:57, Julien Grall wrote:
> On 17/11/15 12:32, Shannon Zhao wrote:
>> > Hi Julien,
>> >
>> > On 2015/11/17 19:27, Julien Grall wrote:
>>> >> Hi Shannon,
>>> >>
>>> >> Why do you want to revert this patch?
>>> >>
>> > Because d->arch.vgic.cbase will be used by creating Dom0 MADT ta
This run is configured for baseline tests only.
flight 38300 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build
Joao Martins wrote:
>
> On 11/17/2015 02:48 AM, Jim Fehlig wrote:
>> On 11/13/2015 06:14 AM, Joao Martins wrote:
>>> Introduce support for domainInterfaceStats API call for querying
>>> network interface statistics. Consequently it also enables the
>>> use of `virsh domifstat ` command.
>>>
>>> A
flight 64456 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62642
Tests which are failin
Joao Martins wrote:
> Introduce support for domainMemoryStats API call, which
> consequently enables the use of `virsh dommemstat` command to
> query for memory statistics of a domain. We support
> the following statistics: balloon info, available and currently
> in use. swap-in, swap-out, major-fa
flight 64451 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64451/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-amd64-pvgrub 3 host-install(3) broken in 63294 pass in 64451
test-amd64-i386-xl-qemut-stubdom-debi
This run is configured for baseline tests only.
flight 38301 linux-3.10 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38301/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build
On 11/17/2015 11:35 AM, Neil Sikka wrote:
How does Linda's work relate to Wei's patches available here (I didnt
see them in Xen-4.6.0):
http://downloads.xen.org/Wiki/VirtioOnXen/qemu-01-xenpv-exec.patch
http://downloads.xen.org/Wiki/VirtioOnXen/qemu-02-virtio-for-pv.patch
I'll let Wei answer
On 11/17/2015 02:37 PM, Boris Ostrovsky wrote:
On 11/17/2015 02:16 PM, Andy Lutomirski wrote:
Looks good to me. Does Xen have any sysexit/sysret32 equivalent to
return to 32-bit user mode? If so, it could be worth trying to wire
it up by patching the jz instead of the test instruction.
We ca
On 11/17/2015 02:16 PM, Andy Lutomirski wrote:
Looks good to me. Does Xen have any sysexit/sysret32 equivalent to
return to 32-bit user mode? If so, it could be worth trying to wire
it up by patching the jz instead of the test instruction.
We can actually make patching a little bit more effic
On Tue, Nov 17, 2015 at 11:29 AM, Andrew Cooper
wrote:
> On 17/11/15 19:16, Andy Lutomirski wrote:
>> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
>> wrote:
>>> On 17/11/15 18:49, Andy Lutomirski wrote:
On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
wrote:
> On 11/16/2015 04:55 PM,
On 17/11/15 19:16, Andy Lutomirski wrote:
> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
> wrote:
>> On 17/11/15 18:49, Andy Lutomirski wrote:
>>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
>>> wrote:
On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
> On 11/16/15 12:22, Borislav Petkov
On Tue, Nov 17, 2015 at 11:16:11AM -0800, Andy Lutomirski wrote:
> Works for me, too, although seeing "xen_pv_host" in the Linux cpu
> features would be very strange indeed :)
That feature would be, of course, *not* in /proc/cpuinfo.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails wh
On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
wrote:
> On 17/11/15 18:49, Andy Lutomirski wrote:
>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
>> wrote:
>>> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
On 11/16/15 12:22, Borislav Petkov wrote:
> Huh, so what's wrong with a jump:
On 17/11/15 18:49, Andy Lutomirski wrote:
> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" wrote:
>> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
>>> On 11/16/15 12:22, Borislav Petkov wrote:
Huh, so what's wrong with a jump:
jmp 1f
swapgs
1:
>>>
On 17/11/15 18:44, Roger Pau Monne wrote:
> This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:
>
> Xen always set the FPU as initialized when loading a HVM context, so libxc
> has to provide a valid FPU context when setting the CPU registers.
>
> This is a stop-gap measure in order to un
On 17/11/15 18:44, Roger Pau Monne wrote:
> Introduce a new filed to signal if the FPU has been initialised or not. Xen
field
> needs this new filed in order to know whether to set the FPU as initialised
> or not during restore of CPU context. Previously Xen always wrongly assumed
> the FPU was i
On 17/11/15 18:44, Roger Pau Monne wrote:
> In order to cope with types having multiple compat versions pass a parameter
> to the fixup function so we can identify which compat version Xen is dealing
> with.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Jan Beulic
On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" wrote:
>
> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
>>
>> On 11/16/15 12:22, Borislav Petkov wrote:
>>>
>>> Huh, so what's wrong with a jump:
>>>
>>> jmp 1f
>>> swapgs
>>> 1:
>>>
>> What is the point of that jump?
>>
If i
On 17/11/15 18:09, Julien Grall wrote:
> (Resending with this time xen-devel in CC)
>
> Hi,
>
> On ARM, it's possible to fail when removing a page from the P2M. It's
> happening if we are trying to shatter a superpage and we don't have
> memory to allocate the table. Therefore the mapping won't be
This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:
Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.
This is a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix
Introduce a new filed to signal if the FPU has been initialised or not. Xen
needs this new filed in order to know whether to set the FPU as initialised
or not during restore of CPU context. Previously Xen always wrongly assumed
the FPU was initialised on restore.
Signed-off-by: Roger Pau Monné
Cc
Hello,
This patch series tries to properly solve the problem seen with the HVMlite
series, that Xen always assumes the FPU is initialised on CPU context
restore.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
In order to cope with types having multiple compat versions pass a parameter
to the fixup function so we can identify which compat version Xen is dealing
with.
Signed-off-by: Roger Pau Monné
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Tim Deegan
---
xen/include/public/arch-x86/hvm/s
How does Linda's work relate to Wei's patches available here (I didnt see
them in Xen-4.6.0):
http://downloads.xen.org/Wiki/VirtioOnXen/qemu-01-xenpv-exec.patch
http://downloads.xen.org/Wiki/VirtioOnXen/qemu-02-virtio-for-pv.patch
Also, since 9p is being worked on, which is a filesystem that shou
(Resending with this time xen-devel in CC)
Hi,
On ARM, it's possible to fail when removing a page from the P2M. It's
happening if we are trying to shatter a superpage and we don't have
memory to allocate the table. Therefore the mapping won't be removed
from the P2M.
However on ARM (and until re
On 17/11/15 17:39, Jan Beulich wrote:
On 17.11.15 at 18:30, wrote:
>> On 17/11/15 17:04, Jan Beulich wrote:
>> On 03.11.15 at 18:58, wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -178,6 +178,10 @@ struct active_grant_entry {
#define _active_
>>> On 17.11.15 at 18:30, wrote:
> On 17/11/15 17:04, Jan Beulich wrote:
> On 03.11.15 at 18:58, wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -178,6 +178,10 @@ struct active_grant_entry {
>>> #define _active_entry(t, e) \
>>> ((t)->active[(e)/ACGNT
>>> On 28.10.15 at 04:21, wrote:
> --- a/xen/include/asm-x86/div64.h
> +++ b/xen/include/asm-x86/div64.h
Considering you don't even do this in common code, why did you pick
the BITS_PER_LONG == 32 variants from Linux? Would make for
quite a bit smaller a patch and quite a bit better easier to rea
On Tue, Nov 17, 2015 at 05:34:36PM +, Marc Zyngier wrote:
> On 17/11/15 17:29, Will Deacon wrote:
> > On Tue, Nov 10, 2015 at 02:11:38PM +, Stefano Stabellini wrote:
> >> On Thu, 5 Nov 2015, Stefano Stabellini wrote:
> >>> Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
> >
On 17/11/15 17:29, Will Deacon wrote:
> On Tue, Nov 10, 2015 at 02:11:38PM +, Stefano Stabellini wrote:
>> On Thu, 5 Nov 2015, Stefano Stabellini wrote:
>>> Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
>>> Necessary duplication of paravirt.h and paravirt.c with ARM.
>>>
>>>
On 17/11/15 17:04, Jan Beulich wrote:
On 03.11.15 at 18:58, wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -178,6 +178,10 @@ struct active_grant_entry {
>> #define _active_entry(t, e) \
>> ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>>
>> +b
On Tue, Nov 10, 2015 at 02:11:38PM +, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Stefano Stabellini wrote:
> > Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
> > Necessary duplication of paravirt.h and paravirt.c with ARM.
> >
> > The only paravirt interface supported is
No change to the output of standalone-generate-dump-flight-runvars
The inlined xenbranch vs arch filters remain where they are since they
are common (in that they reflect the addition and removal of arches)
and apply equally to all make-*-flight.
Signed-off-by: Ian Campbell
---
make-flight | 3
It is not useful to try and drop jobs based on scrobbling around in
the standalone history.
This makes it possible to "./standalone make-flight
xen-unstable-smoke" and fixes standalone-generate-dump-flight-runvars
Signed-off-by: Ian Campbell
---
mg-adjust-flight-makexrefs | 7 +++
1 file ch
test_matrix_branch_filter_callback was recently updated to exclude
testing of linux-3.10 (54f237784d4b) and 3.14 (b0c5663a03e7), however
this only excludes test and not build jobs so we were still trying to
build the arm kernel there.
This changes the build job filtering to be in sync with the tes
I just got tripped up again by putting a build job filter definition
after the call to create_build_jobs. Reorder the make-*flight scripts
to reduce the probability of me doing so any more times.
The general order of these scripts is now:
- job filter callbacks
- test job creation
- top-leve
Currently we have a test_matrix_branch_filter_callback which filters
jobs based on the $xenarch and $branch and a separate more adhoc
filter inline for the build jobs.
This has lead to things getting out of sync in the past (e.g. recently
we dropped armhf tests from the linux-3.10 and -3.14 branch
The mechanisms for omitting certain archs from jobs are inconsistently
applied to build vs test jobs.
This series tries to tidy that up somewhat.
I've check the output of standalone-generate-dump-flight-runvars at each
step (i.e. covering the main make-flight).
I also did a before and after the
>>> On 03.11.15 at 18:58, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -178,6 +178,10 @@ struct active_grant_entry {
> #define _active_entry(t, e) \
> ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>
> +bool_t grant_rwlock_barrier;
> +
> +DEFINE_PER_
>>> On 03.11.15 at 18:58, wrote:
> Per-cpu read-write locks allow for the fast path read case to have low
> overhead
> by only setting/clearing a per-cpu variable for using the read lock.
> The per-cpu read fast path also avoids locked compare swap operations which
> can
> be particularly slow o
On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
[...]
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xe
There are mixed usage of libxl__sprintf(gc) and GCSPRINTF. Convert all
libxl__sprintf to GCSPRINTF to make code base consistent.
Wei Liu (2):
libxl: convert libxl__sprintf(gc) to GCSPRINTF
libxl: fix line wrapping issues introduced by automatic replacement
tools/libxl/libxl.c| 22
>>> On 17.11.15 at 17:24, wrote:
> On 17/11/15 10:26, Jan Beulich wrote:
> On 16.11.15 at 18:45, wrote:
>>> Furthermore, it is unclear (given the unwritten ABI) whether it is even
>>> safe to move _PAGE_GNTTAB out of the way, as this is visible to a PV guest.
>> It seems pretty clear to me th
On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a bus_notifier for AMBA bus device in order to map the device
> mmio regions when DOM0 booting with ACPI.
[...]
> +static int xen_map_amba_device_mmio(struct amba_device *adev)
> +{
> + int rc = 0;
> + struct r
The rune used is:
sed -i 's/libxl__sprintf(gc,\s*/GCSPRINTF(/g' libxl*.c
This rune is simple and better than trying to match every possible
patterns.
Two instances in libxl_dm.c need fixing up. They are in fact better to just
use libxl__strdup.
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c
On 17/11/15 10:26, Jan Beulich wrote:
On 16.11.15 at 18:45, wrote:
>> Furthermore, it is unclear (given the unwritten ABI) whether it is even
>> safe to move _PAGE_GNTTAB out of the way, as this is visible to a PV guest.
> It seems pretty clear to me that this would be unsafe: It being
> part
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c | 55 ++-
tools/libxl/libxl_dm.c | 57 ++---
tools/libxl/libxl_pci.c | 33 ++--
3 files changed, 66 insertions(+), 79 deletions(-)
d
On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a bus_notifier for platform bus device in order to map the device
> mmio regions when DOM0 booting with ACPI.
[...]
> --- /dev/null
> +++ b/drivers/xen/platform.c
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (c) 2015, Lin
On 17/11/15 16:36, Boris Ostrovsky wrote:
> After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
> allocating descs for legacy IRQs") early_irq_init() will no longer
> preallocate descriptors for legacy interrupts if PIT does not
> exist.
>
> Therefore we need to allocate those descr
On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Move xlated_setup_gnttab_pages to common place, so it can be reused by
> ARM to setup grant table when booting with ACPI.
[...]
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -664,6 +664,55 @@ int
flight 64568 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64568/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
>>> On 03.11.15 at 09:43, wrote:
> Add the utility to dump the posted format IRTE.
>
> CC: Yang Zhang
> CC: Kevin Tian
> Signed-off-by: Feng Wu
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
On Tue, Nov 17, 2015 at 03:32:18PM +, Ian Campbell wrote:
> On Tue, 2015-11-17 at 15:24 +, Wei Liu wrote:
> > On Tue, Nov 17, 2015 at 03:21:39PM +, Ian Campbell wrote:
> > > On Tue, 2015-11-17 at 15:16 +, Wei Liu wrote:
> > > > On Tue, Nov 17, 2015 at 03:08:47PM +, Wei Liu wrote
flight 38299 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail REGR. vs.
38263
On Tue, 2015-11-17 at 15:24 +, Wei Liu wrote:
> On Tue, Nov 17, 2015 at 03:21:39PM +, Ian Campbell wrote:
> > On Tue, 2015-11-17 at 15:16 +, Wei Liu wrote:
> > > On Tue, Nov 17, 2015 at 03:08:47PM +, Wei Liu wrote:
> > > > The rune is
> > > >
> > > > sed -i 's/libxl__sprintf(gc,\
On Tue, Nov 17, 2015 at 03:34:30PM +, David Vrabel wrote:
> On 17/11/15 15:08, Wei Liu wrote:
> > There are mixed usage of libxl__sprintf(gc) and GCSPRINTF. Convert all
> > libxl__sprintf to GCSPRINTF.
>
> This looks like pointless churn /and/ GCSPRINTF is /less/ readable than
> libxl__sprintf
On 17/11/15 15:36, Boris Ostrovsky wrote:
> After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
> allocating descs for legacy IRQs") early_irq_init() will no longer
> preallocate descriptors for legacy interrupts if PIT does not
> exist.
>
> Therefore we need to allocate those descr
>>> On 10.11.15 at 08:33, wrote:
> Thanks for your effort on this series and kindly ping..
Well - now that I got to look at the state of the series, the primary
problem with some more of it to go in than the two patches I pushed
earlier today is that there are VT-d/VMX maintainer acks missing.
An
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIT does not
exist.
Therefore we need to allocate those descriptors for PV guests
ourselves.
Signed-off-by: Boris
On 17/11/15 15:08, Wei Liu wrote:
> There are mixed usage of libxl__sprintf(gc) and GCSPRINTF. Convert all
> libxl__sprintf to GCSPRINTF.
This looks like pointless churn /and/ GCSPRINTF is /less/ readable than
libxl__sprintf(gc,...) because the reader now has to also look up what
GCSPRINTF does.
flight 64450 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64450/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 64290
Regressions which
On Tue, Nov 17, 2015 at 03:21:39PM +, Ian Campbell wrote:
> On Tue, 2015-11-17 at 15:16 +, Wei Liu wrote:
> > On Tue, Nov 17, 2015 at 03:08:47PM +, Wei Liu wrote:
> > > The rune is
> > >
> > > sed -i 's/libxl__sprintf(gc,\s*\(".*",.*\)/GCSPRINTF(\1/g' libxl*.c
> > >
> >
> > Hmm...
On Tue, 2015-11-17 at 15:16 +, Wei Liu wrote:
> On Tue, Nov 17, 2015 at 03:08:47PM +, Wei Liu wrote:
> > The rune is
> >
> > sed -i 's/libxl__sprintf(gc,\s*\(".*",.*\)/GCSPRINTF(\1/g' libxl*.c
> >
>
> Hmm... It looks like this rune alone doesn't cover all situations.
>
> $ ack-grep '
On Tue, Nov 17, 2015 at 03:08:47PM +, Wei Liu wrote:
> The rune is
>
> sed -i 's/libxl__sprintf(gc,\s*\(".*",.*\)/GCSPRINTF(\1/g' libxl*.c
>
Hmm... It looks like this rune alone doesn't cover all situations.
$ ack-grep 'libxl__sprintf\(gc' | wc -l
43
Let me see if I can refine it a bi
There are mixed usage of libxl__sprintf(gc) and GCSPRINTF. Convert all
libxl__sprintf to GCSPRINTF.
Wei Liu (2):
libxl: replace libxl__sprintf(gc, ...) with GCSPRINTF
libxl: fix line wrapping issues introduced by sed
tools/libxl/libxl.c| 181 --
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c| 21 ++---
tools/libxl/libxl_dm.c | 29 -
2 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9f52cc2..2f2ce45 100644
--- a/tools/libxl/libxl
The rune is
sed -i 's/libxl__sprintf(gc,\s*\(".*",.*\)/GCSPRINTF(\1/g' libxl*.c
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c| 170 -
tools/libxl/libxl_blktap2.c| 4 +-
tools/libxl/libxl_bootloader.c | 10 +--
tools/libxl/libxl_creat
Ping?
None of the discussion on this thread altered the contents of this
patch, and the bug is still present.
~Andrew
On 03/06/15 10:31, Andrew Cooper wrote:
> There appears to be no formal statement of what pv_irq_ops.save_fl() is
> supposed to return precisely. Native returns the full flags,
pte_update_defer can be removed as it is always set to the same
function as pte_update. So any usage of pte_update_defer() can be
replaced by pte_update().
pmd_update and pmd_update_defer are always set to paravirt_nop, so they
can just be nuked.
Signed-off-by: Juergen Gross
---
arch/x86/includ
On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
On 11/16/15 12:22, Borislav Petkov wrote:
Huh, so what's wrong with a jump:
jmp 1f
swapgs
1:
What is the point of that jump?
If it would make you feel better, it could be X86_BUG_XENPV :-p
That doesn't matter - I just do
On Tue, Nov 17, 2015 at 05:57:04PM +0800, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a bus_notifier for AMBA bus device in order to map the device
> mmio regions when DOM0 booting with ACPI.
>
> Signed-off-by: Shannon Zhao
> ---
> drivers/xen/Makefile | 1 +
> drivers/xen/amb
On 17/11/15 15:46, Juergen Gross wrote:
> pte_update_defer can be removed as it is always set to the same
> function as pte_update. So any usage of pte_update_defer() can be
> replaced by pte_update().
>
> pmd_update_defer is always set to paravirt_nop, so it can just be
> nuked.
>
> Signed-off-b
pte_update_defer can be removed as it is always set to the same
function as pte_update. So any usage of pte_update_defer() can be
replaced by pte_update().
pmd_update_defer is always set to paravirt_nop, so it can just be
nuked.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h
On Tue, Nov 17, 2015 at 05:57:03PM +0800, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add a bus_notifier for platform bus device in order to map the device
> mmio regions when DOM0 booting with ACPI.
>
> Signed-off-by: Shannon Zhao
> ---
> drivers/xen/Makefile | 1 +
> drivers/
On Mon, 2015-09-21 at 13:47 +0100, Ian Campbell wrote:
> TL;DR: There are issues, but IMHO switching can be justified.
Since some time has passed here is a fresh comparison of linux-3.14 flight
64435 (latest flight which would have passed except it incorrectly tried to
build an armhf kernel) vs li
On 17/11/15 12:57, Shannon Zhao wrote:
> Hi,
>
> On 2015/11/17 20:26, Julien Grall wrote:
>> Hi Shannon,
>>
>> I would have appreciate if you I had looked on comments made on the
>> series sent by Parth.
>>
> I do look. But I didn't find "Follow-Ups" ones at [1]. And among the
> mails which Parth
Signed-off-by: Ian Campbell
---
ap-common | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/ap-common b/ap-common
index 19c7580..5e7a791 100644
--- a/ap-common
+++ b/ap-common
@@ -61,8 +61,12 @@
: ${PUSH_TREE_LINUX:=$XENBITS:/home/xen/git/linux-pvops.git}
: ${BASE_TR
On 17/11/15 13:21, Shannon Zhao wrote:
>> AFAICT, it does only works for SPCR table used for UART device. For the
>> GIC you've hardcoded the value and I can't find any version number in
>> the table.
>>
> No, I didn't hardcode the GIC version. Since ACPI 6.0 introduces GIC
> version in generic dis
Hi Shannon,
On 17/11/15 12:45, Shannon Zhao wrote:
>
>
> On 2015/11/17 19:58, Julien Grall wrote:
>> Hi Shannon,
>>
>> On 17/11/15 09:40, shannon.z...@linaro.org wrote:
>>> From: Shannon Zhao
>>>
>>> EFI table, memory description table and some of acpi tables will be
>>> placed after DOM0 memor
On Tue, Nov 17, 2015 at 07:13:34AM +0800, Bob Liu wrote:
>
> On 11/17/2015 05:27 AM, Konrad Rzeszutek Wilk wrote:
> >> /* Common code used when first setting up, and when resuming. */
> >> static int talk_to_blkback(struct xenbus_device *dev,
> >> @@ -1527,10 +1582,9 @@ static int talk_to_blkbac
* Fix (unsafe) assumption that X86_FEATURE_APIC resided in feature word 0.
* All 64bit processors have local APICs; drop the vendor check.
* Unconditionally probe MSR_IA32_APICBASE (safely, to fail more gracefully in
broken situations) and avoid a redundant double rdmsr().
* Avoid repeatedly OR'i
On 17/11/15 12:32, Shannon Zhao wrote:
> Hi Julien,
>
> On 2015/11/17 19:27, Julien Grall wrote:
>> Hi Shannon,
>>
>> Why do you want to revert this patch?
>>
> Because d->arch.vgic.cbase will be used by creating Dom0 MADT table
> later. See [PATCH v3 43/62].
> +gicc.base_address = d->
On 17/11/15 13:44, Juergen Gross wrote:
> The only member of that structure is startup_ipi_hook which is always
> set to paravirt_nop.
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
1 - 100 of 258 matches
Mail list logo
