Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Thu, Dec 14, 2017 at 02:50:17PM +, Paul Durrant wrote: >> -Original Message- >> > >> > Hmm. That looks like it is because the ioreq server pages are not owned by >> > the correct domain. The Xen patch series underwent some changes later in >> > review and I did not re-test my QEMU

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Tue, Dec 12, 2017 at 09:07:46AM +, Paul Durrant wrote: >> -Original Message- >[snip] >> >> Hi, Paul. >> >> I merged the two qemu patches, the privcmd patch [1] and did some tests. >> I encountered a small issue and report it to you, so you can pay more >> attention to it when

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Thu, Dec 07, 2017 at 08:41:14AM +, Paul Durrant wrote: >> -Original Message- >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Paul Durrant >> Sent: 06 December 2017 16:10 >> To: 'Chao Gao' <chao@intel.com>

[Xen-devel] [RFC Patch v4 3/8] xl/acpi: unify the computation of lapic_id

There were two places where the lapic_id is computed, one in hvmloader and one in libacpi. Unify them by defining LAPIC_ID in a header file and incluing it in both places. To address compilation issue and make libacpi.h self-contained, include stdint.h in libacpi.h. Signed-off-by: Chao Gao <c

[Xen-devel] [RFC Patch v4 6/8] hvmload: Add x2apic entry support in the MADT and SRAT build

Local x2APIC Affinity Structure. Signed-off-by: Lan Tianyu <tianyu@intel.com> Signed-off-by: Chao Gao <chao@intel.com> --- v4: - also add x2apic entry in SRAT --- tools/libacpi/acpi2_0.h | 25 -- tools/liba

[Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

Signed-off-by: Chao Gao <chao@intel.com> --- xen/include/public/hvm/hvm_info_table.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/public/hvm/hvm_info_table.h b/xen/include/public/hvm/hvm_info_table.h index 08c252e..6833a4c 100644 --- a/xen/include/

[Xen-devel] [RFC Patch v4 0/8] Extend resources to support more vcpus in single VM

e" syntax for other vcpus in ACPI DSDT table. 3) Use XAPIC structure for vcpus with APIC id < 255 in dsdt and use x2APIC structure for other vcpus in the ACPI MADT table. This patchset is to extend some resources(i.e, event channel, hap and so) to support more vcpus for single VM. Chao

[Xen-devel] [RFC Patch v4 1/8] ioreq: remove most 'buf' parameter from static functions

It is a preparation to support multiple IOREQ pages. No functional change. Signed-off-by: Chao Gao <chao@intel.com> --- v4: -new --- xen/arch/x86/hvm/ioreq.c | 48 +++- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/xen/ar

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Wed, Dec 06, 2017 at 03:04:11PM +, Paul Durrant wrote: >> -Original Message- >> From: Chao Gao [mailto:chao@intel.com] >> Sent: 06 December 2017 07:50 >> To: xen-de...@lists.xen.org >> Cc: Chao Gao <chao@intel.com>; Paul Durrant >> &

Re: [Xen-devel] [PATCH v3 2/3] xen/pt: Pass the whole msi addr/data to Xen

On Mon, Dec 11, 2017 at 05:59:08PM +, Anthony PERARD wrote: >On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote: >> Previously, some fields (reserved or unalterable) are filtered by >> Qemu. This fields are useless for the legacy interrupt format. >> However,

Re: [Xen-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request

On Mon, Dec 11, 2017 at 06:07:48PM +, Anthony PERARD wrote: >On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote: >> According to VT-d spec Interrupt Remapping and Interrupt Posting -> >> Interrupt Remapping -> Interrupt Request Formats On Intel 64 >> Pl

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Fri, Dec 08, 2017 at 11:06:43AM +, Paul Durrant wrote: >> -Original Message- >> From: Chao Gao [mailto:chao@intel.com] >> Sent: 07 December 2017 06:57 >> To: Paul Durrant <paul.durr...@citrix.com> >> Cc: Stefano Stabellini <sst

Re: [Xen-devel] [RFC Patch v4 1/8] ioreq: remove most 'buf' parameter from static functions

On Wed, Dec 06, 2017 at 02:44:52PM +, Paul Durrant wrote: >> -Original Message- >> From: Chao Gao [mailto:chao@intel.com] >> Sent: 06 December 2017 07:50 >> To: xen-de...@lists.xen.org >> Cc: Chao Gao <chao@intel.com>; Andrew Cooper >>

[Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading

patch, and keep the processors in until all have completed the patch.", in [1]. [1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates Signed-off-by: Chao Gao <chao@intel.com> Tested-by: Chao Gao <chao@intel

[Xen-devel] [Patch v3 1/2] x86/smp: count the number of online physical processor in the system

Mainly for the patch behind which relies on 'nr_phys_cpus' to estimate the time needed for microcode update in the worst case. Signed-off-by: Chao Gao <chao@intel.com> --- v3: - new --- xen/arch/x86/smpboot.c| 13 + xen/include/asm-x86/smp.h | 3 +++ 2 files chang

Re: [Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading

On Wed, May 16, 2018 at 07:46:48AM -0600, Jan Beulich wrote: On 16.05.18 at 15:25, wrote: >> On 16/05/18 14:10, Jan Beulich wrote: +static int do_microcode_update(void *_info) +{ +struct microcode_info *info = _info; +unsigned int cpu =

Re: [Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading

On Fri, May 18, 2018 at 03:21:14PM +0800, Chao Gao wrote: >On Wed, May 16, 2018 at 07:46:48AM -0600, Jan Beulich wrote: >>>>> On 16.05.18 at 15:25, <andrew.coop...@citrix.com> wrote: >>> On 16/05/18 14:10, Jan Beulich wrote: >>>>

Re: [Xen-devel] [PATCH v2] x86/microcode: Synchronize late microcode loading

On Mon, Apr 30, 2018 at 09:25:26AM -0600, Jan Beulich wrote: On 25.04.18 at 13:46, wrote: >> @@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, >> size_t size) >> return err; >> } >> >> -static long do_microcode_update(void *_info) >> +/* Wait

[Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

information. [1]: during guest creation, those information helps hvmloader to build ACPI. Signed-off-by: Chao Gao <chao@intel.com> --- xen/arch/x86/domctl.c | 27 ++ xen/arch/x86/hvm/hvm.c | 7 ++ xen/arch/x86/mm.c

[Xen-devel] [RFC PATCH 4/8] libxl: calculate and set vcpu topology

w software should extract topology from APIC_ID. The unique APIC_ID consists of three sub fields: PACKAGE_ID, CORE_ID and SMT_ID. PACKAGE_ID is the virtual numa ID (if no numa information, PACKAGE_ID is always 0). CORE_ID and SMT_ID increase from 0. Signed-off-by: Chao Gao <chao@intel.co

[Xen-devel] [RFC PATCH 2/8] x86/vlapic: use apic_id array to set initial (x2)APIC ID

It removes the fixed mapping between vcpu_id and apic_id. Signed-off-by: Chao Gao <chao@intel.com> --- xen/arch/x86/cpuid.c | 7 +-- xen/arch/x86/hvm/vlapic.c| 10 +- xen/include/asm-x86/hvm/domain.h | 3 +++ 3 files changed, 13 insertions(+), 7 del

[Xen-devel] [RFC PATCH 6/8] hvmloader: get CPU topology information from hypervisor

The previous relationship between APIC_ID and vcpu_id won't hold. The APIC_ID array got from hypervisor is used to boot APs. Signed-off-by: Chao Gao <chao@intel.com> --- tools/firmware/hvmloader/Makefile| 2 +- tools/firmware/hvmloader/hvmloader.c | 8 + tools/firmware/hvm

[Xen-devel] [RFC PATCH 0/8] Add guest CPU topology support

ccordingly. In hvmloader, guest CPU topology is retrieved from Xen in order to build ACPI and boot APs. Chao Gao (8): x86/domctl: introduce a pair of hypercall to set and get cpu topology x86/vlapic: use apic_id array to set initial (x2)APIC ID xl/parse: introduce cpu_topology to guest conf

[Xen-devel] [RFC PATCH 3/8] xl/parse: introduce cpu_topology to guest config

Signed-off-by: Chao Gao <chao@intel.com> --- docs/man/xl.cfg.pod.5.in| 21 + tools/libxl/libxl_types.idl | 7 +++ tools/xl/xl_parse.c | 19 +++ 3 files changed, 47 insertions(+) diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg

[Xen-devel] [RFC PATCH 8/8] x86/cpuid: emulate extended topology enumeration leaf

] should be the same value in ecx input . ecx[15:8] should be the level type. This patch also sets policy for guest's CPUID.4:EAX[25:14]. Rather than passing the host value to guest, we set this field to the number of thread in each core to be consistent with CPU topology. Signed-off-by: Chao Gao <c

[Xen-devel] [RFC PATCH 5/8] xen/mem: handle XENMEM_get_cpu_topology in compat_memory_op

hvmloader needs to get cpu topology to build ACPI and boot APs. Signed-off-by: Chao Gao <chao@intel.com> --- xen/common/compat/memory.c | 21 + xen/include/xlat.lst | 1 + 2 files changed, 22 insertions(+) diff --git a/xen/common/compat/memory.c b/xen/

[Xen-devel] [RFC PATCH 7/8] libacpi: build madt/srat according cpu topology

Callers pass an APIC_ID array to libacpi and libacpi will use this array to fill the APIC_ID field of MADT and SRAT. Signed-off-by: Chao Gao <chao@intel.com> --- tools/firmware/hvmloader/util.c | 8 ++-- tools/libacpi/build.c | 4 ++-- tools/libacpi/libacpi.h

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On Tue, Jan 09, 2018 at 12:18:13PM -0500, Daniel De Graaf wrote: >On 01/09/2018 04:06 AM, Chao Gao wrote: >> On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote: >> > On 01/07/2018 11:01 PM, Chao Gao wrote: >> > > Define interface, structures and hyp

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote: >On 01/07/2018 11:01 PM, Chao Gao wrote: >> Define interface, structures and hypercalls for toolstack to build >> cpu topology and for guest that will retrieve it [1]. >> Two subop hypercalls int

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On Tue, Jan 09, 2018 at 11:47:54PM +, Andrew Cooper wrote: >On 08/01/18 04:01, Chao Gao wrote: >> Define interface, structures and hypercalls for toolstack to build >> cpu topology and for guest that will retrieve it [1]. >> Two subop hypercalls int

Re: [Xen-devel] [PATCH v4 02/28] VIOMMU: Add vIOMMU framework and vIOMMU domctl

On Fri, Feb 09, 2018 at 02:33:57PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:09PM +0800, Chao Gao wrote: >> From: Lan Tianyu <tianyu@intel.com> >> >> This patch is to introduce an abstract layer for arch vIOMMU implementation >> and vIOMMU

Re: [Xen-devel] [PATCH v4 01/28] Xen/doc: Add Xen virtual IOMMU doc

On Fri, Feb 09, 2018 at 12:54:11PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:08PM +0800, Chao Gao wrote: >> From: Lan Tianyu <tianyu@intel.com> >> >> This patch is to add Xen virtual IOMMU doc to introduce motivation, >> framework, vIOM

Re: [Xen-devel] [PATCH v4 05/28] VIOMMU: Introduce callback of checking irq remapping mode

On Fri, Feb 09, 2018 at 03:11:25PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:12PM +0800, Chao Gao wrote: >> From: Lan Tianyu <tianyu@intel.com> >> >> This patch is to add callback for vIOAPIC and vMSI to check whether interrupt >&

Re: [Xen-devel] [PATCH v4 07/28] x86/hvm: Introduce a emulated VTD for HVM

On Fri, Feb 09, 2018 at 04:27:54PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:14PM +0800, Chao Gao wrote: >> This patch adds create/destroy function for the emulated VTD >> and adapts it to the common VIOMMU abstraction. >> >> As the Makefile is

Re: [Xen-devel] [PATCH v4 04/28] VIOMMU: Add get irq info callback to convert irq remapping request

On Fri, Feb 09, 2018 at 03:06:07PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:11PM +0800, Chao Gao wrote: >> From: Lan Tianyu <tianyu@intel.com> >> >> This patch is to add get_irq_info callback for platform implementation >> to convert irq r

Re: [Xen-devel] [PATCH v4 06/28] vtd: clean-up and preparation for vvtd

On Fri, Feb 09, 2018 at 03:17:59PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:13PM +0800, Chao Gao wrote: >> This patch contains following changes: >> - align register definitions >> - use MASK_EXTR to define some macros about extended capabilies >&

Re: [Xen-devel] [PATCH v4 09/28] x86/vvtd: Set Interrupt Remapping Table Pointer through GCMD

On Fri, Feb 09, 2018 at 04:59:11PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:16PM +0800, Chao Gao wrote: >> Software sets SIRTP field of GCMD to set/update the interrupt remapping >> table pointer used by hardware. The interrupt remapping table pointer is >&

Re: [Xen-devel] [PATCH v4 10/28] x86/vvtd: Enable Interrupt Remapping through GCMD

On Fri, Feb 09, 2018 at 05:15:17PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:17PM +0800, Chao Gao wrote: >> Software writes this field to enable/disable interrupt reampping. This >> patch emulate IRES field of GCMD. Currently, Guest's whole IRT are >> mapp

Re: [Xen-devel] [PATCH v4 11/28] x86/vvtd: Process interrupt remapping request

On Fri, Feb 09, 2018 at 05:44:17PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:18PM +0800, Chao Gao wrote: >> When a remapping interrupt request arrives, remapping hardware computes the >> interrupt_index per the algorithm described in VTD spec >> "

Re: [Xen-devel] [PATCH v4 12/28] x86/vvtd: decode interrupt attribute from IRTE

On Mon, Feb 12, 2018 at 11:55:42AM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:19PM +0800, Chao Gao wrote: >> Without interrupt remapping, interrupt attributes can be extracted from >> msi message or IOAPIC RTE. However, with interrupt remapping enabled, &g

Re: [Xen-devel] [PATCH v4 14/28] x86/vvtd: Handle interrupt translation faults

On Mon, Feb 12, 2018 at 12:55:06PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:21PM +0800, Chao Gao wrote: >> Interrupt translation faults are non-recoverable fault. When faults >> are triggered, it needs to populate fault info to Fault Recording >> Reg

Re: [Xen-devel] [PATCH v4 08/28] x86/vvtd: Add MMIO handler for VVTD

On Fri, Feb 09, 2018 at 05:51:29PM +, Roger Pau Monné wrote: >On Sat, Feb 10, 2018 at 01:21:09AM +0800, Chao Gao wrote: >> On Fri, Feb 09, 2018 at 04:39:15PM +, Roger Pau Monné wrote: >> >On Fri, Nov 17, 2017 at 02:22:15PM +0800, Chao Gao wrote: >> >> Thi

Re: [Xen-devel] [PATCH v4 10/28] x86/vvtd: Enable Interrupt Remapping through GCMD

On Mon, Feb 12, 2018 at 11:30:18AM +, Roger Pau Monné wrote: >On Sun, Feb 11, 2018 at 01:05:01PM +0800, Chao Gao wrote: >> On Fri, Feb 09, 2018 at 05:15:17PM +, Roger Pau Monné wrote: >> >On Fri, Nov 17, 2017 at 02:22:17PM +0800, Chao Gao wrote: >> >> +sta

Re: [Xen-devel] [PATCH v4 15/28] x86/vvtd: Enable Queued Invalidation through GCMD

On Mon, Feb 12, 2018 at 02:04:46PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:22PM +0800, Chao Gao wrote: >> Software writes to QIE field of GCMD to enable or disable queued >> invalidations. This patch emulates QIE field of GCMD. >> >> Si

Re: [Xen-devel] [PATCH v4 20/28] xen/pt: when binding guest msi, accept the whole msi message

On Mon, Feb 12, 2018 at 03:16:25PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:27PM +0800, Chao Gao wrote: >> ... rather than a filtered one. Previously, some fields (reserved or >> unalterable) are filtered by QEMU. These fields are useless for the >> legacy

Re: [Xen-devel] [PATCH v4 18/28] x86/vioapic: Hook interrupt delivery of vIOAPIC

On Mon, Feb 12, 2018 at 02:54:02PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:25PM +0800, Chao Gao wrote: >> When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping >> format. If that, generate an irq_remapping_request and call the commo

Re: [Xen-devel] [PATCH v4 21/28] vvtd: update hvm_gmsi_info when binding guest msi with pirq or

On Mon, Feb 12, 2018 at 03:38:07PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:28PM +0800, Chao Gao wrote: >> ... handlding guest's invalidation request. >> >> To support pirq migration optimization and using VT-d posted interrupt to >> inject msi from

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On Fri, Feb 23, 2018 at 06:11:39PM +, Roger Pau Monné wrote: >On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote: >> Signed-off-by: Chao Gao <chao@intel.com> >> --- >> xen/include/public/hvm/hvm_info_table.h | 2 +- >> 1 file changed, 1 insertion(+)

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote: >On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote: >> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software" >> has the following description: >> >> "The

Re: [Xen-devel] [PATCH v4 16/28] x86/vvtd: Add queued invalidation (QI) support

On Mon, Feb 12, 2018 at 02:36:10PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:23PM +0800, Chao Gao wrote: >> Queued Invalidation Interface is an expanded invalidation interface with >> extended capabilities. Hardware implementations report support for queued

Re: [Xen-devel] [PATCH v4 17/28] x86/vvtd: save and restore emulated VT-d

On Mon, Feb 12, 2018 at 02:49:12PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:24PM +0800, Chao Gao wrote: >> Provide a save-restore pair to save/restore registers and non-register >> status. >> >> Signed-off-by: Chao Gao <chao@intel.com> >

Re: [Xen-devel] [PATCH v2 00/13] x86: CPUID and MSR policy marshalling support

On Fri, Jul 13, 2018 at 09:03:01PM +0100, Andrew Cooper wrote: >This series introduces libx86, a small shared library between the hypervisor >and libxc, and hypercalls to get full CPUID/MSR policies. Future work will >implement XEN_DOMCTL_set_cpumsr_policy, after the auditing and comparison

Re: [Xen-devel] [PATCH v2 13/13] x86/domctl: Implement XEN_DOMCTL_get_cpu_policy

On Fri, Jul 13, 2018 at 09:03:14PM +0100, Andrew Cooper wrote: >From: Sergey Dyasli > >This finally (after literally years of work!) marks the point where the >toolstack can ask the hypervisor for the current CPUID configuration of a >specific domain. > >Also extend xen-cpuid's --policy mode to

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote: >>>> On 26.02.18 at 14:11, <chao@intel.com> wrote: >> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote: >>>>>> On 23.02.18 at 19:11, <roger@citrix.com> wrote: >>

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On Thu, Mar 01, 2018 at 12:37:57AM -0700, Jan Beulich wrote: >>>> Chao Gao <chao@intel.com> 03/01/18 7:34 AM >>> >>On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote: >>>Again - here we're talking about implementation limits, not >>>

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

7AM +0100, George Dunlap wrote: >>>>> On 04/05/2018 10:34 AM, Roger Pau Monné wrote: >>>>>> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote: >>>>>>> ... the same page with other registers which are not relevant to MSI-X. >>

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

On Thu, Apr 05, 2018 at 10:34:39AM +0100, Roger Pau Monné wrote: >On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote: >> ... the same page with other registers which are not relevant to MSI-X. Xen >> marks pages where PBA resides as read-only. When assigning such devices to &

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

On Thu, Apr 05, 2018 at 12:25:26PM +0100, Roger Pau Monné wrote: >On Thu, Apr 05, 2018 at 07:00:41PM +0800, Chao Gao wrote: >> On Thu, Apr 05, 2018 at 10:34:39AM +0100, Roger Pau Monné wrote: >> >On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote: >> >> diff --

[Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

to specify a list of devices. For those devices, Xen doesn't control the access right to pages where PBA resides. Hence, guest device driver is able to write those pages and functions well. Note that adding an untrusted device to this option may endanger security of the entire system. Signed-off-by: Chao

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

On Wed, Apr 04, 2018 at 04:45:32PM +0100, Roger Pau Monné wrote: >On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote: >> ... the same page with other registers which are not relevant to MSI-X. Xen >> marks pages where PBA resides as read-only. When assigning such devices to &

Re: [Xen-devel] [PATCH v2] pci: a workaround for nonstandard PCI devices whose PBA shares

On Mon, Apr 09, 2018 at 07:40:15AM -0600, Jan Beulich wrote: On 09.04.18 at 15:16, wrote: >> Given that parsing parameters starts at very early stage in which xmalloc is >> unusable, I choose to continue using an array other than a list to store >> SBDFs >> of such kind

[Xen-devel] [PATCH v2] pci: a workaround for nonstandard PCI devices whose PBA shares

to specify a list of devices. For those devices, Xen doesn't control the access right to pages where PBA resides. Hence, guest device driver is able to write those pages and functions well. Note that adding an untrusted device to this option may endanger security of the entire system. Signed-off-by: Chao

Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

On Thu, Apr 12, 2018 at 09:29:34AM -0700, Raj, Ashok wrote: >On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote: >> From: Gao Chao <chao@intel.com> >> >> This patch is to backport microcode improvement patches from linux >> kernel. Below are

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes

arc.info/?l=xen-devel= >v4 posted by Chao Gao: ​https://xen.markmail.org/thread/wfyorbn3nzsio6s >**Seems to have had review by Roger Pau Monne (1 ACK) >No issues** >Primarily needs George as reviewer >Agreed to park this, because NVDIMM work is more important I want to clarify that I w

Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

Ping... Can someone help to review these two patches? On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote: >From: Gao Chao <chao@intel.com> > >This patch is to backport microcode improvement patches from linux >kernel. Below are the original patches descript

Re: [Xen-devel] [RFC Patch v4 7/8] x86/hvm: bump the number of pages of shadow memory

On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote: On 06.12.17 at 08:50, wrote: >> Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256 >> (for hap case) pages are pre-allocated as shadow memory at beginning. It >> would >> run out if

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

On Wed, Apr 18, 2018 at 02:38:48AM -0600, Jan Beulich wrote: On 06.12.17 at 08:50, wrote: >> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software" >> has the following description: >> >> "The ACPI interfaces for the x2APIC are described in Section 5.2,

Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

On Fri, Apr 13, 2018 at 09:49:17AM -0600, Jan Beulich wrote: On 30.03.18 at 08:59, wrote: >> @@ -281,24 +287,52 @@ static int microcode_update_cpu(const void *buf, >> size_t size) >> return err; >> } >> >> -static long do_microcode_update(void *_info) >> +static

Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

On Mon, Apr 16, 2018 at 04:26:09AM -0600, Jan Beulich wrote: On 16.04.18 at 08:20, wrote: >> On Fri, Apr 13, 2018 at 09:49:17AM -0600, Jan Beulich wrote: >> On 30.03.18 at 08:59, wrote: +static int do_microcode_update(void *_info) +{

[Xen-devel] [PATCH v2] x86/microcode: Synchronize late microcode loading

all online cpus in an IPI to apply the patch, and keep the processors in until all have completed the patch.", in [1]. [1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates Signed-off-by: Chao Gao <chao@intel.com> Tested-by: Chao Gao <c

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote: >Hi all, >so it seems we have no perfect slot proposals, but 2 semi-perfect. >May 2nd: 16:00 - 17:00 Christopher can't attend >May 2nd: 17:00 - 18:00 Chao can't attend >Maybe a compromise would be 16:30 to 17:30 Hi Lars, Your suggestion

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

On Mon, Apr 23, 2018 at 10:12:22PM +0800, Chao Gao wrote: >On Mon, Apr 23, 2018 at 08:26:59AM +, Lars Kurth wrote: >>Hi all, >>so it seems we have no perfect slot proposals, but 2 semi-perfect. >>May 2nd: 16:00 - 17:00 Christopher can't attend >>May 2nd: 17:00 - 18:0

Re: [Xen-devel] [RFC PATCH 2/8] x86/vlapic: use apic_id array to set initial (x2)APIC ID

On Mon, Apr 23, 2018 at 10:04:56AM -0600, Jan Beulich wrote: On 08.01.18 at 05:01, wrote: >> --- a/xen/include/asm-x86/hvm/domain.h >> +++ b/xen/include/asm-x86/hvm/domain.h >> @@ -213,6 +213,9 @@ struct hvm_domain { >> uint8_t thread_per_core; >> }; >> >>

[Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

endezvous all online cpus in an IPI to apply the patch, and keep the processors in until all have completed the patch.", in [1]. [1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates Signed-off-by: Chao Gao <chao@intel.com> Cc: Kevin Tian &l

Re: [Xen-devel] Need some advices on how to workaround a hardware bug

On Fri, Mar 30, 2018 at 02:23:13AM -0600, Jan Beulich wrote: >>>> Chao Gao <chao@intel.com> 03/30/18 7:19 AM >>> >>I met an EPT violation and then the guest was destroyed by Xen >>after assigning a device to the guest. After some investigation, I f

[Xen-devel] Need some advices on how to workaround a hardware bug

Hi, I met an EPT violation and then the guest was destroyed by Xen after assigning a device to the guest. After some investigation, I found it is caused by the device isn't a standard PCI device -- its MSI-x PBA locates in the same 4k-byte page with other CSR. When the driver in guest writes the

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote: >>>> On 23.02.18 at 19:11, <roger@citrix.com> wrote: >> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote: >>> Signed-off-by: Chao Gao <chao@intel.com> >>> --- >>&g

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

On Mon, Feb 26, 2018 at 01:28:07AM -0700, Jan Beulich wrote: >>>> On 24.02.18 at 06:49, <chao@intel.com> wrote: >> On Fri, Feb 23, 2018 at 04:42:10PM +, Roger Pau Monné wrote: >>>On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote: >

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

On Mon, Oct 15, 2018 at 01:06:12PM +0100, Andrew Cooper wrote: >On 15/10/18 11:30, Roger Pau Monné wrote: >> Hello, >> >> Wei recently discovered an issue when running a Linux PVH Dom0 on a >> box with a Intel Family 6 (0x6), Model 158 (0x9e), Stepping 9 (raw >> 000906e9) CPU, we are not sure

Re: [Xen-devel] [PATCH RFC] VMX: fix vmx_handle_eoi()

I'd vector and >original SVI don't match. > >Signed-off-by: Jan Beulich After correcting the description in the first paragraph Reviewed-by: Chao Gao I am curious about in which case, the EOI'd vector differs from original SVI. The sole caller of vmx_handle_eoi() is vlapic_EOI_set

Re: [Xen-devel] [PATCH] xen/pt: fix some pass-thru devices don't work across reboot

On Fri, Nov 09, 2018 at 02:14:04AM -0700, Jan Beulich wrote: On 09.11.18 at 01:11, wrote: >> I find some pass-thru devices don't work any more across guest >> reboot. Assigning it to another domain also meets the same issue. And >> the only way to make it work again is un-binding and binding

Re: [Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading

atch is also in accord with Andrew's suggestion, >"Rendezvous all online cpus in an IPI to apply the patch, and keep the >processors in until all have completed the patch.", in [1]. > >[1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates

Re: [Xen-devel] [PATCH v2] xen/pt: fix some pass-thru devices don't work across reboot

On Thu, Nov 15, 2018 at 11:40:39AM +0100, Roger Pau Monné wrote: >On Thu, Nov 15, 2018 at 09:10:26AM +0800, Chao Gao wrote: >> I find some pass-thru devices don't work any more across guest >> reboot. Assigning it to another domain also meets the same issue. And >> the onl

[Xen-devel] [PATCH v2] xen/pt: fix some pass-thru devices don't work across reboot

/lists.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html Signed-off-by: Chao Gao --- xen/arch/x86/msi.c| 18 ++ xen/drivers/passthrough/pci.c | 1 + 2 files changed, 19 insertions(+) diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c index 5567990..cd5

[Xen-devel] [PATCH] xen/pt: fix some pass-thru devices don't work across reboot

bit is updated. Also 'msix->warned' is initialized to DOMID_INVALID to avoid warnings missing for Dom0. [1]: https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg02520.html Signed-off-by: Chao Gao --- xen/drivers/passthrough/pci.c | 21 + 1 file changed,

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

On Wed, Jan 16, 2019 at 01:34:28PM +0100, Roger Pau Monné wrote: >On Wed, Jan 16, 2019 at 07:59:44PM +0800, Chao Gao wrote: >> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote: >> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote: >> >> diff -

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote: >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote: >> I find some pass-thru devices don't work any more across guest >> reboot. Assigning it to another domain also meets the same issue. And >> the onl

Re: [Xen-devel] an assertion triggered when running Xen on a HSW desktop

On Tue, Jan 15, 2019 at 09:18:25AM +0100, Roger Pau Monné wrote: >On Tue, Jan 15, 2019 at 04:04:40PM +0800, Chao Gao wrote: >[...] >> (XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04) >> 7.3.0) debug=y Tue Jan 15 07:25:29 UTC 2019 >> (XEN) Late

Re: [Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote: >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote: >> I find some pass-thru devices don't work any more across guest >> reboot. Assigning it to another domain also meets the same issue. And >> the onl

[Xen-devel] an assertion triggered when running Xen on a HSW desktop

The output of lscpu is: Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):8 On-line CPU(s) list: 0-7 Thread(s) per core:2 Core(s) per socket:4 Socket(s): 1 NUMA node(s): 1 Vendor ID:

[Xen-devel] [PATCH v5 1/3] xen/pt: fix some pass-thru devices don't work across reboot

/xen-devel/2017-09/msg02520.html Signed-off-by: Chao Gao --- Changes in v5: - fix the potential infinite loop - assert that unmap_domain_pirq() won't fail - assert msi_list is empty after the loop in pci_unmap_msi - provide a stub for pt_irq_destroy_bind_msi() if !CONFIG_HVM to fix a comp

[Xen-devel] [PATCH v5 2/3] libxl: don't reset device when it is accessible by the guest

the memory decoding of the device is disabled. Performing a device reset without proper method to avoid guest's MSI-X operation would lead to this issue. The fix is basic - detach pci device before resetting the device. Signed-off-by: Chao Gao Reviewed-by: Roger Pau Monné Acked-by: Wei Liu --- t

[Xen-devel] [PATCH v5 3/3] xen/pt: initialize 'warned' field of arch_msix properly

Also clean up current code by moving initialization of arch specific fields out of common code. Signed-off-by: Chao Gao Reviewed-by: Jan Beulich Reviewed-by: Roger Pau Monné --- Changes in v5: - rename init_arch_msix to arch_init_msix - place arch_init_msix right after the definition

Re: [Xen-devel] [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote: >>>> On 12.12.18 at 08:06, wrote: >> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote: >>>On 12/5/18 4:32 AM, Roger Pau Monné wrote: >>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800,

Re: [Xen-devel] [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

Ostrovsky wrote: >>>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote: >>>>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote: >>>>>>> I find some pass-thru devices don't work any more across guest reboot. >>>>>>> Assign

Re: [Xen-devel] [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

Jan Beulich wrote: >>>>>>>> On 12.12.18 at 08:06, wrote: >>>>>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote: >>>>>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote: >>>>>>>> On Wed, Dec 05, 2018 at

[Xen-devel] [PATCH v3 2/2] libxl: don't reset device when it is accessible by the guest

the memory decoding of the device is disabled. Performing a device reset without proper method to avoid guest's MSI-X operation would lead to this issue. The fix is basic - detach pci device before resetting the device. Signed-off-by: Chao Gao --- tools/libxl/libxl_pci.c | 10 +- 1 file

[Xen-devel] [PATCH v3 1/2] xen/pt: fix some pass-thru devices don't work across reboot

/xen-devel/2017-09/msg02520.html Signed-off-by: Chao Gao --- Applied this patch, qemu would report the error below: [00:05.0] msi_msix_disable: Error: Unbinding of MSI-X failed. (err: 1, pirq: 302, gvec: 0xd5) [00:05.0] msi_msix_disable: Error: Unbinding of MSI-X failed. (err: 1, pirq: 30

[Xen-devel] [PATCH v4 1/3] xen/pt: fix some pass-thru devices don't work across reboot

/xen-devel/2017-09/msg02520.html Signed-off-by: Chao Gao --- Changes in v4: - split out change to 'msix->warned' field - handle multiple msi cases - use list_first_entry_or_null to traverse 'pdev->msi_list' --- xen/drivers/passthrough/io.c | 57 +-- x

[Xen-devel] [PATCH v4 3/3] xen/pt: initialize 'warned' field of arch_msix properly

Also clean up current code by moving initialization of arch specific fields out of common code. Signed-off-by: Chao Gao --- Changes in v4: - newly added --- xen/drivers/passthrough/pci.c | 2 +- xen/include/asm-x86/msi.h | 5 + 2 files changed, 6 insertions(+), 1 deletion(-) diff

  1   2   3   4   >