Re: [Xen-devel] [PATCH v1] x86/hvm/viridian: flush remote tlbs by hypercall

>>> On 19.11.15 at 10:43, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -2452,6 +2452,13 @@ int hvm_vcpu_initialise(struct vcpu *v) > if ( rc != 0 ) > goto fail6; > > +if ( is_viridian_domain(d) ) > +{ > +rc =

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Thu, Nov 19, 2015 at 10:30:30AM +, Ian Campbell wrote: > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: > > On 18/11/15 15:49, Wei Liu wrote: > > > Hi Juergen > > > > > > Looks like there is something we missed after all. > > > > > > On Wed, Nov 18, 2015 at 02:31:57PM +,

[Xen-devel] [ovmf baseline-only test] 38308: all pass

This run is configured for baseline tests only. flight 38308 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38308/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 386cdfbecbbacb600ffc8e2ffa8c7af1b3855a61 baseline version:

[Xen-devel] [qemu-mainline baseline-only test] 38307: tolerable FAIL

This run is configured for baseline tests only. flight 38307 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38307/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl 21

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Hi, > > Another area of extension is how to expose a framebuffer to QEMU for > > seamless integration into a SPICE/VNC channel. For this I believe we > > could use a new region, much like we've done to expose VGA access > > through a vfio device file descriptor. An area within this new > >

[Xen-devel] [PATCH] tools/hotplug: quote all variables in vif-bridge

Cosmetics: most of the variables used in vif-bridge are already quoted. Add quoting also to the remaining shell variables. Signed-off-by: Olaf Hering Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian Campbell

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

>>> On 19.11.15 at 08:44, wrote: > >> -Original Message- >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Wednesday, November 18, 2015 6:11 PM >> To: Wu, Feng ; Jan Beulich >> Cc: Tian, Kevin

[Xen-devel] [PATCH] get_maintainer: fix perl 5.22/5.24 deprecated/incompatible "\C" use

From: Joe Perches Perl 5.22 emits a deprecated message when "\C" is used in a regex. Perl 5.24 will disallow it altogether. Fix it by using [A-Z] instead of \C. [ Upstream commit ce8155f7a3d59ce868ea16d8891edda4d865e873 ] Signed-off-by: Olaf Hering Cc: Ian

[Xen-devel] [linux-next test] 64723: regressions - FAIL

flight 64723 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/64723/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 64320

[Xen-devel] [tip:x86/urgent] x86/cpu: Fix SMAP check in PVOPS environments

Commit-ID: 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Gitweb: http://git.kernel.org/tip/581b7f158fe0383b492acd1ce3fb4e99d4e57808 Author: Andrew Cooper AuthorDate: Wed, 3 Jun 2015 10:31:14 +0100 Committer: Thomas Gleixner CommitDate: Thu, 19

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 20:02, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper 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

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, November 19, 2015 4:44 PM > To: Wu, Feng > Cc: Andrew Cooper ; ian.campb...@citrix.com; > wei.l...@citrix.com; george.dun...@eu.citrix.com; >

Re: [Xen-devel] [PATCH v2] xen/events: Always allocate legacy interrupts on PV guests

On 18/11/15 19:14, 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 PIC does not > exist, which is the case for Xen PV guests. > >

[Xen-devel] [PATCH v1] x86/hvm/viridian: flush remote tlbs by hypercall

The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend whether or not to issue a hypercall for local or remote TLB flush. Whilst it's doubtful whether using a hypercall for local TLB flush would be any more

[Xen-devel] [PATCH] x86/IO-APIC: fix setting of destinations

In commit a85da715cf ("x86/IO-APIC: adjust setting of destinations") I made a pretty blatant mistake: get_apic_id() can be used there only when running APICs in physical mode. For both flat and clustered modes the change was wrong, causing different kinds of boot problems on affected systems.

Re: [Xen-devel] [PATCH] sched_rt: Improved nested virtualization performance

Hi, Thanks Tianyang for the report and for the patch, and Meng for helping getting the patch itself on the list and to me, and for commenting. On Wed, 2015-11-18 at 22:38 -0500, Meng Xu wrote: > [cc. Dario...] > > 2015-11-18 22:24 GMT-05:00 Tianyang Chen : > > In nested

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 20:02, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper 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

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

Am 19.11.15 um 11:38 schrieb Andrew Cooper: On 19/11/15 10:24, Jan Beulich wrote: On 19.11.15 at 00:17, wrote: The disassembly of do_IRQ now looks like a plausible function, but the consistently faulting address has no plausible way of generating a double fault. I

[Xen-devel] [linux-linus test] 64733: regressions - trouble: blocked/broken/fail/pass

flight 64733 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/64733/ Regressions :-( 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. 59254

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvh-amd

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-pvh-amd testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

Re: [Xen-devel] bridge call iptables being forced

On 2015-11-19 12:46, Juan Rossi wrote: Hi I am sending this due the change of behaviour in some parts, and perhaps it needs some code amendments, unsure if the devel list is the best place, fell free to point me to the right place for this. Let me know if I should load a bug instead. I'm

Re: [Xen-devel] [PATCH 04/10] x86/hvm: pkeys, add pkeys support when setting CR4

> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Huaitong Han > Sent: Monday, November 16, 2015 6:32 PM > To: jbeul...@suse.com; andrew.coop...@citrix.com; Nakajima, Jun > ; Dong, Eddie

Re: [Xen-devel] Current LibXL Status

On 2015年11月19日 20:16, Ian Campbell wrote: On Thu, 2015-11-19 at 11:55 +, Ian Campbell wrote: On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote: On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote: The majority of those are cases are not appropriate uses of exit(). AFAIIR, the

[Xen-devel] [V11 3/3] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

From: Shuai Ruan This patch exposes xsaves/xgetbv1/xsavec to hvm guest. The reserved bits of eax/ebx/ecx/edx must be cleaned up when call cpuid(0dh) with leaf 1 or 2..63. According to the spec the following bits must be reserved: For leaf 1, bits 03-04/08-31 of ecx is

[Xen-devel] [V11 0/3] add xsaves/xrstors support

From: Shuai Ruan Changes in v11: * Address comments from Jan: * Using alternative asm on xrstor side. For xsave side(alternative asm), I will send a seperate patch to do this. Changes in v10: * Address comments from Jan: * Add two new macros to handle alternative asm

[Xen-devel] [V11 2/3] x86/xsaves: enable xsaves/xrstors for hvm guest

This patch enables xsaves for hvm guest, includes: 1.handle xsaves vmcs init and vmexit. 2.add logic to write/read the XSS msr. Add IA32_XSS_MSR save/rstore support. Signed-off-by: Shuai Ruan Reviewed-by: Jan Beulich --- xen/arch/x86/hvm/hvm.c

[Xen-devel] [V11 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen

This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor to perform the xsave_area switching so that xen itself can benefit from them when available. For xsaves/xrstors/xsavec only use compact format. Add format conversion support when perform guest os migration. Also, pv guest will not

[Xen-devel] [PATCH 1/3] libxl: add libxl_domain_config to libxlDomainObjPrivate

This new field in libxlDomainObjPrivate is named "config" and is kept while the domain is active. For now, "config" will be used in libxlDomainStartCallback to set network interface names based on domid and libxl_device_nic devid that is set in the config on domain create. Signed-off-by: Joao

[Xen-devel] [PATCH 2/3] libxl: rename libxlConsoleCallback

. to a more generic name i.e. libxlDomainStartCallback, since it will now cover another case other than the console. Signed-off-by: Joao Martins --- src/libxl/libxl_domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Xen-devel] [PATCH 0/3] libxl: implement virDomainInterfaceStats

Hey, As discussed yesterday, this patch series implements virDomainInterfaceStats but based on "ConsoleCallback" as opposed of doing it in libxlDomainStart. The series is divided as following: Patch 1 adds up domain config to libxlDomainObjPrivate, Patch 2 renames console callback to something

[Xen-devel] [PATCH 3/3] libxl: implement virDomainInterfaceStats

Introduce support for domainInterfaceStats API call for querying network interface statistics. Consequently it also enables the use of `virsh domifstat ` command plus seeing the interfaces names instead of "-" when doing `virsh domiflist `. After succesful guest creation we fill the network

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

On 19/11/2015 20:02, Atom2 wrote: > Am 19.11.15 um 02:06 schrieb Andrew Cooper: >> Thanks! That is what I was looking for. >> >> Sadly, it is less useful than I was hoping. The guest is not appearing >> to do anything interesting which causes the bad state; it is almost a >> full second between

[Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

Xen staging-4.6 crashes when booting on VMware Fusion 8.0.2 (with VT-x/EPT enabled), with 4 virtual CPUs: Loading xen-4.6-amd64.gz... ok Loading vmlinuz-3.14.51-grsec-dock... ok Loading initrd.img-3.14.51-grsec-dock... ok (XEN) Xen version 4.6.1-pre (Debian 4.6.1~pre-1skyport1) (

[Xen-devel] [xen-unstable-smoke test] 64861: tolerable all pass - PUSHED

flight 64861 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/64861/ 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 12

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Hi Kevin, On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Thursday, November 19, 2015 2:12 AM > > > > [cc +qemu-devel, +paolo, +gerd] > > > > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote: > > > Hi all, > > > > >

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

Am 19.11.15 um 02:06 schrieb Andrew Cooper: Thanks! That is what I was looking for. Sadly, it is less useful than I was hoping. The guest is not appearing to do anything interesting which causes the bad state; it is almost a full second between the previous action of note, and the crash. Can

Re: [Xen-devel] [PATCH seabios.git rel-1.7.5] fix release-1.7.5 for gcc5

On Fri, Oct 9, 2015 at 12:34 AM, Jan Beulich wrote: On 08.10.15 at 21:36, wrote: >> Signed-off-by: Mark Pryor > > Without any description I cannot see what is being fixed here, or why > there are _different_ comment changes on the

[Xen-devel] [PATCH v2 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_regs). Since we end up calling xen_iret from xen_sysexit we don't

[Xen-devel] [PATCH v2 2/3] x86: irq_enable_sysexit pv op is no longer needed

As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests" irq_enable_sysexit pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky ---

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On Thu, Nov 19, 2015 at 04:55:44PM -0500, Boris Ostrovsky wrote: > The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike > the > earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit > (and sysret32 in compat mode) pv ops, as suggested by Andy. > >

[Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky wrote: > The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike > the > earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit > (and sysret32 in compat mode) pv ops, as

[Xen-devel] [xen-unstable test] 64750: regressions - FAIL

flight 64750 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/64750/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64035

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 19/11/2015 09:40, Gerd Hoffmann wrote: >> > But this code should be >> > minor to be maintained in libvirt. > As far I know libvirt only needs to discover those devices. If they > look like sr/iov devices in sysfs this might work without any changes to > libvirt. I don't think they will

Re: [Xen-devel] missing block script support for qemu in libxl

> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Olaf Hering > Sent: 18 November 2015 09:45 > To: George Dunlap > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] missing block script support for qemu in libxl > >

[Xen-devel] [PATCH v2] x86/hvm/viridian: flush remote tlbs by hypercall

The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend whether or not to issue a hypercall for local or remote TLB flush. Whilst it's doubtful whether using a hypercall for local TLB flush would be any more

[Xen-devel] [distros-debian-wheezy test] 38310: all pass

flight 38310 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38310/ Perfect :-) All tests in this flight passed baseline version: flight 38270 jobs: build-amd64 pass build-armhf

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On 19/11/15 11:30, Ian Campbell wrote: > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: >> On 18/11/15 15:49, Wei Liu wrote: >>> Hi Juergen >>> >>> Looks like there is something we missed after all. >>> >>> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote: flight

Re: [Xen-devel] [PATCH v1] x86/hvm/viridian: flush remote tlbs by hypercall

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 19 November 2015 10:18 > To: Paul Durrant > Cc: Andrew Cooper; Ian Campbell; Wei Liu; Ian Jackson; Stefano Stabellini; > xen-de...@lists.xenproject.org; Keir (Xen.org) > Subject: Re: [PATCH v1] x86/hvm/viridian:

Re: [Xen-devel] Current LibXL Status

On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote: > On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote: > >   > > The majority of those are cases are not appropriate uses of exit(). > > AFAIIR, the *only* valid use of exit() in a library is to clean up in a > > child process from a

Re: [Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Wed, Nov 18, 2015 at 12:21:56PM -0800, Andy Lutomirski wrote: > Could we make this a little less subtle: > > ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp > .Lsyscasll_32_done", X86_FEATURE_XENPV > > Borislav, what do you think? I don't mind either. I would've said your version

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On 19/11/15 13:19, Wei Liu wrote: > On Thu, Nov 19, 2015 at 12:47:41PM +0100, Juergen Gross wrote: >> On 19/11/15 11:30, Ian Campbell wrote: >>> On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: On 18/11/15 15:49, Wei Liu wrote: > Hi Juergen > > Looks like there is something

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Thu, Nov 19, 2015 at 01:29:01PM +0100, Juergen Gross wrote: [...] > > To be precise, the problem is in mini-os, which is used by rump kernel > > as well. :-( > > > >> pvgrub is making assumptions about the page table allocation scheme > >> of the toolset starting pvgrub. It is calculating the

Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: flush remote tlbs by hypercall

>>> On 19.11.15 at 13:33, wrote: > +case HvFlushVirtualAddressSpace: > +case HvFlushVirtualAddressList: > +{ > +cpumask_var_t pcpu_mask; cpumask_t * (or else ... [skip next comment] > +struct vcpu *v; > + > +struct { Stray blank

Re: [Xen-devel] Current LibXL Status

create ! title it libxl exit() on ENOMEM incompatible with gc'd languages thanks On Thu, 2015-11-19 at 10:55 +, Andrew Cooper wrote: > On 19/11/15 09:20, Ian Campbell wrote: > > On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote: > > > > > I wanted to inquire about the current state of

[Xen-devel] Processed: Re: Current LibXL Status

Processing commands for x...@bugs.xenproject.org: > create ! Created new bug #51 rooted at `<1447932195.5647.46.ca...@citrix.com>' Title: `Re: [Xen-devel] Current LibXL Status' > title it libxl exit() on ENOMEM incompatible with gc'd languages Set title for #51 to `libxl exit() on ENOMEM

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On 19/11/15 11:30, Ian Campbell wrote: > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: >> On 18/11/15 15:49, Wei Liu wrote: >>> Hi Juergen >>> >>> Looks like there is something we missed after all. >>> >>> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote: flight

Re: [Xen-devel] Current LibXL Status

On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote: >  > The majority of those are cases are not appropriate uses of exit(). > AFAIIR, the *only* valid use of exit() in a library is to clean up in a > child process from a library-initiated fork(). ... or (in this case) in the

Re: [Xen-devel] [PATCH 0/3] Fix and cleanup for 32-bit PV sysexit

On Wed, Nov 18, 2015 at 03:06:16PM -0500, Boris Ostrovsky wrote: > The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike > the > earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit > (and sysret32 in compat mode) pv ops, as suggested by Andy. (I

Re: [Xen-devel] Current LibXL Status

On Thu, 2015-11-19 at 11:55 +, Ian Campbell wrote: > On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote: > > On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote: > > >   > > > The majority of those are cases are not appropriate uses of exit(). > > > AFAIIR, the *only* valid use of

[Xen-devel] [PATCH] tools/libxl: Drop dead code following calls to libxl__exec()

libxl__exec() doesn't ever return. Inform the compiler of this, and remove all dead code. No functional change. Signed-off-by: Andrew Cooper --- CC: Ian Campbell CC: Ian Jackson CC: Wei Liu

[Xen-devel] [PATCH] xen/arm: use masking operation instead of test_bit for MCSF bits

This is a follow of commit 90f2e2a307fc6a6258c39cc87b3b2bf9441c0fa7 "use masking operation instead of test_bit for MCSF bits" where the ARM changes were missing. Signed-off-by: Julien Grall --- xen/arch/arm/domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [Xen-devel] Current LibXL Status

On 19/11/15 11:23, Ian Campbell wrote: > create ! > title it libxl exit() on ENOMEM incompatible with gc'd languages > thanks Can this be extended to "should not use exit() in general" ? andrewcoop@andrewcoop:/local/xen.git/xen$ git grep exit\( -- :/tools/libxl/libxl*

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Thu, Nov 19, 2015 at 12:47:41PM +0100, Juergen Gross wrote: > On 19/11/15 11:30, Ian Campbell wrote: > > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: > >> On 18/11/15 15:49, Wei Liu wrote: > >>> Hi Juergen > >>> > >>> Looks like there is something we missed after all. > >>> > >>> On

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

>>> On 19.11.15 at 00:17, wrote: > The disassembly of do_IRQ now looks like a plausible function, but the > consistently faulting address has no plausible way of generating a > double fault. I suspect therefore that something has caused memory > corruption in Xen .text

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On 18/11/15 15:49, Wei Liu wrote: > Hi Juergen > > Looks like there is something we missed after all. > > On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote: >> flight 64494 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/64494/ >> >> Regressions

Re: [Xen-devel] Current LibXL Status

On Thu, Nov 19, 2015 at 9:20 AM, Ian Campbell wrote: > On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote: > >> I wanted to inquire about the current state of LibXL and in particular >> if there are any issues with using it in long-running processes. > > It is

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

On 19/11/15 10:24, Jan Beulich wrote: On 19.11.15 at 00:17, wrote: >> The disassembly of do_IRQ now looks like a plausible function, but the >> consistently faulting address has no plausible way of generating a >> double fault. I suspect therefore that something

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: > On 18/11/15 15:49, Wei Liu wrote: > > Hi Juergen > > > > Looks like there is something we missed after all. > > > > On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote: > > > flight 64494 xen-unstable real [real] > > >

Re: [Xen-devel] Current LibXL Status

On 19/11/15 09:20, Ian Campbell wrote: > On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote: > >> I wanted to inquire about the current state of LibXL and in particular >> if there are any issues with using it in long-running processes. > It is currently being used by libvirtd which I think

Re: [Xen-devel] 9p file system for xen

On Thu, Nov 19, 2015 at 09:55:00AM -0500, Neil Sikka wrote: > Is there any documentation about planned interfaces and API contracts for > people building around the virtio/9pfs layers? For example, while this is I assume that you're interested in getting 9pfs to work but don't care much about how

Re: [Xen-devel] 9p file system for xen

On Mon, Nov 16, 2015 at 08:02:35PM -0700, Linda wrote: > Hi Wei, > > On 11/16/2015 10:35 AM, Wei Liu wrote: > >On Mon, Nov 16, 2015 at 10:22:41AM -0700, Linda wrote: > ... > >> > >>The bug is a timing issue: During virtio's probe step, on the front end, it > >>initialized the mount path. Since

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Thu, 2015-11-19 at 10:50 +, Wei Liu wrote: > On Thu, Nov 19, 2015 at 10:30:30AM +, Ian Campbell wrote: > > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: > > > On 18/11/15 15:49, Wei Liu wrote: > > > > Hi Juergen > > > > > > > > Looks like there is something we missed after

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Thu, Nov 19, 2015 at 10:55:13AM +, Ian Campbell wrote: > On Thu, 2015-11-19 at 10:50 +, Wei Liu wrote: > > On Thu, Nov 19, 2015 at 10:30:30AM +, Ian Campbell wrote: > > > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote: > > > > On 18/11/15 15:49, Wei Liu wrote: > > > > > Hi

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 11/19/2015 11:52 PM, Alex Williamson wrote: On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote: On Thu, 19 Nov 2015, Jike Song wrote: Hi Alex, thanks for the discussion. In addition to Kevin's replies, I have a high-level question: can VFIO be used by QEMU for both KVM and Xen?

[Xen-devel] [xen-4.3-testing test] 64765: tolerable FAIL - PUSHED

flight 64765 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/64765/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail like 64434

[Xen-devel] [xen-4.6-testing test] 64755: regressions - FAIL

flight 64755 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/64755/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 5 xen-buildfail in 64352 REGR. vs. 63449 build-amd64-prev

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 11/19/2015 07:09 PM, Paolo Bonzini wrote: On 19/11/2015 09:40, Gerd Hoffmann wrote: But this code should be minor to be maintained in libvirt. As far I know libvirt only needs to discover those devices. If they look like sr/iov devices in sysfs this might work without any changes to

[Xen-devel] [libvirt test] 64762: regressions - FAIL

flight 64762 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/64762/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote: > On 11/19/2015 11:52 PM, Alex Williamson wrote: > > On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote: > >> On Thu, 19 Nov 2015, Jike Song wrote: > >>> Hi Alex, thanks for the discussion. > >>> > >>> In addition to Kevin's replies, I

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 11/20/2015 12:22 PM, Alex Williamson wrote: On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote: On 11/19/2015 11:52 PM, Alex Williamson wrote: On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote: On Thu, 19 Nov 2015, Jike Song wrote: Hi Alex, thanks for the discussion. In

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Song, Jike > Sent: Friday, November 20, 2015 1:52 PM > > On 11/20/2015 12:22 PM, Alex Williamson wrote: > > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote: > >> On 11/19/2015 11:52 PM, Alex Williamson wrote: > >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote: > On

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On Thu, 19 Nov 2015, Paolo Bonzini wrote: > On 19/11/2015 16:32, Stefano Stabellini wrote: > > > In addition to Kevin's replies, I have a high-level question: can VFIO > > > be used by QEMU for both KVM and Xen? > > > > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU > > is

Re: [Xen-devel] [Minios-devel] [PATCH v4 0/] Begin to disentangle libxenctrl and provide some stable libraries

On Wed, 21 Oct 2015, Ian Campbell wrote: > (Trimming CCs a bit) > > On Wed, 2015-10-21 at 16:22 +0100, Ian Campbell wrote: > > > [...] > > Still to come would be libraries for specific out of tree purposes > > (device model, kexec), which would be adding new library at the same > > level as

Re: [Xen-devel] 9p file system for xen

Hi Wei, On 11/19/2015 8:03 AM, Wei Liu wrote: On Thu, Nov 19, 2015 at 09:55:00AM -0500, Neil Sikka wrote: Is there any documentation about planned interfaces and API contracts for people building around the virtio/9pfs layers? For example, while this is I assume that you're interested in

[Xen-devel] [xen-4.4-testing test] 64766: tolerable FAIL - PUSHED

flight 64766 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/64766/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail REGR. vs. 64150

Re: [Xen-devel] HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2

>>> On 19.11.15 at 20:51, wrote: > In terms of non-standard options passed to gcc I have tried to make sense of > what flags are actually being used during the build process. I am not > absolutely sure, but I think the options passed to gcc are as follows: > > I do have

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Thursday, November 19, 2015 4:41 PM > > Hi, > > > > Another area of extension is how to expose a framebuffer to QEMU for > > > seamless integration into a SPICE/VNC channel. For this I believe we > > > could use a new region, much like

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, November 20, 2015 4:03 AM > > > > > > > The proposal is therefore that GPU vendors can expose vGPUs to > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio > > > supports modular bus drivers and

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On Thu, 19 Nov 2015, Jike Song wrote: > Hi Alex, thanks for the discussion. > > In addition to Kevin's replies, I have a high-level question: can VFIO > be used by QEMU for both KVM and Xen? No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU is owned by Xen.

Re: [Xen-devel] [PATCH v3] x86/hvm/viridian: flush remote tlbs by hypercall

>>> On 19.11.15 at 14:19, wrote: > The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines > two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend > whether or not to issue a hypercall for local or remote TLB flush. > > Whilst it's

Re: [Xen-devel] Current LibXL Status

On Thu, Nov 19, 2015 at 11:23 AM, Ian Campbell wrote: > create ! > title it libxl exit() on ENOMEM incompatible with gc'd languages > thanks Actually, can I suggest that someone send a new thread with an appropriate title, so that people who aren't directly following the

[Xen-devel] x86/mm patch ping

George, could I please get an ack or otherwise on http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00764.html http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00765.html ? While the latter has been reviewed by Andrew, it would feel wrong to commit it without your ack,

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 19/11/2015 16:32, Stefano Stabellini wrote: > > In addition to Kevin's replies, I have a high-level question: can VFIO > > be used by QEMU for both KVM and Xen? > > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU > is owned by Xen. I don't think QEMU command line

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote: > On Thu, 19 Nov 2015, Jike Song wrote: > > Hi Alex, thanks for the discussion. > > > > In addition to Kevin's replies, I have a high-level question: can VFIO > > be used by QEMU for both KVM and Xen? > > No. VFIO cannot be used with

[Xen-devel] [PATCH] minios: don't rely on specific page table allocation scheme

Today mini-os is making assumptions how the page tables it is started with are being allocated. Especially it is using the number of page table frames to calculate which is the first unmapped pfn. Instead of relying on page table number assumptions just look into the page tables to find the first

Re: [Xen-devel] [PATCH v3] x86/hvm/viridian: flush remote tlbs by hypercall

On 19/11/15 13:19, Paul Durrant wrote: > @@ -561,10 +584,81 @@ int viridian_hypercall(struct cpu_user_regs *regs) > switch ( input.call_code ) > { > case HvNotifyLongSpinWait: > +/* > + * See Microsoft Hypervisor Top Level Spec. section 18.5.1. > + */ >

[Xen-devel] [PATCH] libxl: correct bug in domain builder regarding page tables for pvh

Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of domain builder's page table handler") dropped a special case for pvh resulting in page tables being mapped read-only. This led to a panic of the domain in early boot. Correct this error. Signed-off-by: Juergen Gross

[Xen-devel] [PATCH] tools/libxc: Correct XC_DOM_PAGE_SIZE() to return a long long

c/s abdf3c5b "libxc: create p2m list outside of kernel mapping if supported" introduces a use which Coverity objects to; an int used to mask a uint64_t. The result needs to be signed to allow ~XC_DOM_PAGE_SIZE() to function correctly, and long long to function properly in 32bit builds.

Re: [Xen-devel] 9p file system for xen

Is there any documentation about planned interfaces and API contracts for people building around the virtio/9pfs layers? For example, while this is still getting debugged/checked in, in order to build DomU support for these devices, the expected API contracts/interfaces would need to be known. On

  1   2   >