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>
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>
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
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>
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>
- Remove the 15cpus hack from ovmf because it should be unnecessary on
nowadays windows/EFI supported.
Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
...when specified in the guest configuration file.
This work is somewhat based on Bei Guan effort during the SoC 2011 and
relies on upstream edk2/ovmf Tianocore ROM to be built separately and
manually copied as:
Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ->
tools/firmware/ovmf/ovmf-x64.bin
Build/OvmfIa32/DEBUG_GCC44/FV/OVMF.fd ->
toolf/firmware/ovmf/ovmf-ia32.bin
A way to integrate OVMF build directly into XEN has still be discussed
on the mailing list appropriately.
Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Disable CONFIG_OVMF by default as ovmf is not integrated into the
build.
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
This patch introduces configuration options allowing to built either a
rombios only or a seabios only hvmloader.
Building option ROMs like vgabios or etherboot is only enabled for a
rombios hvmloader, since SeaBIOS takes care or extracting option ROMs
itself from the PCI devices (these option ROMs are provided by the
device model and do not need to be built in hvmloader).
The Makefile in tools/firmware/ now only checks for bcc if rombios is
enabled.
These two configuration options are left on by default to remain
compatible.
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Make load_rom field in struct bios_config an optionnal callback rather
than a boolean value. It allow BIOS specific code to implement it's
own option ROM loading methods.
Facilities to scan PCI devices, extract an deploy ROMs are moved into
a separate file that can be compiled optionnaly.
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
To remain consistent with how other ROMs are built into hvmloader,
call mkhex on etherboot ROMs from the hvmloader directory, instead of
the etherboot directory. In other words, eb-roms.h is not used any
more.
Introduce ETHERBOOT_NICS config option to choose which ROMs should be
built (kept rtl8139 and 8086100e per default as before).
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
32bitbios_support.c only contains code specific to rombios, and should
not be built-in when building hvmloader for SeaBIOS only (as for
rombios.c).
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Do not expose the ACPI power management "_PS0/3" Method to guest
firmware. According to section 3.4 of the APCI specification 4.0, PCI
device control the device power through its own specification but not
through APCI.
Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
PCI PM as a result of incorrect ACPI table shipped with the guest
BIOS, it may cause a failure of PCI device PM state transition(from
PCI_UNKNOWN to PCI_D0).
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>
Committed-by: Keir Fraser <keir@xen.org>
Unfortunately a HID of PNP0A06 will not work for an existing client
driver so this patch aims to choose something that's pretty certain
not to class with anything else.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
and populate it at boot time with a value read from
"platform/generation_id". Also add code to libxl to populate this
xenstore key with the value of a new 'generation_id' parameter in the
VM config file. Populate the ADDR package of VM_Gen_Counter ACPI
device such that the first integer evaluates to the low order 32 bits
of the buffer address and the second integer evaluates to the high
order 32 bits of the buffer address.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
evaluating to two integers, and with _CID and _DDN set to
"VM_Gen_Counter".
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.
This patch reserves 2 pages on the top of the memory in the
reserved area and mark this region as NVS in the e820. Then
we write the address to the config space (offset 0xfc) so the
device model can map the OpRegion at this address in the guest.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Change the way we relocate the memory page if they overlap with pci
hole. Use new map space (XENMAPSPACE_gmfn_range) to move the loop
into xen.
This code usually get triggered when a device is pass through to a
guest and the PCI hole has to be extended to have enough room to map
the device BARs. The PCI hole will starts lower and it might overlap
with some RAM that has been alocated for the guest. That usually
happen if the guest has more than 4G of RAM. We have to relocate
those pages in high mem otherwise they won't be accessible.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
S3 and S4 packages are moved into separate SSDTs and their inclusion
is controlled by the new configuration options.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Ian Campbell
Andrew Cooper
Fabio Fantoni
Jan Beulich
George Dunlap
Frediano Ziglio
David Vrabel
Keir Fraser
Ross Philipson
Xiantao Zhang
Paul Durrant
Attilio Rao
Julian Pidancet
Xudong Hao
Jean Guyader