>>> On 21.03.18 at 18:57, wrote:
> On 21/03/18 05:46, Juergen Gross wrote:
>> On 20/03/18 18:22, Andrew Cooper wrote:
>>> On 20/03/18 16:58, Jan Beulich wrote:
>>> On 19.03.18 at 20:13, wrote:
> It is not entirely clear why this interlock was introduced in c/s
> 8cbb5278e
> "x86/
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
Those three registers are v2 emulation specific, so their implementation
lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
as their implementation is pretty simple.
We choose to piggy-back on the existing KVM identifi
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.
This is based on Linux commit 55cc01fb9004, written by Andre Przywara.
Signed-off-by: Andre Przywara
Reviewed-by: Julien Grall
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 maximum number of VCPUs a certain GIC model supports. Simila
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and number of virtual CPUs is frozen.
Implement the various functions that the Xen arch
flight 120982 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120982/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120921
test-armhf-armhf-libvirt 14 saveresto
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
At the moment we allocate exactly one page for struct vcpu on ARM, also
have a check in place to prevent it growing beyond 4KB.
As the struct includes the state of all 32 private (per-VCPU) interrupts,
we are at 3840 bytes on arm64 at the m
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 +981,16 @@ unsigned int vgic_max_vcpus(const struct domain *d)
Hi,
On 03/21/2018 04:47 AM, Julien Grall wrote:
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Sorry I added in the changelog but forgot to add George's reviewed-by
Reviewed-by: George Dunlap
Cheers,
Changes in v6:
- Remove the justification from the commit messa
Hi,
On 03/21/2018 04:47 AM, Julien Grall wrote:
Arm does not have an M2P and very unlikely to get one in the future,
therefore don't keep defines that are not necessary in the common code.
At the same time move the remaining M2P define just above
set_gpfn_from_mfn to keep all the dummy helpers
>>> 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 will be
>>> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will
>>> look:
>>>
>>> QEMU receives PCIEXBAR update -> c
Hi,
On 03/21/2018 04:43 PM, Wei Liu wrote:
On Wed, Mar 14, 2018 at 01:27:37PM +, Julien Grall wrote:
Hi,
On 03/14/2018 12:32 PM, Wei Liu wrote:
Gcc with -O3 failed to spot the loop to initialise p2m_size runs at
least once.
Aside, Andrew's comment the patch looks okay. But I am wonderin
On Wed, Mar 21, 2018 at 06:09:57PM +, Wei Liu wrote:
> On Wed, Mar 21, 2018 at 02:42:10PM +, Roger Pau Monne wrote:
> > The start_info size calculated in bootlate_hvm is wrong. It should use
> > HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
> > take into account the
>>> On 21.03.18 at 20:52, wrote:
> On 28/02/18 16:09, Sergey Dyasli wrote:
>> +uint32_t:1; /* 15 reserved */
>> +bool superpage_2mb:1;
>> +bool superpage_1gb:1;
>
> _2mb and _1gb respectively.
That'll be a name space vi
On Wed, Mar 21, 2018 at 01:53:37PM -0400, Boris Ostrovsky wrote:
> On 03/21/2018 10:18 AM, Roger Pau Monné wrote:
> > On Wed, Mar 21, 2018 at 09:37:09AM -0400, Boris Ostrovsky wrote:
> >> On 03/21/2018 06:07 AM, Roger Pau Monné wrote:
> >>> On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wro
> -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 ; Wei Liu ; Paul Durrant
> ; Anthony Perard ;
> Stefano Stabellini
> Subject: Re: [Xen-deve
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 application
and its helper library [2], ca
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 {
> > +uint3
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 will
be overcomplicated a bit for _PCI_CONFIG ioreqs. Here
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
> >> for DM whether it pr
>>> 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 properly.
>
> Signed-of
> -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 ; Roger Pau Monne
> ; Wei Liu ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-deve
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 is
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
__
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 by
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 wi
> -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 ; Wei Liu
> ; Anthony Perard ;
> Stefano Stabellini
> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvm
>>> 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 )
> +for ( i =
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 = PIN_BASED_EXT_INTR_MAS
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) Call
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 = VMX_PINBASED_CTLS_DEFAULT1
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 ; Daniel Kiper
; Roger Pau Monné ; Christopher
Clark ; Rich Persaud ; Paul
Durrant
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) != PCI_SRIOV_NUM_BARS);
> > -
>>> 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;
>> >
>> > BUILD_BUG_ON(ARRAY_SIZE(pdev->vf_
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 +981
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
exce
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 avoid is the reconstruction o
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.
Al
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 th
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 gues
>>> 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);
> }
>
> +static void svm_set_icebp_
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
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 d
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
Reviewed-by: Andrew Cooper
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 chan
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: [VMX_
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.
Signed-off
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.
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 the MCFG area. And this is e
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
... 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. The
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 Lengyel ; Wei Liu
> ; Andrew Cooper ; Dan
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 th
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 def
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 o
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
---
Cc: Ian Jackson
v4:
- Removed extraneous
...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 PG_tr
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
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
---
Cc: Andrew Cooper
v18:
- Trivial re-base.
---
xen/arch/x86/hvm/ioreq.c
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
>> ; Ian Jackson ;
>> Paul Durrant ; Roger Pau Monne
>> ; Wei Liu ; Stefano
>> St
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 R-b:
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 res
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 sta
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 th
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 Beulich
Cc: Andrew Cooper
Cc:
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, in
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]
http://xenbit
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 no
>>> 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 only to emulated PC
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
Reviewed-by: Wei
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 bl
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
Xen-devel@lists.xenproject.org
https://lists.xenproj
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 by
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
>> a real system or emu
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
> >> they can be considere
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
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 same thing as any other MMIO range QEMU
>> already emulates via map_io_range_to_ioreq_server(). No se
>>> 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 same thing as any other MMIO range QEMU
>>> already emulat
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
> Tested-by: Juergen Gro
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
>>> 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 _toggle_guest_pt(struc
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 Natarajan ; Tamas K Lengy
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 loc
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
set_
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
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
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
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v6:
- Remove the rom local variable.
Changes si
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 d
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 rangese
Some functions in vpci.c (vpci_remove_device and vpci_add_handlers)
are not used by the user-space test harness, so guard them with
__XEN__ in order to avoid exposing them to the user-space test
harness.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: I
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é
Reviewed-by: Jan Beulic
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 ei
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
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackso
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 th
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é
Reviewed-by: Jan Beulic
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 correspo
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,
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 t
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
Cc: Andrew Cooper
Cc: Paul Durrant
---
Changes since v7:
- Add newline in hvm_physd
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
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->irq_lock);
+
+desc = irq_to_desc(irq->hwintid);
+spin_lock(&desc->lock)
1 - 100 of 152 matches
Mail list logo
