From: Manish Jaggi
Structure of Hardware domain's (hwdom) IORT
hwdom's IORT will only have PCIRC nodes and ITS group nodes
in the following order. SMMU nodes as they are hidden from hardware
domain.
[IORT Header]
[ITS Group 1 ]
...
[ITS Group n ]
[PCIRC Node 1]
[PCIRC IDMAP entry 1]
...
[
From: Manish Jaggi
This patch aims to add the support of IORT in Xen. Below is the list
of major components which this patchset provides.
a. Add support for parsing the IORT
b. Provides API to populate/query requesterid - streamID mappings and
reuqesterid - deviceid mappings
c. The requesteri
From: Manish Jaggi
Provide definition for this macro.
Signed-off-by: Manish Jaggi
---
xen/include/xen/pci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index dd5ec43a70..ee1d4dbf93 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/
From: Manish Jaggi
Code to query estimated IORT size for hardware domain.
IORT for hardware domain is generated using the requesterid and
deviceid map. Xen code requires the size to be predeterminded.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/acpi/Makefile | 1 +
xen/arch/arm/acp
From: Manish Jaggi
asm-arm/pci.h has an incorrect #ifndef label.
Fixing it to ARM
Signed-off-by: Manish Jaggi
---
xen/include/asm-arm/pci.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index de13359f65..3145ed50
From: Manish Jaggi
Remove the parts of acpi_iort.h which are not required for Xen.
Signed-off-by: Manish Jaggi
---
xen/include/asm-arm/acpi/acpi_iort.h | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/xen/include/asm-arm/acpi/acpi_iort.h
b/xen/include/asm-arm/acp
From: Manish Jaggi
dev_is_pci for ARM was todo till now.
Provide definition for this macro.
Signed-off-by: Manish Jaggi
---
xen/include/asm-arm/device.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 7f2
From: Manish Jaggi
fwnode is firmware device node object handle type definition. This can
be used either for device tree node or ACPI table node.
However in the context of this patchset it is used mainly for ACPI
nodes.
iommu_fwspec defines set of opeations associated with fwnode.
This patch do
From: Manish Jaggi
Signed-off-by: Manish Jaggi
---
xen/arch/arm/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2782ee6589..d3fbcbcc6f 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -59,6 +59,10 @@ config SBSA_VU
From: Manish Jaggi
This patch adds code to parse the pci_rc, idmaps and smmu nodes to
- prepare idmaps (rid-sid rid-devid)
While resolving the ipmap from pcirc->smmu->its some fixup is required
this is done by fixup_rid_devid_map.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/acpi/iort.c | 207
From: Manish Jaggi
This patch copies the basic code from linux (iort.c) required to parse
IORT and
hooks for iommu configuration and initializes smmu device.
Provides a top level initcall acpi_iort_init which would call
parse_iort (next patch) to parse and prepare the rid-devid and rid-sid
maps.
From: Manish Jaggi
IORT has a hierarchical structure containing PCIRC nodes, IORT nodes
and SMMU nodes. Each node has with it an array of ids and a mapping
which maps a range of ids to another node's ids.
PCIRC(requesterid)->SMMU(streamid)->ITS(devid) or PCIRC->ITS
IORT is parsed multiple times
From: Manish Jaggi
to_pci_dev for ARM was todo till now.
Provide definition for this macro.
Signed-off-by: Manish Jaggi
---
xen/drivers/passthrough/arm/smmu.c | 3 ++-
xen/include/asm-arm/pci.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/passt
From: Manish Jaggi
Import acpi_iort.h verbatim from linux 4.14
Signed-off-by: Manish Jaggi
---
xen/include/asm-arm/acpi/acpi_iort.h | 57
1 file changed, 57 insertions(+)
diff --git a/xen/include/asm-arm/acpi/acpi_iort.h
b/xen/include/asm-arm/acpi/acpi_io
flight 120399 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 broken
test-amd64-i386-qemuu-rhel6hvm-inte
Am Tue, 6 Mar 2018 11:07:54 +
schrieb Andrew Cooper :
> > Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the
> > tolerance value of a running domU that is supposed to be migrated.
> Please can we not proliferate the domctls.
> This looks like it should be part of the set_tsc_in
> > diff --git a/docs/misc/xen-command-line.markdown
> > b/docs/misc/xen-command-line.markdown
> > index 781110d..95411cf 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1009,6 +1009,13 @@ debug hypervisor only).
> > ### idle\_latency\_fac
> On 9 Mar 2018, at 17:02, Ian Jackson wrote:
>
> Ian Jackson writes ("Re: osstest planned outage consultation"):
>> It turns out that another key member of staff is away then. We will
>> have to do this some time in late April. Some time the [week] of the
>> 16th-20th I think.
>
> Lars, can
Hi,
On 11/03/18 20:48, Stefano Stabellini wrote:
On Wed, 7 Mar 2018, Jan Beulich wrote:
On 06.03.18 at 20:24, wrote:
On Tue, 6 Mar 2018, Jan Beulich wrote:
these stable releases should go out before the end of the month.
Please point out backport candidates you find missing from the
respecti
On 12/03/18 10:24, Julien Grall wrote:
Hi,
On 11/03/18 20:48, Stefano Stabellini wrote:
On Wed, 7 Mar 2018, Jan Beulich wrote:
On 06.03.18 at 20:24, wrote:
On Tue, 6 Mar 2018, Jan Beulich wrote:
these stable releases should go out before the end of the month.
Please point out backport can
On 12/03/18 02:32, Peng Fan wrote:
On Fri, Mar 09, 2018 at 02:40:25PM +, Julien Grall wrote:
Hi,
On 09/03/18 13:30, Peng Fan wrote:
Hi Julien,
On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
Hi Peng,
On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +
flight 120409 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev broken in 120364
test-amd64-i386-rumprun-i38
Hi,
On 12/03/18 02:57, Peng Fan wrote:
Hi Stefano,
On Fri, Mar 09, 2018 at 05:09:20PM -0800, Stefano Stabellini wrote:
On Fri, 9 Mar 2018, Julien Grall wrote:
Furthermore, the workaround is not in Linux upstream and I doubt this will be
accepted as it is. So I am not convinced that we should m
branch xen-4.7-testing
xenbranch xen-4.7-testing
job test-amd64-i386-xl-qemut-ws16-amd64
testid windows-install
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: qem
Hi Andre,
On 09/03/18 15:11, Andre Przywara wrote:
The redistributor-stride property in a GICv3 DT node is only there to
cover broken platforms where this value deviates from the architected one.
Since we emulate the GICv3 distributor even for Dom0, we don't need to
copy the broken behaviour. Al
Hi Andre,
On 09/03/18 15:11, Andre Przywara wrote:
domain_max_vcpus(), which is used by generic Xen code, returns the
maximum number of VCPUs for a domain, which on ARM is mostly limited by
the VGIC model emulated (a (v)GICv2 can only handle 8 CPUs).
Our current implementation lives in arch/arm/
Hi,
On 09/03/18 15:11, Andre Przywara wrote:
gic_event_needs_delivery() is not named very intuitively, especially
the gic_ prefix is somewhat misleading.
Rename it to vgic_pending_irq(), which makes it clear that this relates > to
the virtual GIC and is about interrupts.
It looks like the com
The problem with the old patch is illustrated by the following section
from the old patch for tools/ocaml/xenstored/utils.ml
@@ -85,7 +85,7 @@ let create_unix_socket name =
let read_file_single_integer filename =
let fd = Unix.openfile filename [ Unix.O_RDONLY ] 0o640 in
let buf
Hi,
On 09/03/18 15:11, Andre Przywara wrote:
At the moment vgic_vcpu_inject_irq() is the interface for Xen internal
code and virtual devices to inject IRQs into a guest. This interface has
two shortcomings:
1) It requires a VCPU pointer, which we may not know (and don't need!)
for shared interru
Hi Andre,
On 09/03/18 15:11, 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
flight 120426 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120426/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7548947d040edfa915dbc05513b3eed074422daa
baseline version:
ovmf 7878f706e7eb8f29f6696
Hi,
I have committed all the patches except #8 and #14 as I had some
comments on them.
45 patches to go before finishing the vGIC :).
Thank you,
On 09/03/18 15:11, Andre Przywara wrote:
To get away from that scary xx/57 number in the new vGIC series, these
are the first few patches split of
On 03/11/2018 08:29 PM, Stefano Stabellini wrote:
> On Fri, 9 Mar 2018, George Dunlap wrote:
>> All this information is now covered in SUPPORT.md.
>>
>> Most of the emulated hardware is obvious a couple of the items are
>> worth pointing out specifically.
>>
>> "xen_disk" is listed under "Blkback"
flight 120451 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120451/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
From: Manish Jaggi
Since this is a SoC errata and trapping of certain group1 registers
should not affect the normal flow. A new file vsysreg_errata.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 ski
From: Manish Jaggi
Rename the menu text to Errata Workarounds. Subsequent patches will
add config options for SoC specific erratas.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconf
From: Manish Jaggi
gicv3_ich_read/write_lr functions are duplicated in vsysreg_errata.c
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/vsysreg_errata.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/xen/arch/arm/arm64/vsysreg_errata.c
b/xen/arch
From: Manish Jaggi
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
---
xen/arch/arm/arm64/vsysre
From: Manish Jaggi
Add MIDR values for Cavium ThunderX1 SoC's (88xx, 81xx, 83xx).
Signed-off-by: Manish Jaggi
---
xen/include/asm-arm/processor.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e1..649
From: Manish Jaggi
Enable trapping for Group1 register access when
CONFIG_CAVIUM_ERRATUM_30115 is enabled.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3.c | 16 ++--
xen/include/asm-arm/gic.h | 1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/xen/arch
From: Manish Jaggi
Some Cavium Thunder CPUs suffer a problem where a KVM 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
---
xen/arch/arm/Kconfig
From: Manish Jaggi
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
independe
From: Manish Jaggi
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
---
xen/arch/arm/arm64/v
From: Manish Jaggi
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.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/arm64/
From: Manish Jaggi
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
priorit
From: Manish Jaggi
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
From: Manish Jaggi
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
hi
> On 12 Mar 2018, at 11:12, Lars Kurth wrote:
>
>
>
>> On 9 Mar 2018, at 17:02, Ian Jackson wrote:
>>
>> Ian Jackson writes ("Re: osstest planned outage consultation"):
>>> It turns out that another key member of staff is away then. We will
>>> have to do this some time in late April. Som
Manish,
On 12/03/18 12:42, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi
>
> 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 th
>>> Andrew Cooper 03/09/18 6:06 PM >>>
>On 09/03/18 17:00, Jan Beulich wrote:
> On 09.03.18 at 14:18, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -426,8 +426,8 @@ static bool emulation_flags_ok(const struct domain *d,
>>> uint32_t emflags)
>>> return tr
>>> Juergen Gross 03/09/18 7:05 PM >>>
>On 09/03/18 16:29, Jan Beulich wrote:
> On 05.03.18 at 10:50, wrote:
>>> @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va,
>>> unsigned int flags)
>>> else
>>> {
>>> u32 t = pre_flush();
>>> -
On 12/03/18 13:59, Jan Beulich wrote:
Juergen Gross 03/09/18 7:05 PM >>>
>> On 09/03/18 16:29, Jan Beulich wrote:
>> On 05.03.18 at 10:50, wrote:
@@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va,
unsigned int flags)
else
{
>>> Juergen Gross 03/12/18 2:10 PM >>>
>BTW: are you already working on rebasing your XPTI speed up series to
>current staging? I'd like my series to use your series as a base unless
>you are telling me you won't be able to resend your series soon.
I hope to be able to get to this later this week
On 12/03/18 14:13, Jan Beulich wrote:
Juergen Gross 03/12/18 2:10 PM >>>
>> BTW: are you already working on rebasing your XPTI speed up series to
>> current staging? I'd like my series to use your series as a base unless
>> you are telling me you won't be able to resend your series soon.
>
>
Hi all,
The last posting date for Xen 4.11 is March 16th, 2018. If you want your
features to be included for the release, please make sure they are
posted for the first time before March 16th, 2018.
Juergen Gross
___
Xen-devel mailing list
Xen-devel@l
From: Julien Grall
A recent update to the ARM SMCCC_ARCH_WORKAROUND_1 specification (see [1])
allows firmware to return a non zero, positive value, to describe that
although the mitigation is implemented at the higher exception level,
the CPU on which the call is made is not affected.
Relax the
Hi,
Thanks for looking into.
> Would you mind creating a page on Xen wiki to explain how to boot Xen on
> that board? See [1].
Sure, I would do it and it was on my TODO list as well.
Thanks
Amit.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.
On Fri, Mar 9, 2018 at 3:24 PM, Chris Brannon wrote:
> I recently made a build of xen 4.10.0 and installed it.
> I have a pre-existing HVM guest that uses the following configuration:
> 1 hard drive using the phy disk backend. The guest also uses a device
> model stubdomain. After upgrading, it
Hi
Thanks for the comments.
> OOI, do you have any plan for adding earlyprintk support for that platform?
I didn't think about it but I would look into it.
> Please give a link to the Linux driver. This would help me for reviewing and
> also for future reference.
Ok.
> This is part of xen/dri
On 12/03/18 14:36, Amit Tomer wrote:
Hi
Hi Amit,
Thanks for the comments.
OOI, do you have any plan for adding earlyprintk support for that platform?
I didn't think about it but I would look into it.
This is quite useful to get output without any serial driver. I am quite
impressed
Hi all,
this is my first go at the agenda.
See
https://docs.google.com/document/d/1n7HAu5IbuRt5aJbQKt5X470kv2Ubvk5P2mG0vp6rKfU/edit?usp=sharing
and attached PDF
Text without tables below
As I didn't get a priority order, nor design stuff, but a few series to discuss
I sorted by what looked s
Patch ping. Jan, I would like to touch base once more to see if we can
get this patch included in 4.11. The patch as-is correctly tells the
difference between buffers provided by both an EFI shell or by the
firmware as an EFI_LOAD_OPTION.
Thanks,
Tamas
On Wed, Feb 7, 2018 at 9:00 AM, Tamas K Leng
From: Julien Grall
Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
assumed the read-write lock can be taken recursively. However, this
assumption is wrong and will lead to deadlock when the lock is
contended.
The read lock is taken recursively in the following case:
1) get
The usage of DEBUG_DIR breaks OVMF build. Rename it to XEN_DEBUG_DIR.
The default DEBUG_DIR=/usr/lib/debug can not be used for rpm builds
because that directory is "owned" by rpm-packaging itself to store the
autogenerated ${pkg}-debuginfo.rpm data. Thats why I set it to /boot.
This worked fine un
flight 120425 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120425/
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 Sat, Mar 10, 2018 at 11:08:21PM -0600, Doug Goldstein wrote:
> On 3/2/18 6:46 AM, Wei Liu wrote:
> > On Fri, Feb 23, 2018 at 11:26:17PM -0600, Doug Goldstein wrote:
> >> On 4/28/16 12:40 PM, Wei Liu wrote:
> >>> On Tue, Apr 26, 2016 at 09:38:45AM -0500, Doug Goldstein wrote:
> When building
On Sun, Mar 11, 2018 at 07:59:16PM +, Julien Grall wrote:
> Hi Andrew,
>
> On 03/09/2018 01:18 PM, Andrew Cooper wrote:
> > ARM guests are HVM and have hardware assisted paging. There are no PV
> > guests
> > or shadow paging, and all other creation flags are x86 specific.
> >
> > Signed-of
flight 120582 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120582/
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
Hi,
> This is quite useful to get output without any serial driver. I am quite
> impressed you managed to debug your serial driver without it :).
Actually, we have earlycon=xenboot(suggested by Andre) enabled in
Dom0 bootargs and it allowed us to
debug XEN boot further.
I am wondering if ealyco
George Dunlap writes:
> Can you attach the following?
>
> * the output of `xl dmesg`
> * the output of `dmesg`
> * the config file for the guest
Attached.
> I just tested stubdoms with staging-4.10 and everything works
> correctly *as long as dom0 is assigned all memory*. If I limit the
> amou
This patch series introduces support of Q35 emulation for Xen HVM guests
(via QEMU). This feature is present in other virtualization products and
Xen can greatly benefit from this feature as well.
The main goal for implementing Q35 emulation for Xen was extending PCI/GPU
passthrough capabilities.
Current Xen/QEMU method to control Xen Platform device is a bit odd --
changing 'xen_platform_device' option value actually modifies QEMU
emulated machine type, namely xenfv <--> pc.
In order to avoid multiplying machine types, use the new way to control
Xen Platform device for QEMU -- xen-platfor
Provide building for newly added dsdt_q35.asl file, in a way similar
to dsdt.asl.
Note that '15cpu' ACPI tables are only applicable to qemu-traditional
(which have no support for Q35), so we need to use 'anycpu' version only.
Signed-off-by: Alexey Gerasimenko
---
tools/firmware/hvmloader/Makefi
Allows to select Q35 DSDT table in hvmloader_acpi_build_tables(). Function
get_pc_machine_type() is used to select a proper table (i440/q35).
As we are bound to the qemu-xen device model for Q35, no need
to initialize config->dsdt_15cpu/config->dsdt_15cpu_len fields.
Signed-off-by: Alexey Gerasim
This adds construct_mcfg() function to libacpi which allows to build MCFG
table for a given mmconfig_addr/mmconfig_len pair if the ACPI_HAS_MCFG
flag was specified in acpi_config struct.
The maximum bus number is calculated from mmconfig_len using
MCFG_SIZE_TO_NUM_BUSES macro (1MByte of MMIO space
This patch does following:
1. Move PCI-device specific initialization out of pci_setup function
to the newly created class_specific_pci_device_setup function to simplify
code.
2. PCI-device specific initialization extended with LPC controller
initialization
3. Initialize PIRQA...{PIRQD, PIRQH} r
In order to turn on ACPI for OS, we need to write a chipset-specific value
to SMI_CMD register (sort of imitation of the APM->ACPI switch on real
systems). Modify acpi_enable_sci() function to support both i440 and Q35
emulation.
Signed-off-by: Alexey Gerasimenko
---
tools/firmware/hvmloader/hvm
This adds a new function get_pc_machine_type() which allows to determine
the emulated chipset type. Supported return values:
- MACHINE_TYPE_I440
- MACHINE_TYPE_Q35
- MACHINE_TYPE_UNKNOWN, results in the error message being printed
followed by calling BUG() in hvmloader.
Signed-off-by: Alexey Ge
This patch adds description for 'device_model_machine' option which allows
to control which chipset will be emulated by device model.
Signed-off-by: Alexey Gerasimenko
---
docs/man/xl.cfg.pod.5.in | 27 +++
1 file changed, 27 insertions(+)
diff --git a/docs/man/xl.cfg.po
Provide a new domain config option to select the emulated machine type,
device_model_machine. It has following possible values:
- "i440" - i440 emulation (default)
- "q35" - emulate a Q35 machine. By default, the storage interface is AHCI.
Note that omitting device_model_machine parameter means i4
Much like normal PCI BARs or other chipset-specific memory-mapped
resources, MMCONFIG area needs space in MMIO hole, so we must allocate
it manually.
The actual MMCONFIG size depends on a number of PCI buses available which
should be covered by ECAM. Possible options are 64MB, 128MB and 256MB.
As
xen_pt_config_init.c reads Device/Port Type and Capability version fields
in many places. Two functions are used for this purpose:
get_capability_version and get_device_type. These functions perform PCI
conf space reading every time they're called. Another bad thing is that
these functions know not
This patch adds the DSDT table for Q35 (new tools/libacpi/dsdt_q35.asl
file). There are not many differences with dsdt.asl (for i440) at the
moment, namely:
- BDF location of LPC Controller
- Minor changes related to FDC detection
- Addition of _OSC method to inform OSPM about PCIe features suppor
This patch allows to use ACPI PCI hotplug functionality for Xen on Q35.
All added code depends on xen_enabled(), so no functionality change for
non-Xen usage.
We need to call the acpi_set_pci_info function from ich9_pm_init as well,
so it was made globally visible again (as it was before).
Signed
The primary difference in PCI device IRQ management between Xen HVM and
QEMU is that Xen PCI IRQs are "device-centric" while QEMU PCI IRQs are
"chipset-centric". Namely, Xen uses PCI device BDF and INTx as coordinates
to assert IRQ while QEMU finds out to which chipset PIRQ the IRQ is routed
throug
This patch extends hvmloader_acpi_build_tables() with code which detects
if MMCONFIG is available -- i.e. initialized and enabled (+we're running
on Q35), obtains its base address and size and asks libacpi to build MCFG
table for it via setting the flag ACPI_HAS_MCFG in a manner similar
to other op
Even if we have some real PCIe device being passed through to a guest,
there are situations when we cannot use its PCIe features, primarily
allowing to access extended (>256) config space.
Basically, we can allow reading PCIe extended config space only if both
the device and emulated system are PC
This patch introduces 2 new functions,
- xen_host_pci_find_next_ext_cap (actually a reworked
xen_host_pci_find_ext_cap_offset function which is unused)
- xen_host_pci_find_next_cap
These functions allow to search for PCI/PCIe capabilities in a uniform
way. Both functions allow to search either a
There are two small issues in PCIEXBAR address mask handling:
- wrong bit positions for address mask bits (see PCIEXBAR description
in Q35 datasheet)
- incorrect usage of 64ADR_MASK
Due to this, attempting to write a valid PCIEXBAR address may cause it to
shift to another address, causing memory
Compared to legacy i440 system, there are certain difficulties while
passing through PCIe devices to guest OSes like Windows 7 and above
on platforms with native support of PCIe bus (in our case Q35). This
problem is not applicable to older OSes like Windows XP -- PCIe
passthrough on such OSes can
This patch provides basic facilities for PCIe Extended Capabilities and
support for controlled (via s->pcie_enabled_dev flag) access to PCIe
config space (>256).
PCIe Extended Capabilities make use of 16-bit capability ID. Also,
a capability size might exceed 8-bit width. So as the very first step
We need to hide some unwanted PCI/PCIe capabilities for passed through
devices.
Normally we do this by marking the capability register group
as XEN_PT_GRP_TYPE_HARDWIRED which exclude this capability from the
capability list and returns zeroes on attempts to read capability body.
Skipping the capab
This adds description structures for all fixed-size PCIe Extended
Capabilities.
For every capability register group, only 2 registers are emulated
currently: Capability ID (16 bit) and Next Capability Offset/Version (16
bit). Both needed to implement selective capability hiding. All other
register
Add few more PCIe Extended Capabilities entries to the
xen_pt_emu_reg_grps[] array along with their corresponding *_size_init()
functions.
All these capabilities have non-fixed size but their size calculation
is very simple, hence adding them in a single batch.
For every capability register group
The patch adds new xen_pt_ext_cap_ptr_reg_init function which is used
to initialize the emulated next pcie extended capability pointer.
Primary mission of this function is to have a method to selectively hide
some extended capabilities from the capability linked list, skipping them
by altering the
The patch provides Advanced Error Reporting PCIe Extended Capability
description structure and corresponding capability sizing function.
Signed-off-by: Alexey Gerasimenko
---
hw/xen/xen_pt_config_init.c | 72 +
1 file changed, 72 insertions(+)
diff --
On Q35 we still need to assign BSEL property to bus(es) for PCI device
add/hotplug to work.
Extend acpi_set_pci_info() function to support Q35 as well. Previously
it was limited to find_i440fx() call, this patch adds new (trivial)
function find_q35() which returns root PCIBus object on Q35, in a wa
The patch provides Vendor-specific PCIe Extended Capability description
structure and corresponding sizing function. In this particular case the
size of the Vendor capability is available in the VSEC Length field.
Signed-off-by: Alexey Gerasimenko
---
hw/xen/xen_pt_config_init.c | 77 +++
Virtual Channel/MFVC capabilities are relatively useless for emulation
(passing through accesses to them should be enough in most cases) yet they
have hardest format of all PCIe Extended Capabilities, mostly because
VC capability format allows the sparse config space layout with gaps
between the pa
Current Xen/QEMU method to control Xen Platform device on i440 is a bit
odd -- enabling/disabling Xen platform device actually modifies the QEMU
emulated machine type, namely xenfv <--> pc.
In order to avoid multiplying machine types, use a new way to control Xen
Platform device for QEMU -- "xen-p
1 - 100 of 132 matches
Mail list logo
