>>> On 15.03.18 at 18:07, wrote:
> On 15/03/18 17:02, Jan Beulich wrote:
> On 15.03.18 at 17:43, wrote:
>>> +static inline void enable_nmis(void)
>>> +{
>>> +unsigned long tmp;
>>> +
>>> +asm volatile ( "mov %%rsp, %[sp] \n\t"
>>> + "push %[ss] \n\t"
>>
>>> On 15.03.18 at 18:10, wrote:
> On 13/03/18 13:50, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -14,8 +14,6 @@
>> #include
>> #include
>>
>> -.section .text.entry, "ax", @progbits
>> -
>> /* %rbx: struct vcpu */
>> ENTRY(swit
>>> On 15.03.18 at 17:33, wrote:
> On Thu, Mar 15, 2018 at 06:45:58AM -0600, Jan Beulich wrote:
>> >>> On 15.03.18 at 13:01, wrote:
>> > On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beulich wrote:
>> >> >>> On 14.03.18 at 15:04, wrote:
>> >> > +process_pending_softirqs();
>> >>
>>
>>> On 15.03.18 at 21:15, wrote:
> On 09/03/18 16:54, Jan Beulich wrote:
> On 09.03.18 at 14:18, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -430,20 +430,37 @@ int arch_domain_create(struct domain *d, unsigned int
>>> domcr_flags,
>>>
>>> On 15.03.18 at 21:25, wrote:
> On 13/03/18 14:39, Jan Beulich wrote:
> On 13.03.18 at 13:28, wrote:
>>> On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote:
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1187,8 +1187,8 @@ unsigned long domain_get_maximum_gpfn
On Tue, Mar 13, 2018 at 06:21:05PM +0200, 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], capable of running as a We
On 16/03/2018 07:43, Jan Beulich wrote:
On 15.03.18 at 21:25, wrote:
>> On 13/03/18 14:39, Jan Beulich wrote:
>> On 13.03.18 at 13:28, wrote:
On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1187,8 +
>>> On 15.03.18 at 20:44, wrote:
> On 13/03/18 13:47, 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
On 16/03/18 00:08, Stefano Stabellini wrote:
Hi all,
Hi Stefano,
I suggest to have the next community call on Wednesday 4th April 4PM
UTC. Keep in mind that due to Daylight Savings Time 4PM UTC is the usual
time slot: 9AM California, 5PM UK. Does it work for everybody?
This works for me.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 March 2018 16:54
> To: Paul Durrant
> Cc: Kevin Tian ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 4/7] vtd: add lookup_page method to iommu_ops
>
> >>> On 12.02.18 at 11:47, wrote:
> > This patch add
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 March 2018 16:16
> To: Paul Durrant
> Cc: Suravee Suthikulpanit ; Andrew
> Cooper ; Kevin Tian ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 3/7] iommu: push use of type-safe BFN and MFN into
> iommu_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 March 2018 15:45
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Jun Nakajima ; Kevin Tian
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; Konrad
>>> On 16.03.18 at 11:19, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 15 March 2018 16:54
>>
>> >>> On 12.02.18 at 11:47, wrote:
>> > This patch adds a new method to the VT-d IOMMU implementation to find
>> the
>> > MFN currently mapped by the specified BFN. This functionalit
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 March 2018 13:40
> To: Paul Durrant
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Kevin Tian ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 1/7] iommu: introduce the concept of BF
On 16/03/18 10:46, Jan Beulich wrote:
On 15.03.18 at 20:44, wrote:
>> On 13/03/18 13:47, 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 condition
>>> On 16.03.18 at 11:31, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 15 March 2018 13:40
>>
>> >>> On 12.02.18 at 11:47, wrote:
>> > --- a/xen/include/xen/iommu.h
>> > +++ b/xen/include/xen/iommu.h
>> > @@ -23,11 +23,15 @@
>> > #include
>> > #include
>> > #include
>> >
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 March 2018 10:29
> To: Paul Durrant
> Cc: Kevin Tian ; xen-devel@lists.xenproject.org
> Subject: RE: [PATCH 4/7] vtd: add lookup_page method to iommu_ops
>
> >>> On 16.03.18 at 11:19, wrote:
> >> From: Jan Beu
>>> On 16.03.18 at 11:37, wrote:
> I think we should do some performance testing to decide whether it makes
> sense to take the patch or not. After all I don't see a reason to punish
> AMD processors for INTEL's bugs. And I've already found out that some
> branches in interrupt handling can really
>>> On 15.03.18 at 21:30, wrote:
> This pulls in Linux' list_sort.c, which is a merge sort implementation
> for linked lists. Apart from adding a full featured license header and
> adjusting the #include file, nothing has been changed in this code.
Please mention the version of Linux this was tak
>>> On 15.03.18 at 21:30, wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -19,6 +19,7 @@ obj-y += keyhandler.o
> obj-$(CONFIG_KEXEC) += kexec.o
> obj-$(CONFIG_KEXEC) += kimage.o
> obj-y += lib.o
> +obj-y += list_sort.o
Why here rather than in patch 17? And why also for x86?
flight 120739 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 120441
Tests which did not
Hi, Daniel!
Sorry, if I strip the patch too much below.
On 03/16/2018 10:23 AM, Daniel Vetter wrote:
S-o-b line went missing here :-)
will restore it back ;)
I've read through it, 2 actual review comments (around hot-unplug and
around the error recovery for failed flips), a few bikesheds, bu
>>> On 15.03.18 at 18:51, wrote:
> Removes special purpose access to Credit1 vCPU
> migration delay parameter.
>
> This fixes a build breakage, occuring when Xen
> is configured with SCHED_CREDIT=n.
>
> Signed-off-by: Dario Faggioli
> Acked-by: Wei Liu
Acked-by: Jan Beulich
(for the parts it
Hi Andre,
On 15/03/18 20:30, Andre Przywara wrote:
gic_event_needs_delivery() is not named very intuitively, especially
the gic_ prefix is somewhat misleading.
Rename it to vgic_vcpu_pending_irq(), which makes it clear that this
relates to the virtual GIC and is about interrupts.
Also add a VCPU
>>> On 15.03.18 at 21:09, wrote:
> On 13/03/18 12:05, Roger Pau Monné wrote:
>> Maybe this could be:
>>
>> if ( is_idle_domain(d) )
>> ...
>> else
>> {
>> rc = is_hvm_domain(d) ? hvm_domain_initialise(d)
>> : pv_domain_initialise(d);
>> if ( rc )
>> goto f
Hi Andre,
On 15/03/18 20:30, Andre Przywara wrote:
If we change something in a vCPU that affects its runnability or
otherwise needs the vCPU's attention, we might need to tell the scheduler
about it.
We are using this in one place (vIRQ injection) at the moment, but will
need this at more places
>>> On 15.03.18 at 22:33, wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to shar
On Fri, Mar 16, 2018 at 01:36:53AM -0600, Jan Beulich wrote:
> >>> On 15.03.18 at 17:33, wrote:
> > On Thu, Mar 15, 2018 at 06:45:58AM -0600, Jan Beulich wrote:
> >> >>> On 15.03.18 at 13:01, wrote:
> >> > On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beulich wrote:
> >> >> >>> On 14.03.18 at 15:
Hi,
On 16/03/18 10:48, Jan Beulich wrote:
On 15.03.18 at 21:30, wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -19,6 +19,7 @@ obj-y += keyhandler.o
>> obj-$(CONFIG_KEXEC) += kexec.o
>> obj-$(CONFIG_KEXEC) += kimage.o
>> obj-y += lib.o
>> +obj-y += list_sort.o
>
>
On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> wo
Hi Stefano,
On 15/03/18 23:52, Stefano Stabellini wrote:
On Wed, 14 Mar 2018, Stefano Stabellini wrote:
After looking at the test results, which are good for arm, and
considering that master hasn't passed yet after 2 more days, I agree
with Julien: I think we should not release 4.9.2 and 4.7.5
>>> On 15.03.18 at 18:31, wrote:
> @@ -71,7 +72,7 @@ all: acpi subdirs-all
> acpi:
> $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
> DSDT_FILES="$(DSDT_FILES)"
>
> -rombios.o: roms.inc
> +rombios.o: $(ETHERBOOT_ROM) roms.inc
Please don't introduce dead dependencies: If a need for th
On 16/03/18 11:18, Jan Beulich wrote:
>
>> @@ -113,6 +114,11 @@ endif
>>
>> mv $@.new $@
>>
>> +ifneq ($(ETHERBOOT_ROMS),)
>> +$(ETHERBOOT_ROM): $(ETHERBOOT_ROMS)
>> +cat $^ > $@
>> +endif
> I don't understand this: How can the bare concatenation of multiple
> binary blobs produce anyt
>>> On 15.03.18 at 18:31, wrote:
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -33,6 +33,11 @@ struct bios_config {
> void (*create_mp_tables)(void);
> void (*create_smbios_tables)(void);
> void (*create_pir_tables)(void);
> +
> +/* Phy
>>> On 16.03.18 at 12:11, wrote:
> On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
>> @@ -48,6 +49,15 @@
>> * 32 ++
>> *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
>> * 40 ++
>> + *| memmap_paddr | Physical addr
>>> On 16.03.18 at 12:10, wrote:
> On 16/03/18 10:48, Jan Beulich wrote:
> On 15.03.18 at 21:30, wrote:
>>> --- a/xen/common/Makefile
>>> +++ b/xen/common/Makefile
>>> @@ -19,6 +19,7 @@ obj-y += keyhandler.o
>>> obj-$(CONFIG_KEXEC) += kexec.o
>>> obj-$(CONFIG_KEXEC) += kimage.o
>>> obj-y +
On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 12:11, wrote:
> > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
> >> @@ -48,6 +49,15 @@
> >> * 32 ++
> >> *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
>>> On 16.03.18 at 12:03, wrote:
> On Fri, Mar 16, 2018 at 01:36:53AM -0600, Jan Beulich wrote:
>> >>> On 15.03.18 at 17:33, wrote:
>> > On Thu, Mar 15, 2018 at 06:45:58AM -0600, Jan Beulich wrote:
>> >> >>> On 15.03.18 at 13:01, wrote:
>> >> > On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beuli
On 16/03/18 11:26, Jan Beulich wrote:
On 15.03.18 at 18:31, wrote:
>> --- a/tools/firmware/hvmloader/config.h
>> +++ b/tools/firmware/hvmloader/config.h
>> @@ -33,6 +33,11 @@ struct bios_config {
>> void (*create_mp_tables)(void);
>> void (*create_smbios_tables)(void);
>> void
This patch is a cosmetic re-structuring of some of the loops with look up
an ioreq server based on target domain and server id.
The restructuring is done separately here to ease review of a subsquent
patch.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm
This series tightens up permissions checking on ioreq server control plane
operations.
Paul Durrant (4):
x86/hvm: stop passing explicit domid to hvm_create_ioreq_server()
x86/hvm: take a reference on ioreq server emulating domain
x86/hvm: re-structure some of the ioreq server look-up loops
There are only two call-sites for this function:
- The 'default' call site, which sets the is_default argument to true
and passes the value of HVM_PARAM_DM_DOMAIN as domid.
- The 'dm op' call site, which sets the is_default argument to false
and passes current->domain->domain_id as domid.
Cle
There has always been an intention in the ioreq server API that only the
domain that creates an ioreq server should be able to manipulate it.
However, so far, nothing has enforced this. This means that two domains
with DM_PRIV over a target domain can currently manipulate each others
ioreq servers.
When an ioreq server is created the code currently stores the id
of the emulating domain, but does not take a reference on that domain.
This patch modifies the code to hold a reference for the lifetime of the
ioreq server.
NOTE: For the default server only it is theoritically possible for the
>>> On 16.03.18 at 12:37, wrote:
> On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote:
>> >>> On 16.03.18 at 12:11, wrote:
>> > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
>> >> @@ -48,6 +49,15 @@
>> >> * 32 ++
>> >> *| rsdp_paddr | Physical
This patch is ported to xen from linux commit
63000dd8006dc987db31ba670edc23142ea91e01
As we're about to access the Active Priority registers a lot more,
let's define accessors that take the register number as a parameter.
This patch only has accessors, another patch will have register trap handl
Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.
Signed-off-by: Manish Jaggi
diff --git a/docs/misc/arm/silicon-errata.txt b/d
Add MIDR values for Cavium ThunderX1 SoC family.
ThunderX1, 81XX, 83XX.
Signed-off-by: Manish Jaggi
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e1..62ad244785 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -4
On Fri, Mar 16, 2018 at 05:48:09AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 12:37, wrote:
> > On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote:
> >> >>> On 16.03.18 at 12:11, wrote:
> >> > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
> >> >> @@ -48,6 +49,15 @@
>
This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen
This patch is ported to xen from linux commit:
fbc48a0011deb3d51cb657ca9c0f9083f41c0665
Add a handler for reading/writing the guest's view of the
ICC_IGRPEN0_EL1 register, which is located in the ICH_VMCR_EL2.VENG0
field.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c
This patch is ported to xen from linux commit:
423de85a98c2b50715a0784a74f6124fbc0b1548
Add a handler for reading/writing the guest's view of the ICC_BPR0_EL1
register, which is located in the ICH_VMCR_EL2.BPR0 field.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xe
gicv3_ich_read/write_lr functions are duplicated in vgic-v3-sr.c
This is done to make the file independent of the xen vgic code for
handling the errata.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 1aaade40dc..93ac6f03a9 100644
This patch is ported to xen from linux commit
132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe.
Add a handler for reading the guest's view of the ICC_IAR1_EL1
register. This involves finding the highest priority Group-1
interrupt, checking against both PMR and the active group
priority, activating the int
This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359
Add a handler for reading/writing the guest's view of the
ICC_IGRPEN1_EL1
register, which is located in the ICH_VMCR_EL2.VENG1 field.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c
Since this is a SoC errata and trapping of certain group1 registers
should not affect the normal flow. A new file vgic-v3-sr.c is added.
Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync
if ARM64_WORKAROUND_CAVIUM_30115 capability is found.
A flag skip_hyp_tail is introduced
This patch is ported to xen from linux commit:
eab0b2dc4f6f34147e3d10da49ab8032e15dbea0
A number of Group-0 registers can be handled by the same accessors
as that of Group-1, so let's add the required system register encodings
and catch them in the dispatching function.
Signed-off-by: Manish Jagg
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
The current RFC patchset is a subset of [1], as it handleing only Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler function is
kept
independent of the usual guest
This patch is ported from linux to xen
commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e
(KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler)
Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available inter
This patch is a xen port of linux commit
f9e7449c780f688bf61a13dfa8c344afeb4ad6e0.
Add a handler for reading/writing the guest's view of the ICV_AP1Rn_EL1
registers. We just map them to the corresponding ICH_AP(0/1)Rn_EL2 registers.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/arm64/v
This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).
Signed-off-by : Manish Jaggi
dif
Enable trapping for Group0/1 register access when
CONFIG_CAVIUM_ERRATUM_30115 is enabled.
Signed-off-by: Manish Jaggi
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..6ffed6a634 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -43,6 +43,7 @@
#include
On 16/03/18 12:48, Jan Beulich wrote:
On 16.03.18 at 12:37, wrote:
>> On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote:
>> On 16.03.18 at 12:11, wrote:
On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
> @@ -48,6 +49,15 @@
> * 32 ++
>
>>> On 12.02.18 at 11:47, wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
> obj-y += hypercall.o
> obj-y += i387.o
> obj-y += i8259.o
> +obj-y += iommu_op.o
As mentioned in other contexts, I'd prefer if we stopped us
>>> On 16.03.18 at 13:05, wrote:
> I'd regard an address of zero and count > 0 as invalid.
Indeed.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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
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
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 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
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 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,
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
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
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
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
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
On 03/15/2018 03:45 PM, Boris Ostrovsky wrote:
> On 03/15/2018 10:22 AM, Joao Martins wrote:
>> All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
>> changing only the acpi_id. For processors which P-state coordination type
>> is HW_ALL (0xFD) it is OK to upload bogus P-state de
Gentle ping. The vGIC rework from Andre is based on that assumption.
Cheers,
On 08/03/18 15:24, julien.gr...@arm.com wrote:
From: Julien Grall
Xen is currently allowing to route/remove an interrupt from/to the
domain while it is running.
However, we never sync the virtual interrupt state to
>>> On 16.03.18 at 14:30, wrote:
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -47,6 +47,7 @@ void vpci_remove_device(struct pci_dev *pdev)
> xfree(r);
> }
> spin_unlock(&pdev->vpci->lock);
> +xfree(pdev->vpci->msi);
> xfree(pdev->vpci);
Okay, th
This series is in preparation for passing more parameters via
XEN_DOMCTL_createdomain.
Andrew Cooper (2):
tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state
tools/libxl: Don't prepare or save xc_config when soft resetting a domain
tools/libxl/libxl_create.c | 53 +++
xc_config is only used by xc_domain_create(), but by calling
libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
the default settings.
Move all data and calls relating to xc_domain_create() into the path which
calls it.
As far as I can tell, soft_reset has always been bro
The data it stores is initialised and exclusively used within
libxl__domain_make(), with the important details written back elsewhere by
libxl__arch_domain_save_config(). Prepare xc_config on libxl__domain_make()'s
stack, and drop the parameter.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
moved the STI past the PUSHF. While this isn't an active problem (as we
force EFLAGS.IF to 1 before exiting to guest context), let's not risk
internal confusion by finding a PV guest frame with interrupts
apparently off.
Signed-
flight 120838 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120838/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid xen-boot/l1
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://g
On 16/03/18 14:13, Jan Beulich wrote:
> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
> moved the STI past the PUSHF. While this isn't an active problem (as we
> force EFLAGS.IF to 1 before exiting to guest context), let's not risk
> internal confusion by finding a PV guest
On Tue, Mar 13, 2018 at 01:43:39PM -0500, Venu Busireddy wrote:
> This patch set is part of a set of patches that together allow containment
> of unrecoverable AER errors from PCIe devices assigned to guests in
> passthrough mode. The containment is achieved by forcibly removing the
> erring PCIe d
On Fri, Mar 16, 2018 at 08:04:55AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 14:30, wrote:
> > --- a/xen/drivers/vpci/vpci.c
> > +++ b/xen/drivers/vpci/vpci.c
> > @@ -47,6 +47,7 @@ void vpci_remove_device(struct pci_dev *pdev)
> > xfree(r);
> > }
> > spin_unlock(&pdev->vpci
On 2018-03-16 10:32:10 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 13, 2018 at 01:43:39PM -0500, Venu Busireddy wrote:
> > This patch set is part of a set of patches that together allow containment
> > of unrecoverable AER errors from PCIe devices assigned to guests in
> > passthrough mode. T
Hi,
I am new to Xen and trying to understand how does the VGA passthrough will work
on a ARM based hardware.
I have come across to a very limited information on this topic online.
I will be very grateful if someone can point to the right direction.
Kind Regards
Naveed
On Fri, 16 Mar 2018 10:32:10 -0400
Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 13, 2018 at 01:43:39PM -0500, Venu Busireddy wrote:
> > This patch set is part of a set of patches that together allow containment
> > of unrecoverable AER errors from PCIe devices assigned to guests in
> > passthrough
>>> On 16.03.18 at 15:29, wrote:
> On 16/03/18 14:13, Jan Beulich wrote:
>> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
>> moved the STI past the PUSHF. While this isn't an active problem (as we
>> force EFLAGS.IF to 1 before exiting to guest context), let's not risk
>> i
>>> On 16.03.18 at 15:34, wrote:
> On Fri, Mar 16, 2018 at 08:04:55AM -0600, Jan Beulich wrote:
>> >>> On 16.03.18 at 14:30, wrote:
>> > --- a/xen/drivers/vpci/vpci.c
>> > +++ b/xen/drivers/vpci/vpci.c
>> > @@ -47,6 +47,7 @@ void vpci_remove_device(struct pci_dev *pdev)
>> > xfree(r);
>>
Hi,
On 16/03/18 11:32, Jan Beulich wrote:
On 16.03.18 at 12:10, wrote:
>> On 16/03/18 10:48, Jan Beulich wrote:
>> On 15.03.18 at 21:30, wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -19,6 +19,7 @@ obj-y += keyhandler.o
obj-$(CONFIG_KEXEC) += kexec.o
flight 120748 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120748/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 119780
Tests which are
>>> On 16.03.18 at 16:13, wrote:
> Hi,
>
> On 16/03/18 11:32, Jan Beulich wrote:
> On 16.03.18 at 12:10, wrote:
>>> On 16/03/18 10:48, Jan Beulich wrote:
>>> On 15.03.18 at 21:30, wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -19,6 +19,7 @@ obj-y += key
On Fri, Mar 16, 2018 at 09:05:44AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 15:34, wrote:
> > vpci_remove_device is never called from the user-space test harness,
> > so it just needs to build, but not necessarily be correct in that
> > context.
> >
> > The test harness doesn't use vpci_add
On 16/03/18 15:04, Jan Beulich wrote:
On 16.03.18 at 15:29, wrote:
>> On 16/03/18 14:13, Jan Beulich wrote:
>>> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
>>> moved the STI past the PUSHF. While this isn't an active problem (as we
>>> force EFLAGS.IF to 1 before exi
Hi,
On 15/03/18 20:30, 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_pen
1 - 100 of 141 matches
Mail list logo
