This should help to reduce a CPU hotplug race window where a cpu hotplug
event while not be seen by the OS.
When hotplugging more than one vcpu, some of those vcpus might not be
seen as plugged by the guest.
This is what is currently happenning:
1. hw adds cpu, sets GPE.2 bit and sends SCI
2. OSPM gets SCI, reads GPE00.sts and masks GPE.2 bit in GPE00.en
3. OSPM executes _L02 (level-triggered event associate to cpu hotplug)
4. hw adds second cpu and sets GPE.2 bit but SCI is not asserted
since GPE00.en masks event
5. OSPM resets GPE.2 bit in GPE00.sts and umasks it in GPE00.en
as result event for step 4 is lost because step 5 clears it and OS
will not see added second cpu.
ACPI 50 spec: 5.6.4 General-Purpose Event Handling
defines GPE event handling as following:
1. Disables the interrupt source (GPEx_BLK EN bit).
2. If an edge event, clears the status bit.
3. Performs one of the following:
* Dispatches to an ACPI-aware device driver.
* Queues the matching control method for execution.
* Manages a wake event using device _PRW objects.
4. If a level event, clears the status bit.
5. Enables the interrupt source.
So, by using edge-triggered General-Purpose Event instead of a
level-triggered GPE, OSPM is less likely to clear the status bit of the
addition of the second CPU. On step 5, QEMU will resend an interrupt if
the status bit is set.
This description apply also for PCI hotplug since the same step are
followed by QEMU, so we also change the GPE event type for PCI hotplug.
This does not apply to qemu-xen-traditional because it does not resend
an interrupt if necessary as a result of step 5.
Patch and description inspired by SeaBIOS's commit:
Replace level gpe event with edge gpe event for hot-plug handlers
9c6635bd48d39a1d17d0a73df6e577ef6bd0037c
from Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
OVMF info contains E820 map allocated by hvmloader. This info is passed
to OVMF to help it do proper initialization.
Currently only E820 is necessary, but we reserve spaces for other tables
in ovmf_info for later usage.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Load OVMF from (100000000ULL - sizeof(ovmf)) to 0xFFFFFFFF, with proper
rounding down.
Tested with OVMF release build (1 MB) and debug build (2 MB), both
worked fine.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Debian Jessie at least contains an ovmf package that includes
/usr/share/ovmf/OVMF.fd. It's also possible that user may want to supply
his/her own ovmf binary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
for consistency with other foo-dir e.g. qemu, seabios.
Remove obsolete ovmf-find target.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
This allow building of XEN from source on a system without internet
access using either the environment or .config
Do the same with XEN_EXTFILES_URL, QEMU_REMOTE, IPXE_GIT_URL, and
IPXE_TARBALL_URL as QEMU_UPSTREAM_URL, SEABIOS_UPSTREAM_URL, etc.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Coverity complains about the use of strncpy() to completely fill the anchor
strings, resulting in an unterminated string.
Although the strncpy result is correct, the anchor strings are not strings in
the C sense, and use of memcpy is the prevaling style elsewhere in hvmloader
anyway.
While tidying up the style in this function, also remove some trailing
whitespace and gratuitous cast.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
If this option is given don't bother building seabios ourselves.
Likely to be handy for distros who have an existing seabios
package which they want to reuse.
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The SeaBIOS ROM image may validly exceed 128k in size, it's only our
interface code that so far assumed that it wouldn't. Remove that
restriction by setting the base address depending on image size.
Add a check to HVM loader so that too big images won't result in silent
guest failure anymore.
Uncomment the intended build-time size check for rombios, moving it
into a function so that it would actually compile.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Fixes regression indirectly introduced by c/s 4d23036e70
That changeset added some smbios tables which were option based on the
toolstack providing appropriate xenstore keys. The do_struct() macro would
unconditionally increment nr_structs, even if a table was not actually
written.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Default builds of Qemu have the Bochs debug port logging #ifdef'd out, so
remove all the completely wasted VMExits
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
The return value from await_ide() is always ignored, and most calls to
await_ide() immediately reread the status register.
Therefore, making await_ide() return the last value of the status register
removes a further two traps on the int 0x13 path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
So taking two traps when one will do is pointless. This removes 1 of 13
VMExits on the int 0x13 hotpath.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
After issuing a reset, the BSY bit is expected to be set. This is not the
case for Qemu.
In SeaBIOS.git: 580e33293244fee4556e56ecc67b8bd877f3c496
this check was even replaced with a udelay(5), as enough real hardware ignored
the BSY bit as well.
As rombios does not have an equivalent udelay(), replace the wait with a write
to port 0x80 which is whitelisted by Xen for 'a small delay'.
This causes 42k fewer IO traps to Qemu.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Repeated polling of the status register is not going to change its value, so
don't needlessly take 8192 traps to Qemu when 1 will do.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
At the moment, qemu-xen can't handle memory being relocated by
hvmloader. This may happen if a device with a large enough memory
region is passed through to the guest. At the moment, if this
happens, then at some point in the future qemu will crash and the
domain will hang. (qemu-traditional is fine.)
It's too late in the release to do a proper fix, so we try to do
damage control.
hvmloader already has mechanisms to relocate memory to 64-bit space if
it can't make a big enough MMIO hole. By default this is 2GiB; if we
just refuse to make the hole bigger if it will overlap with guest
memory, then the relocation will happen by default.
v5:
- Update comment to not refer to "this series".
v4:
- Wrap long line in libxl_dm.c
- Fix comment
v3:
- Fix polarity of comparison
- Move diagnostic messages to another patch
- Tested with xen platform pci device hacked to have different BAR sizes
{256MiB, 1GiB} x {qemu-xen, qemu-traditional} x various memory
configurations
- Add comment explaining why we default to "allow"
- Remove cast to bool
v2:
- style fixes
- fix and expand comment on the MMIO hole loop
- use "%d" rather than "%s" -> (...)?"1":"0"
- use bool instead of uint8_t
- Move 64-bit bar relocate detection to another patch
- Add more diagnostic messages
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@citrix.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Keir Fraser <keir@xen.org>
CC: Keir Fraser <keir@xen.org>
Allow devices with BARs less than 512MiB to be relocated to high
memory.
This will only be invoked if there is not enough low MMIO space to map
the device, and will be done preferentially to large devices first; so
in all likelihood only large devices will be remapped anyway.
This is needed to work-around the issue of qemu-xen not being able to
handle moving guest memory around to resize the MMIO hole. The
default MMIO hole size is less than 256MiB.
v3:
- Fixed minor style issue
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Keir Fraser <keir@xen.org>
Keep track of how much mmio space is left total, as well as the amount
of "low" MMIO space (<4GiB), and only load devices into high memory if
there is not enough low memory for the rest of the devices to fit.
Because devices are processed by size in order from large to small,
this should preferentially relocate devices with large BARs to 64-bit
space.
v3:
- Just use mmio_total rather than introducing a new variable.
- Port to using mem_resource directly rather than low_mmio_left
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@citrix.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Keir Fraser <keir@xen.org>
When deciding whether to map a device in low MMIO space (<4GiB),
hvmloader compares it with "mmio_left", which is set to the size of
the low MMIO range (pci_mem_end - pci_mem_start). However, even if it
does map a device in high MMIO space, it still removes the size of its
BAR from mmio_left.
In reality we don't need to do a separate accounting of the low memory
available -- this can be calculated from mem_resource. Just get rid
of the variable and the duplicate accounting entirely. This will make
the code more robust.
Note also that the calculation of whether to move a device to 64-bit
is fragile at the moment, depending on some unstated assumptions.
State those assumptions in a comment for future reference.
v5:
- Add comment documenting fragility of the move-to-highmem check
v3:
- Use mem_resource values directly instead of doing duplicate
accounting
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@citrix.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Keir Fraser <keir@xen.org>
After attempting to resize the MMIO hole, the check to determine
whether there is a need to relocate BARs into 64-bit space checks the
specific thing that caused the loop to exit (MMIO hole == 2GiB) rather
than checking whether the required MMIO will fit in the hole.
But even then it does it wrong: the polarity of the check is
backwards.
Check for the actual condition we care about (the sizeof the MMIO
hole) rather than checking for the loop exit condition.
v3:
- Move earlier in the series, before other functional changes
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@citrix.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Keir Fraser <keir@xen.org>
hvmloader will read hvm_info->high_mem_pgend to calculate where to
start the highmem PCI region. However, if the guest does not have any
memory in the high region, this is set to zero, which will cause
hvmloader to use the "0" for the base of the highmem region, rather
than 1 << 32.
Check to see whether hvm_info->high_mem_pgend is set; if so, do the
normal calculation; otherwise, use 1<<32.
v4:
- Handle case where hfm_info->high_mem_pgend is non-zero but doesn't
point into high memory, throwing a warning.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@citrix.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Keir Fraser <keir@xen.org>
With hvmloader telling the guest that it may skip REG_C reads during
the processing of RTC interrupts, the emulation code must not depend
upon these reads to occur. Introduce two modes of operation for the
emulation code, and short of a HVM parameter (too late to be
introduced for 4.3) hard code the mode determination to always assume
that Windows-conforming one for the time being.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Roger Pau Monné <roger.pau@citrix.com> (FreeBSD guest)
This device was removed due to change in specifications.
Original patch written by Paul Durrant
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
First draft specification document it as a 64bit counter, now are a 128bit
value handled as a couple of 64bit values.
Allow to disable the device is values are all zeroes.
Add documentation for platform/generation-id key.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
The emacs variable to set the C style from a local variable block is
c-file-style, not c-set-style.
Signed-off-by: David Vrabel <david.vrabel@citrix.com
Only lightly tested with a Linux HVM guest PXE boot.
Accept the defaults for the config options. Many of them are not
relevant to Xen but this matches what others (at least the Debian
SeaBIOS packages and the binary shipped by Qemu) are doing. The
Debian Xen packages are built against Debian's SeaBIOS package so
there is value in being similar.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
ACPI table passthrough support allowing additional static tables and
SSDTs (AML code) to be loaded. These additional tables are added at
the end of the secondary table list in the RSDT/XSDT tables.
Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Passthrough support for the SMBIOS structures including three new DMTF
defined types and support for OEM defined tables. Passed in SMBIOS
types override the default internal values. Default values can be
enabled for the new type 22 portable battery using a xenstore
flag. All other new DMTF defined and OEM structures will only be added
to the SMBIOS table if passthrough values are present.
Signed-off-by: Ross Philipson <ross.philipson@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Some OSes don't come with wget by default, so ftp should be choosen
on those. Add an autoconf check to check for wget and ftp, and
replace the usage of hardcoded wget in tools.
[ Stubdom builds still use wget unconditionally. -iwj ]
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Xen platform promises never to use this physical address region, and
will always mark it as reserved in the physical memory map presented
to the OS (preventing its use by generic OS services such as BAR
remapping).
Linux will use this region for mapping the shared-info page.
Signed-off-by: Keir Fraser <keir@xen.org>
Currently it is assumed PCI device BAR access < 4G memory. If there is
such a device whose BAR size is larger than 4G, it must access > 4G
memory address. This patch enable the 64bits big BAR support on
hvmloader.
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
These fields need to be valid at all times. Hypervisor ensures this
even across 32/64-bit guest transitions.
This fixes a bug where wallclock time is incorrect for booting 32-bit
HVM guests.
This should be backported to Xen 4.1 and 4.2.
Signed-off-by: Keir Fraser <keir@xen.org>
Tested-and-Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Microsoft have now published their VM generation ID specification at
https://www.microsoft.com/en-us/download/details.aspx?id=30707.
It differs from the original specification upon which I based my
implementation in several key areas. Particularly, it is no longer
an incrementing 64-bit counter and so this patch is to remove
the incr_generationid field from the build_info and also disable the
ACPI device before 4.2 is released.
I will follow up with further patches to implement the VM generation
ID to the new specification.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was
already in the environment during make invocation. If CFLAGS is in
environment then make will append all of the various flags specified in
xen Makefiles to this environment variable, which is then used in qemu
configure. Since qemu-xen is not ready for compiler flags like
"-std=gnu99" compilation will fail. If CFLAGS is not in environment,
then configure will use just its own "-O2 -g" because make does not
export its own CFLAGS variable.
>From a distro perspective, it is required to build libraries and
binaries with certain global cflags (arbitrary gcc options). Up to the
point when qemu-xen was imported it worked as expected by exporting
CFLAGS before 'make tools'. Now qemu-upstream reuses these CFLAGS, but
it cant deal with the result.
This patch extends the tools Makefiles so that three new environment
variables are recognized:
EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.
Special care needs to be taken in tools/firmware because the resulting
binaries are not linked with the hosts runtime libraries. These binaries
run in guest context. To avoid build errors from gcc options like
-fstack-protector, reuse existing practice to unset the new
EXTRA_CFLAGS_XEN_TOOLS for the firmware dirs.
The new feature can be used like this in a rpm xen.spec file:
export EXTRA_CFLAGS_XEN_TOOLS="${RPM_OPT_FLAGS}"
export EXTRA_CFLAGS_QEMU_TRADITIONAL="${RPM_OPT_FLAGS}"
export EXTRA_CFLAGS_QEMU_XEN="${RPM_OPT_FLAGS}"
./configure \
--libdir=%{_libdir} \
--prefix=/usr
make
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Roger Pau Monne
Anthony PERARD
Wei Liu
Andrew Cooper
Ian Campbell
Don Slutz
Fabio Fantoni
Jan Beulich
George Dunlap
fantonifabio@tiscali.it
Frediano Ziglio
David Vrabel
Keir Fraser
Ross Philipson
Xiantao Zhang
Paul Durrant
Olaf Hering