flight 100371 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 9 debian-installfail REGR. vs. 99879
Regressions which are
flight 100378 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
Tests which
On Aug 9, 2016 7:09 PM, "James Bottomley" <
james.bottom...@hansenpartnership.com> wrote:
>
> On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote:
> > > table development go under copyleft-next, Rusty recently asked for
> > > code to go in prior to the license tag being added denoting this
This run is configured for baseline tests only.
flight 66947 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66947/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-a
flight 100369 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100363
Regressions which
flight 100375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
Tests which
This run is configured for baseline tests only.
flight 66948 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66948/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9e730bd16418d76e400f87cf852b53f960d1d5b3
baseline v
flight 100367 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100367/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 100361
build-i386-rumpuserxen
flight 100374 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
Tests which
On Tue, Aug 9, 2016 at 7:07 PM, Kamenee Arumugam wrote:
>
> Hi Chen,
>
> I have tried to flash UEFI in my board with latest one but still facing the
> same issue. Regarding to use dtb file from kernel source, I couldnt find
> hi6220-hikey.dtb in my source kernel. i am downloading my kernel sourc
Hi Chen,
I have tried to flash UEFI in my board with latest one but still facing the
same issue. Regarding to use dtb file from kernel source, I couldnt find
hi6220-hikey.dtb in my source kernel. i am downloading my kernel source
from here: https://github.com/96boards/linux/tree/android-hikey-lina
flight 100373 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100373/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
Tests which
This is where struct acpi_config is now defined
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/rombios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloader/rombios.c
b/tools/firmware/hvmloader/rombios.c
index 1f8fc2d..b66f8e9 100644
--- a/t
1.rombios.c needs to include libacpi.h instead of acpi2_0.h. Apparently
I was testing without CONFIG_ROMBIOS
2.acpi_config can't be passed to acpi_build_tables() as a const since
vm_gid_addr will be updated by the builder. We can either unconstify it
or return vm_gid_addr as a separate param
With that we can pass acpi_config as a const.
Signed-off-by: Boris Ostrovsky
---
This is an alternative to patch 2. Only compile-tested.
tools/firmware/hvmloader/acpi/build.c | 15 ---
tools/firmware/hvmloader/acpi/libacpi.h | 8 ++--
tools/firmware/hvmloader/util.c |
We'd need to update other routines' definitions. However, acpi_config
is not really a const since new_vm_gid() wants to update
acpi_config.vm_gid_addr.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/build.c | 2 +-
tools/firmware/hvmloader/acpi/libacpi.h | 2 +-
2 files chang
flight 66946 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66946/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail blocked in
66884
test-am
flight 100370 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100370/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
Tests which
This run is configured for baseline tests only.
flight 66945 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 11 guest-start
On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall wrote:
> Hello Sergej,
>
>
> On 01/08/16 18:10, Sergej Proskurin wrote:
>>
>> This commit moves the altp2m-related code from x86 to ARM. Functions
>> that are no yet supported notify the caller or print a BUG message
>> stating their absence.
>>
>> Als
flight 100366 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100366/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99758
test-amd64-i386-xl-qemuu-win7-am
flight 100368 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
test-armhf-a
> >> > @@ -70,7 +71,11 @@ struct payload {
> >> > unsigned int nsyms; /* Nr of entries in .strtab
> >> > and
> >> > symbols. */
> >> > struct livepatch_build_id id;/*
> >> > ELFNOTE_DESC(.note.gnu.build-id) of the payload. */
> >> > struct livepatch_build_
On 08/09/2016 06:56 PM, Anthony PERARD wrote:
On Tue, Aug 02, 2016 at 04:06:30PM +0200, Paulina Szubarczyk wrote:
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq_
osstest service owner writes ("[xen-4.5-testing test] 100322: regressions -
trouble: broken/fail/pass"):
> flight 100322 xen-4.5-testing real [real]
> test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 99752
This was merlot1 having forgotten its boot order. I fixed it
yester
On Tue, Aug 9, 2016 at 3:41 AM, Tim Deegan wrote:
> At 19:29 +0300 on 08 Aug (1470684579), Razvan Cojocaru wrote:
>> On 08/08/16 18:52, Tamas K Lengyel wrote:
>> >> I think the issue might be that vm_event_vcpu_pause() uses
>> >> > vcpu_pause_nosync(), and it's being used everywhere we pause the V
On Tue, Aug 02, 2016 at 04:06:30PM +0200, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
>
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operati
flight 100363 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100363/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100356
test-amd64-amd64-xl-qemuu-
On Tue, Aug 09, 2016 at 03:24:29PM +0100, One Thousand Gnomes wrote:
> However you need to clarify the licence first I think. Linux is GPLv2,
> your document only allows use of GPL with "GPL" works - not GPL v2 works ?
The license defines "GPL" as "a version of the GNU General Public
License or th
On Tue, Aug 09, 2016 at 03:24:29PM +0100, One Thousand Gnomes wrote:
> It would also be good if someone clarified whether 6 and 7 are intended
> to combine so you can take contributed patches and put them in your own
> proprietary version. As a non-lawyer the intent is not clear at all.
6 and 7 ar
flight 100365 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100365/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 09.08.16 at 18:12, wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -225,8 +225,16 @@
/* Location of the VM Generation ID in guest physical address space. */
#define HVM_PARAM_VM_GENERATION_ID_ADDR 34
-/* Boolean: Ena
>>> --- a/xen/include/public/hvm/params.h
>>> +++ b/xen/include/public/hvm/params.h
>>> @@ -225,8 +225,16 @@
>>> /* Location of the VM Generation ID in guest physical address space. */
>>> #define HVM_PARAM_VM_GENERATION_ID_ADDR 34
>>>
>>> -/* Boolean: Enable altp2m */
>>> +/*
>>> + * Set mode fo
On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote:
> > table development go under copyleft-next, Rusty recently asked for
> > code to go in prior to the license tag being added denoting this
> > license as GPL-compatible [3] -- I had noted in the patch
> > submission which annotated c
On Tue, Aug 9, 2016 at 2:06 AM, Jan Beulich wrote:
On 09.08.16 at 01:56, wrote:
>> @@ -5238,18 +5238,19 @@ static int do_altp2m_op(
>> goto out;
>> }
>>
>> -if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
>> +if ( !d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
>> +
On Tue, Aug 9, 2016 at 1:55 AM, Jan Beulich wrote:
On 09.08.16 at 01:56, wrote:
>> Use __get_gfn_type_access instead of get_gfn_type_access when checking
>> the hostp2m entries during altp2m mem_access setting and gfn remapping
>> to avoid a lock conflict which can make dom0 freeze.
>
> You
On Tue, Aug 09, 2016 at 02:11:27PM +0100, Andrew Cooper wrote:
> On 08/08/16 14:13, Wei Liu wrote:
> > On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote:
> >> On 08/08/16 12:24, Wei Liu wrote:
> >>> Now that xl create -c is fixed in xen-unstable, there is no need to keep
> >>> the hack
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 09 August 2016 16:19
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini
> Subject: Re: [PATCH] xen: handle inbound migration of VMs without ioreq
> server
On Mon, Aug 01, 2016 at 10:16:25AM +0100, Paul Durrant wrote:
> VMs created on older versions on Xen will not have been provisioned with
> pages to support creation of non-default ioreq servers. In this case
> the ioreq server API is not supported and QEMU's only option is to fall
> back to using t
>>> On 09.08.16 at 17:13, wrote:
> On 08/09/2016 10:48 AM, Jan Beulich wrote:
> On 09.08.16 at 15:51, wrote:
>>> On 08/09/2016 09:29 AM, Jan Beulich wrote:
>>> On 04.08.16 at 23:06, wrote:
> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Jan Beulich
> ---
> v2:
> * N
>>> On 09.08.16 at 17:09, wrote:
> On 08/09/2016 10:47 AM, Andrew Cooper wrote:
>> On 09/08/16 15:31, Jan Beulich wrote:
>> On 09.08.16 at 15:50, wrote:
On 08/09/2016 09:11 AM, Jan Beulich wrote:
On 04.08.16 at 23:06, wrote:
>> --- a/tools/firmware/hvmloader/acpi/build.c
>>
On 08/09/2016 10:48 AM, Jan Beulich wrote:
On 09.08.16 at 15:51, wrote:
>> On 08/09/2016 09:29 AM, Jan Beulich wrote:
>> On 04.08.16 at 23:06, wrote:
Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
---
v2:
* Note: didn't break "if ( !waet ) return -1" l
On 09/08/16 16:09, Boris Ostrovsky wrote:
> On 08/09/2016 10:47 AM, Andrew Cooper wrote:
>> On 09/08/16 15:31, Jan Beulich wrote:
>> On 09.08.16 at 15:50, wrote:
On 08/09/2016 09:11 AM, Jan Beulich wrote:
On 04.08.16 at 23:06, wrote:
>> --- a/tools/firmware/hvmloader/acpi/bu
On 08/09/2016 10:47 AM, Andrew Cooper wrote:
> On 09/08/16 15:31, Jan Beulich wrote:
> On 09.08.16 at 15:50, wrote:
>>> On 08/09/2016 09:11 AM, Jan Beulich wrote:
>>> On 04.08.16 at 23:06, wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/b
On 08/09/2016 10:46 AM, Jan Beulich wrote:
On 04.08.16 at 23:06, wrote:
>> +if (dom->nr_vnodes) {
>> +struct acpi_numa *numa = &config->numa;
>> +
>> +rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
>> +&numa->nr_vmemranges,
>> +
>>> On 09.08.16 at 16:56, wrote:
> --- a/xen/arch/x86/boot/mkelf32.c
> +++ b/xen/arch/x86/boot/mkelf32.c
> @@ -260,7 +260,7 @@ int main(int argc, char **argv)
> u32loadbase, dat_siz, mem_siz, note_base, note_sz, offset;
> char *inimage, *outimage;
> intinfd, out
The mkelf32 executable was using an uninitialized stack buffer for
padding after the ehdr and phdr are written to the xen file, which
leads to non-deterministic bytes in the binary and prevented Xen
hypervisors from being reproducibly built.
Additionally, the file was then compressed with gzip -9
>>> On 09.08.16 at 15:51, wrote:
> On 08/09/2016 09:29 AM, Jan Beulich wrote:
> On 04.08.16 at 23:06, wrote:
>>> Signed-off-by: Boris Ostrovsky
>>> Reviewed-by: Jan Beulich
>>> ---
>>> v2:
>>> * Note: didn't break "if ( !waet ) return -1" line since that's the style
>>> of the file.
>> St
On 08/08/16 12:09, Wei Liu wrote:
> On Mon, Aug 08, 2016 at 12:05:58PM +0100, Wei Liu wrote:
>> On Mon, Aug 08, 2016 at 10:54:31AM +0100, George Dunlap wrote:
>>> +
>>> +new_size = s->sample_size << 1;
>>> +
>>> +if (new_size == 0)
>>> +new_size = opt.sample_
On 09/08/16 15:31, Jan Beulich wrote:
On 09.08.16 at 15:50, wrote:
>> On 08/09/2016 09:11 AM, Jan Beulich wrote:
>> On 04.08.16 at 23:06, wrote:
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -462,32 +462,26 @@ static int constru
>>> On 04.08.16 at 23:06, wrote:
> +if (dom->nr_vnodes) {
> +struct acpi_numa *numa = &config->numa;
> +
> +rc = xc_domain_getvnuma(xch, domid, &numa->nr_vnodes,
> +&numa->nr_vmemranges,
> +&config->hvminfo->nr_vcp
>>> On 09.08.16 at 15:43, wrote:
> On 08/09/2016 09:27 AM, Jan Beulich wrote:
> On 04.08.16 at 23:06, wrote:
>>> ---
>>> v2:
>>> * Note: struct acpi_numa's pointers can't be constified due to their
>>> use in later patches
>> Well, I hope I'll remember once I get there.
>
> Patch 22, init_
>>> On 09.08.16 at 16:27, wrote:
> On 09/08/16 15:01, Jan Beulich wrote:
> On 09.08.16 at 14:41, wrote:
>>> The use of -fno-builtin inhibits this automatic transformation. Manually
>>> tranform the callsites. This causes constructs such as strlen("literal") to
>>> be evaluated at compile ti
>>> On 09.08.16 at 15:50, wrote:
> On 08/09/2016 09:11 AM, Jan Beulich wrote:
> On 04.08.16 at 23:06, wrote:
>>> --- a/tools/firmware/hvmloader/acpi/build.c
>>> +++ b/tools/firmware/hvmloader/acpi/build.c
>>> @@ -462,32 +462,26 @@ static int construct_secondary_tables(unsigned long
>>> *tabl
Hi all,
just a quick note that we are upgrading the MediaWiki instance on Wed Aug 10,
from 8:00 - 9:00 UTC. During this time, the wiki will be disabled for up to 15
minutes while we copy the database into the updated Wiki installation.
Should you have any problems after the upgrade, please repo
>>> On 09.08.16 at 16:09, wrote:
> On 09/08/16 14:52, Jan Beulich wrote:
> On 09.08.16 at 15:24, wrote:
>>> On 06/08/16 00:04, Daniel Kiper wrote:
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -32,7 +32,7 @@ multiboot1_header_start: /*** MULTIBOOT1 HEAD
flight 100361 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100361/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 100348
build-i386-rumpuserxen
On 09/08/16 15:01, Jan Beulich wrote:
On 09.08.16 at 14:41, wrote:
>> The use of -fno-builtin inhibits this automatic transformation. Manually
>> tranform the callsites. This causes constructs such as strlen("literal") to
>> be evaluated at compile time, and certain simple operations to be
> table development go under copyleft-next, Rusty recently asked for code
> to go in prior to the license tag being added denoting this license as
> GPL-compatible [3] -- I had noted in the patch submission which annotated
> copyleft-next's compatibility to GPLv2 that copyleft-next is the license
>
>>> On 09.08.16 at 15:24, wrote:
> On 06/08/16 00:04, Daniel Kiper wrote:
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -32,7 +32,7 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER /
>> .long MULTIBOOT_HEADER_FLAGS
>> /* Checksum: must be
On 09/08/16 15:06, Jan Beulich wrote:
On 09.08.16 at 15:16, wrote:
>> On 09/08/16 11:39, Jan Beulich wrote:
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -22,8 +22,6 @@
>>>
>>> enum system_state system_state = SYS_STATE_early_boot;
>>>
>>> -int tainted;
>>> -
>>> xe
On 09/08/16 14:52, Jan Beulich wrote:
On 09.08.16 at 15:24, wrote:
>> On 06/08/16 00:04, Daniel Kiper wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -32,7 +32,7 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER
>>> /
>>> .long MULTIB
>>> On 09.08.16 at 15:16, wrote:
> On 09/08/16 11:39, Jan Beulich wrote:
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -22,8 +22,6 @@
>>
>> enum system_state system_state = SYS_STATE_early_boot;
>>
>> -int tainted;
>> -
>> xen_commandline_t saved_cmdline;
>>
>> static vo
On Mon, Aug 8, 2016 at 5:38 AM, Dario Faggioli
wrote:
> On Thu, 2016-08-04 at 01:15 -0400, Meng Xu wrote:
>> Hi Dario,
>>
> Hi,
>
>> I'm thinking about changing the current RTDS scheduler to
>> work-conserving version as we briefly discussed before.
>> Below is a design of the work-conserving RTDS
>>> On 09.08.16 at 14:41, wrote:
> The use of -fno-builtin inhibits this automatic transformation. Manually
> tranform the callsites. This causes constructs such as strlen("literal") to
> be evaluated at compile time, and certain simple operations to be replaced
> with repeated string operations
>>> On 09.08.16 at 14:48, wrote:
> For d->shutdown_code, change the field to being unsigned and using an unsigned
> sentinel. The sentinal needs to be distinguishable from any value
> representable in a u8.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: George Dunlap
Reviewed-by: Jan Beulich
This run is configured for baseline tests only.
flight 66944 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 gues
On 08/09/2016 09:29 AM, Jan Beulich wrote:
On 04.08.16 at 23:06, wrote:
>> Signed-off-by: Boris Ostrovsky
>> Reviewed-by: Jan Beulich
>> ---
>> v2:
>> * Note: didn't break "if ( !waet ) return -1" line since that's the style
>> of the file.
> Style of the file? At best there's a mix in th
On 08/09/2016 09:43 AM, Boris Ostrovsky wrote:
> On 08/09/2016 09:27 AM, Jan Beulich wrote:
> On 04.08.16 at 23:06, wrote:
>>> ---
>>> v2:
>>> * Note: struct acpi_numa's pointers can't be constified due to their
>>> use in later patches
>> Well, I hope I'll remember once I get there.
> Patch
On 08/09/2016 09:11 AM, Jan Beulich wrote:
On 04.08.16 at 23:06, wrote:
>> --- a/tools/firmware/hvmloader/acpi/build.c
>> +++ b/tools/firmware/hvmloader/acpi/build.c
>> @@ -462,32 +462,26 @@ static int construct_secondary_tables(unsigned long
>> *table_ptrs,
>> *
>> * Return 0 if memory
On 09/08/16 11:39, Jan Beulich wrote:
> Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -22,8 +22,6 @@
>
> enum system_state system_state = SYS_STATE_early_boot;
>
> -int tainted;
> -
On 06/08/16 00:04, Daniel Kiper wrote:
> Its visibility is not needed and just pollute symbol table.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Daniel Kiper
> ---
> xen/arch/x86/boot/head.S |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/boot/head.S b
On 08/09/2016 09:27 AM, Jan Beulich wrote:
On 04.08.16 at 23:06, wrote:
>> ---
>> v2:
>> * Note: struct acpi_numa's pointers can't be constified due to their
>> use in later patches
> Well, I hope I'll remember once I get there.
Patch 22, init_acpi_config() routine.
>
>> --- a/tools/firmw
On 08/08/16 14:13, Wei Liu wrote:
> On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote:
>> On 08/08/16 12:24, Wei Liu wrote:
>>> Now that xl create -c is fixed in xen-unstable, there is no need to keep
>>> the hack to get guest console output anymore.
>>>
>>> Use xl create -Fc directly,
The use of -fno-builtin inhibits this automatic transformation. Manually
tranform the callsites. This causes constructs such as strlen("literal") to
be evaluated at compile time, and certain simple operations to be replaced
with repeated string operations.
Signed-off-by: Andrew Cooper
---
CC: J
flight 100364 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100364/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1fbd0ca16a997b68ed320340aef18645e71e8a73
baseline version:
ovmf 9e730bd16418d76e400f8
The checksums should be calculated using unsigned 32bit integers, as they are
intended to overflow and end at 0. Replace some other signed integers with
unsigned ones, to avoid mixed-sign comparisons.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Kevin Tian
CC:
For d->shutdown_code, change the field to being unsigned and using an unsigned
sentinel. The sentinal needs to be distinguishable from any value
representable in a u8.
Signed-off-by: Andrew Cooper
Reviewed-by: George Dunlap
---
CC: Jan Beulich
CC: George Dunlap
CC: Konrad Rzeszutek Wilk
CC:
>>> On 04.08.16 at 23:06, wrote:
> @@ -568,13 +577,13 @@ void acpi_build_tables(struct acpi_config *config)
> offsetof(struct acpi_header, checksum),
> sizeof(struct acpi_20_fadt));
>
> -nr_secondaries = construct_secondary_tables(secondary_tables,
> +
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
v2:
* Use ~0u as opposed to -1u
---
xen/arch/x86/apic.c | 2 +-
xen/arch/x86/cpu/common.c | 2 +-
xen/arch/x86/x86_64/traps.c | 2 +-
xen/include/asm-x86/apicdef.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
di
>>> On 04.08.16 at 23:06, wrote:
> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Jan Beulich
> ---
> v2:
> * Note: didn't break "if ( !waet ) return -1" line since that's the style
> of the file.
Style of the file? At best there's a mix in the file, and hence correcting
it here is rather desi
>>> On 04.08.16 at 23:06, wrote:
> ---
> v2:
> * Note: struct acpi_numa's pointers can't be constified due to their
> use in later patches
Well, I hope I'll remember once I get there.
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -70,7 +70,8 @
>>> On 04.08.16 at 23:06, wrote:
> Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()
>
> Signed-off-by: Boris Ostrovsky
> ---
> v2:
> * Dropped pt_ prefix
> * Slight change in construct_passthrough_tables() code (thus dropped Jan's
> R-b)
Feel free to re-instate.
Jan
_
>>> On 04.08.16 at 23:06, wrote:
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -462,32 +462,26 @@ static int construct_secondary_tables(unsigned long
> *table_ptrs,
> *
> * Return 0 if memory failure, != 0 if success
> */
> -static int new_
>>> On 09.08.16 at 14:36, wrote:
> Hi Jan,
>
> A question about ' XENFEAT_auto_translated_physmap':
>
> In linux code, in arch/x86/xen/mmu.c,
I assume you know that I'm not a maintainer of the Linux code.
> __xen_pgd_walk()
> {
>
>
> if (xen_feature(XENFEAT_auto_translated_physm
Hi Jan,
A question about ' XENFEAT_auto_translated_physmap':
In linux code, in arch/x86/xen/mmu.c,
__xen_pgd_walk()
{
if (xen_feature(XENFEAT_auto_translated_physmap))
return 0;
}
Why xen_feature(XENFEAT_auto_translated_physmap) is true, then return directl
>>> On 04.08.16 at 23:06, wrote:
> By doing this we can move hvmloader-private interfaces (such as
> uart_exists(), lpt_exists() etc.) out of the ACPI builder. This will
> help us with allowing to call the builder from places other than
> hvmloader.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-b
>>> On 09.08.16 at 11:13, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1434,6 +1434,13 @@ Set the serial transmit buffer size.
>
> Flag to enable Supervisor Mode Execution Protection
>
> +### xen_smep
> +> `= `
> +
> +> Default: `true`
>
>>> On 06.08.16 at 01:04, wrote:
> ..nor EFI platforms with runtime services disabled.
DYM non-EFI in the subject part of the sentence?
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -80,6 +80,9 @@ static void __init set_reboot_type(char *str)
> break;
>
On August 07, 2016 7:39 PM, Emil Condrea wrote:
On Mon, Jul 25, 2016 at 7:01 PM, Anthony PERARD
wrote:
> >
> > > +{
> > > +xs_transaction_t xbt = XBT_NULL;
> > > +
> > > +if (xendev->fe_state == xbus) {
> > > +return 0;
> > > +}
> > > +
> > > +xendev->fe_state = xbus;
> >
>>> On 09.08.16 at 12:48, wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
> depriv)"):
>> Actually, having thought about this some more, and taking this
>> together with the expectations to the privcmd driver previously
>> outlined, I think this part is problemat
Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
depriv)"):
> Actually, having thought about this some more, and taking this
> together with the expectations to the privcmd driver previously
> outlined, I think this part is problematic: If all the driver is to know
> is the
This doesn't cover all of them, just the ones that I think would most
obviously better be -EINVAL or -EOPNOTSUPP.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -440,7 +440,7 @@ int unmmap_broken_page(struct domain *d,
return -EIN
Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments.
Signed-off-by: Jan Beulich
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -22,8 +22,6 @@
enum system_state system_state = SYS_STATE_early_boot;
-int tainted;
-
xen_commandline_t saved_cmdline;
static void __init assign
>>> On 08.08.16 at 15:46, wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu
> depriv)"):
>> On 05.08.16 at 18:28, wrote:
>> > That is, a bug of class 2 would allow the unprivileged qemu process in
>> > dom0 to cause damage to other parts of dom0.
> ...
>> Ah, okay
On 8/9/2016 5:45 PM, Jan Beulich wrote:
On 09.08.16 at 11:25, wrote:
On 8/9/2016 4:13 PM, Jan Beulich wrote:
On 09.08.16 at 09:39, wrote:
On 8/9/2016 12:29 AM, Jan Beulich wrote:
On 12.07.16 at 11:02, wrote:
@@ -5512,6 +5513,12 @@ static int hvmop_set_mem_type(
if ( rc )
flight 100356 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100356/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100334
test-amd64-amd64-xl-qemuu-
This is more efficient than list_for_each_safe() when list modification
is accompanied by breaking out of the loop.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
---
v2: Avoid commit message to continue from subject.
---
drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++--
1 file chang
flight 100362 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100362/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9e730bd16418d76e400f87cf852b53f960d1d5b3
baseline version:
ovmf 7989300df75f274203d74
On Mon, Aug 8, 2016 at 6:11 PM, anshul makkar wrote:
> On 08/08/16 10:54, George Dunlap wrote:
>>
>> Rather than have large fixed-size buffers, start with smaller buffers
>> and allow them to grow as needed (doubling each time), with a fairly
>> large maximum. Allow this maximum to be set by a co
1 - 100 of 125 matches
Mail list logo
