Re: [Xen-devel] OProfile with Xen-4.9

On 12/21/2017 11:06 AM, Сергей wrote: > Hello. > > I have installed Xen-4.9 from Ubuntu 17.10 package. And I would like to > profile it with OProfile (as far as I know this is the only option). > > With instruction from >

[Xen-devel] [PATCH] xen-blkfront: move negotiate_mq to cover all cases of new VBDs

negotiate_mq should happen in all cases of a new VBD being discovered by xen-blkfront, whether called through _probe() or a hot-attached new VBD from dom-0 via xenstore. Otherwise, hot-attached new VBDs are left configured without multi-queue. Signed-off-by: Bhavesh Davda

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

Hi all, Another crash this morning: vif vif-2-0 vif2.0: Trying to unmap invalid handle! pending_idx: 0x3a [ cut here ] kernel BUG at drivers/net/xen-netback/netback.c:430! invalid opcode: [#1] SMP Modules linked in: xt_physdev(E) iptable_filter(E) ip_tables(E)

Re: [Xen-devel] [RFC] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Stefano, Thanks for review. On Tue, Dec 12, 2017 at 12:10 AM, Stefano Stabellini wrote: > On Wed, 9 Aug 2017, Mirela Simonovic wrote: > > This document contains our draft proposal for implementing "suspend to > RAM" > > support for ARM in Xen, as discussed during

[Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

This document contains our design specification for "suspend to RAM" support for ARM in Xen. It covers the basic suspend to RAM mechanism based on ARM PSCI standard, that would allow individual guests and Xen itself to suspend/resume. We would appreciate your feedback. Signed-off-by: Mirela

[Xen-devel] Fw: Boot Xen on Jetson TX2

From: Wang, Baoqian Sent: Thursday, December 21, 2017 7:53 PM To: Andrii Anisov Subject: Re: [Xen-devel] Boot Xen on Jetson TX2 I also dumped domain0 info, it shows : VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=F] poll=0

Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

On 12/22/2017 05:58 PM, Konrad Rzeszutek Wilk wrote: On Fri, Dec 22, 2017 at 05:48:45PM +0200, Oleksandr Andrushchenko wrote: On 12/22/2017 05:12 PM, Konrad Rzeszutek Wilk wrote: On Mon, Dec 11, 2017 at 10:45:27AM +0200, Oleksandr Andrushchenko wrote: ping ..snip.. This is implemented as

Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

On 12/22/2017 05:12 PM, Konrad Rzeszutek Wilk wrote: On Mon, Dec 11, 2017 at 10:45:27AM +0200, Oleksandr Andrushchenko wrote: ping ..snip.. This is implemented as a change to the sndif protocol [8] and allows [8]

Re: [Xen-devel] [PATCH 2/2] x86/svm: Add checks for nested HW features

On 21/12/17 15:26, Brian Woods wrote: > Add a nestedhvm_enable() check to the existing checks for setting the > virtual GIF and virtual VMLOAD/VMSAVE features. If it isn't a nestedhvm > guest, do not enable the features in the VMCB. > > Signed-off-by: Brian Woods

Re: [Xen-devel] [PATCH 1/2] x86/svm: Add SVME checking for SVM intercepts

On Thu, Dec 21, 2017 at 11:52:27PM -0500, Boris Ostrovsky wrote: > s/it/is Oopsy, thank you. > I haven't checked all of them but at least for the first two > (svm_vmexit_do_vmrun() and smv_vmexit_do_vmload()) we check EFER and > print a similar error message. So it seems they can be handled in

Re: [Xen-devel] Boot Xen on Jetson TX2

Hello Baoqian, It looks like vcpu0 of dom0 was not scheduled to run. But I can't imagine why this happened. Please do not miss CC'ing xen-devel mailing list. This will increase a probability to get proper suggestions. On 22.12.17 05:53, Wang, Baoqian wrote: I also dumped domain0 info,

Re: [Xen-devel] Xen Performance Results

On 12/22/2017 01:18 PM, George Dunlap wrote: > On Fri, Dec 22, 2017 at 10:41 AM, Sergej Proskurin > wrote: >> Hi George, >> >> Thank you for your reply. >> >> On 12/22/2017 11:26 AM, George Dunlap wrote: >>> On Thu, Dec 21, 2017 at 2:42 PM, Sergej Proskurin >>>

Re: [Xen-devel] [Qemu-devel] [PATCH v2 5/6] xen: Add only xen-sysdev to dynamic sysbus device list

Hi, On Sat, Nov 25, 2017 at 4:16 PM, Eduardo Habkost wrote: > There's no need to make the machine allow every possible sysbus > device. We can now just add xen-sysdev to the allowed list. > > Cc: Stefano Stabellini > Cc: Anthony Perard

Re: [Xen-devel] Xen Performance Results

On Fri, Dec 22, 2017 at 10:41 AM, Sergej Proskurin wrote: > Hi George, > > Thank you for your reply. > > On 12/22/2017 11:26 AM, George Dunlap wrote: >> On Thu, Dec 21, 2017 at 2:42 PM, Sergej Proskurin >> wrote: >>> Hi all, >>> >>> For the sake

[Xen-devel] [distros-debian-jessie test] 73204: trouble: blocked/broken

flight 73204 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/73204/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken

Re: [Xen-devel] [PATCH v2] x86/hvm: Add MSR old value

On 12/05/2017 11:07 AM, Jan Beulich wrote: On 04.12.17 at 16:45, wrote: >>> On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila wrote: This patch adds the old value param and the onchangeonly option to the VM_EVENT_REASON_MOV_TO_MSR event.

Re: [Xen-devel] Xen Performance Results

Hi George, Thank you for your reply. On 12/22/2017 11:26 AM, George Dunlap wrote: > On Thu, Dec 21, 2017 at 2:42 PM, Sergej Proskurin > wrote: >> Hi all, >> >> For the sake of completeness: the solution to the issue stated in my >> last email was deactivating Intel's

[Xen-devel] [PATCH 4.14 074/159] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Boris Ostrovsky commit e17f8234538d1ff708673f287a42457c4dee720d upstream. Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them NMI-safe") added

[Xen-devel] [PATCH 4.14 064/159] x86/virt, x86/platform: Merge struct x86_hyper into struct x86_platform and struct x86_init

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit f72e38e8ec8869ac0ba5a75d7d2f897d98a1454e upstream. Instead of x86_hyper being either NULL on bare metal or a pointer to a struct hypervisor_x86 in case

[Xen-devel] [PATCH 4.14 065/159] x86/virt: Add enum for hypervisors to replace x86_hyper

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 03b2a320b19f1424e9ac9c21696be9c60b6d0d93 upstream. The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor