[Xen-devel] [distros-debian-snapshot test] 44321: tolerable trouble: blocked/broken

flight 44321 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44321/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 44284 build-armhf

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: From: Tamas K Lengyel The ARM SMC instructions are already configured to trap to Xen by default. In this patch we allow a user-space process in a privileged domain to receive notification of when such event happens through the vm_event subsystem. T

[Xen-devel] [sh_eth.c] Problem in dma_map_single()

Hi, I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it doesn't work. The root cause of the problem is that driver cannot satisfy the condition of dma_capable(). I found the same problem in the mailing list, but the problem is still remaining I guess. previous mail: ( http://lists

Re: [Xen-devel] xenpm and scheduler

On Tue, 2016-04-12 at 03:52 +, tutu sky wrote: > Thanks Xu. I will do as desired about cross messaging. > > i need it because i exactly want to know that which part of the > scheduler's corde (credit), takes effect from this feature. because > it is important to me knowing that where would be

Re: [Xen-devel] [PATCH v7] xSplice v1 design and implementation.

On 04/11/2016 04:43 PM, Konrad Rzeszutek Wilk wrote: On Mon, Apr 11, 2016 at 10:32:20AM -0400, Konrad Rzeszutek Wilk wrote: *Hypervisor Maintainers* Jan, the hypervisor patches #2, #5-#17, #21-#23 need your Ack. s/Ack./Ack please./ *Are there any TODOs left from v5 or v6 reviews?* One I hop

Re: [Xen-devel] pv-grub guest booting fail with recent qemu-xen

On Tue, Apr 12, 2016 at 01:56:50AM +, Hao, Xudong wrote: > > -Original Message- > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: Monday, April 11, 2016 6:54 PM > > To: Samuel Thibault ; Wei Liu > > ; Hao, Xudong ; Konrad > > Rzeszutek Wilk ; xen-devel@lists.xen.org; > > stefano.

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

Wei, thanks for your help. After following your advice I added to the DomU config the 'device_model_version = "qemu-xen-traditional"' (and removing 'device_model_stubdomain_override'), the DomU started successfully as without stub domain: (d18) Press F12 for boot menu. (d18) (d18) Booting from H

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

On Tue, Apr 05, 2016 at 05:17:00PM +0200, Fanny Dwargee wrote: > Hi, > > after adding the 'device_model_stubdomain_override = 1' to an otherwise > fine configuration the domain crashes on start. > > Xen is v4.6.1 compiled from source on Debian Jessie 64bits this way: > >- ./configure --enabl

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

On 04/08/16 09:52, Jan Beulich wrote: > >>> On 08.04.16 at 07:02, wrote: > > On 03/29/16 04:49, Jan Beulich wrote: > >> >>> On 29.03.16 at 12:10, wrote: > >> > On 03/29/16 03:11, Jan Beulich wrote: > >> >> >>> On 29.03.16 at 10:47, wrote: > > [..] > >> >> > I still cannot find a neat approach to

Re: [Xen-devel] [PATCH v7.2 07/24] x86/mm: Introduce modify_xen_mappings()

On 11/04/16 18:54, Jan Beulich wrote: On 11.04.16 at 19:46, wrote: >> To simply change the permissions on existing Xen mappings. The existing >> destroy_xen_mappings() is altered to support a change the PTE permissions. >> >> A new destroy_xen_mappings() is introduced, as the special case of

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

On 12/04/16 05:26, Razvan Cojocaru wrote: > On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote: >> On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote: >>> This patch only allows introspection-related MSR write events to >>> be sent out, improving performance. Should additional events be >>

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

Wei, It works now! Many, many thanks for your invaluable time. By the way, Do you know when the patch will be included in the stable-4.6 branch? Maybe will be on time for the 4.6.2 version? IMHO is an important patch because of the added security shielding it provides (allowing the use of stub

Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

On 4/12/2016 12:31 AM, Jan Beulich wrote: On 11.04.16 at 13:14, wrote: On 4/9/2016 6:28 AM, Jan Beulich wrote: On 31.03.16 at 12:53, wrote: @@ -168,13 +226,72 @@ static int hvmemul_do_io( break; case X86EMUL_UNHANDLEABLE: { -struct hvm_ioreq_server *s = -

Re: [Xen-devel] Stub domain crash on Xen v4.6.1

On Tue, Apr 12, 2016 at 11:44:16AM +0200, Fanny Dwargee wrote: > Wei, > > It works now! > Good to know. > Many, many thanks for your invaluable time. > You're welcome. > By the way, Do you know when the patch will be included in the stable-4.6 > branch? Maybe will be on time for the 4.6.2 ve

[Xen-devel] [PATCH 0/2] xenfb bug fix and clean up

Wei Liu (2): xenfb: use the correct condition to avoid excessive looping xenfb: remove out_cons in xenfb_handle_events hw/display/xenfb.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel

[Xen-devel] [PATCH 2/2] xenfb: remove out_cons in xenfb_handle_events

The variable out_cons was only used to temporarily hold the consumer index. Use cons directly to simplify code a bit. No functional change introduced. Signed-off-by: Wei Liu --- Cc: Stefano Stabellini Cc: Anthony Perard --- hw/display/xenfb.c | 8 1 file changed, 4 insertions(+), 4 d

[Xen-devel] [PATCH 1/2] xenfb: use the correct condition to avoid excessive looping

In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <= out_cons"), ">=" was used. In fact, a full ring is a legit state. Correct the test to use ">". Reported-by: "Hao, Xudong" Signed-off-by: Wei Liu Tested-by: "Hao, Xudong" --- Cc: Stefano Stabellini Cc: Anthony Perard Backport ca

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich wrote: [snip] >> ISTM that the lower duplication (which in principle is an advantage >> which will be time limited if we are ever able to completely remove >> teh old hypercall) comes with the cost of (in the long term) increased >> mess in this particu

Re: [Xen-devel] [PATCH 2/2] xenfb: remove out_cons in xenfb_handle_events

On 12/04/16 10:57, Wei Liu wrote: > The variable out_cons was only used to temporarily hold the consumer > index. Use cons directly to simplify code a bit. > > No functional change introduced. > > Signed-off-by: Wei Liu > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > --- > hw/display/xenf

Re: [Xen-devel] [PATCH 2/2] xenfb: remove out_cons in xenfb_handle_events

On Tue, Apr 12, 2016 at 10:59:53AM +0100, Andrew Cooper wrote: > On 12/04/16 10:57, Wei Liu wrote: > > The variable out_cons was only used to temporarily hold the consumer > > index. Use cons directly to simplify code a bit. > > > > No functional change introduced. > > > > Signed-off-by: Wei Liu >

Re: [Xen-devel] [PATCH 1/2] xenfb: use the correct condition to avoid excessive looping

On Tue, Apr 12, 2016 at 10:57:16AM +0100, Wei Liu wrote: > In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <= > out_cons"), ">=" was used. In fact, a full ring is a legit state. > Correct the test to use ">". > > Reported-by: "Hao, Xudong" > Signed-off-by: Wei Liu > Tested-by: "Hao

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

On 04/12/2016 12:38 PM, Andrew Cooper wrote: > On 12/04/16 05:26, Razvan Cojocaru wrote: >> On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote: >>> On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote: This patch only allows introspection-related MSR write events to be sent out, im

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

On 12/04/16 11:17, Razvan Cojocaru wrote: > On 04/12/2016 12:38 PM, Andrew Cooper wrote: >> On 12/04/16 05:26, Razvan Cojocaru wrote: >>> On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote: On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote: > This patch only allows introspection-

[Xen-devel] [linux-3.16 test] 90920: regressions - FAIL

flight 90920 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/90920/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 85048 Tests which are

[Xen-devel] [linux-linus test] 90908: regressions - FAIL

flight 90908 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/90908/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 build-amd64-rumpuserx

[Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

It should be placed before first time producer and consumer are used. Signed-off-by: Wei Liu --- Cc: Stefano Stabellini Cc: Anthony Perard Backport candidate to our own tree. --- hw/display/xenfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/display/xenfb.c b/hw/dis

[Xen-devel] [PATCH v2 0/3] xenfb bug fixes and cleanup

Wei Liu (3): xenfb: use the correct condition to avoid excessive looping xenfb: move xen_rmb to the correct location xenfb: remove out_cons in xenfb_handle_events hw/display/xenfb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) -- 2.1.4 ___

[Xen-devel] [PATCH v2 3/3] xenfb: remove out_cons in xenfb_handle_events

The variable out_cons was only used to temporarily hold the consumer index. Use cons directly to simplify code a bit. No functional change introduced. Signed-off-by: Wei Liu --- Cc: Stefano Stabellini Cc: Anthony Perard --- hw/display/xenfb.c | 8 1 file changed, 4 insertions(+), 4 d

[Xen-devel] [PATCH v2 1/3] xenfb: use the correct condition to avoid excessive looping

In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <= out_cons"), ">=" was used. In fact, a full ring is a legit state. Correct the test to use ">". Reported-by: "Hao, Xudong" Signed-off-by: Wei Liu Tested-by: "Hao, Xudong" Acked-by: Anthony Perard --- Cc: Stefano Stabellini Cc: An

Re: [Xen-devel] xenpm and scheduler

Thanks Dario, Yeah, I do like playing with xenpm and try understanding relationship between this and scheduler. but i established a xen environment on vmware, but xenpm does not work correctly and even for 'cpufreq', it is silent at all! so it does not let me try to play with :(. I asked this pr

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

On 12/04/16 11:43, Wei Liu wrote: > It should be placed before first time producer and consumer are used. This change isn't necessary and is confusing as this is not what this barrier is for. The barrier needs to be between the load of prod and the load of the ring contents (there's even a commen

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

On Thu, Mar 10, Juergen Gross wrote: > +#define NUM_RMCPU_BUSY_RETRIES 5 > + > int xc_cpupool_removecpu(xc_interface *xch, > uint32_t poolid, > int cpu) > { > +unsigned retries; > +int err; > DECLARE_SYSCTL; > > sysctl.cmd =

Re: [Xen-devel] [PATCHv7] x86/ept: defer the invalidation until the p2m lock is released

On 03/02/16 03:44, Tian, Kevin wrote: >> From: David Vrabel [mailto:david.vra...@citrix.com] >> Sent: Tuesday, February 02, 2016 12:27 AM Looks like I forgot about this patch. >> It is safe to defer the invalidate until the p2m lock is released >> except for two cases: >> >> 1. When freeing a pag

Re: [Xen-devel] [for-4.7 v2 1/5] drivers/pl011: ACPI: The interrupt should always be high level triggered

On Tue, Apr 12, 2016 at 09:00:42AM +0800, Shannon Zhao wrote: > > > On 2016/4/11 22:07, Konrad Rzeszutek Wilk wrote: > > On Mon, Apr 11, 2016 at 02:33:33PM +0100, Julien Grall wrote: > >> The SPCR does not specify if the interrupt is edge or level triggered. > >> So the configuration needs to be

[Xen-devel] [linux-3.18 test] 90979: regressions - FAIL

flight 90979 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/90979/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86513 test-amd64-i386

Re: [Xen-devel] xenpm and scheduler

On Tue, Apr 12, 2016 at 11:50:42AM +, tutu sky wrote: > Thanks Dario, > Yeah, I do like playing with xenpm and try understanding relationship between > this and scheduler. but i established a xen environment on vmware, but xenpm > does not work correctly and even for 'cpufreq', it is silent a

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

On 12/04/16 15:02, Olaf Hering wrote: > On Thu, Mar 10, Juergen Gross wrote: > >> +#define NUM_RMCPU_BUSY_RETRIES 5 >> + >> int xc_cpupool_removecpu(xc_interface *xch, >> uint32_t poolid, >> int cpu) >> { >> +unsigned retries; >> +int e

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

On Tue, Apr 12, Juergen Gross wrote: > IMO this is a compiler bug. The compiler could detect easily that err > can't be uninitialized at the return statement (e.g. via loop > unrolling). There is another place like that in blktap2. There was some discussion about -Og usage in tools, not sure if i

Re: [Xen-devel] [PATCH v4 1/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case

On Tue, Apr 12, 2016 at 03:45:06PM +0200, Juergen Gross wrote: > On 12/04/16 15:02, Olaf Hering wrote: > > On Thu, Mar 10, Juergen Gross wrote: > > > >> +#define NUM_RMCPU_BUSY_RETRIES 5 > >> + > >> int xc_cpupool_removecpu(xc_interface *xch, > >> uint32_t poolid, > >>

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

On 12/04/16 13:57, David Vrabel wrote: > On 12/04/16 11:43, Wei Liu wrote: >> It should be placed before first time producer and consumer are used. > This change isn't necessary and is confusing as this is not what this > barrier is for. > > The barrier needs to be between the load of prod and the

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Tue, Apr 12, 2016 at 10:58:09AM +0100, George Dunlap wrote: > On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich wrote: > [snip] > >> ISTM that the lower duplication (which in principle is an advantage > >> which will be time limited if we are ever able to completely remove > >> teh old hypercall) co

[Xen-devel] [PATCH] tools: fix compile errors with -Og

At least gcc-4.8 and older fails to recognize that err is always initialized, the build fails: xc_cpupool.c: In function 'xc_cpupool_removecpu': xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this function [-Werror=maybe-uninitialized] return err; Fix this in blktap2 and li

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

On Tue, Apr 12, 2016 at 02:38:13PM +0100, Andrew Cooper wrote: > On 12/04/16 13:57, David Vrabel wrote: > > On 12/04/16 11:43, Wei Liu wrote: > >> It should be placed before first time producer and consumer are used. > > This change isn't necessary and is confusing as this is not what this > > barr

Re: [Xen-devel] Question about the XEN platform pci

On Tue, Apr 12, 2016 at 02:19:48AM +, Wu, Bob wrote: > > Really thanks for your reply. Hey! CC-ing Xen-devel back on. Please do not drop it and please don't top-post. > > Can you explain a little more? I am not sure what you want me to explain. Perhaps if you read http://xenbits.xen.org/do

[Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

Previously, subscribing to MSR write events was an all-or-none approach, with special cases for introspection MSR-s. This patch allows the vm_event consumer to specify exactly what MSR-s it is interested in, and as a side-effect gets rid of the vmx_introspection_force_enabled_msrs[] special case. T

Re: [Xen-devel] [PATCH v2] docs: add misc/qemu-backends.txt

On Mon, Apr 11, 2016 at 03:04:09PM +0200, Juergen Gross wrote: > Document the interface between qemu and libxl regarding backends > supported by qemu. > > Signed-off-by: Juergen Gross Reviewed-by: Wei Liu > --- > v2: - replace variable Xenstore path parts () with bash-like syntax > ($XYZ

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk wrote: >> 3. We could use a new hypercall only for new functionality, with the >> proposed new semantics. This would at minimum be build-id, but >> probably also extraversion, compileinfo, changeset, maybe >> capabilities_info. >> >> 4. Have

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

Hello Razvan, On 12/04/2016 15:34, Razvan Cojocaru wrote: Previously, subscribing to MSR write events was an all-or-none approach, with special cases for introspection MSR-s. This patch allows the vm_event consumer to specify exactly what MSR-s it is interested in, and as a side-effect gets rid

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

On 04/12/2016 05:42 PM, Julien Grall wrote: > Hello Razvan, > > On 12/04/2016 15:34, Razvan Cojocaru wrote: >> Previously, subscribing to MSR write events was an all-or-none >> approach, with special cases for introspection MSR-s. This patch >> allows the vm_event consumer to specify exactly what

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On Mon, Apr 11, 2016 at 01:47:22PM -0600, Tamas K Lengyel wrote: > From: Tamas K Lengyel > > The ARM SMC instructions are already configured to trap to Xen by default. In > this patch we allow a user-space process in a privileged domain to receive > notification of when such event happens through

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Tue, Apr 12, 2016 at 03:38:31PM +0100, George Dunlap wrote: > On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk > wrote: > >> 3. We could use a new hypercall only for new functionality, with the > >> proposed new semantics. This would at minimum be build-id, but > >> probably also extrave

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On Apr 12, 2016 01:51, "Corneliu ZUZU" wrote: > > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: >> >> From: Tamas K Lengyel >> >> The ARM SMC instructions are already configured to trap to Xen by default. In >> this patch we allow a user-space process in a privileged domain to receive >> notifica

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On Apr 11, 2016 22:31, "Jan Beulich" wrote: > > >>> Tamas K Lengyel 04/11/16 9:47 PM >>> > >--- a/xen/include/public/vm_event.h > >+++ b/xen/include/public/vm_event.h > >@@ -166,6 +166,31 @@ struct vm_event_regs_x86 { > >uint32_t _pad; > >}; > > > >+struct vm_event_regs_arm { > >+uint3

Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

>>> "Yu, Zhang" 04/12/16 11:47 AM >>> >On 4/12/2016 12:31 AM, Jan Beulich wrote: > On 11.04.16 at 13:14, wrote: >>> On 4/9/2016 6:28 AM, Jan Beulich wrote: >>> On 31.03.16 at 12:53, wrote: > +if ( s->id == id ) > +{ > +rc = p2m_set_ioreq_server(d,

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

>>> George Dunlap 04/12/16 11:58 AM >>> >On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich wrote: >>> ISTM that the lower duplication (which in principle is an advantage >>> which will be time limited if we are ever able to completely remove >>> teh old hypercall) comes with the cost of (in the long t

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On Apr 12, 2016 08:58, "Konrad Rzeszutek Wilk" wrote: > > On Mon, Apr 11, 2016 at 01:47:22PM -0600, Tamas K Lengyel wrote: > > From: Tamas K Lengyel > > > > The ARM SMC instructions are already configured to trap to Xen by default. In > > this patch we allow a user-space process in a privileged d

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

> >> @@ -254,6 +279,7 @@ typedef struct vm_event_st { > > >union { > > >union { > > >struct vm_event_regs_x86 x86; > >> +struct vm_event_regs_arm arm; > > >} regs; > > > > Does this alter the x86 ABI? Perhaps the ARM structure is small enough

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Tue, Apr 12, 2016 at 09:17:29AM -0600, Jan Beulich wrote: > >>> George Dunlap 04/12/16 11:58 AM >>> > >On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich wrote: > >>> ISTM that the lower duplication (which in principle is an advantage > >>> which will be time limited if we are ever able to completel

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

>>> George Dunlap 04/12/16 4:38 PM >>> >On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk > wrote: >> options (1-4) seem perfectly fine to me. FWIW my preferred color >> would probably be 1 because it's the easiest and least inconsistent >> with the current state of things. My least favorit

Re: [Xen-devel] Question about the XEN platform pci

The INTx interrupt of this platform device can be used by Xen in HVM case to notify the guest of pending events in the event channel. However that's usually not used in favor of vector callbacks support in Xen where a vector is injected directly to the vCPU bypassing LAPIC. (that said, the platfor

Re: [Xen-devel] Question about the XEN platform pci

On Tue, Apr 12, 2016 at 05:33:47PM +0200, karim.allah.ah...@gmail.com wrote: > The INTx interrupt of this platform device can be used by Xen in HVM case to > notify the guest of pending events in the event channel. However that's > usually > not used in favor of vector callbacks support in Xen whe

Re: [Xen-devel] [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM

Hi George, On 11/04/2016 10:52, George Dunlap wrote: On Fri, Apr 8, 2016 at 6:58 PM, Andrew Cooper wrote: On 08/04/16 16:49, Jan Beulich wrote: On 08.04.16 at 12:42, wrote: On 04/04/16 19:48, Benjamin Sanda wrote: +else +{ +/* retrieve the page to determine read/write or re

[Xen-devel] [ovmf test] 91000: regressions - FAIL

flight 91000 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91000/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovm

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

Hello Tamas, On 12/04/2016 16:05, Tamas K Lengyel wrote: On Apr 11, 2016 22:31, "Jan Beulich" mailto:jbeul...@suse.com>> wrote: > > >>> Tamas K Lengyel mailto:ta...@tklengyel.com>> 04/11/16 9:47 PM >>> [...] > > >+uint64_t ttbr0; > >+uint64_t ttbr1; > >+uint32_t _pad; > >+

[Xen-devel] [PATCH v2] xen: change the sizes of memory fields in the HVM start info to be 64bits

At the moment the only consumer of this structure is x86, but other arches might also use it, so make all the fields 64bits. On x86 Xen will still try to place everything below the 4GiB boundary, but that might not be feasible in other arches. Signed-off-by: Roger Pau Monné Requested-by: Jan Beul

Re: [Xen-devel] Question about the XEN platform pci

Please don't top post. On Tue, Apr 12, 2016 at 05:33:47PM +0200, karim.allah.ah...@gmail.com wrote: > The INTx interrupt of this platform device can be used by Xen in HVM case to > notify the guest of pending events in the event channel. However that's > usually > not used in favor of vector call

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

flight 91132 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/91132/ 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] [PATCH 09/46] tools/hotplug: use XEN_LOCK_DIR instead of hardcoded path

On Mon, Apr 11, George Dunlap wrote: > if [ -d ${XEN_LOCK_DIR}/subsys ] ; then > LOCKFILE=${XEN_LOCK_DIR}/subsys/xendomains > else > LOCKFILE=${XEN_LOCK_DIR}/xendomains > fi This will probably work, yes. Olaf ___ Xen-devel mailing list Xen-dev

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

Hello, On 12/04/2016 16:01, Tamas K Lengyel wrote: On Apr 12, 2016 01:51, "Corneliu ZUZU" mailto:cz...@bitdefender.com>> wrote: > > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: >> >> From: Tamas K Lengyel mailto:tkleng...@sec.in.tum.de>> >> >> The ARM SMC instructions are already configu

Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

(CC Stefano and Konrad) On 12/04/2016 08:54, Wonseok Ko wrote: Hi, I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it doesn't work. The root cause of the problem is that driver cannot satisfy the condition of dma_capable(). I found the same problem in the mailing list, but the

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."): > Well we know which option Andy prefers, but are there other options > that Andy is not absolutely opposed to? And we don't know

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On 4/12/2016 7:24 PM, Julien Grall wrote: Hello, On 12/04/2016 16:01, Tamas K Lengyel wrote: On Apr 12, 2016 01:51, "Corneliu ZUZU" mailto:cz...@bitdefender.com>> wrote: > > On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: >> >> From: Tamas K Lengyel mailto:tkleng...@sec.in.tum.de>> >> >> T

Re: [Xen-devel] xenpm and scheduler

Thanks Konrad. I will do :) Yeah, I believe so. as i can see that there is not any bios settings for power management in there (vmware). I hope you be the correct party which i want to ask this question: there is a tutorial here in this page: 1) http://xenserver.org/partners/developing-products

Re: [Xen-devel] xenpm and scheduler

On Tue, Apr 12, 2016 at 05:04:04PM +, tutu sky wrote: > Thanks Konrad. I will do :) > Yeah, I believe so. as i can see that there is not any bios settings for > power management in there (vmware). I hope you be the correct party which i > want to ask this question: there is a tutorial here i

Re: [Xen-devel] [sh_eth.c] Problem in dma_map_single()

On Tue, Apr 12, 2016 at 04:54:55PM +0900, Wonseok Ko wrote: > Hi, > > I'm trying to enable ethernet driver in Domain0 for R-Car H2, but it > doesn't work. The root cause of the problem is that driver cannot satisfy > the condition of dma_capable(). I found the same problem in the mailing So what

Re: [Xen-devel] [PATCH v2 1/3] xenfb: use the correct condition to avoid excessive looping

On Tue, 12 Apr 2016, Wei Liu wrote: > In commit ac0487e1 ("xenfb.c: avoid expensive loops when prod <= > out_cons"), ">=" was used. In fact, a full ring is a legit state. > Correct the test to use ">". > > Reported-by: "Hao, Xudong" > Signed-off-by: Wei Liu > Tested-by: "Hao, Xudong" > Acked-by

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

On Tue, Apr 12, 2016 at 11:05 AM, Corneliu ZUZU wrote: > On 4/12/2016 7:24 PM, Julien Grall wrote: > >> Hello, >> >> On 12/04/2016 16:01, Tamas K Lengyel wrote: >> >>> >>> On Apr 12, 2016 01:51, "Corneliu ZUZU" >> > wrote: >>> > >>> > On 4/11/2016 10:47 PM, Tamas K

Re: [Xen-devel] [PATCH v2 2/3] xenfb: move xen_rmb to the correct location

On Tue, 12 Apr 2016, Wei Liu wrote: > On Tue, Apr 12, 2016 at 02:38:13PM +0100, Andrew Cooper wrote: > > On 12/04/16 13:57, David Vrabel wrote: > > > On 12/04/16 11:43, Wei Liu wrote: > > >> It should be placed before first time producer and consumer are used. > > > This change isn't necessary and

Re: [Xen-devel] [PATCH v2 3/3] xenfb: remove out_cons in xenfb_handle_events

On Tue, 12 Apr 2016, Wei Liu wrote: > The variable out_cons was only used to temporarily hold the consumer > index. Use cons directly to simplify code a bit. > > No functional change introduced. > > Signed-off-by: Wei Liu Except for the fact that it is based on patch #2, which is wrong, this lo

Re: [Xen-devel] xenpm and scheduler

yeah, running xenpm gives short comments on its commands and their options but not about how to establish it. I try my best for this :) thanks a lot. From: Konrad Rzeszutek Wilk Sent: Tuesday, April 12, 2016 5:08 PM To: tutu sky Cc: Dario Faggioli; Meng

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

> > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > index 1fec412..1be058a 100644 > --- a/xen/arch/x86/monitor.c > +++ b/xen/arch/x86/monitor.c > @@ -20,6 +20,7 @@ > */ > > #include > +#include > #include > > int arch_monitor_domctl_event(struct domain *d, > @@ -77,25 +78,25

Re: [Xen-devel] [PATCH] vm_event: Allow subscribing to write events for specific MSR-s

On 04/12/16 20:49, Tamas K Lengyel wrote: > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > index 1fec412..1be058a 100644 > --- a/xen/arch/x86/monitor.c > +++ b/xen/arch/x86/monitor.c > @@ -20,6 +20,7 @@ > */ > > #include > +#include > #incl

[Xen-devel] [PATCHv8 0/1] x86/ept: reduce translation invalidation impact

This series improves the performance of EPT by further reducing the impact of the translation invalidations (ept_sync_domain()). By: a) Deferring invalidations until the p2m write lock is released. Prior to this change a 16 VCPU guest could not be successfully migrated on an (admittedly slow) 160

[Xen-devel] [PATCHv8] x86/ept: defer the invalidation until the p2m lock is released

Holding the p2m lock while calling ept_sync_domain() is very expensive since it does an on_selected_cpus() call. IPIs on many socket machines can be very slow and on_selected_cpus() is serialized. It is safe to defer the invalidate until the p2m lock is released except for two cases: 1. When fre

Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

Yes, I have been shuffling this struct around and didn't check the >> layout. Will fix. I'll also try to make this struct usable for aarch64 >> too. >> > > You may want to give a look to vcpu_guest_core_regs in public/arch-arm.h > Thanks, so the easiest way to be compatible with both it seems is t

Re: [Xen-devel] [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On Mon, Apr 11, 2016 at 09:49:56AM -0400, Boris Ostrovsky wrote: > On 04/08/2016 07:40 PM, Luis R. Rodriguez wrote: > > diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h > index 1ae89a2721d6..8bb8c1a4615a 100644 > --- a/arch/x86/include/asm/x86_init.h > +++ b/arch/x86/

Re: [Xen-devel] [PATCH v7] xSplice v1 design and implementation.

On Mon, Apr 11, 2016 at 10:32:20AM -0400, Konrad Rzeszutek Wilk wrote: > > *Hypervisor Maintainers* > > > > Jan, the hypervisor patches #2, #5-#17, #21-#23 need your Ack. > > s/Ack./Ack please./ > > *Are there any TODOs left from v5 or v6 reviews?* > > > > One I hope can be deferred - that is xens

[Xen-devel] [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup

The current mechanism is geared towards fast virtual address -> symbol names lookup. This is fine for the normal use cases (BUG_ON, WARN_ON, etc), but for xSplice - where we need to find hypervisor symbols - it is slow. To understand this patch, a description of the existing method is explained fi

Re: [Xen-devel] [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On Mon, Apr 11, 2016 at 08:50:19AM +0200, Juergen Gross wrote: > On 09/04/16 01:40, Luis R. Rodriguez wrote: > > We have 4 types of x86 platforms that disable RTC: > > > > * Intel MID > > * Lguest - uses paravirt > > * Xen dom-U - uses paravirt > > * x86 on legacy systems annotated with an

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Sun, Apr 10, 2016 at 10:12 PM, Juergen Gross wrote: > On 08/04/16 22:40, Luis R. Rodriguez wrote: >> On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote: >>> On 06/04/16 03:40, Luis R. Rodriguez wrote: * You don't need full EFI emulation >>> >>> I think needing any EFI em

Re: [Xen-devel] xenpm and scheduler

On Tue, 2016-04-12 at 17:46 +, tutu sky wrote: > yeah, running xenpm gives short comments on its commands and their > options but not about how to establish it. > I do not understand what you mean with 'establishing' xenpm. If you run Xen on a machine that has power management and/or frequency

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Wei Liu wrote: > Hi libvirt maintainers, Sorry for the delay. Slowly catching up on mail after vacation... > > Xen's control library libxenlight (libxl) requires application > (libvirt in this case) to explictily define LIBXL_API_VERSION. Where is this requirement written? :-) > This is > lack

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

On Tue, Apr 12, 2016 at 03:31:46PM -0600, Jim Fehlig wrote: > Wei Liu wrote: > > Hi libvirt maintainers, > > Sorry for the delay. Slowly catching up on mail after vacation... > > > > > Xen's control library libxenlight (libxl) requires application > > (libvirt in this case) to explictily define

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote: > On Fri, Apr 08, 2016 at 03:16:14PM +0100, George Dunlap wrote: > > On 07/04/16 19:51, Luis R. Rodriguez wrote: > > > While Andrew's position is right in that perhaps only Xen tools have to > > > deal > > > with the HVMLite specif

Re: [Xen-devel] [PATCH v1 0/2] x86/init: extend quirk use

On Mon, Apr 11, 2016 at 09:31:54AM +0200, Sebastian Andrzej Siewior wrote: > On 04/09/2016 02:22 AM, Luis R. Rodriguez wrote: > > What seems a bit odd is CE4100 leaves RTC enabled, can someone > > confirm if indeed it really needs it, or can it also disable it > > as with Xen, lguest, and Intel MID

[Xen-devel] [PATCH v2] x86/init: disable pnpbios and rtc for X86_SUBARCH_CE4100

As per hpa CE4100 platforms can also disable pnpbios [0]. Then Sebastian also recently noted that CE4100 also disables RTC probe, to do that Sebastian had long ago added the RTC of_have_populated_dt() check, he noted that it was meant to skip the RTC probe on all OF platforms but as of now, CE4100

[Xen-devel] [linux-4.1 test] 91008: regressions - FAIL

flight 91008 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/91008/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen

[Xen-devel] [qemu-mainline test] 91031: regressions - FAIL

flight 91031 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/91031/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454 test-amd64-i386-fre

Re: [Xen-devel] [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup

On Tue, Apr 12, 2016 at 04:59:02PM -0400, Konrad Rzeszutek Wilk wrote: > The current mechanism is geared towards fast virtual address -> > symbol names lookup. This is fine for the normal use cases > (BUG_ON, WARN_ON, etc), but for xSplice - where we need to find > hypervisor symbols - it is slow.

Re: [Xen-devel] [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup

On Tue, Apr 12, 2016 at 10:03:12PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 12, 2016 at 04:59:02PM -0400, Konrad Rzeszutek Wilk wrote: > > The current mechanism is geared towards fast virtual address -> > > symbol names lookup. This is fine for the normal use cases > > (BUG_ON, WARN_ON, et

  1   2   >