On 15/11/16 08:15, Jan Beulich wrote:
On 15.11.16 at 07:33, wrote:
>> On 15/11/16 01:11, Alex Thorlton wrote:
>>> Hey everyone,
>>>
>>> We're having problems with large systems hitting a BUG in
>>> xen_memory_setup, due to extra e820 entries created in the
>>> XENMEM_machine_memory_map callba
flight 102253 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102253/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7c7453b5d6302227264b096b528ba9461b2a68d4
baseline version:
ovmf c37dcee6d8c24cff4c50f
>>> On 15.11.16 at 07:33, wrote:
> On 15/11/16 01:11, Alex Thorlton wrote:
>> Hey everyone,
>>
>> We're having problems with large systems hitting a BUG in
>> xen_memory_setup, due to extra e820 entries created in the
>> XENMEM_machine_memory_map callback. The change in the patch gets things
>>
On 14/11/16 13:52, Geliang Tang wrote:
> Use builtin_pci_driver() helper to simplify the code.
>
> Signed-off-by: Geliang Tang
Reviewed-by: Juergen Gross
> ---
> drivers/xen/platform-pci.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/xen/platform-pci.
On 15/11/16 01:11, Alex Thorlton wrote:
> Hey everyone,
>
> We're having problems with large systems hitting a BUG in
> xen_memory_setup, due to extra e820 entries created in the
> XENMEM_machine_memory_map callback. The change in the patch gets things
> working, but Boris and I wanted to get opi
* 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 entries to the
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 architecture will be built.
>
> Signed-off-by: Bo
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
I see you are a Citrix Employee and you and your coworkers must help Xen. I
guess start a dedicated GUI project for Xen help Xen users like me a lot. It is
mandatory and if you see that some users use VirtualBox is it because of its
nice GUI and not performance.
On Monday, November 14, 2016 1
flight 102247 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102247/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c37dcee6d8c24cff4c50fa5dd139e5a26678eb62
baseline version:
ovmf a5991c8832c5301ec969c
ACK
-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Monday, November 14, 2016 3:05 PM
To: xen-de...@lists.xenproject.org; boris.ostrov...@oracle.com
Cc: jbeul...@suse.com; andrew.coop...@citrix.com; wei.l...@citrix.com;
lars.ku...@citrix.c
On Tuesday 15 November 2016 03:42 AM, Konrad Rzeszutek Wilk wrote:
Instead of the scripts having to poke at various fields we can
provide that functionality via the -S parameter.
Returns 0 if the payload is loaded. Can be used in combination
with -l or -p to get the state of the proper kexec i
Hey everyone,
We're having problems with large systems hitting a BUG in
xen_memory_setup, due to extra e820 entries created in the
XENMEM_machine_memory_map callback. The change in the patch gets things
working, but Boris and I wanted to get opinions on whether or not this
is the appropriate/enti
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 entries to the BIOS-provided
e820 table to accou
On Tuesday 15 November 2016 03:42 AM, Konrad Rzeszutek Wilk wrote:
Heya!
I am cross-posting on two mailing lists:
xen-de...@lists.xenproject.org
ke...@lists.infradead.org
as it may be easier to review and provide input then me going back and forth.
Hu..its confusing infact. Patch 1/2
On 11/14/2016 11:52 PM, Boris Ostrovsky wrote:
First patch makes all DSDT tables to be licensed under LGPL.
Seconds patch updates makefiles to create only DSDT files that are
needed by a particular component/architecture (some files were
built unnecessarily). I haven't tested on ARM so if Juli
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
---
tools/firmware/hvmloader/Makefile | 8
tools/li
First patch makes all DSDT tables to be licensed under LGPL.
Seconds patch updates makefiles to create only DSDT files that are
needed by a particular component/architecture (some files were
built unnecessarily). I haven't tested on ARM so if Julian or
Shannon could give it a quick test I'd apprec
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 seeping into non-GPL binaries") and 26c4f0b8a4cf
("tools/libacpi: fix sed us
flight 102230 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102230/
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-
This run is configured for baseline tests only.
flight 68038 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68038/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a5991c8832c5301ec969c37cce5c1b332c7e0127
baseline v
On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:
I found out that my domU kernels invoke the 'apic_disable' function
because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
which would cause the 'smp_found_config' bit to be unset at boot-up.
smp_found_config is not the problem,
This run is configured for baseline tests only.
flight 68037 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68037/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 653bde546200af46573cdfac88257f03b3420d88
baseline v
On Mon, 14 Nov 2016, Andrii Anisov wrote:
> > Could you define unacceptable performance drop? Have you tried to measure
> > what would be the impact?
>
> > I know it can be bad, depending on the class of protocols. I think that
> > if numbers were provided to demonstrate that bounce buffers (the s
flight 102223 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt15 guest-start/debian.repeat fail REGR. vs. 102201
Regressions which
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 and does not check for subcommands.
Signed-off-by: Konrad Rze
Heya!
I am cross-posting on two mailing lists:
xen-de...@lists.xenproject.org
ke...@lists.infradead.org
as it may be easier to review and provide input then me going back and forth.
Anyhow the patches are to help with the various distro's poking in
/sys/../kexec to figure out whether an kexec
Instead of the scripts having to poke at various fields we can
provide that functionality via the -S parameter.
Returns 0 if the payload is loaded. Can be used in combination
with -l or -p to get the state of the proper kexec image.
Signed-off-by: Konrad Rzeszutek Wilk
---
v0: First version (int
flight 102236 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102236/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a5991c8832c5301ec969c37cce5c1b332c7e0127
baseline version:
ovmf 653bde546200af46573cd
Hi George,
On Mon, Nov 14, 2016 at 05:09:01PM +, George Dunlap wrote:
> There is probably a way to configure Xen to make it possible to build
> domains while making a full dump-core difficult to implement even by a
> motivated attacker; but that would be quite a bit more work (and very
> bespo
Hi Andrii,
On 14/11/2016 03:11, Andrii Anisov wrote:
There are many reasons: for example because you want Dom0 to be Linux
and the storage driver domain to be FreeBSD. Or because you want the
network driver domain to be QNX.
What we estimate now is a thin Dom0 without any drivers running with
r
Hi Stefano,
On 11/11/2016 13:55, Stefano Stabellini wrote:
On Fri, 11 Nov 2016, Julien Grall wrote:
Hi Stefano,
On 11/11/2016 02:24, Stefano Stabellini wrote:
On Thu, 10 Nov 2016, Julien Grall wrote:
(CC Stefano and change the title)
Hello,
On 10/11/16 12:13, casionwoo wrote:
I’m pleased
On Sat, Nov 12, 2016 at 01:02:08PM +, Ken Lancaster wrote:
> My apologies for the delay, this is approved.
>
> We approve the action to re-license
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=801d469ad8b2b88f669326327df03d03200efbfb
> under LGPLv2.1 as requested.
>
> Best,
>
flight 102229 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102229/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 653bde546200af46573cdfac88257f03b3420d88
baseline version:
ovmf bab82372a9e6ce066fa72
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 breaking the current 'all or nothing'
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. They expect to start all max VCPUs and
> then o
On Mon, 2016-11-14 at 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.
>
That's not really accurate. Virt-manager is --at least last time I've
tried, which is not too long ago-- a GUI front-end for li
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. They expect to start all max VCPUs and
then offline them. This, of course, can be fixed but all
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 breaking the current 'all or nothing' approach.
>
> Motivation:
> - Xen related x86 cod
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. They expect to start all max VCPUs and
>>> then offline them. This, of course, can be fixed but all non-updated
>>> kernels will stop booting.
>>
flight 68032 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68032/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail like 68007
test-amd64-i386-i38
Hi,
On 01/11/16 15:13, Julien Grall wrote:
> Hi Andre,
>
> On 28/09/2016 19:24, Andre Przywara wrote:
>> Parse the DT GIC subnodes to find every ITS MSI controller the hardware
>> offers. Store that information in a list to both propagate all of them
>> later to Dom0, but also to be able to itera
On 14/11/16 15:01, Boris Ostrovsky wrote:
> On 11/09/2016 04:01 PM, Boris Ostrovsky wrote:
>> On 11/09/2016 02:58 PM, Andrew Cooper wrote:
>>> On 09/11/16 15:14, Boris Ostrovsky wrote:
On 11/09/2016 09:59 AM, Andrew Cooper wrote:
>> diff --git a/xen/include/public/hvm/ioreq.h
>> b/xen
On Mon, Nov 14, 2016 at 3:29 PM, Andy Smith wrote:
> Hi Andrew,
>
> On Mon, Nov 14, 2016 at 03:06:12PM +, Andrew Cooper wrote:
>> You have misunderstood a step.
>>
>> Dom0 can map all of guest memory. This is how `xl dump-core` is
>> implemented, as well as how Qemu emulates devices for the g
xen_pmu_init/finish() functions are used in suspend.c and
enlighten_common.c, add stubs for now.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Kconfig | 2 +-
arch/x86/xen/Makefile | 4 ++--
arch/x86/xen/pmu.h| 5 +
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/
More or less mechanically split smp.c into 3 files. XEN_PV_SMP and
XEN_PVHVM_SMP config options added to support the change.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Kconfig | 8 ++
arch/x86/xen/Makefile | 5 +-
arch/x86/xen/enlighten.c | 8 ++
arch/x86/xen/smp.c|
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 to support
future xen_smp_intr_init() split.
Signed-o
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 breaking the current 'all or nothing' approach.
Motivation:
- Xen related x86 code in kernel is rather big and it is unclear which
parts o
These three files (mmu.c, p2m.c, setup.c) are mostly required to
support PV guests, in fact p2m.c and setup.c have no code for PVHVM
at all. mmu.c has some, move it to mmu_common.c and mmu_hvm.c.
Some additional changes are required:
- In the balloon driver we can't use xen_start_info, xen_release
On 14/11/16 14:59, Boris Ostrovsky wrote:
> On 11/09/2016 02:47 PM, Boris Ostrovsky wrote:
>> On 11/09/2016 02:23 PM, Andrew Cooper wrote:
>>> On 09/11/16 15:29, Boris Ostrovsky wrote:
On 11/09/2016 10:04 AM, Andrew Cooper wrote:
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> This domc
>>> 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/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/
This run is configured for baseline tests only.
flight 68035 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68035/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bab82372a9e6ce066fa725a792e71d07191046ca
baseline v
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/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -643,6 +643,11 @@ vo
Hi all,
a quick reminder that the CfP is closing on Friday
Lars
> On 19 Oct 2016, at 12:01, Lars Kurth wrote:
>
> Hi all,
>
> I am co-organizing the FOSDEM 2017 Virtualization & IaaS DevRoom next year
> again. The CfP for the DevRoom is now open at
> http://www.ovirt.org/blog/2016/10/call-for
>>> On 29.10.16 at 11:00, wrote:
> Also, regions marked as E820_ACPI or E820_NVS are identity mapped into Dom0
> p2m, plus any top-level ACPI tables that should be accessible to Dom0 and
> that don't reside in RAM regions. This is needed because some memory maps
> don't properly account for all th
Hi, there!
Sorry for the long read ahead, but it seems I've got stuck...
I am working on a PV driver and facing an mmap issue.
This actually happens when user-space tries to mmap
the memory allocated by the driver:
cma_obj->vaddr = dma_alloc_wc(drm->dev, size, &cma_obj->paddr,
GFP_KERNEL |
flight 102209 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102209/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-amd64-
Hi,
few months later Ingo decided again to give it a try as he really
doesn't want to keep ipv6 disabled in 2016.
He tried Xen 4.8 - which didn't help, the crash reappeared.
He then managed to build Xen with debug=y and soon it crashed with the
following output, which looks a little bit longer tha
Hi Andrew,
On Mon, Nov 14, 2016 at 03:06:12PM +, Andrew Cooper wrote:
> You have misunderstood a step.
>
> Dom0 can map all of guest memory. This is how `xl dump-core` is
> implemented, as well as how Qemu emulates devices for the guest.
Ah, okay, thanks. That is what I feared.
Due to deta
On 14/11/16 14:51, Andy Smith wrote:
> Hello,
>
> Please forgive me if this is a naive question but I do not know this
> low-level stuff very well.
>
> If the ability of the toolstack to dump a guest's memory (e.g. xl
> dump-core) were disabled on the hypervisor side, would there be any
> other way
>>> 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/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -643,6 +643,11 @@ void load_system_tables(void)
.
On 11/09/2016 04:01 PM, Boris Ostrovsky wrote:
> On 11/09/2016 02:58 PM, Andrew Cooper wrote:
>> On 09/11/16 15:14, Boris Ostrovsky wrote:
>>> On 11/09/2016 09:59 AM, Andrew Cooper wrote:
> diff --git a/xen/include/public/hvm/ioreq.h
> b/xen/include/public/hvm/ioreq.h
> index 2e5809b..
On 11/09/2016 02:47 PM, Boris Ostrovsky wrote:
> On 11/09/2016 02:23 PM, Andrew Cooper wrote:
>> On 09/11/16 15:29, Boris Ostrovsky wrote:
>>> On 11/09/2016 10:04 AM, Andrew Cooper wrote:
On 09/11/16 14:39, Boris Ostrovsky wrote:
> This domctl is called when a VCPU is hot-(un)plugged to a
Qdisk supports qcow and qcow2, extend it to also support qed disk
format.
Signed-off-by: Cédric Bosdonnat
---
tools/libxl/libxl_device.c |1 +
tools/libxl/libxl_dm.c |1 +
tools/libxl/libxl_types.idl |1 +
tools/libxl/libxl_utils.c |2 +
tools/libxl/libxlu_disk_l.c | 1018
Hello,
Please forgive me if this is a naive question but I do not know this
low-level stuff very well.
If the ability of the toolstack to dump a guest's memory (e.g. xl
dump-core) were disabled on the hypervisor side, would there be any
other way to do so from dom0 without rebooting the machine i
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/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -643,6 +643,11 @@ void load_system_tables(void)
>>> .limit = (IDT_ENTRIES * sizeof(idt_entry_t
>>> On 14.11.16 at 15:24, wrote:
On 14.11.16 at 14:45, wrote:
>> The BUILD_BUG_ON() is useful to retain, but I would suggest making
>> get_stack_bottom() a static inline and putting the BUILD_BUG_ON() there.
>
> I would agree if we were to not add back the BUG_ON(), but as
> per above I'm n
flight 102220 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102220/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bab82372a9e6ce066fa725a792e71d07191046ca
baseline version:
ovmf b17d5507cfdfd10c4f1f5
>>> On 14.11.16 at 14:45, wrote:
> On 14/11/16 13:25, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -643,6 +643,11 @@ void load_system_tables(void)
>> .limit = (IDT_ENTRIES * sizeof(idt_entry_t)) - 1,
>> };
>>
>> +/* Bottom-o
Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: Geliang Tang
---
drivers/xen/platform-pci.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index b59c9455..112ce42 100644
--- a/drivers/xen/platf
This run is configured for baseline tests only.
flight 68034 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68034/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b17d5507cfdfd10c4f1f5911ffe75fdc49fafa37
baseline v
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.
On Monday, November 14, 2016 5:22 PM, Dario Faggioli
wrote:
On Thu, 2016-11-10 at 18:20 +000
On Thu, 2016-11-10 at 18:20 +, Jason Long wrote:
> I mean is a nice GUI like VirtualBox.
>
It's certainly possible, and it would be nice. It's "just" that no one
has stepped up and started to do it. :-)
Personally, I think that, rather than developing something from
scratch, it would be a lot
On 14/11/16 13:25, Jan Beulich wrote:
> Commit 279840d5ea ("x86/boot: install trap handlers much earlier on
> boot"), perhaps not really intentionally, removed this check. Add it
No - that was deliberate. The check isn't useful (see below).
> back,
> - preventing it to trigger before any output
Commit 279840d5ea ("x86/boot: install trap handlers much earlier on
boot"), perhaps not really intentionally, removed this check. Add it
back,
- preventing it to trigger before any output is set up,
- accompanying it with a (weaker, due to its open coding of what
get_stack_bottom() does) build ti
On 14/11/16 11:38, Jan Beulich wrote:
On 14.11.16 at 12:01, wrote:
>> Luckily, hvm_hypervisor_cpuid_leaf() and vmx_hypervisor_cpuid_leaf() are safe
>> to execute in the context of a PV guest, but HVM-specific feature flags
>> shouldn't be visible to PV guests.
>>
>> Signed-off-by: Andrew Coop
>>> On 14.11.16 at 12:56, wrote:
> On 14/11/16 10:34, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -3438,6 +3438,53 @@ void grant_table_init_vcpu(struct vcpu *
>> v->maptrack_tail = MAPTRACK_TAIL;
>> }
>>
>> +#ifdef CONFIG_HAS_MEM_SHARING
>>
flight 102201 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102201/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 102160
test-armhf-armhf-libvirt-xs
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 in V4:
- use \Q\E for tests names
- write the full name of the tests to skip
- use push @ign
Hi,
I have looked into getting OpenStack been tested on the latest Xen via
osstest.
The ts-openstack-deploy script does prepare a bit more the host, clone
devstack and other OpenStack trees, then run ./stack.sh, which is a bit
like raisin and deploy OpenStack on the host. Once the machine is read
This patch should create a flight "openstack-nova", with those jobs:
build-amd64
build-amd64-xsm
build-amd64-pvops
build-amd64-libvirt
test-amd64-amd64-devstack
test-amd64-amd64-devstack-xsm
About the runvars revision_* of test-*-*-devstack:
only REVISION_OPENSTACK_NOVA is set, the o
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
---
Changes in V7:
- reindent
- fix style
- remove many workaround, there are not needed anymore.
- create bug report upstream
Changes
On Fri, Nov 11, 2016 at 12:42:52PM +, Lars Kurth wrote:
> Ronald,
> I am not sure whether you checked the Outreachy page and apologies for
> getting back late, but this project has been accepted. Let me know of your
> own blog and whether you'd be willing to write a guest blog or let me cover
flight 102214 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102214/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b17d5507cfdfd10c4f1f5911ffe75fdc49fafa37
baseline version:
ovmf 8677a56af68ea7fc93938
On 14/11/16 10:34, Jan Beulich wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3438,6 +3438,53 @@ void grant_table_init_vcpu(struct vcpu *
> v->maptrack_tail = MAPTRACK_TAIL;
> }
>
> +#ifdef CONFIG_HAS_MEM_SHARING
> +int mem_sharing_gref_to_gfn(struct grant_ta
>>> On 14.11.16 at 12:01, wrote:
> Luckily, hvm_hypervisor_cpuid_leaf() and vmx_hypervisor_cpuid_leaf() are safe
> to execute in the context of a PV guest, but HVM-specific feature flags
> shouldn't be visible to PV guests.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit ...
>>> On 14.11.16 at 12:01, wrote:
> %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 incorrect visibility of the SYSCALL feature
> in CPUID, and by extension,
>>> On 14.11.16 at 12:12, wrote:
> /proc/xen/xenbus does not work correctly. A read blocked waiting for
> a xenstore message holds the mutex needed for atomic file position
> updates. This blocks any writes on the same file handle, which can
> deadlock if the write is needed to unblock the read.
This run is configured for baseline tests only.
flight 68033 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68033/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8677a56af68ea7fc93938c710be2ec53752ae961
baseline v
From: Seth Forshee
Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export t
Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file. This is easiest to achive by clearing FMODE_ATOMIC_POS.
David
Changes in v5:
- Clear FMODE_ATOMIC_POS instead of using symlinks.
Changes in
/proc/xen/xenbus does not work correctly. A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates. This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.
Clear FMODE_ATOMIC_POS when opening this
%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 incorrect visibility of the SYSCALL feature
in CPUID, and by extension, incorrect behaviour in hvm_efer_valid().
S
Luckily, hvm_hypervisor_cpuid_leaf() and vmx_hypervisor_cpuid_leaf() are safe
to execute in the context of a PV guest, but HVM-specific feature flags
shouldn't be visible to PV guests.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/traps.c | 5 +
1 file chang
This run is configured for baseline tests only.
flight 68030 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68030/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 9 xen-boot/src_h
flight 102210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102210/
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.11.16 at 22:24, wrote:
> On Fri, Nov 04, 2016 at 10:51:33PM +0200, Andrushchenko, Oleksandr wrote:
>> + * Addressing
>> -
>> + *
>> + * Indices used to address frontends, driver instances, cards,
>> + * devices and streams.
They need to be range checked against the current table limit in any
event.
Reported-by: Huawei PSIRT
Move the code to where it belongs, eliminating a number of duplicate
definitions. Add locking. Produce proper error codes, and consume them
instead of making one up. Check grant type. Convert pa
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 instructions may end with
#GP(0) without that
> Could you define unacceptable performance drop? Have you tried to measure
> what would be the impact?
> I know it can be bad, depending on the class of protocols. I think that
> if numbers were provided to demonstrate that bounce buffers (the swiotlb
> in Linux) are too slow for a given use case
1 - 100 of 107 matches
Mail list logo
