Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

> -Original Message- > From: Roger Pau Monne > Sent: 22 March 2018 10:06 > To: Paul Durrant > Cc: 'Alexey G' ; xen-devel@lists.xenproject.org; > Andrew Cooper ; Ian Jackson > ; Jan Beulich

[Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

Hi all, please find attached a) Meeting details (just a link with timezones) – the meeting invite will follow when we have an agenda Bridge details – will be sent with the meeting invite I am thinking of using GotoMeeting, but want to try this with a Linux only user before I commit c)

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 10:09:16 + Paul Durrant wrote: [...] >> > I don't think we even want QEMU to have the freedom to say where >> > the MMCONFIG areas are located, do we? >> >> Sadly this how the chipset works. The PCIEXBAR register contains the >> position of

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

flight 120988 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/120988/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 120943 Tests which did

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

>>> On 22.03.18 at 12:56, wrote: > I really don't understand why some people have that fear of emulated > MMCONFIG -- it's really the same thing as any other MMIO range QEMU > already emulates via map_io_range_to_ioreq_server(). No sensitive > information exposed. It is related

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 09:57:16 + Roger Pau Monné wrote: [...] >> Yes, and it is still needed as we have two distinct (and not equal) >> interfaces to PCI conf space. Apart from 0..FFh range overlapping >> they can be considered very different interfaces. And whether it is

Re: [Xen-devel] [PATCH v5 2/5] x86/msr: add VMX MSRs into HVM_max domain policy

On 22/03/2018 10:14, Sergey Dyasli wrote: > On Wed, 2018-03-21 at 20:46 +, Andrew Cooper wrote: >> On 28/02/2018 16:09, Sergey Dyasli wrote: >>> + >>> +dp->vmx.pinbased_ctls.allowed_0.raw = VMX_PINBASED_CTLS_DEFAULT1; >>> +dp->vmx.pinbased_ctls.allowed_1.raw =

Re: [Xen-devel] [PATCH v3 39/39] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

Hi, On 22/03/18 08:16, Julien Grall wrote: > Hi Andre, > > On 03/21/2018 04:32 PM, Andre Przywara wrote: >> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c >> index 131358a5a1..22c70ff7cd 100644 >> --- a/xen/arch/arm/vgic/vgic.c >> +++ b/xen/arch/arm/vgic/vgic.c >> @@ -981,6

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 09:29:44 + Paul Durrant wrote: >> -Original Message- [...] >> >In both cases Xen would have to do the MCFG access decoding in order >> >to figure out which IOREQ server will handle the request. At which >> >point the only step that you

[Xen-devel] [PATCH v18 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table

A previous patch added support for priv-mapping guest resources directly (rather than having to foreign-map, which requires P2M modification for HVM guests). This patch makes use of the new API to seed the guest grant table unless the underlying infrastructure (i.e. privcmd) doesn't support it,

Re: [Xen-devel] [PATCH v5 1/5] x86/msr: add VMX MSRs definitions and populate Raw domain policy

On Wed, 2018-03-21 at 19:52 +, Andrew Cooper wrote: > On 28/02/18 16:09, Sergey Dyasli wrote: > > > > +struct { > > +/* 0x0480 MSR_IA32_VMX_BASIC */ > > +union { > > +uint64_t raw; > > +struct { > > +

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, Mar 22, 2018 at 08:49:58AM +1000, Alexey G wrote: > On Wed, 21 Mar 2018 17:15:04 + > Roger Pau Monné wrote: > [...] > >> Above scenario makes it obvious that at least for QEMU the MMIO->PCI > >> conf translation is a redundant step. Why not to allow specifying >

Re: [Xen-devel] [PATCH v11 10/12] vpci: add a priority parameter to the vPCI register initializer

>>> On 20.03.18 at 16:15, wrote: > This is needed for MSI-X, since MSI-X will need to be initialized > before parsing the BARs, so that the header BAR handlers are aware of > the MSI-X related holes and make sure they are not mapped in order for > the trap handlers to work

Re: [Xen-devel] [PATCH v11 04/12] pci: split code to size BARs from pci_add_device

On Thu, Mar 22, 2018 at 04:15:06AM -0600, Jan Beulich wrote: > >>> On 20.03.18 at 16:15, wrote: > > @@ -672,11 +722,16 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, > > unsigned int i; > > > > BUILD_BUG_ON(ARRAY_SIZE(pdev->vf_rlen) !=

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, Mar 22, 2018 at 09:29:44AM +, Paul Durrant wrote: > > The more I think about it, the more I like the existing > > map_io_range_to_ioreq_server() approach. :( It works without doing > > anything, no hacks, no new interfaces, both MMCONFIG and CF8/CFC are > > working as expected. There

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

> -Original Message- > From: Alexey G [mailto:x19...@gmail.com] > Sent: 22 March 2018 09:55 > To: Jan Beulich > Cc: Andrew Cooper ; Anthony Perard > ; Ian Jackson ; Paul > Durrant

Re: [Xen-devel] [PATCH v4] hvm/svm: Implement Debug events

>>> On 22.03.18 at 11:46, wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -172,6 +172,24 @@ static void svm_enable_msr_interception(struct domain > *d, uint32_t msr) > svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE); > } > >

Re: [Xen-devel] [PATCH v3 34/39] ARM: new VGIC: vgic-init: register VGIC

Hi, On 22/03/18 08:00, Julien Grall wrote: > Hi Andre, > > On 03/21/2018 04:32 PM, Andre Przywara wrote: >> This patch implements the function which is called by Xen when it wants >> to register the virtual GIC. >> This also implements vgic_max_vcpus() for the new VGIC, which reports >> back the

[Xen-devel] [PATCH v6 1/5] x86/msr: add VMX MSRs definitions and populate Raw domain policy

New definitions provide a convenient way of accessing contents of VMX MSRs. They are separated into 5 logical blocks based on the availability conditions of MSRs in the each block: 1. vmx: [VMX_BASIC, VMX_VMCS_ENUM] 2. VMX_PROCBASED_CTLS2 3. VMX_EPT_VPID_CAP 4. vmx_true_ctls:

[Xen-devel] [PATCH v6 3/5] x86/cpuid: update signature of hvm_cr4_guest_valid_bits()

With the new cpuid infrastructure there is a domain-wide struct cpuid policy and there is no need to pass a separate struct vcpu * into hvm_cr4_guest_valid_bits() anymore. Make the function accept struct domain * instead and update callers. Signed-off-by: Sergey Dyasli

[Xen-devel] [PATCH v6 4/5] x86/msr: update domain policy on CPUID policy changes

Availability of some MSRs depends on certain CPUID bits. Add function recalculate_domain_msr_policy() which updates availability of MSRs based on current domain's CPUID policy. This function is called when CPUID policy is changed from a toolstack. Add recalculate_domain_vmx_msr_policy() which

[Xen-devel] [PATCH v6 5/5] x86/msr: handle VMX MSRs with guest_rd/wrmsr()

Now that each domain has a correct view of VMX MSRs in it's per-domain MSR policy, it's possible to handle guest's RD/WRMSR with the new handlers. Do it and remove the old nvmx_msr_read_intercept() and associated bits. There is no functional change to what a guest sees in its VMX MSRs.

[Xen-devel] [PATCH v6 0/5] VMX MSRs policy for Nested Virt: part 1

The end goal of having VMX MSRs policy is to be able to manage L1 VMX features. This patch series is the first part of this work. There is no functional change to what L1 sees in VMX MSRs at this point. But each domain will have a policy object which allows to sensibly query what VMX features the

[Xen-devel] [PATCH v18 08/11] tools/libxenforeignmemory: add support for resource mapping

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest resources for direct priv-mapping. This patch adds new functionality into libxenforeignmemory to make use of a new privcmd ioctl [1] that uses the new memory op to make such resources available via mmap(2). [1]

Re: [Xen-devel] [PATCH v4 7/8] x86: also NOP out xen_cr3 restores of XPTI

On Mon, Mar 19, 2018 at 07:41:11AM -0600, Jan Beulich wrote: > ... despite quite likely the gain being rather limited. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v4 5/8] x86/XPTI: reduce .text.entry

On Mon, Mar 19, 2018 at 07:40:12AM -0600, Jan Beulich wrote: > This exposes less code pieces and at the same time reduces the range > covered from slightly above 3 pages to a little below 2 of them. > > The code being moved is unchanged, except for the removal of trailing > blanks, insertion of

Re: [Xen-devel] [PATCH v4 6/8] x86: enable interrupts earlier with XPTI disabled

On Mon, Mar 19, 2018 at 07:40:50AM -0600, Jan Beulich wrote: > The STI instances were moved (or added in the INT80 case) to meet TLB > flush requirements. When XPTI is disabled, they can be put back where > they were (or omitted in the INT80 case). > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

On 03/22/2018 03:14 AM, Boris Ostrovsky wrote: On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 03:04:16 -0600 "Jan Beulich" wrote: On 22.03.18 at 01:31, wrote: >> On Wed, 21 Mar 2018 17:06:28 + >> Paul Durrant wrote: >> [...] Well, this might work actually. Although the overall scenario

Re: [Xen-devel] [PATCH v11 04/12] pci: split code to size BARs from pci_add_device

>>> On 20.03.18 at 16:15, wrote: > @@ -672,11 +722,16 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, > unsigned int i; > > BUILD_BUG_ON(ARRAY_SIZE(pdev->vf_rlen) != PCI_SRIOV_NUM_BARS); > -for ( i = 0; i < PCI_SRIOV_NUM_BARS; ++i ) >

Re: [Xen-devel] [PATCH v5 2/5] x86/msr: add VMX MSRs into HVM_max domain policy

On Wed, 2018-03-21 at 20:46 +, Andrew Cooper wrote: > On 28/02/2018 16:09, Sergey Dyasli wrote: > > + > > +dp->vmx.pinbased_ctls.allowed_0.raw = VMX_PINBASED_CTLS_DEFAULT1; > > +dp->vmx.pinbased_ctls.allowed_1.raw = VMX_PINBASED_CTLS_DEFAULT1; > > +supported =

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

De-htmling... - From: Lars Kurth Sent: 22 March 2018 10:22 To: xen-de...@lists.xensource.com Cc: committ...@xenproject.org; Juergen Gross ; Janakarajan Natarajan ; Tamas K Lengyel ; Wei Liu ; Andrew Cooper

Re: [Xen-devel] [PATCH v11 04/12] pci: split code to size BARs from pci_add_device

>>> On 22.03.18 at 11:31, wrote: > On Thu, Mar 22, 2018 at 04:15:06AM -0600, Jan Beulich wrote: >> >>> On 20.03.18 at 16:15, wrote: >> > @@ -672,11 +722,16 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, >> > unsigned int i; >> > >> >

[Xen-devel] [PATCH v6 2/5] x86/msr: add VMX MSRs into HVM_max domain policy

Currently, when nested virt is enabled, the set of L1 VMX features is fixed and calculated by nvmx_msr_read_intercept() as an intersection between the full set of Xen's supported L1 VMX features, the set of actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of features that Xen uses.

[Xen-devel] [PATCH v18 06/11] x86/hvm/ioreq: add a new mappable resource type...

... XENMEM_resource_ioreq_server This patch adds support for a new resource type that can be mapped using the XENMEM_acquire_resource memory op. If an emulator makes use of this resource type then, instead of mapping gfns, the IOREQ server will allocate pages from the emulating domain's heap.

[Xen-devel] [PATCH v18 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requested

A subsequent patch will introduce a new scheme to allow an emulator to map ioreq server pages directly from Xen rather than the guest P2M. This patch lays the groundwork for that change by deferring mapping of gfns until their values are requested by an emulator. To that end, the pad field of the

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, Mar 22, 2018 at 10:29:22PM +1000, Alexey G wrote: > On Thu, 22 Mar 2018 09:57:16 + > Roger Pau Monné wrote: > [...] > >> Yes, and it is still needed as we have two distinct (and not equal) > >> interfaces to PCI conf space. Apart from 0..FFh range overlapping >

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

> -Original Message- > From: Alexey G [mailto:x19...@gmail.com] > Sent: 21 March 2018 22:50 > To: Roger Pau Monne > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; Ian Jackson ; Jan > Beulich

[Xen-devel] [PATCH v4] hvm/svm: Implement Debug events

At this moment the Debug events for the AMD architecture are not forwarded to the monitor layer. This patch adds the Debug event to the common capabilities, adds the VMEXIT_ICEBP then forwards the event to the monitor layer. Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1

[Xen-devel] [PATCH v3a 00/39] (0/3) Fixups for the new VGIC(-v2) implementation

Hi, this is just an update of the three patches which didn't get any review tags so far. The fixes for the new versions of 03/39 and 39/39 are pretty straight forward, but 14/39 is more of a beast. I sent a diff to the original patch [1] separately to give an idea of the changes. I added the

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 10:06:09 + Paul Durrant wrote: >> -Original Message- >> From: Alexey G [mailto:x19...@gmail.com] >> Sent: 22 March 2018 09:55 >> To: Jan Beulich >> Cc: Andrew Cooper ; Anthony Perard >>

[Xen-devel] [PATCH v3a 39/39] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

Now that we have both the old VGIC prepared to cope with a sibling and the code for the new VGIC in place, lets add a Kconfig option to enable the new code and wire it into the Xen build system. This will add a compile time option to use either the "old" or the "new" VGIC. In the moment this is

[Xen-devel] [PATCH v3a 03/39] ARM: GIC: Allow tweaking the active and pending state of an IRQ

When playing around with hardware mapped, level triggered virtual IRQs, there is the need to explicitly set the active or pending state of an interrupt at some point. To prepare the GIC for that, we introduce a set_active_state() and a set_pending_state() function to let the VGIC manipulate the

[Xen-devel] [PATCH v3a 14/39] ARM: new VGIC: Add GICv2 world switch backend

Processing maintenance interrupts and accessing the list registers are dependent on the host's GIC version. Introduce vgic-v2.c to contain GICv2 specific functions. Implement the GICv2 specific code for syncing the emulation state into the VGIC registers. This also adds the hook to let Xen setup

[Xen-devel] [PATCH v18 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

This patch allows grant table frames to be mapped using the XENMEM_acquire_resource memory op. NOTE: This patch expands the on-stack mfn_list array in acquire_resource() but it is still small enough to remain on-stack. Signed-off-by: Paul Durrant --- Cc: Jan

[Xen-devel] [xen-unstable-smoke test] 121056: trouble: blocked/broken/pass

flight 121056 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121056/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf

Re: [Xen-devel] [PATCH v4 1/8] x86: NOP out XPTI entry/exit code when it's not in use

On Mon, Mar 19, 2018 at 07:37:54AM -0600, Jan Beulich wrote: > Introduce a synthetic feature flag to use alternative instruction > patching to NOP out all code on entry/exit paths. Having NOPs here is > generally better than using conditional branches. > > Also change the limit on the number of

Re: [Xen-devel] [PATCH v4 4/8] x86/XPTI: use %r12 to write zero into xen_cr3

On Mon, Mar 19, 2018 at 07:39:34AM -0600, Jan Beulich wrote: > Now that we zero all registers early on all entry paths, use that to > avoid a couple of immediates here. > > Signed-off-by: Jan Beulich > Acked-by: Andrew Cooper Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH v4 3/8] x86: log XPTI enabled status

On Mon, Mar 19, 2018 at 07:39:04AM -0600, Jan Beulich wrote: > At the same time also report the state of the two defined > ARCH_CAPABILITIES MSR bits. To avoid further complicating the > conditional around that printk(), drop it (it's a debug level one only > anyway). > > Issue the main message

Re: [Xen-devel] [PATCH v3 15/39] ARM: new VGIC: Implement vgic_vcpu_pending_irq

Hi, On 22/03/18 03:52, Julien Grall wrote: > Hi Andre, > > On 03/21/2018 04:32 PM, Andre Przywara wrote: >> Tell Xen whether a particular VCPU has an IRQ that needs handling >> in the guest. This is used to decide whether a VCPU is runnable or >> if a hypercall should be preempted to let the

[Xen-devel] [PATCH v18 00/11] x86: guest resource mapping

This series introduces support for direct mapping of guest resources. The resources are: - IOREQ server pages - Grant tables v18: - Re-base - Use the now-reference-counted emulating domain to host ioreq pages v17: - Make sure ioreq page free-ing is done at domain destruction v16: - Fix

[Xen-devel] [PATCH v18 02/11] x86/hvm/ioreq: simplify code and use consistent naming

This patch re-works much of the ioreq server initialization and teardown code: - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called separately by outer functions. - Several functions now test the validity

[Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

Certain memory resources associated with a guest are not necessarily present in the guest P2M. This patch adds the boilerplate for new memory op to allow such a resource to be priv-mapped directly, by either a PV or HVM tools domain. NOTE: Whilst the new op is not intrinsicly specific to the x86

[Xen-devel] [PATCH v18 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

This patch adjusts the ioreq server code to use type-safe gfn_t values where possible. No functional change. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

On Thu, Mar 22, 2018 at 10:27:35AM +, Paul Durrant wrote: > De-htmling... > > - > From: Lars Kurth > Sent: 22 March 2018 10:22 > To: xen-de...@lists.xensource.com > Cc: committ...@xenproject.org; Juergen Gross ; Janakarajan > Natarajan ; Tamas K

[Xen-devel] [PATCH v18 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

A subsequent patch will remove the current implicit limitation on creation of ioreq servers which is due to the allocation of gfns for the ioreq structures and buffered ioreq ring. It will therefore be necessary to introduce an explicit limit and, since this limit should be small, it simplifies

[Xen-devel] [PATCH v18 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint

By using a static inline stub in private.h for OS where this functionality is not implemented, the various duplicate stubs in the OS-specific source modules can be avoided. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Acked-by: Wei Liu

[Xen-devel] [PATCH v18 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

...to allow the calling domain to prevent translation of specified l1e value. Despite what the comment in public/xen.h might imply, specifying a command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with the specified value. Instead, mod_l1_entry() tests whether foreign_dom has

Re: [Xen-devel] [for-4.11][PATCH v6 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

Hi, At 04:47 + on 21 Mar (1521607657), Julien Grall wrote: > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make page_to_mfn and mfn_to_page return mfn_t

Re: [Xen-devel] [PATCH v3 3/7] xen/x86: support per-domain flag for xpti

On 22/03/18 16:26, Jan Beulich wrote: On 21.03.18 at 13:51, wrote: >> +void xpti_domain_init(struct domain *d) >> +{ >> +if ( !is_pv_domain(d) || is_pv_32bit_domain(d) ) >> +return; > > As you rely on the zero-initialization of the field here, ... > >> +

Re: [Xen-devel] [PATCH v3 4/7] xen/x86: use invpcid for flushing the TLB

>>> On 21.03.18 at 13:51, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1380,6 +1380,14 @@ Because responsibility for APIC setup is shared > between Xen and the > domain 0 kernel this option is automatically propagated to

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

On 03/22/2018 12:22 PM, Lars Kurth wrote: > Hi all, > > please find attached  > a) Meeting details (just a link with timezones) – the meeting invite > will follow when we have an agenda >    Bridge details – will be sent with the meeting invite >    I am thinking of using GotoMeeting, but want to

[Xen-devel] [PATCH v12 05/12] pci: add support to size ROM BARs to pci_size_mem_bar

Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Julien Grall

[Xen-devel] [PATCH v12 02/12] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

Introduce a set of handlers for the accesses to the MMCFG areas. Those areas are setup based on the contents of the hardware MMCFG tables, and the list of handled MMCFG areas is stored inside of the hvm_domain struct. The read/writes are forwarded to the generic vpci handlers once the address is

[Xen-devel] [PATCH v12 07/12] vpci: add header handlers

Introduce a set of handlers that trap accesses to the PCI BARs and the command register, in order to snoop BAR sizing and BAR relocation. The command handler is used to detect changes to bit 2 (response to memory space accesses), and maps/unmaps the BARs of the device into the guest p2m. A

[Xen-devel] [PATCH v12 06/12] xen: introduce rangeset_consume_ranges

This function allows to iterate over a rangeset while removing the processed regions. This will be used in order to split processing of large memory areas when mapping them into the guest p2m. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu ---

Re: [Xen-devel] [PATCH v3a 03/39] ARM: GIC: Allow tweaking the active and pending state of an IRQ

Hi Andre, On 03/22/2018 11:56 AM, Andre Przywara wrote: When playing around with hardware mapped, level triggered virtual IRQs, there is the need to explicitly set the active or pending state of an interrupt at some point. To prepare the GIC for that, we introduce a set_active_state() and a

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

>>> On 22.03.18 at 15:34, wrote: > On Thu, 22 Mar 2018 07:20:00 -0600 > "Jan Beulich" wrote: > > On 22.03.18 at 14:05, wrote: >>> On Thu, 22 Mar 2018 06:09:44 -0600 >>> "Jan Beulich" wrote: >>> >>> On

Re: [Xen-devel] [PATCH] x86emul: fix #XM delivery typo

On 22/03/18 14:41, Roger Pau Monné wrote: > On Thu, Mar 22, 2018 at 08:40:04AM -0600, Jan Beulich wrote: >> This clearly wasn't meant the way it was originally written. >> >> Reported-by: Roger Pau Monné >> Signed-off-by: Jan Beulich > Reviewed-by: Roger

Re: [Xen-devel] [PATCH v3 1/7] x86/xpti: avoid copying L4 page table contents when possible

On 22/03/18 15:31, Jan Beulich wrote: On 21.03.18 at 13:51, wrote: >> --- a/xen/arch/x86/flushtlb.c >> +++ b/xen/arch/x86/flushtlb.c >> @@ -158,6 +158,9 @@ unsigned int flush_area_local(const void *va, unsigned >> int flags) >> } >> } >> >> +if ( flags &

Re: [Xen-devel] possible I/O emulation state machine issue

On 22/03/18 15:12, Jan Beulich wrote: > Paul, > > our PV driver person has found a reproducible crash with ws2k8, > triggered by one of the WHQL tests. The guest get crashed because > the re-issue check of an ioreq close to the top of hvmemul_do_io() > fails. I've handed him a first debugging

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

>>> On 22.03.18 at 14:05, wrote: > On Thu, 22 Mar 2018 06:09:44 -0600 > "Jan Beulich" wrote: > > On 22.03.18 at 12:56, wrote: >>> I really don't understand why some people have that fear of emulated >>> MMCONFIG -- it's really the

Re: [Xen-devel] [PATCH v4 8/8] x86: avoid double CR3 reload when switching to guest user mode

On Mon, Mar 19, 2018 at 07:41:42AM -0600, Jan Beulich wrote: > When XPTI is active, the CR3 load in restore_all_guest is sufficient > when switching to user mode, improving in particular system call and > page fault exit paths for the guest. > > Signed-off-by: Jan Beulich >

Re: [Xen-devel] [PATCH v5 05/14] x86/HVM: eliminate custom #MF/#XM handling

On Thu, Mar 15, 2018 at 07:06:36AM -0600, Jan Beulich wrote: > @@ -8478,7 +8411,8 @@ x86_emulate( > } > > complete_insn: /* Commit shadow register state. */ > -put_fpu(, false, state, ctxt, ops); > +put_fpu(fpu_type, false, state, ctxt, ops); > +fpu_type = X86EMUL_FPU_none; >

Re: [Xen-devel] [PATCH v3 1/7] x86/xpti: avoid copying L4 page table contents when possible

>>> On 21.03.18 at 13:51, wrote: > --- a/xen/arch/x86/flushtlb.c > +++ b/xen/arch/x86/flushtlb.c > @@ -158,6 +158,9 @@ unsigned int flush_area_local(const void *va, unsigned > int flags) > } > } > > +if ( flags & FLUSH_ROOT_PGTBL ) > +

Re: [Xen-devel] [PATCH v3 2/7] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

>>> On 21.03.18 at 13:51, wrote: > When switching to a 64-bit pv context the TLB is flushed twice today: > the first time when switching to the new address space in > write_ptbase(), the second time when switching to guest mode in > restore_to_guest. > > Avoid the first TLB

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 08:42:09 -0600 "Jan Beulich" wrote: On 22.03.18 at 15:34, wrote: >> On Thu, 22 Mar 2018 07:20:00 -0600 >> "Jan Beulich" wrote: >> >> On 22.03.18 at 14:05, wrote: On Thu, 22 Mar

Re: [Xen-devel] [PATCH v3 3/7] xen/x86: support per-domain flag for xpti

>>> On 21.03.18 at 13:51, wrote: > +void xpti_domain_init(struct domain *d) > +{ > +if ( !is_pv_domain(d) || is_pv_32bit_domain(d) ) > +return; As you rely on the zero-initialization of the field here, ... > +switch ( opt_xpti ) > +{ > +case XPTI_OFF: >

Re: [Xen-devel] [PATCH v3a 14/39] ARM: new VGIC: Add GICv2 world switch backend

Hi Andre, On 03/22/2018 11:56 AM, Andre Przywara wrote: +/* The locking order forces us to drop and re-take the locks here. */ +if ( irq->hw ) +{ +spin_unlock(>irq_lock); + +desc = irq_to_desc(irq->hwintid); +spin_lock(>lock); +

Re: [Xen-devel] [PATCH v5 05/14] x86/HVM: eliminate custom #MF/#XM handling

>>> On 22.03.18 at 15:12, wrote: > On Thu, Mar 15, 2018 at 07:06:36AM -0600, Jan Beulich wrote: >> @@ -8478,7 +8411,8 @@ x86_emulate( >> } >> >> complete_insn: /* Commit shadow register state. */ >> -put_fpu(, false, state, ctxt, ops); >> +put_fpu(fpu_type,

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 12:44:02 + Roger Pau Monné wrote: >On Thu, Mar 22, 2018 at 10:29:22PM +1000, Alexey G wrote: >> On Thu, 22 Mar 2018 09:57:16 + >> Roger Pau Monné wrote: >> [...] >> >> Yes, and it is still needed as we have two distinct

[Xen-devel] [xen-unstable-smoke test] 121061: trouble: blocked/broken/pass

flight 121061 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121061/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf

Re: [Xen-devel] [PATCH v4 8/8] x86: avoid double CR3 reload when switching to guest user mode

>>> On 22.03.18 at 14:20, wrote: > On Mon, Mar 19, 2018 at 07:41:42AM -0600, Jan Beulich wrote: >> --- a/xen/arch/x86/pv/domain.c >> +++ b/xen/arch/x86/pv/domain.c >> @@ -219,10 +219,22 @@ int pv_domain_initialise(struct domain * >> return rc; >> } >> >> -static void

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

Hi, On 03/22/2018 11:55 AM, Roger Pau Monné wrote: On Thu, Mar 22, 2018 at 10:27:35AM +, Paul Durrant wrote: De-htmling... - From: Lars Kurth Sent: 22 March 2018 10:22 To: xen-de...@lists.xensource.com Cc: committ...@xenproject.org; Juergen Gross ; Janakarajan

Re: [Xen-devel] [PATCH v3 14/39] ARM: new VGIC: Add GICv2 world switch backend

Hi Andre, On 03/22/2018 11:04 AM, Andre Przywara wrote: This is a "patch to the patch" mentioned above, to make it clear what changed: We now take the desc lock in vgic_v2_fold_lr_state() when we are dealing with a hardware IRQ. This is a bit complicated, because we have to obey the existing

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

Removing the non-working Intel alias @John: once this alias actually works, let me know. The start of the thread is at https://lists.xenproject.org/archives/html/xen-devel/2018-03/threads.html#02672 @All: To summarize in terms of higher level discussions: * Discuss PCI emulation and our future

Re: [Xen-devel] [for-4.11][PATCH v6 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

On 03/22/2018 12:24 PM, Tim Deegan wrote: Hi, Hi Tim, At 04:47 + on 21 Mar (1521607657), Julien Grall wrote: Most of the users of page_to_mfn and mfn_to_page are either overriding the macros to make them work with mfn_t or use mfn_x/_mfn because the rest of the function use mfn_t. So

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Thu, 22 Mar 2018 07:20:00 -0600 "Jan Beulich" wrote: On 22.03.18 at 14:05, wrote: >> On Thu, 22 Mar 2018 06:09:44 -0600 >> "Jan Beulich" wrote: >> >> On 22.03.18 at 12:56, wrote: I really don't

[Xen-devel] possible I/O emulation state machine issue

Paul, our PV driver person has found a reproducible crash with ws2k8, triggered by one of the WHQL tests. The guest get crashed because the re-issue check of an ioreq close to the top of hvmemul_do_io() fails. I've handed him a first debugging patch, output of which suggests that we're dealing

[Xen-devel] [PATCH v12 08/12] x86/pt: mask MSI vectors on unbind

When a MSI device with per-vector masking capabilities is detected or added to Xen all the vectors are masked when initializing it. This implies that the first time the interrupt is bound to a domain it's masked. This however only applies to the first time the interrupt is bound because neither

[Xen-devel] [PATCH v12 10/12] vpci: add a priority parameter to the vPCI register initializer

This is needed for MSI-X, since MSI-X will need to be initialized before parsing the BARs, so that the header BAR handlers are aware of the MSI-X related holes and make sure they are not mapped in order for the trap handlers to work properly. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v12 01/12] vpci: introduce basic handlers to trap accesses to the PCI config space

This functionality is going to reside in vpci.c (and the corresponding vpci.h header), and should be arch-agnostic. The handlers introduced in this patch setup the basic functionality required in order to trap accesses to the PCI config space, and allow decoding the address and finding the

[Xen-devel] [PATCH v12 00/12] vpci: PCI config space emulation

Hello, The following series contain an implementation of handlers for the PCI configuration space inside of Xen. This allows Xen to detect accesses to the PCI configuration space and react accordingly. Why is this needed? IMHO, there are two main points of doing all this emulation inside of Xen,

[Xen-devel] [PATCH v12 11/12] vpci/msix: add MSI-X handlers

Add handlers for accesses to the MSI-X message control field on the PCI configuration space, and traps for accesses to the memory region that contains the MSI-X table and PBA. This traps detect attempts from the guest to configure MSI-X interrupts and properly sets them up. Note that accesses to

[Xen-devel] [PATCH v12 03/12] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

So that MMCFG regions not present in the MCFG ACPI table can be added at run time by the hardware domain. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant --- Cc: Jan Beulich

[Xen-devel] [PATCH v12 09/12] vpci/msi: add MSI handlers

Add handlers for the MSI control, address, data and mask fields in order to detect accesses to them and setup the interrupts as requested by the guest. Note that the pending register is not trapped, and the guest can freely read/write to it. Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v3a 39/39] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

Hi Andre, On 03/22/2018 11:56 AM, Andre Przywara wrote: Now that we have both the old VGIC prepared to cope with a sibling and the code for the new VGIC in place, lets add a Kconfig option to enable the new code and wire it into the Xen build system. This will add a compile time option to use

[Xen-devel] [PATCH v12 04/12] pci: split code to size BARs from pci_add_device

So that it can be called from outside in order to get the size of regular PCI BARs. This will be required in order to map the BARs from PCI devices into PVH Dom0 p2m. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich

Re: [Xen-devel] [PATCH v3 14/39] ARM: new VGIC: Add GICv2 world switch backend

This is a "patch to the patch" mentioned above, to make it clear what changed: We now take the desc lock in vgic_v2_fold_lr_state() when we are dealing with a hardware IRQ. This is a bit complicated, because we have to obey the existing locking order, so do our infamous "drop-take-retake" dance.

Re: [Xen-devel] [PATCH v3 03/39] ARM: GIC: Allow tweaking the active and pending state of an IRQ

Hi, On 22/03/18 01:51, Julien Grall wrote: > Hi Andre, > > On 03/21/2018 04:31 PM, Andre Przywara wrote: >> When playing around with hardware mapped, level triggered virtual IRQs, >> there is the need to explicitly set the active or pending state of an >> interrupt at some point. >> To prepare

  1   2   >