Per Intel 82540EM Software Developer's Manual pp. 211, the mmio size
is 0x20000, or address overlapping occurs and causes the second card
to fail, which happened to me earlier.
From: Tina Yang <tina.yang@oracle.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Recent Solaris enhancements have changed the way virtual NIC
statistics are collected - fix libxenstat up for this.
Signed-off-by: John Levon <john.levon@sun.com>
Reading qemu code I realized that the qemu vnc server sometimes sends
framebuffer updates even if the client didn't request any. This is not
consistent with the RFB protocol spec and can break some clients.
This patch strictly enforces compliance with the RFB protocol making
sure framebuffer updates are sent only if the client requested one.
Doing so is more difficult than it seems because some framebuffer
pseudo-encoding updates cannot be discarded but must be sent anyway:
for example desktop resize and pixel format change messages. To solve
the problem I wrote a queue that stores those messages and sends them
as soon as the client asks for an update. Since 90% of the times the
queue is used to store only few elements, the queue allocates 10
elements at the beginning and every time it runs out of elements
allocates other 10 elements. This is should drastically limit the
number of malloc and free needed to maintain the queue. I did some
stress tests in the last couple of days and seems to work well.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
xce handles are not supposed to be used as file descriptors, but
xc_evtchn_fd() be used.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Before writing records, xentrace will check to make sure that there is
a minimum amount of space left on the output filesystem.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
This is a direct port of the e1000 driver currently in Qemu CVS with
extremely minimal changes. This is useful for Xen as new OSes may not
support the old 100Mbps NICs we currently support (especially on
non-x86). Drivers for e1000 should be more readily available.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Saved images contain rtc_timeoffset as a string value, resulting in a
TypeError exception when calling xc.domain_set_time_offset() on
restore. Cast rtc_timeoffset to int before calling
xc.domain_set_time_offset().
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
I am adding some functions for external tools to call the vTPM scripts.
It also contains a fix for the functions that previously used to be
called by domain name, but now are using the vTPM's uuid as parameter.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
No need to generate the correct number dynamically since
present/not-present can be determined from the MADT. What *is*
required is that we have a Processor Object for every present
processor. We statically declare 16 Objects, which should be plenty
for now.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
With my qcow2 patch to blktap I contributed a bit to the mess, so here
an attempt to clean up and remove at least some of the code
duplication in the functions dealing with aio operations.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
the caller. This is used in cases where the writeback may be to an
MMIO region with side effects (the APIC EOI register is the main
example of this).
Also fix up build of the x86_emulate user-space test harness.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This patch adds support for the qcow2 image format to blktap. It
consists mostly of qemu code, adapted to the blktap interfaces.
Snapshots and compressed images are supported.
The qcow2 driver may be used by either specifying tap:qcow2 or by
using tap:qcow which will detect that you have a version 2 image and
will call the qcow2 driver.
Signed-off-by: Kevin Wolf <kwolf@suse.de>
Previously a newline was forced after every call to
write_with_timestamp. This could result in some ugly logs when a
single console line stretched over multiple calls. This change carries
some extra state to determine if we ended the last call to
write_with_timestamp on a newline, and prints the timestamp as
appropriate.
This also fixes a bug where logging hv messages was dependent on the
guest timestamp flag.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Now that the qemu WMVi patch is applied we can take full advantage of
it sharing the video buffer between the vga driver and the qemu vnc
server. This saves a lot of memcpy. It's worth mentioning again that
when the guest colour depth is 24 bit we cannot share the buffer
because 24 bpp is not supported by the vnc protocol, so we still have
to do the translation 24 bpp -> 32 bpp.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
** Currently only 2 virtual hotplug pci slots(6~7) are created so more
than 2 vtd dev can't be hotplugged, but we can easily extend it in
future.
Three new commands are added:
"xm pci-list domid" show the current assigned vtd device, like:
VSlt domain bus slot func
0x6 0x0 0x02 0x00 0x0
"xm pci-detach" hot remove the specified vtd device by the virtual
slot, like:
xm pci-detach EdwinHVMDomainVtd 6
"xm pci-attach DomainID dom bus dev func [vslot]" hot add a new vtd
device in the vslot. If no vslot specified, a free slot will be picked
up. e.g. to insert '0000:03:00.0':
xm pci-attach EdwinHVMDomainVtd 0 3 0 0
** guest pci hotplug
linux: pls. use 2.6.X and enable ACPI PCI hotplug ( Bus options=> PCI
hotplug => ACPI PCI hotplug driver )
windows: 2000/xp/2003/vista are all okay
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
If the client implements it, it is supposed to be able to change
colour depth when receiving a WMVi message.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
by removing some obvious typos, handling CR3 folding and hvirt_start
based on guest word-size, and understanding 32-bit INVALID_MFN.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
- Move PAGE_SIZE and STACK_SIZE into __PAGE_SIZE and __STACK_SIZE in
arch_limits.h so as to permit getting them from there without
pulling all the internal Mini-OS defines.
- Setup a xen-elf cross-compilation environment in stubdom/cross-root
- Add a POSIX layer on top of Mini-OS by linking against the newlib C
library and lwIP, and implementing the Unixish part in mini-os/lib/sys.c
- Cross-compile zlib and libpci too.
- Add an xs.h-compatible layer on top of Mini-OS' xenbus.
- Cross-compile libxc with an additional xc_minios.c and a few things
disabled.
- Cross-compile ioemu with an additional block-vbd, but without sound,
tpm and other details. A few hacks are needed:
- Align ide and scsi buffers at least on sector size to permit
direct transmission to the block backend. While we are at it, just
page-align it to possibly save a segment. Also, limit the scsi
buffer size because of limitations of the block paravirtualization
protocol.
- Allocate big tables dynamically rather that letting them go to
bss: when Mini-OS gets installed in memory, bss is not lazily
allocated, and doing so during Mini-OS is unnecessarily trick while
we can simply use malloc.
- Had to change the Mini-OS compilation somehow, so as to export
Mini-OS compilation flags to the Makefiles of libxc and ioemu.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
mb/rmb/wmb. Instead add a xen_ prefix. Modify Xen's public headers to
expect the prefixed names instead of bare mb/rmb/wmb, but gate this
expectation on a bump of __XEN_INTERFACE_VERSION__.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Make qemu unblock SIGHUP and make sure the default handler is in
place. Have the domain killer send SIGHUP to the device-model script,
allow the script 10s to clean up, and if still not dead, send
SIGKILL.
Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
Currently, a wrong value of maximum memory size is checked by
_safe_set_memory() and _memory_sanity_check().
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The qemu vnc server changes its internal colour depth based on the
client request. This way just one colour conversion is done: the one
in vga_template.h, from the guest colour depth and the vnc server
internal colour depth.
This patch is meant to remove this colour conversion to improve
performances. It accomplishes the goal making the qemu internal colour
depth always the same as the guest colour depth.
The basic idea is that the vnc client is the one that should do the
colour conversion, if necessary. In general it should accept the pixel
format suggested by the server during the initial negotiation. This
behaviour can be set in most vnc clients (vncviewer included).
If the guest changes colour depth, the qemu vnc server changes colour
depth too and notifies the client. The problem is that the vnc
protocol doesn't provide a message from the server to the client to
ask for a colour depth change. So what I am doing is either:
1) quietly starting to do the conversion on vnc server (not gaining
any performance here);
2) closing the vnc connection with the client, so the client can
reconnect and choose the new pixel format.
By default I am doing 1), however the second choice can be enabled
passing the -vnc-switch-bpp command line option.
In order to do the colour conversion on the vnc server I had to
improve the colour conversion code already in place because it only
supported conversions from 32 bpp. The patch adds colour conversion
code that support conversions from any resolution to any resolution.
A last note: to get most out of this patch it is best to set Windows
to 16 bit colour depth, because the 24 bit mode is 24 bit depth and 24
bpp, meaning no alpha channel. The vnc protocol doesn't support 24
bpp, only 32 bpp, so this conversion is unavoidable.
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Keir Fraser
Alex Williamson