[Xen-devel] [PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

_child_property() will access msix->mmio's obj. But the whole msix struct has already been freed by xen_pt_msix_delete. This will cause segment fault when msix->mmio has been overwritten. This patch is to fix the issue. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/xen/xen_pt.c

[Xen-devel] [Resend Fix PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

deleting pt device's properties, this will cause segment fault. Reproduce the bug via hotplugging device frequently. This patch is to fix the issue via moving MSIX MMIO memory region into struct XenPCIPassthroughState and free it together with pt device's obj. Signed-off-by: Lan Tianyu <tia

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 6/3/2016 7:17 PM, Tian, Kevin wrote: From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: Friday, June 03, 2016 2:59 AM On 02/06/16 16:03, Lan, Tianyu wrote: On 5/27/2016 4:19 PM, Lan Tianyu wrote: On 2016年05月26日 19:35, Andrew Cooper wrote: On 26/05/16 09:29, Lan Tianyu wrote

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 2016年05月26日 19:35, Andrew Cooper wrote: > On 26/05/16 09:29, Lan Tianyu wrote: > > To be viable going forwards, any solution must work with PVH/HVMLite as > much as HVM. This alone negates qemu as a viable option. > > From a design point of view, having Xen needing t

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 5/27/2016 4:19 PM, Lan Tianyu wrote: On 2016年05月26日 19:35, Andrew Cooper wrote: On 26/05/16 09:29, Lan Tianyu wrote: To be viable going forwards, any solution must work with PVH/HVMLite as much as HVM. This alone negates qemu as a viable option. From a design point of view, having Xen

[Xen-devel] Discussion about virtual iommu support for Xen guest

Hi All: We try pushing virtual iommu support for Xen guest and there are some features blocked by it. Motivation: --- 1) Add SVM(Shared Virtual Memory) support for Xen guest To support iGFX pass-through for SVM enabled devices, it requires virtual iommu support to emulate

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 2016年05月26日 16:42, Dong, Eddie wrote: > If enabling virtual Q35 solves the problem, it has the advantage: When more > and more virtual IOMMU feature comes (likely), we can reuse the KVM code for > Xen. > How big is the effort for virtual Q35? I think the most effort are to rebuild all ACPI

Re: [Xen-devel] Xen Q35 & virtual VTD support

rrent code or not. If yes, we can reuse Qemu virtual VTD for Xen with minor changes. Thanks, Stefano On Mon, 9 May 2016, Lan, Tianyu wrote: Hi All: We are researching how to add virtual VTD support for Xen HVM guest. Current qemu has a basic virtual VTD support for Q35. I'd like to confirm w

Re: [Xen-devel] Xen Q35 & virtual VTD support

On 5/10/2016 10:52 PM, Anthony PERARD wrote: On Tue, May 10, 2016 at 10:31:38PM +0800, Lan, Tianyu wrote: On 5/10/2016 6:11 PM, Stefano Stabellini wrote: Hello Tianyu, What do you mean by reusing Q35 for Xen? If you mean using QEMU to emulate a Q35 based machine for HVM guests, I think

[Xen-devel] Xen Q35 & virtual VTD support

Hi All: We are researching how to add virtual VTD support for Xen HVM guest. Current qemu has a basic virtual VTD support for Q35. I'd like to confirm whether Xen supports Q35 or not. Can we reuse it for Xen? Thanks. The motivations of adding virtual VTD support for Xen prepare for 1) Shared

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 5/27/2016 4:19 PM, Lan Tianyu wrote: > As for the individual issue of 288vcpu support, there are already issues > with 64vcpu guests at the moment. While it is certainly fine to remove > the hard limit at 255 vcpus, there is a lot of other work required to > even get 128vcpu g

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 7/5/2016 9:57 PM, Jan Beulich wrote: On 05.07.16 at 15:37, wrote: Hi Stefano, Andrew and Jan: Could you give us more guides here to move forward virtual iommu development? Thanks. Due to ... On 6/29/2016 11:04 AM, Tian, Kevin wrote: Please let us know your

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

Hi Stefano, Andrew and Jan: Could you give us more guides here to move forward virtual iommu development? Thanks. On 6/29/2016 11:04 AM, Tian, Kevin wrote: From: Lan, Tianyu Sent: Sunday, June 26, 2016 9:43 PM On 6/8/2016 4:11 PM, Tian, Kevin wrote: It makes sense... I thought you used

[Xen-devel] Xen virtual IOMMU high level design doc

Hi All: The following is our Xen vIOMMU high level design for detail discussion. Please have a look. Very appreciate for your comments. This design doesn't cover changes when root port is moved to hypervisor. We may design it later. Content:

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 2016年08月31日 20:02, Jan Beulich wrote: On 31.08.16 at 10:39, wrote: >> > On 2016年08月25日 19:11, Jan Beulich wrote: >> > On 17.08.16 at 14:05, wrote: >>> 1 Motivation for Xen vIOMMU >>>

Re: [Xen-devel] Xen virtual IOMMU high level design doc

Hi Jan: Sorry for later response. Thanks a lot for your comments. On 2016年08月25日 19:11, Jan Beulich wrote: On 17.08.16 at 14:05, wrote: >> 1 Motivation for Xen vIOMMU >> >> === >> 1.1

Re: [Xen-devel] Xen virtual IOMMU high level design doc

Hi Andrew: Sorry to bother you. To make sure we are on the right direction, it's better to get feedback from you before we go further step. Could you have a look? Thanks. On 8/17/2016 8:05 PM, Lan, Tianyu wrote: Hi All: The following is our Xen vIOMMU high level design for detail

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/13/2016 11:25 PM, Jan Beulich wrote: Wait - what is do_invalid_op() doing on the stack? I don't think it belongs there, and hence I wonder whether the keypress happened after some already fatal event (in which case all bets are off anyway). Not clear why do_invalid_op() on the stack.

[Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On a machine with a mount of cpus, dump_timerq() lasts several seconds which may exceed watchdog timeout and cause Xen hyperviosr reboot. This patch is to disable watchdog when dump timer queues to fix the issue. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/timer.c

[Xen-devel] [Resend PATCH 2/2] Xen/timer: Process softirq during dumping timer info

Dumping timer info may run for a long time on the huge machine with a lot of physical cpus. To avoid triggering NMI watchdog, add process_pending_softirqs() in the loop of dumping timer info. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/timer.c |1 + 1 files chan

[Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

-by: Lan Tianyu <tianyu@intel.com> --- xen/common/keyhandler.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c index 16de6e8..fce52d2 100644 --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -75,7

[Xen-devel] [Resend PATCH 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.

Resend because the patchset seems to miss xen devel maillist. This patchset is to fix triggering NMI watchdog during dump timer info on the huge machine with a mount of physical cpus. Detail please see change log of Patch 1. Previous discussion: https://patchwork.kernel.org/patch/9328449/ Lan

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

On 2016年10月06日 20:52, Jan Beulich wrote: On 30.09.16 at 04:19, wrote: >> @@ -87,10 +89,10 @@ void handle_keypress(unsigned char key, struct >> cpu_user_regs *regs) >> if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn ) >> return; >> >> -if

Re: [Xen-devel] [Resend PATCH 2/2] Xen/timer: Process softirq during dumping timer info

On 2016年10月06日 20:56, Jan Beulich wrote: On 30.09.16 at 04:19, wrote: >> --- a/xen/common/timer.c >> +++ b/xen/common/timer.c >> @@ -530,6 +530,7 @@ static void dump_timerq(unsigned char key) >> { >> ts = _cpu(timers, i); >> >> +

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

Hi Konrad: Thanks for your review. On 2016年10月01日 02:07, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 30, 2016 at 10:19:05AM +0800, Lan Tianyu wrote: >> Keyhandler may run for a long time in a timer handler on the large machine > > I am bit lost. > > You say

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/15/2016 10:32 PM, Jan Beulich wrote: On 15.09.16 at 16:16, wrote: On 9/13/2016 11:25 PM, Jan Beulich wrote: Wait - what is do_invalid_op() doing on the stack? I don't think it belongs there, and hence I wonder whether the keypress happened after some already fatal

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/22/2016 10:26 PM, Jan Beulich wrote: But please also answer the earlier question, which you did strip >> from your reply: >> >>> Which btw raises another question: Why are you in polling mode in >>> the first place? Do you have a UART without working interrupt? > > I found there was no

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 2016年09月20日 23:36, Jan Beulich wrote: >> The precondition of process_pending_softirq() working in the debug key >> > handler is that timer interrupt arrives on time and nmi_timer_fn() can >> > run to update nmi_timer_ticks before watchdog timeout. > Precondition? Process_pending_softirq() in

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/19/2016 10:46 PM, Jan Beulich wrote: Well, without a clear understanding of why the issue occurs (for >> which I need to refer you back to the questionable stack dump) >> I'm hesitant to agree to this step, yet ... > > After some researches, I found do_invalid_op() on the stack dump is >

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/21/2016 5:25 PM, Jan Beulich wrote: On 21.09.16 at 03:54, wrote: On 2016年09月20日 23:36, Jan Beulich wrote: The precondition of process_pending_softirq() working in the debug key handler is that timer interrupt arrives on time and nmi_timer_fn() can run to update

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 8/17/2016 8:42 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Lan, Tianyu Sent: 17 August 2016 13:06 To: Jan Beulich; Kevin Tian; Andrew Cooper; yang.zhang...@gmail.com; Jun Nakajima; Stefano Stabellini Cc: Anthony

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

On 2016年10月10日 21:55, Konrad Rzeszutek Wilk wrote: > On Sat, Oct 08, 2016 at 11:26:44AM +0800, Lan Tianyu wrote: >> On 2016年10月06日 20:52, Jan Beulich wrote: >>>>>> On 30.09.16 at 04:19, <tianyu@intel.com> wrote: >>>> @@ -87,10 +89,10 @@ v

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 2016年10月06日 02:36, Konrad Rzeszutek Wilk wrote: >>> 3.3 Interrupt remapping >>> > > Interrupts from virtual devices and physical devices will be delivered >>> > > to vlapic from vIOAPIC and vMSI. It needs to add interrupt remapping >>> > > hooks in the vmsi_deliver() and ioapic_deliver() to

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

On 10/26/2016 5:39 PM, Jan Beulich wrote: On 22.10.16 at 09:32, wrote: On 10/21/2016 4:36 AM, Andrew Cooper wrote: 3.5 Implementation consideration VT-d spec doesn't define a capability bit for the l2 translation. Architecturally there is no way to tell guest that l2

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

On 10/26/2016 5:36 PM, Jan Beulich wrote: On 18.10.16 at 16:14, wrote: 1.1 Enable more than 255 vcpu support HPC cloud service requires VM provides high performance parallel computing and we hope to create a huge VM with >255 vcpu on one machine to meet such

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

On 2016年10月21日 04:36, Andrew Cooper wrote: >> >>> u64 iova; >>> /* Out parameters. */ >>> u64 translated_addr; >>> u64 addr_mask; /* Translation page size */ >>> IOMMUAccessFlags permisson; >> >>

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

Hi Andrew: Thanks for your review. On 2016年10月19日 03:17, Andrew Cooper wrote: On 18/10/16 15:14, Lan Tianyu wrote: Change since V1: 1) Update motivation for Xen vIOMMU - 288 vcpus support part 2) Change definition of struct xen_sysctl_viommu_op 3) Update "3.5 Implement

[Xen-devel] Xen virtual IOMMU high level design doc V2

Change since V1: 1) Update motivation for Xen vIOMMU - 288 vcpus support part 2) Change definition of struct xen_sysctl_viommu_op 3) Update "3.5 Implementation consideration" to explain why we needs to enable l2 translation first. 4) Update "4.3 Q35 vs I440x" - Linux/Windows

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

On 10/21/2016 4:36 AM, Andrew Cooper wrote: 255 vcpus support requires X2APIC and Linux disables X2APIC mode if there is no interrupt remapping function which is present by vIOMMU. Interrupt remapping function helps to deliver interrupt to #vcpu >255. This is only a requirement for xapic

[Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

__serial_rx() runs in either irq handler or timer handler and non-irq keyhandler should not run in these contexts. So always force non-irq keyhandler to run in tasklet when receive a debugkey from serial port Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/drivers/char/console

Re: [Xen-devel] [PATCH v2 2/2] Xen/timer: Process softirq during dumping timer info

On 10/22/2016 1:27 AM, Wei Liu wrote: On Wed, Oct 12, 2016 at 03:58:24PM +0800, Lan Tianyu wrote: Dumping timer info may run for a long time on the huge machine with a lot of physical cpus. To avoid triggering NMI watchdog, add process_pending_softirqs() in the loop of dumping timer info

Re: [Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

On 10/24/2016 9:38 PM, Konrad Rzeszutek Wilk wrote: On Mon, Oct 24, 2016 at 09:29:53PM +0800, Lan, Tianyu wrote: On 10/24/2016 8:19 AM, Konrad Rzeszutek Wilk wrote: On Sat, Oct 22, 2016 at 07:23:03PM +0800, Lan Tianyu wrote: __serial_rx() runs in either irq handler or timer handler and non

Re: [Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

On 10/24/2016 10:31 PM, Jan Beulich wrote: On 24.10.16 at 16:15, <tianyu@intel.com> wrote: On 10/24/2016 9:54 PM, Jan Beulich wrote: On 24.10.16 at 15:29, <tianyu@intel.com> wrote: On 10/24/2016 8:19 AM, Konrad Rzeszutek Wilk wrote: On Sat, Oct 22, 2016 at 07:23:03P

Re: [Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

On 10/24/2016 8:19 AM, Konrad Rzeszutek Wilk wrote: On Sat, Oct 22, 2016 at 07:23:03PM +0800, Lan Tianyu wrote: __serial_rx() runs in either irq handler or timer handler and non-irq keyhandler should not run in these contexts. So always force non-irq keyhandler to run in tasklet when receive

Re: [Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

On 10/24/2016 9:54 PM, Jan Beulich wrote: On 24.10.16 at 15:29, <tianyu@intel.com> wrote: On 10/24/2016 8:19 AM, Konrad Rzeszutek Wilk wrote: On Sat, Oct 22, 2016 at 07:23:03PM +0800, Lan Tianyu wrote: __serial_rx() runs in either irq handler or timer handler and non-irq keyh

Re: [Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

y from serial port Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/drivers/char/console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index b0f74ce..184b523 100644 --- a/xen/drivers/char/console.c +++ b

Re: [Xen-devel] [PATCH] Xen: Force non-irq keyhandler to be run in tasklet when receive a debugkey from serial port

ould not run in these contexts. So always force non-irq keyhandler to run in tasklet when receive a debugkey from serial port Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/drivers/char/console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/char/conso

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

On 2016年11月22日 18:24, Jan Beulich wrote: On 17.11.16 at 16:36, wrote: >> 2) Build ACPI DMAR table in toolstack >> Now tool stack can boot ACPI DMAR table according VM configure and pass >> though it to hvmloader via xenstore ACPI PT channel. But the vIOMMU MMIO >>

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 2016年11月24日 12:09, Edgar E. Iglesias wrote: Hi, > > > > > > I have a few questions. > > > > > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen. > > > So guests will essentially create intel iommu style page-tables. > > > > > > If we

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

On 2016年11月21日 15:05, Tian, Kevin wrote: >> If someone add "intel_iommu=on" kernel parameter manually, IOMMU driver >> > will panic guest because it can't enable DMA remapping function via gcmd >> > register and "Translation Enable Status" bit in gsts register is never >> > set by vIOMMU. This

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

On 2016年11月21日 21:41, Andrew Cooper wrote: > On 17/11/16 15:36, Lan Tianyu wrote: >> 3.2 l2 translation >> 1) For virtual PCI device >> Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new >> hypercall when DMA operation happens. >> >> When

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 11/24/2016 9:37 PM, Edgar E. Iglesias wrote: On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote: On 2016年11月24日 12:09, Edgar E. Iglesias wrote: Hi, I have a few questions. If I understand correctly, you'll be emulating an Intel IOMMU in Xen. So guests will essentially create

[Xen-devel] Xen virtual IOMMU high level design doc V3

Change since V2: 1) Update motivation for Xen vIOMMU - 288 vcpus support part Add descriptor about plan of increasing vcpu from 128 to 255 and dependency between X2APIC and interrupt remapping. 2) Update 3.1 New vIOMMU hypercall interface Change vIOMMU hypercall

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

On 11/19/2016 3:43 AM, Julien Grall wrote: Hi Lan, On 17/11/2016 09:36, Lan Tianyu wrote: 1) Definition of "struct xen_dmop_viommu_op" as new hypercall parameter. struct xen_dmop_viommu_op { u32 cmd; u32 domid; u32 viommu_id; union { struct {

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

On 10/19/2016 4:26 AM, Konrad Rzeszutek Wilk wrote: On Tue, Oct 18, 2016 at 10:14:16PM +0800, Lan Tianyu wrote: 1 Motivation for Xen vIOMMU === 1.1 Enable more than 255 vcpu support HPC cloud service requires VM

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

On 10/26/2016 5:39 PM, Jan Beulich wrote: On 22.10.16 at 09:32, wrote: On 10/21/2016 4:36 AM, Andrew Cooper wrote: 3.5 Implementation consideration VT-d spec doesn't define a capability bit for the l2 translation. Architecturally there is no way to tell guest that l2

Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.

f Patch 1. >> >> Previous discussion: >> https://patchwork.kernel.org/patch/9328449/ >> >> Change since V1: >> Add "async" param for handle_keypress() to identify >> whether run nonirq keyhandler in tasklet or not. This is to >> avoid p

[Xen-devel] [PATCH v2 2/2] Xen/timer: Process softirq during dumping timer info

Dumping timer info may run for a long time on the huge machine with a lot of physical cpus. To avoid triggering NMI watchdog, add process_pending_softirqs() in the loop of dumping timer info. Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Signed-off-by: Lan Tianyu &

[Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.

e_keypress() to identify whether run nonirq keyhandler in tasklet or not. This is to avoid processing debugkey sysctl asynchronously. Lan Tianyu (2): Xen/Keyhandler: Rework process of nonirq keyhandler Xen/timer: Process softirq during dumping timer info xen/common/keyhandler.c |8 +++

[Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

run a timer handler. This patch is to fix the issue to make nonirq keyhandler run in tasklet when receive debug key from serial port. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/keyhandler.c |8 +--- xen/common/sysctl.c |2 +- xen/driver

Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.

On 10/12/2016 7:08 PM, Ian Jackson wrote: Wei Liu writes ("Re: [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine."): On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote: On 2016年10月12日 16:09, Jan Beulich wrote: Also, any reaso

Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

On 10/12/2016 9:19 PM, Jan Beulich wrote: On 12.10.16 at 09:58, wrote: --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -347,7 +347,7 @@ static void switch_serial_input(void) static void __serial_rx(char c, struct cpu_user_regs *regs) { if (

Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

On 2016年10月13日 00:03, Jan Beulich wrote: On 12.10.16 at 16:30, wrote: >> >> Since the issue happens when handle_keypress() runs in a timer handler, >> how about to name new parameter "intimer"? __serial_rx() is called in a >> timer handler or interrupt handler. Or do

[Xen-devel] [PATCH V3] Xen/Keyhandler: Rework process of nonirq keyhandler

run a timer handler. This patch is to fix the issue to make nonirq keyhandler run in tasklet when receive debug key from serial port. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/keyhandler.c |8 +--- xen/common/sysctl.c |2 +- xen/driver

Re: [Xen-devel] [RFC PATCH 1/23] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

On 3/22/2017 7:40 PM, Julien Grall wrote: Hello, On 22/03/17 08:45, Lan Tianyu wrote: Hi Julien: Thanks for review. On 2017年03月22日 03:56, Julien Grall wrote: === diff --git a/xen/include/public/viommu.h b/xen/include/public/viommu.h new file mode

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 2017年03月17日 22:48, Paolo Bonzini wrote: > > > On 17/03/2017 12:29, Lan Tianyu wrote: >> This patchset is to add Xen vIOMMU device model and handle >> irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor >> and the new device module in Qemu

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

On 2017年03月21日 10:28, Lan Tianyu wrote: > On 2017年03月20日 22:23, Roger Pau Monné wrote: >> Thanks! So you add all this vIOMMU code, but the maximum number of allowed >> vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). >> Is >> there any miss

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

On 2017年03月20日 22:23, Roger Pau Monné wrote: > Thanks! So you add all this vIOMMU code, but the maximum number of allowed > vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). > Is > there any missing pieces in order to bump this? To increase vcpu number, we need to

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 2017年03月20日 19:38, Paolo Bonzini wrote: > Fair enough, though I'd be worried about increasing the attack surface > of the hypervisor. For KVM, for example, IOMMU emulation requires using > the "split irqchip" feature to move the PIC and IOAPIC out of the kernel > and back to QEMU. Yes, just

[Xen-devel] [RFC PATCH 7/23] Tools/libacpi: Add new fields in acpi_config to build DMAR table

't add a ACPI_HAS_DMAR table flag there for DMAR table will be only built for HVM guest in this version. But several fields of DMAR table is better to be determined during domain creation rather than compiling tool stack. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tiany

[Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

stack. The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls: - query capabilities of vIOMMU emulated by Xen - create vIOMMU in Xen hypervisor with base address, capability - destroy vIOMMU specified by viommu_id Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Ti

[Xen-devel] [RFC PATCH 2/23] DMOP: Introduce new DMOP commands for vIOMMU support

This patch is to introduce create, destroy and query capabilities command for vIOMMU. vIOMMU layer will deal with requests and call arch vIOMMU ops. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/dm.c | 29 + xen/include/publ

[Xen-devel] [RFC PATCH 6/23] Tools/libacpi: Add DMA remapping reporting (DMAR) ACPI table structures

.@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- tools/libacpi/acpi2_0.h | 45 + 1 file changed, 45 insertions(+) diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h index 2619ba3..8f942b5 100644 --- a/tools/libacpi/a

[Xen-devel] [RFC PATCH 10/23] x86/hvm: Introduce a emulated VTD for HVM

From: Chao Gao <chao@intel.com> Only add create/destroy function for the emulated VTD in this patch and adapt it to common VIOMMU layer. we will add more sub-feature of this emulated VTD. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@inte

[Xen-devel] [RFC PATCH 14/23] X86/vvtd: decode interrupt attribute from IRTE

From: Chao Gao <chao@intel.com> Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vvtd.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vvtd.c

[Xen-devel] [RFC PATCH 15/23] X86/vioapic: Hook interrupt delivery of vIOAPIC

From: Chao Gao <chao@intel.com> When irq remapping enabled, IOAPIC Redirection Entry maybe is in remapping format. If that, generate a irq_remapping_request and send it to domain. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com>

[Xen-devel] [RFC PATCH 18/23] x86/vpt: Get interrupt vector through a vioapic interface

From: Chao Gao <chao@intel.com> When irq remapping enabled, IRE may not contain the vector of interrupt. So, a new function, vioapic_gsi_vector() is added to translate gsi to vector. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com

[Xen-devel] [RFC PATCH 13/23] X86/vvtd: Process interrupt remapping request

, a new function viommu_handle_irq_request() is introduced to emulate the process how remapping hardware handles a remapping interrupt request. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm

[Xen-devel] [RFC PATCH 12/23] X86/vvtd: Set Interrupt Remapping Table Pointer through GCMD

d uses some fields of VVTD to track info about interrupt remapping table. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vvtd.c | 70 + xen/drivers/passthrough/vtd/iommu.h |

[Xen-devel] [RFC PATCH 9/23] Tools/libxl: Inform device model to create a guest with a vIOMMU device

e passed through xenstore. Qemu will create a dummy device to preserve the address range and the dummy device will launch a viommu creation and destruction throuth libxc interface. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- too

[Xen-devel] [RFC PATCH 11/23] X86/vvtd: Add MMIO handler for VVTD

From: Chao Gao <chao@intel.com> This patch is to add VVTD MMIO handler to deal with MMIO access. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vvtd.c | 135 ++

[Xen-devel] [RFC PATCH 17/23] X86/vvtd: Enable Interrupt Remapping through GCMD

From: Chao Gao <chao@intel.com> Software uses this field to enable/disable interrupt reampping. This patch emulate IRES field of GCMD. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vvtd.

[Xen-devel] [RFC PATCH 8/23] Tools/libacpi: Add a user configurable parameter to control vIOMMU attributes

table in tool stack according VM configuration and to pass though it to hvmloader via xenstore ACPI PT channel. If there are ACPI tables needed to pass through, we joint the tables. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- too

[Xen-devel] [RFC PATCH 1/23] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

This patch is to introduct an abstract layer for arch vIOMMU implementation to deal with requests from dom0. Arch vIOMMU code needs to provide callback to perform create, destroy and query capabilities operation. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/Ma

[Xen-devel] [RFC PATCH 4/23] VIOMMU: Add get irq info callback to convert irq remapping request

This patch is to add get_irq_info callback for platform implementation to convert irq remapping request to irq info (E,G vector, dest, dest_mode and so on). Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/viommu.c | 11 +++ xen/include/asm-arm/viommu.

[Xen-devel] [RFC PATCH 3/23] VIOMMU: Add irq request callback to deal with irq remapping

This patch is to add irq request callback for platform implementation to deal with irq remapping request. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/common/viommu.c | 11 +++ xen/include/asm-arm/viommu.h | 4 xen/include/asm-x86/viommu.

[Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

ome fields of hvm_gmsi_info to a sub-structure Tools/libxc: Add a new interface to bind msi-ir with pirq X86/vmsi: Hook guest MSI injection X86/vvtd: Handle interrupt translation faults X86/vvtd: Add queued invalidation (QI) support Lan Tianyu (4): VIOMMU: Add vIOMMU helper functions

[Xen-devel] [RFC PATCH 22/23] X86/vvtd: Handle interrupt translation faults

fault() to log the fault information and viommu_report_non_recoverable_fault() to report faults to software. Currently, only Primary Fault Logging is supported and the Number of Fault-recording Registers is 1. Signed-off-by: Chao Gao <chao....@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com>

[Xen-devel] [RFC PATCH 20/23] Tools/libxc: Add a new interface to bind msi-ir with pirq

From: Chao Gao <chao@intel.com> Introduce a new guest interrupt type and provide a new interface to Qemu to setup/update/unbind the new interrupt type. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- tools/libxc/inclu

[Xen-devel] [RFC PATCH 23/23] X86/vvtd: Add queued invalidation (QI) support

<chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vvtd.c | 248 xen/drivers/passthrough/vtd/iommu.h | 29 - 2 files changed, 276 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vvtd.c

[Xen-devel] [RFC PATCH 21/23] X86/vmsi: Hook guest MSI injection

w type flag HVM_IRQ_DPCI_GUEST_MSI_IR which means the binding relationship is between physical interrupts and guest remappable msi. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/irq.c | 10 + xen/a

[Xen-devel] [RFC PATCH 19/23] passthrough: move some fields of hvm_gmsi_info to a sub-structure

From: Chao Gao <chao@intel.com> No functional change. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vmsi.c | 4 ++-- xen/drivers/passthrough/io.c | 34 +- xen/inc

[Xen-devel] [RFC PATCH 16/23] X86/vvtd: Enable Queued Invalidation through GCMD

From: Chao Gao <chao@intel.com> Software writes to QIE fields of GCMD to enable or disable queued invalidations. This patch emulates QIE fields of GCMD. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- xen/arch/x86/hvm/vvtd.

[Xen-devel] [RFC PATCH 3/4] xen-pt: bind/unbind interrupt remapping format MSI

o bind/unbind msi. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/xen/xen_pt_msi.c | 36 include/hw/i386/apic-msidef.h | 1 + 2 files changed, 29 insertions(+), 8 deletions(-) d

[Xen-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

hannel or not. This patch takes the msi interrupt format into consideration. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/pci/msi.c | 5 +++-- hw/pci/msix.c| 4 +++- hw/xen/xen_pt_msi.c | 2 +- include/hw/xen/xen.h | 2 +- xen-hv

[Xen-devel] [RFC PATCH 2/4] Xen: add a dummy vIOMMU to create/destroy vIOMMU in Xen

From: Chao Gao <chao@intel.com> Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE as parent class. Signed-off-by: Chao Gao <chao@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- hw/xen/Makefile.objs | 1 + hw/xen/x

[Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

This patchset is to add Xen vIOMMU device model and handle irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor and the new device module in Qemu works as hypercall wrappers to create and destroy vIOMMU in hypervisor. Xen only supports emulated I440 and so we enable vIOMMU with

Re: [Xen-devel] [RFC PATCH 1/23] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

Hi Julien: Thanks for review. On 2017年03月22日 03:56, Julien Grall wrote: > === > > diff --git a/xen/include/public/viommu.h b/xen/include/public/viommu.h > new file mode 100644 > index 000..ca2419b > > --- /dev/null > > +++

Re: [Xen-devel] [RFC PATCH 1/23] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

On 3/22/2017 4:36 PM, Tian, Kevin wrote: From: Julien Grall [mailto:julien.gr...@arm.com] Sent: Wednesday, March 22, 2017 3:57 AM diff --git a/xen/common/Makefile b/xen/common/Makefile index 0fed30b..b58de63 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -60,6 +60,7 @@ obj-y +=

Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

On 2017年04月17日 19:08, Wei Liu wrote: > On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote: >> Hi Paul: >> Sorry for later response. >> >> On 3/31/2017 3:57 AM, Chao Gao wrote: >>> On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durran

  1   2   3   4   >