flight 102285 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102285/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2adf689cb7c66f4790a7d0a9e7e99aad6ebee638
baseline version:
ovmf 86a1eca2101686d476ab1
On 11/16/2016 09:22 AM, Tian, Kevin wrote:
> Looks not working with APICv virtual interrupt delivery...
It's only meant to work with "regular" injections (we'd like to be able
to tell if xc_hvm_inject_trap() can succeed). APICv support could be a
later patch, if desirable (AFAICT, the two types sh
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Saturday, November 12, 2016 12:09 AM
>
> Added support for a new event type, VM_EVENT_REASON_INTERRUPT,
> which is now fired in a one-shot manner when enabled via the new
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.
>
flight 102275 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101909
test-amd64-amd64-
If these are all the comments then I'll start preparing patch v9
Thank you all for reviewing and providing feedback
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, November 14, 2016 7:01 PM
>
> %cs.L may be set in a legacy mode segment, or clear in a compatibility mode
> segment; it is not the correct way to check for long mode being active.
>
> Both of these situations result in incor
On 15/11/16 01:11, Alex Thorlton wrote:
> On systems with sufficiently large e820 tables, and several IOAPICs, it
> is possible for the XENMEM_machine_memory_map callback (and its
> counterpart, XENMEM_memory_map) to attempt to return an e820 table with
> more than 128 entries. This callback adds
On 15/11/16 16:22, Alex Thorlton wrote:
> On Tue, Nov 15, 2016 at 10:55:49AM +0100, Juergen Gross wrote:
>> I'd go with the new error code. What about E2BIG or ENOSPC?
>>
>> I think the hypervisor should fill in the number of entries required
>> in this case.
>>
>> In case nobody objects I can post
Has there been any update to this bug/issue last discussed on Tue 6 Sep 2016
14:37:21 +0100? Under Debian stretch running Xen & kernel version 4.8.0-1-amd64
I have a Windows HVM that cannot communicate with other PVM domU instances on
the same dom0. The PVM domU instances report: "net eth0: Inva
This run is configured for baseline tests only.
flight 68046 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68046/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 86a1eca2101686d476ab191f0511b44e369fd8a7
baseline v
flight 102272 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102272/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3)broken REGR. vs. 10225
在 2016/11/15 23:47, Peter Zijlstra 写道:
On Wed, Nov 02, 2016 at 05:08:33AM -0400, Pan Xinhui wrote:
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 0f400c0..38c3bb7 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/pa
flight 102279 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102279/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 86a1eca2101686d476ab191f0511b44e369fd8a7
baseline version:
ovmf 84083b12f234b62fb133d
As far as I can tell in the past decade, energy efficiency, dynamic
migration, load-balancing, etc. in virtualization platforms, server farms
and cloud computing infrastructures have been discussed and researched
which are not new to the academic and industry.
A simple search result in IEEE:
http:
This run is configured for baseline tests only.
flight 68045 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68045/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 84083b12f234b62fb133d8c47ee4ab95f3b0eef9
baseline v
On Mon, Nov 14, 2016 at 12:33:33PM +, Anthony PERARD wrote:
> This script runs the OpenStack integration test suite, Tempest.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Campbell
> Acked-by: Ian Jackson
>
> ---
> Changes in V7:
> - reindent
> - acked
>
> No change in V5
>
> Change
On Mon, Nov 14, 2016 at 12:33:32PM +, Anthony PERARD wrote:
> This script installs any necessary packages and clones all of the OpenStack
> trees which are used by devstack to deploy OpenStack.
>
> Signed-off-by: Anthony PERARD
.. snip..
> diff --git a/ts-openstack-deploy b/ts-openstack-deplo
flight 102263 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
Hey Ian,
I've my test machine, and I can run some of the standalone
tests. But everytime I run any of the jobs I get:
.. snip..
2016-11-16 00:07:55 Z setting xtfbuildjob=build-amd64-xtf
2016-11-16 00:07:55 Z log capturing not enabled
+ rc=0
+ date -u +%Y-%m-%d %H:%M:%S Z exit status 0
2016-11-16
flight 102271 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102271/
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 11/15/2016 03:44 PM, Andrew Cooper wrote:
> On 15/11/2016 20:39, Boris Ostrovsky wrote:
>> On 11/15/2016 02:45 PM, Andrew Cooper wrote:
>>> On 15/11/16 19:34, Boris Ostrovsky wrote:
In addition to running out of e820 entries on that large machine that
Alex was referring to in [0] he is
On 15/11/2016 20:39, Boris Ostrovsky wrote:
> On 11/15/2016 02:45 PM, Andrew Cooper wrote:
>> On 15/11/16 19:34, Boris Ostrovsky wrote:
>>> In addition to running out of e820 entries on that large machine that
>>> Alex was referring to in [0] he is also running out of ACPI fixmap space
>>> while pa
On 11/15/2016 02:45 PM, Andrew Cooper wrote:
> On 15/11/16 19:34, Boris Ostrovsky wrote:
>> In addition to running out of e820 entries on that large machine that
>> Alex was referring to in [0] he is also running out of ACPI fixmap space
>> while parsing MADT (the box has *lots* of processors). The
This run is configured for baseline tests only.
flight 68042 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68042/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-xtf-amd64-amd64-1 10 xtf-fep
On 11/15/2016 03:07 PM, Andrew Cooper wrote:
> On 15/11/16 19:38, Boris Ostrovsky wrote:
>> On 11/15/2016 02:19 PM, Andrew Cooper wrote:
>>> On 15/11/16 15:56, Jan Beulich wrote:
>>> On 15.11.16 at 16:44, wrote:
> On 11/15/2016 10:17 AM, Jan Beulich wrote:
>>> The other option was XEN_
On 15/11/16 19:38, Boris Ostrovsky wrote:
> On 11/15/2016 02:19 PM, Andrew Cooper wrote:
>> On 15/11/16 15:56, Jan Beulich wrote:
>> On 15.11.16 at 16:44, wrote:
On 11/15/2016 10:17 AM, Jan Beulich wrote:
>> The other option was XEN_X86_EMU_ACPI. Would it be better?
> As that's a
On 15/11/16 19:34, Boris Ostrovsky wrote:
> In addition to running out of e820 entries on that large machine that
> Alex was referring to in [0] he is also running out of ACPI fixmap space
> while parsing MADT (the box has *lots* of processors). The
> quick-and-dirty solution is to increase NUM_FIX
On 11/15/2016 02:19 PM, Andrew Cooper wrote:
> On 15/11/16 15:56, Jan Beulich wrote:
> On 15.11.16 at 16:44, wrote:
>>> On 11/15/2016 10:17 AM, Jan Beulich wrote:
> The other option was XEN_X86_EMU_ACPI. Would it be better?
As that's a little too wide (and I think someone else had als
In addition to running out of e820 entries on that large machine that
Alex was referring to in [0] he is also running out of ACPI fixmap space
while parsing MADT (the box has *lots* of processors). The
quick-and-dirty solution is to increase NUM_FIXMAP_ACPI_PAGES but I
wonder whether we should move
On Sat, Nov 12, 2016 at 02:04:25PM +0200, Artem Mygaiev wrote:
> On Fri, Nov 11, 2016 at 10:43 PM, Konrad Rzeszutek Wilk
> wrote:
> > Does this also mean that the hypervisor has to know the co-processors?
> > As in how to start/stop them? And how to tell them to save/restore
> > guest context? Or
On 15/11/16 15:56, Jan Beulich wrote:
On 15.11.16 at 16:44, wrote:
>> On 11/15/2016 10:17 AM, Jan Beulich wrote:
The other option was XEN_X86_EMU_ACPI. Would it be better?
>>> As that's a little too wide (and I think someone else had also
>>> disliked it for that reason), how about XEN_X
On Mon, Nov 14, 2016 at 03:39:34AM -0700, Jan Beulich wrote:
> >>> On 11.11.16 at 22:24, wrote:
> > On Fri, Nov 04, 2016 at 10:51:33PM +0200, Andrushchenko, Oleksandr wrote:
> >> + * Addressing
> >> -
> >> + *
> >> + * Indices used t
flight 102258 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102258/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-vhd 6 xen-boot fail in 102243 pass in 102258
test-armhf-armhf-xl-rtds 15 gues
On 15/11/16 16:58, Boris Ostrovsky wrote:
> On 11/15/2016 11:33 AM, Jan Beulich wrote:
> On 15.11.16 at 17:23, wrote:
>>> On 11/15/2016 10:53 AM, Jan Beulich wrote:
>>> On 15.11.16 at 16:41, wrote:
> On 11/15/2016 10:13 AM, Jan Beulich wrote:
> On 15.11.16 at 15:47, wrote:
>>
flight 102267 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102267/
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
Greetings all,
I am a research student and interested in study of VM migration & load
balancing of VMs dynamically. I have read https://wiki.xen.org/wiki/Migration &
https://www.suse.com/documentation/sles-12/book_virt/data/sec_xen_manage_migrate.html
Is there any option to have Migration dynam
On 15/11/16 17:04, Boris Ostrovsky wrote:
> On 11/15/2016 11:41 AM, Andrew Cooper wrote:
>> It also occurs to me that you necessarily need a get_avail_vcpus
>> hypercall to be able to use this interface sensibly from the toolstack.
> We could modify getdomaininfo but that would make set
flight 102266 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102266/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 84083b12f234b62fb133d8c47ee4ab95f3b0eef9
baseline version:
ovmf c0cb1e1a72bccb5c83d7a
On 11/15/2016 11:41 AM, Andrew Cooper wrote:
>
> It also occurs to me that you necessarily need a get_avail_vcpus
> hypercall to be able to use this interface sensibly from the toolstack.
We could modify getdomaininfo but that would make set_avail_vcpus domctl
non-symmetrical.
>>>
>>> On 15.11.16 at 17:58, wrote:
> On 11/15/2016 11:33 AM, Jan Beulich wrote:
> On 15.11.16 at 17:23, wrote:
>>> On 11/15/2016 10:53 AM, Jan Beulich wrote:
>>> On 15.11.16 at 16:41, wrote:
> On 11/15/2016 10:13 AM, Jan Beulich wrote:
> On 15.11.16 at 15:47, wrote:
>>> On
On 11/15/2016 11:33 AM, Jan Beulich wrote:
On 15.11.16 at 17:23, wrote:
>> On 11/15/2016 10:53 AM, Jan Beulich wrote:
>> On 15.11.16 at 16:41, wrote:
On 11/15/2016 10:13 AM, Jan Beulich wrote:
On 15.11.16 at 15:47, wrote:
>> On 11/15/2016 03:47 AM, Jan Beulich wrote:
>
This run is configured for baseline tests only.
flight 68043 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68043/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c7453b5d6302227264b096b528ba9461b2a68d4
baseline v
On 14/11/16 18:44, Boris Ostrovsky wrote:
> On 11/14/2016 01:19 PM, Andrew Cooper wrote:
>> On 14/11/16 17:48, Boris Ostrovsky wrote:
>>> On 11/14/2016 12:17 PM, Andrew Cooper wrote:
>> I am not convinced though that we can start enforcing this new VCPU
>> count, at least for PV guests. The
>>> On 15.11.16 at 17:23, wrote:
> On 11/15/2016 10:53 AM, Jan Beulich wrote:
> On 15.11.16 at 16:41, wrote:
>>> On 11/15/2016 10:13 AM, Jan Beulich wrote:
>>> On 15.11.16 at 15:47, wrote:
> On 11/15/2016 03:47 AM, Jan Beulich wrote:
>>> --- a/tools/libacpi/static_tables.c
>>
Hi all
Xen 4.8 RC6 is tagged. You can check it out from xen.git:
git://xenbits.xen.org/xen.git 4.8.0-rc6
For you convenience, please find tarball and signature at:
https://downloads.xenproject.org/release/xen/4.8.0-rc6/
Please send bug reports and test reports to
xen-de...@lists.xenproject.o
On 11/15/2016 10:53 AM, Jan Beulich wrote:
On 15.11.16 at 16:41, wrote:
>> On 11/15/2016 10:13 AM, Jan Beulich wrote:
>> On 15.11.16 at 15:47, wrote:
On 11/15/2016 03:47 AM, Jan Beulich wrote:
>> --- a/tools/libacpi/static_tables.c
>> +++ b/tools/libacpi/static_tables.c
On Tue, Nov 15, 2016 at 04:04:05PM +, Wei Liu wrote:
> On Tue, Nov 15, 2016 at 03:09:50PM +, Ian Jackson wrote:
> > This seems to be looking for a function MD5. But nothing uses it.
> > The build works fine if this is disabled and libcrypto is not
> > installed.
> >
> > This check was fir
>>> On 15.11.16 at 17:04, wrote:
> There is no reason to build, for example, dsdt_pvh.asl for hvmloader. We
> pass which DSDTs to build via DSDT_FILES parameter.
>
> If DSDT_FILES is empty all DSDTs for a particular architecture will be
> built.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Ja
>>> On 15.11.16 at 16:47, wrote:
> On 14/11/16 10:32, Jan Beulich wrote:
>> So far we didn't guarantee 16-byte alignment of the stack: While (so
>> far) we don't tell the compiler to use smaller alignment, we also don't
>> guarantee 16-byte alignment when establishing stack pointers for new
>> vCP
There is no reason to build, for example, dsdt_pvh.asl for hvmloader. We
pass which DSDTs to build via DSDT_FILES parameter.
If DSDT_FILES is empty all DSDTs for a particular architecture will be built.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* Simpler syntax in libacpi/Makefile when D
On Tue, Nov 15, 2016 at 03:09:50PM +, Ian Jackson wrote:
> This seems to be looking for a function MD5. But nothing uses it.
> The build works fine if this is disabled and libcrypto is not
> installed.
>
> This check was first introduced in 68a3e1e87325 "[TOOLS] Add more
> checks for devel pa
>>> On 15.11.16 at 16:44, wrote:
> On 11/15/2016 10:17 AM, Jan Beulich wrote:
>>> The other option was XEN_X86_EMU_ACPI. Would it be better?
>> As that's a little too wide (and I think someone else had also
>> disliked it for that reason), how about XEN_X86_EMU_ACPI_FF
>> (for "fixed features"), o
Hi Jason,
On Tue, 2016-11-15 at 14:05 +, Jason Long wrote:
> Thank you but I guess it is serious for Xen.
> Are you Sure Red Hat company help Xen? I guess you wrong. Red Hat employee
> not mean Red Hat company and they can help
> other Open Source projects as hobbyist. I guess some Citrix guy
>>> On 15.11.16 at 16:41, wrote:
> On 11/15/2016 10:13 AM, Jan Beulich wrote:
> On 15.11.16 at 15:47, wrote:
>>> On 11/15/2016 03:47 AM, Jan Beulich wrote:
> --- a/tools/libacpi/static_tables.c
> +++ b/tools/libacpi/static_tables.c
> @@ -20,6 +20,8 @@
> * Firmware ACPI Contr
On 14/11/16 10:32, Jan Beulich wrote:
> So far we didn't guarantee 16-byte alignment of the stack: While (so
> far) we don't tell the compiler to use smaller alignment, we also don't
> guarantee 16-byte alignment when establishing stack pointers for new
> vCPU-s. Runtime service functions using SSE
On Wed, Nov 02, 2016 at 05:08:33AM -0400, Pan Xinhui wrote:
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index 0f400c0..38c3bb7 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -310,6 +310,8
On 11/14/2016 12:17 PM, Vitaly Kuznetsov wrote:
>
> +config XEN_PV
> + bool "Xen PV guest support"
> + default y
> + depends on XEN
> + help
> + Support running as a Xen PV guest.
> +
> config XEN_DOM0
We might consider renaming this to XEN_PV_DOM0 to distinguish it from
e
On 11/15/2016 10:17 AM, Jan Beulich wrote:
>> The other option was XEN_X86_EMU_ACPI. Would it be better?
> As that's a little too wide (and I think someone else had also
> disliked it for that reason), how about XEN_X86_EMU_ACPI_FF
> (for "fixed features"), or if that's still too wide, break things
On 11/15/2016 10:13 AM, Jan Beulich wrote:
On 15.11.16 at 15:47, wrote:
>> On 11/15/2016 03:47 AM, Jan Beulich wrote:
--- a/tools/libacpi/static_tables.c
+++ b/tools/libacpi/static_tables.c
@@ -20,6 +20,8 @@
* Firmware ACPI Control Structure (FACS).
*/
On Tue, Nov 15, 2016 at 10:55:49AM +0100, Juergen Gross wrote:
> I'd go with the new error code. What about E2BIG or ENOSPC?
>
> I think the hypervisor should fill in the number of entries required
> in this case.
>
> In case nobody objects I can post patches for this purpose (both Xen
> and Linu
>>> On 15.11.16 at 15:47, wrote:
> On 11/15/2016 03:47 AM, Jan Beulich wrote:
>>
>>> --- a/tools/libacpi/static_tables.c
>>> +++ b/tools/libacpi/static_tables.c
>>> @@ -20,6 +20,8 @@
>>> * Firmware ACPI Control Structure (FACS).
>>> */
>>>
>>> +#define ACPI_REG_BIT_OFFSET0
>> Can you com
On Mon, Nov 14, 2016 at 11:52:26PM -0500, Boris Ostrovsky wrote:
> We now have permission from Lenovo to relicense commit 801d469ad8b2
> ("[HVM] ACPI support patch 3 of 4: ACPI _PRT table") to LGPLv2.1
>
> This essentially means reverting commits c3397311a658 ("acpi: Prevent
> GPL-only code from s
>>> On 15.11.16 at 15:57, wrote:
> On 11/15/2016 04:36 AM, Jan Beulich wrote:
> On 09.11.16 at 15:39, wrote:
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -1443,6 +1443,18 @@ long arch_do_domctl(
>>> break;
>>>
>>> d->arch.avail_vcpus = num;
>>
>>> On 15.11.16 at 15:55, wrote:
> On 11/15/2016 04:24 AM, Jan Beulich wrote:
> On 09.11.16 at 15:39, wrote:
>>> --- a/xen/arch/x86/hvm/ioreq.c
>>> +++ b/xen/arch/x86/hvm/ioreq.c
>>> @@ -1383,6 +1383,78 @@ static int hvm_access_cf8(static int acpi_ioaccess(
>>> int dir, unsigned int port
This seems to be looking for a function MD5. But nothing uses it.
The build works fine if this is disabled and libcrypto is not
installed.
This check was first introduced in 68a3e1e87325 "[TOOLS] Add more
checks for devel packages." in 2006. At that time -lcrypto was used
by tools/blktap/ and to
On 11/15/2016 09:33 AM, Jan Beulich wrote:
On 15.11.16 at 15:28, wrote:
>> On 11/15/2016 03:34 AM, Jan Beulich wrote:
>> On 09.11.16 at 15:39, wrote:
This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently is only intended to be
On 11/15/2016 04:36 AM, Jan Beulich wrote:
On 09.11.16 at 15:39, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1443,6 +1443,18 @@ long arch_do_domctl(
>> break;
>>
>> d->arch.avail_vcpus = num;
>> +
>> +/*
>> + * For PVH gu
On 11/15/2016 04:24 AM, Jan Beulich wrote:
On 09.11.16 at 15:39, wrote:
>> --- a/xen/arch/x86/hvm/ioreq.c
>> +++ b/xen/arch/x86/hvm/ioreq.c
>> @@ -1383,6 +1383,78 @@ static int hvm_access_cf8(static int acpi_ioaccess(
>> int dir, unsigned int port, unsigned int bytes, uint32_t *val)
>>
On 11/15/2016 03:47 AM, Jan Beulich wrote:
>
>> --- a/tools/libacpi/static_tables.c
>> +++ b/tools/libacpi/static_tables.c
>> @@ -20,6 +20,8 @@
>> * Firmware ACPI Control Structure (FACS).
>> */
>>
>> +#define ACPI_REG_BIT_OFFSET0
> Can you completely exclude us ever wanting to support so
>>> On 11.11.16 at 00:45, wrote:
> @@ -488,43 +489,44 @@ int hap_enable(struct domain *d, u32 mode)
> /* allocate P2m table */
> if ( mode & PG_translate )
> {
> +/* p2m_alloc_table() #1 */
> rv = p2m_alloc_table(p2m_get_hostp2m(d));
> if ( rv != 0 )
>
>>> On 15.11.16 at 15:28, wrote:
> On 11/15/2016 03:34 AM, Jan Beulich wrote:
> On 09.11.16 at 15:39, wrote:
>>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>>> 'xl vcpu-set'). While this currently is only intended to be needed by
>>> PVH guests we will call this domc
flight 102260 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102260/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c0cb1e1a72bccb5c83d7a36a8e52a38002b18671
baseline version:
ovmf 0ab475c9a1d551a919430
On 11/15/2016 03:34 AM, Jan Beulich wrote:
On 09.11.16 at 15:39, wrote:
>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>> 'xl vcpu-set'). While this currently is only intended to be needed by
>> PVH guests we will call this domctl for all (x86) guests for consistency.
On 15/11/2016 13:45, "Andrew Cooper" wrote:
>On 15/11/16 13:35, Boris Ostrovsky wrote:
>> On 11/15/2016 01:17 AM, Wei Liu wrote:
>>> On Mon, Nov 14, 2016 at 11:52:27PM -0500, Boris Ostrovsky wrote:
There is no reason to build, for example, dsdt_pvh.asl for hvmloader.
We
pass which
>>> On 11.11.16 at 00:45, wrote:
> @@ -66,6 +67,60 @@ altp2m_vcpu_destroy(struct vcpu *v)
> }
>
> /*
> + * allocate and initialize memory for altp2m portion of domain
> + *
> + * returns < 0 on error
> + * returns 0 on no operation & success
> + */
> +int
> +altp2m_domain_init(struct domain
On Tue, Nov 15, 2016 at 11:54 AM, John Haxby wrote:
> On 15/11/16 11:17, Jason Long wrote:
>> You said a Red Hat employee and this company like KVM not Xen.
>
> That makes no sense. You're denying what it says on the
> virt-manager.org web site as well as denying what it says in the
> description
Thank you but I guess it is serious for Xen.
Are you Sure Red Hat company help Xen? I guess you wrong. Red Hat employee not
mean Red Hat company and they can help other Open Source projects as hobbyist.
I guess some Citrix guys help KVM as hobbyist too. When you read Virtualization
books then al
flight 68041 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68041/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 68013
test-amd64-am
On 11/15/2016 02:37 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 15, 2016 at 02:19:53PM +0100, Christian Borntraeger wrote:
>> On 11/15/2016 01:30 PM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote:
For spinning loops people do of
On 15/11/16 13:35, Boris Ostrovsky wrote:
> On 11/15/2016 01:17 AM, Wei Liu wrote:
>> On Mon, Nov 14, 2016 at 11:52:27PM -0500, Boris Ostrovsky wrote:
>>> There is no reason to build, for example, dsdt_pvh.asl for hvmloader. We
>>> pass which DSDTs to build via DSDT_FILES parameter.
>>>
>>> If DSDT
On Tue, Nov 15, 2016 at 02:19:53PM +0100, Christian Borntraeger wrote:
> On 11/15/2016 01:30 PM, Russell King - ARM Linux wrote:
> > On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote:
> >> For spinning loops people do often use barrier() or cpu_relax().
> >> For most architectur
On 11/15/2016 01:17 AM, Wei Liu wrote:
> On Mon, Nov 14, 2016 at 11:52:27PM -0500, Boris Ostrovsky wrote:
>> There is no reason to build, for example, dsdt_pvh.asl for hvmloader. We
>> pass which DSDTs to build via DSDT_FILES parameter.
>>
>> If DSDT_FILES is empty all DSDTs for a particular archit
On 11/15/2016 01:30 PM, Russell King - ARM Linux wrote:
> On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote:
>> For spinning loops people do often use barrier() or cpu_relax().
>> For most architectures cpu_relax and barrier are the same, but on
>> some architectures cpu_relax c
On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote:
> For spinning loops people do often use barrier() or cpu_relax().
> For most architectures cpu_relax and barrier are the same, but on
> some architectures cpu_relax can add some latency.
> For example on power,sparc64 and arc,
David Vrabel writes:
> On 14/11/16 17:17, Vitaly Kuznetsov wrote:
>> Introduce CONFIG_XEN_PV config option and split enlighten.c into
>> 3 files. Temporary add #ifdef CONFIG_XEN_PV to smp.c and mmu.c to
>> not break the build and not make the patch even bigger.
>>
>> xen_cpu_up_prepare*/xen_cpu_
On 15/11/16 11:17, Jason Long wrote:
> You said a Red Hat employee and this company like KVM not Xen.
That makes no sense. You're denying what it says on the
virt-manager.org web site as well as denying what it says in the
description of the RPM. Even the Red Hat RPM for virt-manager says
that
flight 102248 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102248/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
Hi Julien,
On 01/11/16 17:22, Julien Grall wrote:
> Hi Andre,
>
> On 28/09/2016 19:24, Andre Przywara wrote:
>> The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
>> The pending bits and the configuration data (priority, enable bits) for
>> those LPIs are stored in tables in normal m
On 14/11/16 17:17, Vitaly Kuznetsov wrote:
> Introduce CONFIG_XEN_PV config option and split enlighten.c into
> 3 files. Temporary add #ifdef CONFIG_XEN_PV to smp.c and mmu.c to
> not break the build and not make the patch even bigger.
>
> xen_cpu_up_prepare*/xen_cpu_die hooks require separation t
You said a Red Hat employee and this company like KVM not Xen.
On Tuesday, November 15, 2016 2:16 PM, John Haxby wrote:
On 14/11/16 14:05, Jason Long wrote:
> Thank you but the problem is that "virt-manager" is for Redhat and Redhat
> don't like Xen anymore because of KVM. Another problem is t
I'm working with XenServer too and XenServer is not a complete Linux and you
can't work it well like Linux. You can Install Xen on your Linux and doing
Virtualization and your daily work with Linux.
On Tuesday, November 15, 2016 1:30 PM, Paul Durrant
wrote:
> -Original Message-
> Fro
Boris Ostrovsky writes:
> On 11/14/2016 01:21 PM, David Vrabel wrote:
>> On 14/11/16 17:17, Vitaly Kuznetsov wrote:
>>> Hi,
>>>
>>> I have a long-standing idea to separate PV and PVHVM code in kernel and
>>> introduce Kconfig options to make it possible to enable the required
>>> parts only brea
>>> On 15.11.16 at 12:07, wrote:
> On 15/11/16 11:44, Jan Beulich wrote:
> On 15.11.16 at 10:55, wrote:
>>> On 15/11/16 10:45, Jan Beulich wrote:
>>> On 15.11.16 at 09:42, wrote:
> For a fully dynamical solution we'd need a way to get a partial
> E820 map from the hypervisor (e.g
On 15/11/16 11:44, Jan Beulich wrote:
On 15.11.16 at 10:55, wrote:
>> On 15/11/16 10:45, Jan Beulich wrote:
>> On 15.11.16 at 09:42, wrote:
For a fully dynamical solution we'd need a way to get a partial
E820 map from the hypervisor (e.g. first 128 entries) in order to
be
On 14/11/16 22:12, Konrad Rzeszutek Wilk wrote:
> The tools that use kexec are asynchronous in nature and do
> not keep state changes. As such provide an hypercall to find
> out whether an image has been loaded for either type.
>
> Note: No need to modify XSM as it has one size fits all
> check an
>>> On 15.11.16 at 11:26, wrote:
> On 14/11/16 16:54, Jan Beulich wrote:
> On 14.11.16 at 17:38, wrote:
>>> On 14/11/16 15:02, Jan Beulich wrote:
>>> On 14.11.16 at 15:38, wrote:
> On 14/11/16 14:24, Jan Beulich wrote:
> On 14.11.16 at 14:45, wrote:
>>> On 14/11/16 13:25
>>> On 15.11.16 at 10:55, wrote:
> On 15/11/16 10:45, Jan Beulich wrote:
> On 15.11.16 at 09:42, wrote:
>>> For a fully dynamical solution we'd need a way to get a partial
>>> E820 map from the hypervisor (e.g. first 128 entries) in order to
>>> be able to setup at least some memory and later
On 14/11/16 14:05, Jason Long wrote:
> Thank you but the problem is that "virt-manager" is for Redhat and Redhat
> don't like Xen anymore because of KVM. Another problem is that a program like
> VirtualBox has a nice GUI but virt-manager not.
virt-manager is also available for Fedora and Fedora
On 14/11/16 16:54, Jan Beulich wrote:
On 14.11.16 at 17:38, wrote:
>> On 14/11/16 15:02, Jan Beulich wrote:
>> On 14.11.16 at 15:38, wrote:
On 14/11/16 14:24, Jan Beulich wrote:
On 14.11.16 at 14:45, wrote:
>> On 14/11/16 13:25, Jan Beulich wrote:
>>> --- a/xen/arc
From: Cédric Bosdonnat
Use LOG*D logging functions where possible instead of the LOG* ones.
Signed-off-by: Cédric Bosdonnat
---
tools/libxl/libxl_vnuma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_vnuma.c b/tools/libxl/libxl_vnuma.c
index db22799..8ec
1 - 100 of 159 matches
Mail list logo