This patch killes the old_data hack in the qemu server and replaces
it with a clean separation of the guest-visible display surface and
the vnc server display surface. Both guest and server surface have
their own dirty bitmap for tracking screen updates.
Workflow is this:
(1) The guest writes to the guest surface. With shared buffers being
active the guest writes are directly visible to the vnc server code.
Note that this may happen in parallel to the vnc server code running
(today only in xenfb, once we have vcpu threads in qemu also for
other display adapters).
(2) vnc_update() callback tags the specified area in the guest dirty
map.
(3) vnc_update_client() will first walk through the guest dirty map. It
will compare guest and server surface for all regions tagged dirty
and in case the screen content really did change the server surface
and dirty map are updated.
Note: old code used old_data in a simliar way, so this does *not*
introduce an extra memcpy.
(4) Then vnc_update_cient() will send the updates to the vnc client
using the server surface and dirty map.
Note: old code used the guest-visible surface instead, causing
screen corruption in case of guest screen updates running in
parallel.
The separate dirty bitmap also has the nice effect that forced screen
updates can be done cleanly by simply tagging the area in both guest and
server dirty map. The old, hackish way was memset(old_data, 42, size)
to trick the code checking for screen changes.
blueswir1 [Fri, 13 Mar 2009 21:16:24 +0000 (21:16 +0000)]
Make the ELF loader aware of backwards compatibility
Most 64 bit architectures I'm aware of support running 32 bit code
of the same architecture as well.
So x86_64 can run i386 code easily and ppc64 can run ppc code.
Unfortunately, the current checks are pretty strict. So you can only
load e.g. an x86_64 elf binary on qemu-system-x86_64, but no i386 one.
This can get really annoying. I first encountered this issue with
my multiboot patch, where qemu-system-x86_64 was unable to load an
i386 elf binary because the elf loader rejected it.
The same thing happened again on PPC64 now. The firmware we're loading
is a PPC32 elf binary, as it's shared with PPC32. But the platform is
PPC64.
Right now there is a hack for this in the ppc cpu.h definition, that
simply sets the type to PPC32 in system emulation mode. While that
works fine for the firmware, it's no good if you also want to load a
PPC64 kernel with -kernel.
So in order to solve this mess, I figured the easiest way is to make
the elf loader aware of platforms that are backwards compatible. For
now I was only sure that x86_64 does i386 and ppc64 does ppc32, but
maybe there are other combinations too.
This patch is a prerequisite for having a working -kernel option on
PPC64.
aliguori [Fri, 13 Mar 2009 15:02:23 +0000 (15:02 +0000)]
Add and use remaining #defines for PCI device IDs (Stuart Brady)
This patch adds and uses #defines for the remaining hardcoded PCI
device IDs. It also moves definitions taken from linux/pci_ids.h
into a separate header (hw/pci_ids.h), removes the 'RTL' from
PCI_DEVICE_ID_REALTEK_RTL8029, and renames PCI_DEVICE_ID_FSL_E500
to PCI_DEVICE_ID_MPC8533E to match Linux's definition.
Changes in v2:
* Don't use C99-style comments
* Move definitions from linux/pci_ids.h into a separate header
* Rename PCI_DEVICE_ID_FSL_E500 to PCI_DEVICE_ID_MPC8533E
aliguori [Fri, 13 Mar 2009 15:02:18 +0000 (15:02 +0000)]
remove is_graphic_console from vga.c (Stefano Stabellini)
Hi all,
since vga_draw_graphic is only called by vga_hw_update when the console
associated with the graphic card is active, we don't need to check if
the current console is active using is_graphic_console.
I suspect I introduced these checks when the console switching mechanism
didn't work as it does now.
aliguori [Fri, 13 Mar 2009 15:02:13 +0000 (15:02 +0000)]
DisplayAllocator interface (Stefano Stabellini)
Hi all,
this patch adds a DisplayAllocator interface that allows display
frontends (sdl in particular) to provide a preallocated display buffer
for the graphical backend to use.
Whenever a graphical backend cannot use
qemu_create_displaysurface_from because its own internal pixel format
cannot be exported directly (text mode or graphical mode with color
depth 8 or 24), it creates another display buffer in memory using
qemu_create_displaysurface and does the conversion.
This new buffer needs to be blitted into the sdl surface buffer every time
we need to update portions of the screen.
We can avoid this using the DisplayAllocator interace: sdl provides its
own implementation of qemu_create_displaysurface, giving back the sdl
surface buffer directly (as we used to do before the DisplayState
changes).
Since the buffer returned by sdl could be in bgr format we need to put
back in the handlers of that case.
This approach is good if the two following conditions are true:
1) the sdl surface is a software surface that resides in main memory;
2) the host display color depth is either 16 or 32 bpp.
If first condition is false we can have bad performances using sdl
and vnc together.
If the second condition is false performances are certainly not going to
improve but they shouldn't get worse either.
The first condition is always true, at least on linux/X11 systems; but I
believe is true also on other platforms.
The second condition is true in the vast majority of the cases.
This patch should also have the good side effect of solving the sdl
2D slowness malc was reporting on MacOS, because SDL_BlitSurface is not
going to be called anymore when the guest is in text mode or 24bpp.
However the root problem is still present so I suspect we may
still see some slowness on MacOS when the guest is in 32 or 16 bpp.
aliguori [Fri, 13 Mar 2009 03:12:03 +0000 (03:12 +0000)]
Fix regression introduced by r6824
The changes introduced by r6824 broke a subtle, and admittedly obscure, aspect
of the block API. While bdrv_{pread,pwrite} return the number of bytes read
or written upon success, bdrv_{read,write} returns a zero upon success.
When using bdrv_pread for bdrv_read, special care must be taken to handle this
case.
This fixes certain guest images (notably linux-0.2 provided on the qemu
website).
aliguori [Thu, 12 Mar 2009 20:12:48 +0000 (20:12 +0000)]
Guest debugging support for KVM (Jan Kiszka)
This is a backport of the guest debugging support for the KVM
accelerator that is now part of the KVM tree. It implements the reworked
KVM kernel API for guest debugging (KVM_CAP_SET_GUEST_DEBUG) which is
not yet part of any mainline kernel but will probably be 2.6.30 stuff.
So far supported is x86, but PPC is expected to catch up soon.
Core features are:
- unlimited soft-breakpoints via code patching
- hardware-assisted x86 breakpoints and watchpoints
Changes in this version:
- use generic hook cpu_synchronize_state to transfer registers between
user space and kvm
- push kvm_sw_breakpoints into KVMState
aliguori [Thu, 12 Mar 2009 19:57:16 +0000 (19:57 +0000)]
Drop internal bdrv_pread()/bdrv_pwrite() APIs (Avi Kivity)
Now that scsi generic no longer uses bdrv_pread() and bdrv_pwrite(), we can
drop the corresponding internal APIs, which overlap bdrv_read()/bdrv_write()
and, being byte oriented, are unnatural for a block device.
aliguori [Thu, 12 Mar 2009 19:57:12 +0000 (19:57 +0000)]
Add internal scsi generic block API (Avi Kivity)
Add an internal API for the generic block layer to send scsi generic commands
to block format driver. This means block format drivers no longer need
to consider overloaded nb_sectors parameters.
aliguori [Thu, 12 Mar 2009 19:57:08 +0000 (19:57 +0000)]
Add specialized block driver scsi generic API (Avi Kivity)
When a scsi device is backed by a scsi generic device instead of an
ordinary host block device, the block API is abused in a couple of annoying
ways:
- nb_sectors is negative, and specifies a byte count instead of a sector count
- offset is ignored, since scsi-generic is essentially a packet protocol
This overloading makes hacking the block layer difficult. Remove it by
introducing a new explicit API for scsi-generic devices. The new API
is still backed by the old implementation, but at least the users are
insulated.
aliguori [Wed, 11 Mar 2009 20:05:37 +0000 (20:05 +0000)]
Revert r6404
This series is broken by design as it requires expensive IO operations at
open time causing very long delays when starting a virtual machine for the
first time.
aliguori [Wed, 11 Mar 2009 20:05:33 +0000 (20:05 +0000)]
Revert r6405
This series is broken by design as it requires expensive IO operations at
open time causing very long delays when starting a virtual machine for the
first time.
aliguori [Wed, 11 Mar 2009 20:05:29 +0000 (20:05 +0000)]
Revert r6406
This series is broken by design as it requires expensive IO operations at
open time causing very long delays when starting a virtual machine for the
first time.
aliguori [Wed, 11 Mar 2009 20:05:25 +0000 (20:05 +0000)]
Revert r6407
This series is broken by design as it requires expensive IO operations at
open time causing very long delays when starting a virtual machine for the
first time.
aliguori [Wed, 11 Mar 2009 20:05:20 +0000 (20:05 +0000)]
Revert r6408
This series is broken by design as it requires expensive IO operations at
open time causing very long delays when starting a virtual machine for the
first time.
aurel32 [Sat, 7 Mar 2009 22:10:40 +0000 (22:10 +0000)]
do not pretend to support low voltage operation
Eliminate "mmc0: SD card claims to support the incompletely defined 'low voltage
range'. This will be ignored." warning. Qemu says the card is a SD card, and SD
spec doesn't define low-voltage cards, so do now pretend to be one.
aurel32 [Sat, 7 Mar 2009 22:00:56 +0000 (22:00 +0000)]
Work around QEMU GDB stub suboptimality
The current XML files claim, on floating point-supporting Power chips,
that $f0 is register 70. This would be fine, except that register 70
for non-XML-aware GDB is FPSCR. More importantly, 70 is less than
NUM_CORE_REGS (71) for Power, so a request for register 70 goes to the
"core" register reading routines, rather than the floating-point
register read routine we registered with gdb_register_coprocessor.
Therefore, when we are talking to an XML-aware GDB, we claim that
register has zero width, which causes the rest of QEMU's GDB stub to
send an error back to GDB, which causes GDB to be unable to read the
floating-point registers. (The problem is also present for SPE
registers and occurs in a slightly different way for Altivec registers.)
The best way to fix this is to have the "core register" XML files for
PPC32 and PPC64 claim that there is a 4-byte register 70, which causes
$f0 to be register 71, and everything works just fine from that point
forward.
aurel32 [Sat, 7 Mar 2009 22:00:49 +0000 (22:00 +0000)]
Fix off-by-one errors for Altivec and SPE registers
Altivec and SPE both have 34 registers in their register sets, not 35
with a missing register 32.
GDB would ask for register 32 of the Altivec (resp. SPE) registers and
the code would claim it had zero width. The QEMU GDB stub code would
then return an E14 to GDB, which would complain about not being sure
whether p packets were supported or not.
aurel32 [Sat, 7 Mar 2009 21:47:53 +0000 (21:47 +0000)]
arm: Fix gic_irq_state.level bitfield type
Found while cleaning up compiler warnings: GIC_*_LEVEL macros strongly
suggest that gic_irq_state.level is intended to be per-CPU and not just
a single, global bit. I'm unable to test the effect, but it seems to be
the most reasonable fix for the apparent brokenness.
blueswir1 [Sat, 7 Mar 2009 20:57:42 +0000 (20:57 +0000)]
Keep SLB in-CPU
Real 970 CPUs have the SLB not memory backed, but inside the CPU.
This breaks bridge mode for 970 for now, but at least keeps us from
overwriting physical addresses 0x0 - 0x300, rendering our interrupt
handlers useless.
I put in a stub for bridge mode operation that could be enabled
easily, but for now it's safer to leave that off I guess (970fx doesn't
have bridge mode AFAIK).
blueswir1 [Sat, 7 Mar 2009 20:53:18 +0000 (20:53 +0000)]
Activate uninorth AGP bridge
Linux tries to poke the AGP bridge port and is pretty sad when it can't,
so let's activate the old code again and throw out the bit modifications,
as we don't really do anything with the values anyways.
blueswir1 [Sat, 7 Mar 2009 20:52:22 +0000 (20:52 +0000)]
Implment tlbiel
Linux uses tlbiel to flush TLB entries in PPC64 mode. This special TLB
flush opcode only flushes an entry for the CPU it runs on, not across
all CPUs in the system.
projects / qemu.git / log