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
2 years, 7 months
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
2 years, 8 months
[RFC PATCH v4] 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 is a dummy file, it has no backing so we only
allocate the space without copying anything into it. This space
requires 1MB alignment and is generally either 1MB or 2MB, depending
on the hardware config. If the user has opted in QEMU to expose
additional stolen memory beyond the GTT (GGMS), the GMS may add an
additional 32MB to 512MB. 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".
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
---
v4: Back to a single patch thanks to Kevin's suggestion to use
memalign_tmphigh() for larger allocations. Now creating
reserved space for stolen memory and writing the value to
the BDSM register is queued off the existence of a fw_cfg
file, just like the OpRegion. The only difference is that
we don't copy the contents, just use the meta data.
src/fw/pciinit.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 0ed5dfb..dc2e433 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -269,6 +269,49 @@ static void ich9_smbus_setup(struct pci_device *dev, void *arg)
pci_config_writeb(bdf, ICH9_SMB_HOSTC, ICH9_SMB_HOSTC_HST_EN);
}
+static void intel_igd_setup(struct pci_device *dev, void *arg)
+{
+ struct romfile_s *opregion = romfile_find("etc/igd-opregion");
+ struct romfile_s *bdsm = romfile_find("etc/igd-bdsm");
+ void *addr;
+ u16 bdf = dev->bdf;
+
+ 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));
+ }
+
+ if (bdsm && bdsm->size) {
+ 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 %dMB, dev "
+ "%02x:%02x.%x\n", (u32)addr, bdsm->size >> 20,
+ pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf));
+ }
+}
+
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,
@@ -302,6 +345,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,
};
2 years, 8 months
Tagging 1.9.2?
by Roger Pau Monné
Hello,
The Xen project is about to release a newer version of Xen (4.7), and we
would like to have commit 3910de in our tree (SeaBIOS version bundled with
Xen is currently 1.9.1). Is there any chance 1.9.2 could be tagged from the
current stable-1.9 branch, or should we cherry-pick the change?
Thanks, Roger.
2 years, 9 months
[PATCH 1/2] virtio: Use threads when scanning for virtio devices
by Kevin O'Connor
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/hw/virtio-blk.c | 6 ++++--
src/hw/virtio-scsi.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c
index 2dfd0c3..dca7855 100644
--- a/src/hw/virtio-blk.c
+++ b/src/hw/virtio-blk.c
@@ -15,6 +15,7 @@
#include "pcidevice.h" // foreachpci
#include "pci_ids.h" // PCI_DEVICE_ID_VIRTIO_BLK
#include "pci_regs.h" // PCI_VENDOR_ID
+#include "stacks.h" // run_thread
#include "std/disk.h" // DISK_RET_SUCCESS
#include "string.h" // memset
#include "util.h" // usleep
@@ -93,8 +94,9 @@ virtio_blk_process_op(struct disk_op_s *op)
}
static void
-init_virtio_blk(struct pci_device *pci)
+init_virtio_blk(void *data)
{
+ struct pci_device *pci = data;
u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER;
dprintf(1, "found virtio-blk at %pP\n", pci);
struct virtiodrive_s *vdrive = malloc_fseg(sizeof(*vdrive));
@@ -203,6 +205,6 @@ virtio_blk_setup(void)
(pci->device != PCI_DEVICE_ID_VIRTIO_BLK_09 &&
pci->device != PCI_DEVICE_ID_VIRTIO_BLK_10))
continue;
- init_virtio_blk(pci);
+ run_thread(init_virtio_blk, pci);
}
}
diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c
index 322d469..5fb9409 100644
--- a/src/hw/virtio-scsi.c
+++ b/src/hw/virtio-scsi.c
@@ -16,6 +16,7 @@
#include "pcidevice.h" // foreachpci
#include "pci_ids.h" // PCI_DEVICE_ID_VIRTIO_BLK
#include "pci_regs.h" // PCI_VENDOR_ID
+#include "stacks.h" // run_thread
#include "std/disk.h" // DISK_RET_SUCCESS
#include "string.h" // memset
#include "util.h" // usleep
@@ -132,8 +133,9 @@ virtio_scsi_scan_target(struct pci_device *pci, struct vp_device *vp,
}
static void
-init_virtio_scsi(struct pci_device *pci)
+init_virtio_scsi(void *data)
{
+ struct pci_device *pci = data;
dprintf(1, "found virtio-scsi at %pP\n", pci);
struct vring_virtqueue *vq = NULL;
struct vp_device *vp = malloc_high(sizeof(*vp));
@@ -199,6 +201,6 @@ virtio_scsi_setup(void)
(pci->device != PCI_DEVICE_ID_VIRTIO_SCSI_09 &&
pci->device != PCI_DEVICE_ID_VIRTIO_SCSI_10))
continue;
- init_virtio_scsi(pci);
+ run_thread(init_virtio_scsi, pci);
}
}
--
2.5.5
2 years, 9 months
[PATCH 1/2] optionroms: Drop support for CONFIG_OPTIONROMS_DEPLOYED
by Kevin O'Connor
No modern software uses this option and it complicates the code.
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/Kconfig | 8 --------
src/fw/shadow.c | 15 +-------------
src/optionroms.c | 61 ++++++++++++++++++++------------------------------------
3 files changed, 23 insertions(+), 61 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index de39b38..e767be1 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -395,14 +395,6 @@ menu "BIOS interfaces"
default y
help
Support finding and running option roms during POST.
- config OPTIONROMS_DEPLOYED
- depends on OPTIONROMS && QEMU
- bool "Option roms are already at 0xc0000-0xf0000"
- default n
- help
- Select this if option ROMs are already copied to
- 0xc0000-0xf0000. This must only be selected when using
- Bochs or QEMU versions older than 0.12.
config PMM
depends on OPTIONROMS
bool "PMM interface"
diff --git a/src/fw/shadow.c b/src/fw/shadow.c
index bdb5c5b..f766bb5 100644
--- a/src/fw/shadow.c
+++ b/src/fw/shadow.c
@@ -26,24 +26,11 @@ static void
__make_bios_writable_intel(u16 bdf, u32 pam0)
{
// Make ram from 0xc0000-0xf0000 writable
- int clear = 0;
int i;
for (i=0; i<6; i++) {
u32 pam = pam0 + 1 + i;
- int reg = pci_config_readb(bdf, pam);
- if (CONFIG_OPTIONROMS_DEPLOYED && (reg & 0x11) != 0x11) {
- // Need to copy optionroms to work around qemu implementation
- void *mem = (void*)(BUILD_ROM_START + i * 32*1024);
- memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024);
- pci_config_writeb(bdf, pam, 0x33);
- memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024);
- clear = 1;
- } else {
- pci_config_writeb(bdf, pam, 0x33);
- }
+ pci_config_writeb(bdf, pam, 0x33);
}
- if (clear)
- memset((void*)BUILD_BIOS_TMP_ADDR, 0, 32*1024);
// Make ram from 0xf0000-0x100000 writable
int reg = pci_config_readb(bdf, pam0);
diff --git a/src/optionroms.c b/src/optionroms.c
index 9897753..65f7fe0 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -347,28 +347,16 @@ optionrom_setup(void)
memset(sources, 0, sizeof(sources));
u32 post_vga = rom_get_last();
- if (CONFIG_OPTIONROMS_DEPLOYED) {
- // Option roms are already deployed on the system.
- u32 pos = post_vga;
- while (pos < rom_get_max()) {
- int ret = init_optionrom((void*)pos, 0, 0);
- if (ret)
- pos += OPTION_ROM_ALIGN;
- else
- pos = rom_get_last();
- }
- } else {
- // Find and deploy PCI roms.
- struct pci_device *pci;
- foreachpci(pci) {
- if (pci->class == PCI_CLASS_DISPLAY_VGA || pci->have_driver)
- continue;
- init_pcirom(pci, 0, sources);
- }
-
- // Find and deploy CBFS roms not associated with a device.
- run_file_roms("genroms/", 0, sources);
+ // Find and deploy PCI roms.
+ struct pci_device *pci;
+ foreachpci(pci) {
+ if (pci->class == PCI_CLASS_DISPLAY_VGA || pci->have_driver)
+ continue;
+ init_pcirom(pci, 0, sources);
}
+
+ // Find and deploy CBFS roms not associated with a device.
+ run_file_roms("genroms/", 0, sources);
rom_reserve(0);
// All option roms found and deployed - now build BEV/BCV vectors.
@@ -427,26 +415,21 @@ vgarom_setup(void)
RunPCIroms = romfile_loadint("etc/pci-optionrom-exec", 2);
ScreenAndDebug = romfile_loadint("etc/screen-and-debug", 1);
- if (CONFIG_OPTIONROMS_DEPLOYED) {
- // Option roms are already deployed on the system.
- init_optionrom((void*)BUILD_ROM_START, 0, 1);
- } else {
- // Clear option rom memory
- memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START);
-
- // Find and deploy PCI VGA rom.
- struct pci_device *pci;
- foreachpci(pci) {
- if (!is_pci_vga(pci))
- continue;
- vgahook_setup(pci);
- init_pcirom(pci, 1, NULL);
- break;
- }
+ // Clear option rom memory
+ memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START);
- // Find and deploy CBFS vga-style roms not associated with a device.
- run_file_roms("vgaroms/", 1, NULL);
+ // Find and deploy PCI VGA rom.
+ struct pci_device *pci;
+ foreachpci(pci) {
+ if (!is_pci_vga(pci))
+ continue;
+ vgahook_setup(pci);
+ init_pcirom(pci, 1, NULL);
+ break;
}
+
+ // Find and deploy CBFS vga-style roms not associated with a device.
+ run_file_roms("vgaroms/", 1, NULL);
rom_reserve(0);
if (rom_get_last() == BUILD_ROM_START)
--
2.5.5
2 years, 9 months
[PATCH 1/2] block: Move send_disk_op() from block.c to disk.c
by Kevin O'Connor
The send_disk_op() function is only called from the 16bit handlers
found in disk.c.
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/block.c | 34 +---------------------------------
src/block.h | 1 -
src/disk.c | 32 ++++++++++++++++++++++++++++++++
3 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/src/block.c b/src/block.c
index d9de29f..a383574 100644
--- a/src/block.c
+++ b/src/block.c
@@ -22,7 +22,7 @@
#include "hw/virtio-scsi.h" // virtio_scsi_process_op
#include "malloc.h" // malloc_low
#include "output.h" // dprintf
-#include "stacks.h" // stack_hop
+#include "stacks.h" // call32
#include "std/disk.h" // struct dpte_s
#include "string.h" // checksum
#include "util.h" // process_floppy_op
@@ -613,35 +613,3 @@ process_op(struct disk_op_s *op)
op->count = 0;
return ret;
}
-
-// Execute a "disk_op_s" request - this runs on the extra stack.
-static int
-__send_disk_op(struct disk_op_s *op_far, u16 op_seg)
-{
- struct disk_op_s dop;
- memcpy_far(GET_SEG(SS), &dop
- , op_seg, op_far
- , sizeof(dop));
-
- dprintf(DEBUG_HDL_13, "disk_op d=%p lba=%d buf=%p count=%d cmd=%d\n"
- , dop.drive_gf, (u32)dop.lba, dop.buf_fl
- , dop.count, dop.command);
-
- int status = process_op(&dop);
-
- // Update count with total sectors transferred.
- SET_FARVAR(op_seg, op_far->count, dop.count);
-
- return status;
-}
-
-// Execute a "disk_op_s" request by jumping to the extra 16bit stack.
-int
-send_disk_op(struct disk_op_s *op)
-{
- ASSERT16();
- if (! CONFIG_DRIVES)
- return -1;
-
- return stack_hop(__send_disk_op, op, GET_SEG(SS));
-}
diff --git a/src/block.h b/src/block.h
index a5f38c4..0f15ff9 100644
--- a/src/block.h
+++ b/src/block.h
@@ -115,7 +115,6 @@ int fill_edd(struct segoff_s edd, struct drive_s *drive_gf);
void block_setup(void);
int default_process_op(struct disk_op_s *op);
int process_op(struct disk_op_s *op);
-int send_disk_op(struct disk_op_s *op);
int create_bounce_buf(void);
#endif // block.h
diff --git a/src/disk.c b/src/disk.c
index 3854d00..bcd6a09 100644
--- a/src/disk.c
+++ b/src/disk.c
@@ -87,6 +87,38 @@ getLCHS(struct drive_s *drive_gf)
return res;
}
+// Execute a "disk_op_s" request - this runs on the extra stack.
+static int
+__send_disk_op(struct disk_op_s *op_far, u16 op_seg)
+{
+ struct disk_op_s dop;
+ memcpy_far(GET_SEG(SS), &dop
+ , op_seg, op_far
+ , sizeof(dop));
+
+ dprintf(DEBUG_HDL_13, "disk_op d=%p lba=%d buf=%p count=%d cmd=%d\n"
+ , dop.drive_gf, (u32)dop.lba, dop.buf_fl
+ , dop.count, dop.command);
+
+ int status = process_op(&dop);
+
+ // Update count with total sectors transferred.
+ SET_FARVAR(op_seg, op_far->count, dop.count);
+
+ return status;
+}
+
+// Execute a "disk_op_s" request by jumping to the extra 16bit stack.
+static int
+send_disk_op(struct disk_op_s *op)
+{
+ ASSERT16();
+ if (! CONFIG_DRIVES)
+ return -1;
+
+ return stack_hop(__send_disk_op, op, GET_SEG(SS));
+}
+
// Perform read/write/verify using old-style chs accesses
static void noinline
basic_access(struct bregs *regs, struct drive_s *drive_gf, u16 command)
--
2.5.5
2 years, 9 months
Add support for legacy USB keyboard/mouse (PS/2 emulation for USB?)
by Adam Rutkowski
Hello,
I think this is the right place to write about this. From a few days I'm fighting with not USB-aware OS-es in QEMU (like Windows 98, IBM OS/2, MS-DOS etc.). When I assign real USB keyboard and mouse to VM, keyboard partially works in DOS (keys like Alt aren't working), but mouse doesn't work at all. After starting, let's say Windows 98 Setup, keyboard stops working too. From my experience these peripherals works only in newer OSes like Windows 2000+ or Linux, because they initialize their own USB HID driver. I'm not using QEMU's emulated USB HID devices, because I utilize VGA passthrough, so I need direct access from guest machine.
Summarizing: is it possible to add full support for USB keyboard and mouse in SeaBIOS?
P.S. I apologize for any grammatical errors.
2 years, 9 months
[RFC] Document and rework debug levels
by Kevin O'Connor
There are a number of debug levels in the SeaBIOS code today.
Unfortunately, much of the code does not follow any particular
standard for which debug level to use.
This is becoming cumbersome for a few reasons:
- some people want fewer debug messages to reduce boot time, but still
want critical messages (eg, error messages). Debug level 1 can be
too verbose while debug level 0 disables all messages.
- some drivers become very verbose before other drivers, and thus
depending on a user's hardware, the user might get flooded with
messages they don't want before seeing the important messages from
the driver they were looking for
- when writing a new driver, it's not easy for a developer to know
what debug level to choose
I'm proposing that the debug levels be documented and that all of the
debug messages in SeaBIOS be reworked to follow that documentation.
Here are the debug levels I propose using:
Level 1:
- SeaBIOS version banner
- Major error messages and major warning messages that are likely
indicative of an error
- Screen output (ie, printf) would also be available at this level
when screen-and-debug is true
Level 2:
- Critical memory layout information. This would include the e820
map prior to booting and similar information about UMB memory,
EBDA memory, BIOS table locations, etc.
Level 3:
- Found hardware for which there is a SeaBIOS driver and critical
information about that hardware (such as its address, hardware
version, hardware capabilities, etc.)
Level 4:
- Major code flow events between SeaBIOS phases (eg, post, boot,
resume phases)
Level 5:
- Code flow notifications at driver and subsystem startup (eg, "init
usb\n" type messages)
- Thread startup and shutdown messages
Level 6:
- Basic driver and subsystem debugging. This would be driver
specific messages that are not expected to be called with high
frequency (ie, not called on every disk access nor on every
keyboard access, etc.)
Finally, for debug messages that could be called with high frequency
(eg, on each disk read), I propose defining a DEBUG_xyz at the top of
the particular driver source code file which would default to 9 and a
developer could change to a lower number when working on that code.
So, for example, DEBUG_xhci could be introduced and be used on
dprintf() messages that are invoked on each xhci transfer.
As part of this proposal, the default debug level would change from
level 1 to level 4. Most dprintf level 1 calls in the code would
change to a level between 1 and 4. Most driver dprintf calls between
levels 3-8 would end up changing to level 6. Most dprintf calls with
9 (or higher) would instead get a DEBUG_xyz definition.
Thoughts?
-Kevin
2 years, 9 months
