[PATCH v2 0/4] support booting more than 255 CPUs with QEMU
by Igor Mammedov
Changelog since:
v1:
* s/count_cpu/apic_id_init/
* merge handle_x2apic() into apic_id_init()
RFC:
* move out max-cpus check out of mptable_setup()
* factor out CPU counting/apic ID detection in separate function
* return back accidentially deleted debug message with APIC ID
* drop unused code in smp_setup()
According to SDM, if CPUs have APIC ID more than 254
firmware should pass control to OS in x2APIC mode.
This series adds x2APIC bootstrap initialization.
QEMU side of x2APIC support:
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01094.html
Igor Mammedov (3):
paravirt: disable legacy bios tables in case of more than 255 CPUs
support booting with more than 255 CPUs
cleanup smp_setup()
Kevin O'Connor (1):
smp: refactor present CPU APIC ID detection and counting
src/fw/paravirt.c | 6 ++++--
src/fw/smp.c | 57 ++++++++++++++++++++++++++++++++++++-------------------
src/x86.h | 1 +
3 files changed, 42 insertions(+), 22 deletions(-)
--
1.8.3.1
3 years
[PATCH]:splash: Skip the RGB555 mode
by Zheng Bao
Current JPEG decoding uses the RGB888 or RGB565. So we need to skip
RGB555 mode.
Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com>
---
src/bootsplash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bootsplash.c b/src/bootsplash.c
index c572685..d6990fc 100644
--- a/src/bootsplash.c
+++ b/src/bootsplash.c
@@ -81,7 +81,7 @@ find_videomode(struct vbe_info *vesa_info, struct vbe_mode_info *mode_info
continue;
u8 depth = mode_info->bits_per_pixel;
if (bpp_req == 0) {
- if (depth != 16 && depth != 24 && depth != 32)
+ if ((depth != 16 && depth != 24 && depth != 32) || mode_info->green_size == 5)
continue;
} else {
if (depth != bpp_req)
3 years, 1 month
KVM Forum 2016: Call For Participation
by Paolo Bonzini
=================================================================
KVM Forum 2016: Call For Participation
August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada
(All submissions must be received before midnight May 1, 2016)
=================================================================
KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead.
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2016.
At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.
KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.
This year, KVM Forum is joining LinuxCon and ContainerCon in Toronto,
Canada. Selected talks from KVM Forum will be presented on Wednesday
August 24 to the full audience of LinuxCon and ContainerCon. Also,
attendees of KVM Forum will have access to all of the LinuxCon and
ContainerCon talks on Wednesday.
http://events.linuxfoundation.org/cfp
Suggested topics:
KVM and Linux
* Scaling and optimizations
* Nested virtualization
* Linux kernel performance improvements
* Resource management (CPU, I/O, memory)
* Hardening and security
* VFIO: SR-IOV, GPU, platform device assignment
* Architecture ports
QEMU
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Scaling and optimizations
* Desktop virtualization and SPICE
* Virtual GPU
* virtio and vhost, including non-Linux or non-virtualized uses
* Hardening and security
* New storage features
* Live migration and fault tolerance
* High availability and continuous backup
* Real-time guest support
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, u-Boot, etc.
* Testing
Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: glusterfs, Ceph, etc.
* Software defined networking: Open vSwitch, OpenDaylight, etc.
* Network Function Virtualization
* Security
* Provisioning
* Performance tuning
===============
SUBMITTING YOUR PROPOSAL
===============
Abstracts due: May 1, 2016
Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk
Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"
You will receive a notification whether or not your presentation proposal
was accepted by May 27, 2016.
Speakers will receive a complimentary pass for the event. In the instance
that your submission has multiple presenters, only the primary speaker for a
proposal will receive a complementary event pass. For panel discussions, all
panelists will receive a complimentary event pass.
TECHNICAL TALKS
A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.
END-USER TALKS
One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.
If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.
HANDS-ON / BOF SESSIONS
We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.
These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at
http://www.linux-kvm.org/page/KVM_Forum_2016_BOF
Let people you think might be interested know about it, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.
PANEL DISCUSSIONS
If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your abstract. We will request full
biographies if a panel is accepted.
===============
HOTEL / TRAVEL
===============
This year's event will take place at the Westin Harbour Castle Toronto.
For information on discounted room rates for conference attendees
and on other hotels close to the conference, please visit
http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-travel.
As of March 15, 2016, non-US citizens need either a visa or an Electronic
Travel Authorization (eTA) in order to enter Canada. Detailed information
on the travel documentation required for your country of origin can
be found at http://www.cic.gc.ca/english/visit/visas.asp and
http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-travel.
** We urge you to start this process as quickly as possible to ensure
** receipt of appropriate travel documentation in time for your conference
** travel to Canada. For processing times for visa applications, please visit
** http://www.cic.gc.ca/english/information/times/.
===============
IMPORTANT DATES
===============
Notification: May 27, 2015
Schedule announced: June 3, 2015
Event dates: August 24-26, 2016
Thank you for your interest in KVM. We're looking forward to your
submissions and seeing you at the KVM Forum 2016 in August!
-your KVM Forum 2016 Program Committee
Please contact us with any questions or comments at
kvm-forum-2016-pc(a)redhat.com
3 years, 1 month
[PATCH v5] fw/pci: Add support for mapping Intel IGD via QEMU
by Alex Williamson
QEMU provides two fw_cfg files to support IGD. The first holds the
OpRegion data which holds the Video BIOS Table (VBT). This needs to
be copied into reserved memory and the address stored in the ASL
Storage register of the device at 0xFC offset in PCI config space.
The OpRegion is generally 8KB. This file is named "etc/igd-opregion".
The second file tells us the required size of the stolen memory space
for the device. This space requires 1MB alignment and is generally
either 1MB to 8MB depending on hardware config, but may be hundreds of
MB for user specified stolen memory. The base address of the reserved
memory allocated for this is written back to the Base Data of Stolen
Memory register (BDSM) at PCI config offset 0x5C on the device. This
file is named "etc/igd-bdsm-size".
QEMU documents these fw_cfg entries in docs/igd-assign.txt.
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
---
v6: fw_cfg BDSM entry now holds an 8-byte size integer as suggested
by Gerd. Also renamed to etc/igd-bdsm-size. Filter based on bdf
to only make use of this for the Intel VGA device at address
00:02.0, not that QEMU should attach this to anything else.
As always, comments appreciated. I expect this will be on hold
pending the QEMU support:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/152123
If there's a better way to sync these projects, please let me know.
Thanks,
Alex
src/fw/pciinit.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 35d9902..08221e6 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -287,6 +287,50 @@ static void ich9_smbus_setup(struct pci_device *dev, void *arg)
ich9_smbus_enable(dev->bdf);
}
+static void intel_igd_setup(struct pci_device *dev, void *arg)
+{
+ struct romfile_s *opregion = romfile_find("etc/igd-opregion");
+ u64 bdsm_size = le64_to_cpu(romfile_loadint("etc/igd-bdsm-size", 0));
+ void *addr;
+ u16 bdf = dev->bdf;
+
+ /* Apply OpRegion to any Intel VGA device, more than one is undefined */
+ if (opregion && opregion->size) {
+ addr = memalign_high(PAGE_SIZE, opregion->size);
+ if (!addr) {
+ warn_noalloc();
+ return;
+ }
+
+ if (opregion->copy(opregion, addr, opregion->size) < 0) {
+ free(addr);
+ return;
+ }
+
+ pci_config_writel(bdf, 0xFC, cpu_to_le32((u32)addr));
+
+ dprintf(1, "Intel IGD OpRegion enabled at 0x%08x, size %dKB, dev "
+ "%02x:%02x.%x\n", (u32)addr, opregion->size >> 10,
+ pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf));
+ }
+
+ /* Apply BDSM only to Intel VGA at 00:02.0 */
+ if (bdsm_size && (bdf == pci_to_bdf(0, 2, 0))) {
+ addr = memalign_tmphigh(1024 * 1024, bdsm_size);
+ if (!addr) {
+ warn_noalloc();
+ return;
+ }
+
+ e820_add((u32)addr, bdsm_size, E820_RESERVED);
+
+ pci_config_writel(bdf, 0x5C, cpu_to_le32((u32)addr));
+
+ dprintf(1, "Intel IGD BDSM enabled at 0x%08x, size %lldMB, dev "
+ "00:02.0\n", (u32)addr, bdsm_size >> 20);
+ }
+}
+
static const struct pci_device_id pci_device_tbl[] = {
/* PIIX3/PIIX4 PCI to ISA bridge */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0,
@@ -320,6 +364,10 @@ static const struct pci_device_id pci_device_tbl[] = {
PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0017, 0xff00, apple_macio_setup),
PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0022, 0xff00, apple_macio_setup),
+ /* Intel IGD OpRegion setup */
+ PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA,
+ intel_igd_setup),
+
PCI_DEVICE_END,
};
3 years, 1 month
[PATCH] keyboard: Inject serial port input as keypresses
by Kyösti Mälkki
Maps characters received from serial port as INT16h keypresses.
This enables making choice of boot media over serial port.
Source extracted from SageBIOS release for PC Engines apu1.
af6c8ab3b85d1a5a9fbeb41efa30a1ef pcengines.apu_139_osp.tar.gz
Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
---
src/Kconfig | 6 +++
src/clock.c | 4 ++
src/kbd.c | 2 +-
src/serial.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/util.h | 2 +
5 files changed, 168 insertions(+), 1 deletion(-)
diff --git a/src/Kconfig b/src/Kconfig
index e767be1..dedce08 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -411,6 +411,12 @@ menu "BIOS interfaces"
default y
help
Support int 16 keyboard calls.
+ config INT16_SERIAL_KEYBOARD
+ bool "Keyboard on serial port"
+ depends on SERIAL && KEYBOARD
+ default n
+ help
+ Translate serial port input to keyboard scancodes.
config KBD_CALL_INT15_4F
depends on KEYBOARD
bool "Keyboard hook interface"
diff --git a/src/clock.c b/src/clock.c
index e83e0f3..b69a139 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -295,6 +295,10 @@ clock_update(void)
floppy_tick();
usb_check_event();
ps2_check_event();
+
+#if CONFIG_INT16_SERIAL_KEYBOARD
+ uart_check_keystrokes();
+#endif
}
// INT 08h System Timer ISR Entry Point
diff --git a/src/kbd.c b/src/kbd.c
index 61d9df0..48c7d06 100644
--- a/src/kbd.c
+++ b/src/kbd.c
@@ -51,7 +51,7 @@ kbd_init(void)
, x + FIELD_SIZEOF(struct bios_data_area_s, kbd_buf));
}
-static u8
+u8
enqueue_key(u16 keycode)
{
u16 buffer_start = GET_BDA(kbd_buf_start_offset);
diff --git a/src/serial.c b/src/serial.c
index 88349c8..8c93411 100644
--- a/src/serial.c
+++ b/src/serial.c
@@ -315,3 +315,158 @@ handle_17(struct bregs *regs)
default: handle_17XX(regs); break;
}
}
+
+#if CONFIG_INT16_SERIAL_KEYBOARD
+static u8 UartToScanCode[] VAR16 = {
+// x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xa xb xc xd xe xf
+// =====================================================================================================
+ 0x0f, 0x1e, 0x30, 0x2e, 0x20, 0x12, 0x21, 0x22, 0x23, 0x17, 0x24, 0x25, 0x26, 0x32, 0x31, 0x18, // 0x
+ 0x19, 0x10, 0x13, 0x1f, 0x14, 0x16, 0x2f, 0x11, 0x2d, 0x15, 0x2c, 0x01, 0x00, 0x00, 0x00, 0x00, // 1x
+ 0x39, 0x02, 0x28, 0x04, 0x05, 0x06, 0x08, 0x28, 0x0a, 0x0b, 0x09, 0x0d, 0x33, 0x0c, 0x34, 0x35, // 2x
+ 0x00, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x27, 0x27, 0x33, 0x0d, 0x34, 0x35, // 3x
+ 0x03, 0x1e, 0x30, 0x2e, 0x20, 0x12, 0x21, 0x22, 0x23, 0x17, 0x24, 0x25, 0x26, 0x32, 0x31, 0x18, // 4x
+ 0x19, 0x10, 0x13, 0x1f, 0x14, 0x16, 0x2f, 0x11, 0x2d, 0x15, 0x2c, 0x1a, 0x2b, 0x1b, 0x07, 0x0c, // 5x
+ 0x29, 0x1e, 0x30, 0x2e, 0x20, 0x12, 0x21, 0x22, 0x23, 0x17, 0x24, 0x25, 0x26, 0x32, 0x31, 0x18, // 6x
+ 0x19, 0x10, 0x13, 0x1f, 0x14, 0x16, 0x2f, 0x11, 0x2d, 0x15, 0x2c, 0x1a, 0x2b, 0x1b, 0x29, 0x00, // 7x
+};
+
+static u8
+inject_key(u8 scan_code, u8 ascii_code)
+{
+ return enqueue_key((u16) scan_code << 8 | ascii_code);
+}
+
+void
+uart_check_keystrokes(void)
+{
+ u8 rx_buf[5], rx_bytes = 0, ascii_code = 0, scan_code = 0;
+
+ // check to see if there is a active serial port
+ if (inb(CONFIG_DEBUG_SERIAL_PORT + SEROFF_LSR) == 0xFF)
+ return;
+
+ while (inb(CONFIG_DEBUG_SERIAL_PORT + SEROFF_LSR) & 0x01) {
+ if (rx_bytes > sizeof(rx_buf)) {
+ dprintf(1, "uart_check_keystrokes: error too many bytes are available\n");
+ while (inb(CONFIG_DEBUG_SERIAL_PORT + SEROFF_LSR) & 0x01)
+ inb(CONFIG_DEBUG_SERIAL_PORT + SEROFF_DATA);
+ return;
+ }
+ else
+ rx_buf[rx_bytes++] = inb(CONFIG_DEBUG_SERIAL_PORT + SEROFF_DATA);
+ }
+
+ if (!rx_bytes)
+ return;
+
+ if (rx_bytes == 1) {
+ ascii_code = rx_buf[0];
+ if (ascii_code >= ARRAY_SIZE(UartToScanCode)) {
+ dprintf(3, "uart_check_keystrokes: error UartToScanCode out of bounds index\n");
+ return;
+ }
+ scan_code = GET_GLOBAL(UartToScanCode[ascii_code]);
+ inject_key(scan_code, ascii_code);
+ }
+ else if (rx_bytes == 2) { // assume it's actually 2 single-byte keystrokes
+ ascii_code = rx_buf[0];
+ if (ascii_code >= ARRAY_SIZE(UartToScanCode)) {
+ dprintf(3, "uart_check_keystrokes: error in 1/2 byte UartToScanCode out of bounds index\n");
+ return;
+ }
+ scan_code = GET_GLOBAL(UartToScanCode[ascii_code]);
+ inject_key(scan_code, ascii_code);
+
+ ascii_code = rx_buf[1];
+ if (ascii_code >= ARRAY_SIZE(UartToScanCode)) {
+ dprintf(3, "uart_check_keystrokes: error in 2/2 UartToScanCode out of bounds index\n");
+ return;
+ }
+ scan_code = GET_GLOBAL(UartToScanCode[ascii_code]);
+ inject_key(scan_code, ascii_code);
+ }
+ else if (rx_bytes == 3) {
+ if ((rx_buf[0] == 0x1b) && (rx_buf[1] == 0x4f)) { // F1-F12
+ ascii_code = 0;
+ if ((rx_buf[2] >= 0x50) && (rx_buf[2] <= 0x59))
+ scan_code = (rx_buf[2] - 0x50) +0x3b;
+ else if ((rx_buf[2] >= 0x5a) && (rx_buf[2] <= 0x5b))
+ scan_code = (rx_buf[2] - 0x5a) + 0x85;
+ else {
+ dprintf(3, "uart_check_keystrokes: error in Fkey handling %x\n",rx_buf[2]);
+ return;
+ }
+ }
+ else if ((rx_buf[0] == 0x1b) && (rx_buf[1] == 0x5b)) { // cursor keys
+ ascii_code = 0xe0;
+ if (rx_buf[2] == 0x41) scan_code = 0x48; // UP
+ else if (rx_buf[2] == 0x42) scan_code = 0x50; // DOWN
+ else if (rx_buf[2] == 0x43) scan_code = 0x4d; // LEFT
+ else if (rx_buf[2] == 0x44) scan_code = 0x4b; // RIGHT
+ else {
+ dprintf(3, "uart_check_keystrokes: error in cursor handling %x\n",rx_buf[2]);
+ return;
+ }
+ }
+ else {
+ dprintf(3, "uart_check_keystrokes: error in 3 byte key sequence\n");
+ return;
+ }
+ inject_key(scan_code, ascii_code);
+ }
+ else if (rx_bytes == 4) {
+ if ((rx_buf[0] == 0x1b) && (rx_buf[1] == 0x5b) && (rx_buf[2] == 0x33) && (rx_buf[3] == 0x7e)) { // DEL
+ ascii_code = 0xe0;
+ scan_code = 0x53;
+ inject_key(scan_code, ascii_code);
+ }
+ else {
+ dprintf(3, "uart_check_keystrokes: unhandled 4 byte keystroke ");
+ dprintf(3, "%x %x %x %x\n",rx_buf[0],rx_buf[1],rx_buf[2],rx_buf[3]);
+ return;
+ }
+ }
+ /* these 5 byte scan codes are used by some terminal emulators */
+ else if (rx_bytes == 5) {
+ if ((rx_buf[0] == 0x1b) && (rx_buf[1] == 0x5b) && (rx_buf[2] == 0x32) && (rx_buf[4] == 0x7e)) { // F9-F12
+ ascii_code = 0x00;
+ if (rx_buf[3] == 0x30) scan_code = 0x43; // F9
+ else if (rx_buf[3] == 0x31) scan_code = 0x44; // F10
+ else if (rx_buf[3] == 0x33) scan_code = 0x85; // F11
+ else if (rx_buf[3] == 0x34) scan_code = 0x86; // F12
+ else {
+ dprintf(3, "uart_check_keystrokes: unhandled 5 byte keystroke F9-F12 ");
+ dprintf(3, "%x %x %x %x %x\n",rx_buf[0],rx_buf[1],rx_buf[2],rx_buf[3],rx_buf[4]);
+ return;
+ }
+ }
+ else if ((rx_buf[0] == 0x1b) && (rx_buf[1] == 0x5b) && (rx_buf[2] == 0x31) && (rx_buf[4] == 0x7e)) { // F1-F8
+ ascii_code = 0x00;
+ if (rx_buf[3] == 0x31) scan_code = 0x3B; // F1
+ else if (rx_buf[3] == 0x32) scan_code = 0x3C; // F2
+ else if (rx_buf[3] == 0x33) scan_code = 0x3D; // F3
+ else if (rx_buf[3] == 0x34) scan_code = 0x3E; // F4
+ else if (rx_buf[3] == 0x35) scan_code = 0x3F; // F5
+ else if (rx_buf[3] == 0x37) scan_code = 0x40; // F6
+ else if (rx_buf[3] == 0x38) scan_code = 0x41; // F7
+ else if (rx_buf[3] == 0x39) scan_code = 0x42; // F8
+ else {
+ dprintf(3, "uart_check_keystrokes: unhandled 5 byte keystroke F1-F8 ");
+ dprintf(3, "%x %x %x %x %x\n",rx_buf[0],rx_buf[1],rx_buf[2],rx_buf[3],rx_buf[4]);
+ return;
+ }
+ }
+ else {
+ dprintf(3, "uart_check_keystrokes: unhandled 5 byte keystroke ");
+ dprintf(3, "%x %x %x %x %x\n",rx_buf[0],rx_buf[1],rx_buf[2],rx_buf[3],rx_buf[4]);
+ return;
+ }
+ inject_key(scan_code, ascii_code);
+ }
+ else {
+ dprintf(3, "uart_check_keystrokes: unhandled rx_bytes = %x\n",rx_bytes);
+ dprintf(3, "%x %x %x %x %x\n",rx_buf[0],rx_buf[1],rx_buf[2],rx_buf[3],rx_buf[4]);
+ return;
+ }
+}
+#endif /* CONFIG_INT16_SERIAL_KEYBOARD */
diff --git a/src/util.h b/src/util.h
index 7b41207..9be308a 100644
--- a/src/util.h
+++ b/src/util.h
@@ -184,6 +184,7 @@ int jpeg_show(struct jpeg_decdata *jpeg, unsigned char *pic, int width
void kbd_init(void);
void handle_15c2(struct bregs *regs);
void process_key(u8 key);
+u8 enqueue_key(u16 keycode);
// misc.c
extern int HaveRunPost;
@@ -230,6 +231,7 @@ void code_mutable_preinit(void);
// serial.c
void serial_setup(void);
void lpt_setup(void);
+void uart_check_keystrokes(void);
// vgahooks.c
void handle_155f(struct bregs *regs);
--
1.9.1
3 years, 1 month
[PATCH] splash: Skip the RGB555 mode
by Zheng Bao
Current JPEG decoding uses the RGB666 or RGB565. So we need to skip
RGB555 mode.
Signed-off-by: Zheng Bao <fishbaozi(a)gmail.com>
---
src/bootsplash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bootsplash.c b/src/bootsplash.c
index c572685..d6990fc 100644
--- a/src/bootsplash.c
+++ b/src/bootsplash.c
@@ -81,7 +81,7 @@ find_videomode(struct vbe_info *vesa_info, struct vbe_mode_info *mode_info
continue;
u8 depth = mode_info->bits_per_pixel;
if (bpp_req == 0) {
- if (depth != 16 && depth != 24 && depth != 32)
+ if ((depth != 16 && depth != 24 && depth != 32) || mode_info->green_size == 5)
continue;
} else {
if (depth != bpp_req)
3 years, 1 month
[PATCH 1/2] scripts/acpi_*: use env python instead of python in shebang
by Alexander Couzens
python should be called via env to support virtualenvs
Signed-off-by: Alexander Couzens <lynxis(a)fe80.eu>
---
scripts/acpi_extract.py | 2 +-
scripts/acpi_extract_preprocess.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py
index 3ed863b..baa6bec 100755
--- a/scripts/acpi_extract.py
+++ b/scripts/acpi_extract.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
# Copyright (C) 2011 Red Hat, Inc., Michael S. Tsirkin <mst(a)redhat.com>
#
# This file may be distributed under the terms of the GNU GPLv3 license.
diff --git a/scripts/acpi_extract_preprocess.py b/scripts/acpi_extract_preprocess.py
index 2698118..31913bd 100755
--- a/scripts/acpi_extract_preprocess.py
+++ b/scripts/acpi_extract_preprocess.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
# Copyright (C) 2011 Red Hat, Inc., Michael S. Tsirkin <mst(a)redhat.com>
#
# This file may be distributed under the terms of the GNU GPLv3 license.
--
2.8.2
3 years, 1 month
qemu-kvm: SeaBIOS 1.9.0 and above cannot boot Windows 10 from harddisk
by Johannes Krottmayer
Hello,
I have following problem...
Host OS: openSUSE 13.1 x86_64
Guest OS: Windows 10 Pro 64-Bit (build 10240 and 10586)
$ qemu-system-x86_64 --version
QEMU emulator version 2.5.93 (Virtualization / openSUSE_13.1), Copyright
(c) 2003-2008 Fabrice Bellard
QEMU output with SeaBIOS 1.9.0 and above:
$ qemu-system-x86_64 -bios ../qemu/seabios-1.9.2/out/bios.bin -machine
pc,accel=kvm -cpu core2duo -m 2048 -smp 2 -hda win10.img -boot c
KVM internal error. Suberror: 1
emulation failure
EAX=00000200 EBX=0000aa55 ECX=00000007 EDX=00000080
ESI=00007be4 EDI=00000800 EBP=000007be ESP=00007bfc
EIP=000000a4 EFL=00003206 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 ffffffff 00809300
CS =07c0 00007c00 ffffffff 00809b00
SS =0000 00000000 ffffffff 00809300
DS =0000 00000000 ffffffff 00809300
FS =0000 00000000 ffffffff 00809300
GS =0000 00000000 ffffffff 00809300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 00000000
IDT= 00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=18 68 1a 00 b4 48 8a 16 0e 00 8b f4 16 1f cd 13 9f 83 c4 18 <9e> 58
1f 72 e1 3b 06 0b 00 75 db a3 0f 00 c1 2e 0f 00 04 1e 5a 33 db b9 00 20
2b c8 66 ff
Thanks,
Johannes
3 years, 1 month
[PATCH] tcgbios: Remove unused const variable
by Paul Menzel
Date: Fri, 13 May 2016 07:10:32 +0200
Subject: [PATCH 2/2] tcgbios: Remove unused const variable
Remove the unused array `PhysicalPresence_CMD_DISABLE` to fix the GCC 6
warnings below.
```
$ gcc-6 --version
gcc-6 (Debian 6.1.1-3) 6.1.1 20160511
[…]
$ make -j CC=gcc-6
[…]
Compile checking out/src/tcgbios.o
[…]
src/tcgbios.c:36:17: warning: 'PhysicalPresence_CMD_DISABLE' defined but not used [-Wunused-const-variable=]
static const u8 PhysicalPresence_CMD_DISABLE[] = { 0x01, 0x00 };
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
---
src/tcgbios.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/tcgbios.c b/src/tcgbios.c
index ddf4f79..334d99b 100644
--- a/src/tcgbios.c
+++ b/src/tcgbios.c
@@ -33,7 +33,6 @@ static const u8 Startup_ST_CLEAR[] = { 0x00, TPM_ST_CLEAR };
static const u8 Startup_ST_STATE[] = { 0x00, TPM_ST_STATE };
static const u8 PhysicalPresence_CMD_ENABLE[] = { 0x00, 0x20 };
-static const u8 PhysicalPresence_CMD_DISABLE[] = { 0x01, 0x00 };
static const u8 PhysicalPresence_PRESENT[] = { 0x00, 0x08 };
static const u8 PhysicalPresence_NOT_PRESENT_LOCK[] = { 0x00, 0x14 };
--
2.8.1
3 years, 2 months
RFC: Proposed vfio IGD assignment fw_cfg ABI
by Alex Williamson
Hey folks,
I'm planning to add a couple fw_cfg files for vfio IGD (Intel
Graphics Device) assignment, but since this does represent a QEMU-BIOS
ABI and since most of the vfio code is committed with only my own
sign-off and review, I'd like to pull this out for discussion separate
from the patches themselves.
#1: "etc/igd-opregion"
the IGD OpRegion is an area of memory which contains among other
things, the Video BIOS Table which is integral in allowing an assigned
IGD to configure and make use of the physical display outputs of the
system. "etc/igd-opregion" is an opaque fw_cfg file which the BIOS
will use to allocate an appropriately sized reserved memory region,
copy the contents of the fw_cfg file into the allocated memory region,
and write the base address of the allocated memory region to the dword
registers at 0xFC in PCI config space on the IGD device itself. The
BIOS will look for this fw_cfg file any time a PCI class VGA device is
found with Intel vendor ID. Multiple IGD devices per VM, such as might
potentially be possible with Intel vGPU, is not within the scope of
this proposal. The expected size of this fw_cfg file is on the order
of a few pages, 8KB is typical.
#2: "etc/igd-bdsm"
The BDSM is the register on IGD storing the base address of stolen
memory (Base Data of Stolen Memory). This is simply an area of
reserved RAM which the IGD uses for both GTT and stolen video memory.
The semantics are much the same as for "etc/igd-opregion" with the
exception that the fw_cfg file is only used to request a reserved
memory allocation for this purpose and to indicate the size of the
reserved memory. There is no content to this fw_cfg file and it should
not be read or written. As above, the BIOS should look for this file
upon discovering a PCI class VGA device with Intel vendor ID, allocate
the necessary size and write the address to the IGD device. The BDSM
register is a dword register located at 0x5C in PCI config space of the
IGD device. This proposal does not intend to address the vague
possibility of multiple BDSM per VM. The expected size of this fw_cfg
file is from 1MB to multiple hundreds of MB with user specified stolen
video memory. 8MB would be the typical maximum as QEMU currently does
not allocate stolen video memory itself.
I'd appreciate any comments on these entries and I'd be happy to
describe them further. Perhaps we should create a docs/api/
directory with these sorts of descriptions where we define how a
given API is intended to work. Thanks,
Alex
3 years, 2 months
