On Wed, Mar 30, 2011 at 10:03 PM, Peter Maydell
peter.mayd...@linaro.org wrote:
Tidy up the message printed when qemu exits due to a signal, so that
it's clearer where the message is coming from and that it's not just
stray debug output.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Dear all,
I have a question to use the qemu-snapshot.
While I create a snapshot file, and use it to restore my vm, everything is
okay.
But, I can't find the temp_snapshot file on my system. It seems like a
invisit file.
How can I get it in my system. Or, could you show me how to fetch it?
On Mon, Mar 07, 2011 at 11:00:13PM +0100, Michael Walle wrote:
To be consistent with the new reference manual.
Applied this and the decoding table patch. Thanks.
Cheers
On Thu, Mar 31, 2011 at 13:39, 涂化衍 david19851...@gmail.com wrote:
Dear all,
I have a question to use the qemu-snapshot.
While I create a snapshot file, and use it to restore my vm, everything is
okay.
But, I can't find the temp_snapshot file on my system. It seems like a
invisit file.
How
Hi Christoph,
I had already updated my driver to reject non 512 multiple sized requests. I
rolled back this update and applied your patch and I now get a non-zero status
response and no qemu crash!
Thanks for your help,
Conor
Am 30.03.2011 03:51, schrieb Ryan Harper:
When removing a drive from the host-side via drive_del we currently have
the following path:
drive_del
qemu_aio_flush()
bdrv_close()// zaps bs-drv, which makes any subsequent I/O get
// dropped. Works as designed
Hi,
Review comments / ACK please ?
regards,
Harsh
On 03/22/2011 11:21 AM, Harsh Prateek Bora wrote:
The nwnames field in TWALK message is assumed to be=0 and= MAXWELEM
which is defined as macro P9_MAXWELEM (16) in virtio-9p.h as per 9p2000 RFC.
Appropriate changes are required in V9fsWalkState
Add support to do chown in chroot process
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot-worker.c | 18 ++
hw/9pfs/virtio-9p-chroot.h|1 +
hw/9pfs/virtio-9p-local.c |9 +
3 files changed, 24 insertions(+), 4
This patch adds both chroot worker and qemu side support to open a file/
directory in the chroot environment
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot.c | 29 +++
hw/9pfs/virtio-9p-chroot.h |2 +-
hw/9pfs/virtio-9p-local.c | 80
Add both chroot worker and qemu side interfaces to create special files
(directory, device nodes, links and symbolic links)
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot-worker.c | 52 +
hw/9pfs/virtio-9p-chroot.h|5
Implement chroot worker side interfaces like sending the file
descriptor to qemu process, reading the object request from socket etc.
Also add chroot main function and other helper routines.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
Makefile.objs |1 +
Support for removing file or directory in chroot environment. Add
interfaces to remove file/directory in chroot worker and qemu side.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot-worker.c | 18 ++
hw/9pfs/virtio-9p-chroot.h|1 +
Add both chroot worker qemu side interfaces to create regular files in
chroot environment
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot-worker.c | 36
hw/9pfs/virtio-9p-chroot.h|1 +
hw/9pfs/virtio-9p-local.c
Add support to do chmod operation in chroot process.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-chroot-worker.c | 18 ++
hw/9pfs/virtio-9p-chroot.h|1 +
hw/9pfs/virtio-9p-local.c |5 +++--
3 files changed, 22 insertions(+), 2
After creating a file object, its permission and ownership details are updated
as per 9p client's request for both passthrough and none security model.
But with chrooted environment its not required for passthrough security model.
Move all post file creation changes to none security model.
Add qemu_read_full function
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
osdep.c | 32
qemu-common.h |2 ++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/osdep.c b/osdep.c
index 327583b..8d84a88 100644
--- a/osdep.c
+++
QEMU side interfaces to communicate with chroot worker process.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
Makefile.objs |2 +-
hw/9pfs/virtio-9p-chroot.c | 92
hw/9pfs/virtio-9p-chroot.h |1 +
3 files changed, 94
In passthrough security model, following symbolic links in the server
side could result in TOCTTOU vulnerabilities.
This patchset resolves this issue by creating a dedicated process which
chroots into the share path and all file object access is done in the
chroot environment.
This patchset
On Wed, Mar 30, 2011 at 10:03:38PM +0100, Peter Maydell wrote:
Tidy up the message printed when qemu exits due to a signal, so that
it's clearer where the message is coming from and that it's not just
stray debug output.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Acked-by: Gleb
9p Chroot environment needs APIs defined in qemu-thread.c, so enable
CONFIG_THREAD if virtfs is enabled
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
configure |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 4a4d085..9bfbe51 100755
---
On Tue, Mar 22, 2011 at 5:51 AM, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
The nwnames field in TWALK message is assumed to be =0 and = MAXWELEM
which is defined as macro P9_MAXWELEM (16) in virtio-9p.h as per 9p2000 RFC.
Appropriate changes are required in V9fsWalkState and v9fs_walk.
Add chroot functionality for systemcalls that can operate on a file
using relative directory file descriptor.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
---
hw/9pfs/virtio-9p-local.c | 125 +
1 files changed, 115 insertions(+), 10 deletions(-)
On Wed, Mar 30, 2011 at 09:51:29PM +0100, Peter Maydell wrote:
2011/3/30 Gleb Natapov g...@redhat.com:
On Wed, Mar 30, 2011 at 07:53:41PM +0100, Peter Maydell wrote:
I'm not convinced about the utility of printing the pid, personally.
Most programs get along fine without printing anything
SDL library initialization mangles signal handlers, so QEMU should
register them after initializing SDL. This was the case before and code
even have a comment about that. Fix it to be so again.
Signed-off-by: Gleb Natapov g...@redhat.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
diff
On (Wed) 30 Mar 2011 [17:40:40], Stefan Hajnoczi wrote:
Several of us have been investigating CD-ROM bugs. Let's update each
other, make sure we're not duplicating effort, and see if we can help
each other make progress.
= Stefan =
Guests do not notice media change when using Linux host
Stefan Hajnoczi stefa...@gmail.com writes:
Several of us have been investigating CD-ROM bugs. Let's update each
other, make sure we're not duplicating effort, and see if we can help
each other make progress.
= Stefan =
Guests do not notice media change when using Linux host CD-ROM
Am 29.03.2011 21:04, schrieb Stefan Hajnoczi:
Piggy-back on the guest CD-ROM polling to poll on the host. Open and
close the host CD-ROM file descriptor to ensure we read the new size and
not a stale size.
Two things are going on here:
1. If hald/udisks is not already polling CD-ROMs on
Am 30.03.2011 14:16, schrieb jes.soren...@redhat.com:
From: Jes Sorensen jes.soren...@redhat.com
This adds the basic infrastructure for supporting progress output
on the command line, as well as progress support for qemu-img commands
'rebase' and 'convert'.
Signed-off-by: Jes Sorensen
bdrv_delete must not be called for a NULL BlockDriverState.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-img.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 074388c..d9c2c12 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1411,8
On 29 March 2011 09:55, Alexander Graf ag...@suse.de wrote:
On 28.03.2011, at 17:40, Peter Maydell wrote:
Doesn't this take you over MAX_OP_PER_INSTR for some cases?
I haven't encountered any case where it does.
This untested patch against your v2 ought to make it print
a warning if you do go
Am 30.03.2011 14:31, schrieb Michael Tokarev:
This fixes the problem when qemu continues even if -drive specification
is somehow invalid, resulting in a mess. Applicable for both current
master and for stable-0.14 (and the same issue exist 0.13 and 0.12 too).
The prob can actually be
On 03/31/11 12:38, Kevin Wolf wrote:
Am 30.03.2011 14:16, schrieb jes.soren...@redhat.com:
From: Jes Sorensen jes.soren...@redhat.com
This adds the basic infrastructure for supporting progress output
on the command line, as well as progress support for qemu-img commands
'rebase' and
Am 31.03.2011 13:15, schrieb Jes Sorensen:
On 03/31/11 12:38, Kevin Wolf wrote:
Am 30.03.2011 14:16, schrieb jes.soren...@redhat.com:
From: Jes Sorensen jes.soren...@redhat.com
This adds the basic infrastructure for supporting progress output
on the command line, as well as progress support
On Tue, Mar 29, 2011 at 19:27, anthony.per...@citrix.com wrote:
From: Anthony PERARD anthony.per...@citrix.com
Hi all,
Here is the few change made since the v11:
- All objects built for each target are now build only for i386 targets.
- The compatibility macros have been replaced by
On Thu, Mar 31, 2011 at 12:38 PM, Kevin Wolf kw...@redhat.com wrote:
Am 31.03.2011 13:15, schrieb Jes Sorensen:
On 03/31/11 12:38, Kevin Wolf wrote:
Am 30.03.2011 14:16, schrieb jes.soren...@redhat.com:
From: Jes Sorensen jes.soren...@redhat.com
This adds the basic infrastructure for
On Thu, Mar 31, 2011 at 11:41 AM, Kevin Wolf kw...@redhat.com wrote:
bdrv_delete must not be called for a NULL BlockDriverState.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-img.c | 8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
Reviewed-by: Stefan Hajnoczi
Here's a quick-n-dirty howto about running OEM version
of windows7 or vista in qemu/kvm, assuming you own a
computer with pre-installed OEM version of such operating
system so you have rights to run it there.
Windows 7 Vista OEM activation are based on a special
OEM marker in BIOS in a form of
block_mig_state.reads is an int, and multiplying by BLOCK_SIZE yielded a
negative number, resulting in a negative bandwidth (running on a 32-bit
machine). Cast to avoid.
Signed-off-by: Avishay Traeger avis...@il.ibm.com
---
block-migration.c |2 +-
1 files changed, 1 insertions(+), 1
On Thu, Mar 31, 2011 at 10:53 AM, Amit Shah amit.s...@redhat.com wrote:
= Amit =
Found that 2.6.38 and later guest kernels fail to report media change.
It's not 2.6.38 and later; it's somewhere around the time libata was
introduced and CDROM emulation went from ide to scsi in the kernel.
The current bandwidth calculation looks like this:
(block_mig_state.reads * BLOCK_SIZE)/ block_mig_state.total_time
total_time is currently the sum of the read request latencies. This is
not very accurate because block migration uses aio and so several requests
can be submitted at once.
2011/3/31 涂化衍 david19851...@gmail.com:
Dear Mr/Miss,
It's Mr :)
Thanks for your information. We have already found something in this path.
But, this problem is still alive. We can't restore this virtual machine on
another physical machine from host A to host B by using snapshot
I might
Currently, vga cards that allocate vga ram,
register it as regular ram. When this happens
a lot, vhost need to get notified and flush
its memory tables, which is slow.
This was observed with cirrus vga.
As a solution, add an explicit flag when
registering vga ram, vhost-net can simply ignore it.
If -pflash is specified and -bios is specified then pflash will
be mapped just below the system rom using hw/pflash_cfi01.c.
If -pflash is specified on the command line, but -bios is
not specified, then 'bios.bin' will NOT be loaded, and
instead the -pflash flash image will be mapped just below
On 03/31/2011 12:43 PM, Michael S. Tsirkin wrote:
Currently, vga cards that allocate vga ram,
register it as regular ram. When this happens
a lot, vhost need to get notified and flush
its memory tables, which is slow.
This was observed with cirrus vga.
As a solution, add an explicit flag when
On Thu, Mar 31, 2011 at 01:33:58PM -0500, Anthony Liguori wrote:
On 03/31/2011 12:43 PM, Michael S. Tsirkin wrote:
Currently, vga cards that allocate vga ram,
register it as regular ram. When this happens
a lot, vhost need to get notified and flush
its memory tables, which is slow.
This
On 03/31/2011 01:49 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 01:33:58PM -0500, Anthony Liguori wrote:
On 03/31/2011 12:43 PM, Michael S. Tsirkin wrote:
Currently, vga cards that allocate vga ram,
register it as regular ram. When this happens
a lot, vhost need to get notified and
On Thu, Mar 31, 2011 at 02:01:52PM -0500, Anthony Liguori wrote:
On 03/31/2011 01:49 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 01:33:58PM -0500, Anthony Liguori wrote:
On 03/31/2011 12:43 PM, Michael S. Tsirkin wrote:
Currently, vga cards that allocate vga ram,
register it as
On Thu, 2011-03-31 at 14:01 -0500, Anthony Liguori wrote:
On 03/31/2011 01:49 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 01:33:58PM -0500, Anthony Liguori wrote:
On 03/31/2011 12:43 PM, Michael S. Tsirkin wrote:
Currently, vga cards that allocate vga ram,
register it as regular
On 31 March 2011 20:01, Anthony Liguori anth...@codemonkey.ws wrote:
VGA is just another device. It happens to be that we treat VGA device
memory as something that behaves like ram occassionally but that does not
make it RAM.
So, to ask a dumb question, what does make something RAM?
My take
On 03/31/2011 02:07 PM, Michael S. Tsirkin wrote:
Just needs some love.
VGA is just another device. It happens to be that we treat VGA
device memory as something that behaves like ram occassionally but
that does not make it RAM.
If we agree on that, will a pair of functions for this work?
How
On 03/31/2011 02:18 PM, Peter Maydell wrote:
On 31 March 2011 20:01, Anthony Liguorianth...@codemonkey.ws wrote:
VGA is just another device. It happens to be that we treat VGA device
memory as something that behaves like ram occassionally but that does not
make it RAM.
So, to ask a dumb
This makes the code more readable.
Also, there's a block like:
if () {
...
} else {
...
}
Split that into
if () {
...
return;
}
...
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/ide/core.c | 37 -
1 files changed, 24 insertions(+), 13
This commit could be split further; but the main thing it does is
implement this command. Linux kernels (at least upto 2.6.38.2) need a
fix to the media change handling to recognise size changes.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/ide/core.c | 138
After a media change, the only commands allowed from the guest were
REQUEST_SENSE and INQUIRY. The guest may also issue
GET_EVENT_STATUS_NOTIFICATION and TEST_UNIT_READY commands to get media
changed notification. Enable those commands.
After this, the HSM violation messages from Linux guests
On Thu, Mar 31, 2011 at 02:26:59PM -0500, Anthony Liguori wrote:
On 03/31/2011 02:07 PM, Michael S. Tsirkin wrote:
Just needs some love.
VGA is just another device. It happens to be that we treat VGA
device memory as something that behaves like ram occassionally but
that does not make it
On 31 March 2011 20:29, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/31/2011 02:18 PM, Peter Maydell wrote:
So, to ask a dumb question, what does make something RAM?
It's a made up concept that we use to make device performance faster.
Basically, RAM should include all of the memory
On 03/31/2011 03:03 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 02:26:59PM -0500, Anthony Liguori wrote:
On 03/31/2011 02:07 PM, Michael S. Tsirkin wrote:
Just needs some love.
VGA is just another device. It happens to be that we treat VGA
device memory as something that behaves
On 03/31/2011 03:12 PM, Peter Maydell wrote:
On 31 March 2011 20:29, Anthony Liguorianth...@codemonkey.ws wrote:
On 03/31/2011 02:18 PM, Peter Maydell wrote:
So, to ask a dumb question, what does make something RAM?
It's a made up concept that we use to make device performance faster.
In the current migration code, bandwidth is estimated by measuring the
time spent in the ram_save_block loop and dividing by the number of sent
bytes. However, because of buffering, the time spent in this loop is
usually much less than the actual time required to send data on the
wire. Try to
MDI control is a 32 bit register, but may be read or written using
8 or 16 bit access. Data is latched when the MSB is written.
Add support for byte/word read/write access.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c | 34 --
1 files
The packet data part of this structure was only used to calculate
the size of the preceding data. This can be simplified.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
Like other Intel devices, e100 (eepro100) uses little endian byte order.
This patch was tested with these combinations:
i386 host, i386 + mipsel guests (le-le)
mipsel host, i386 guest (le-le)
i386 host, mips + ppc guests (le-be)
mips host, i386 guest (be-le)
mips and mipsel hosts were emulated
pointer is a 32 bit register, but may be written using 8 or 16 bit writes.
Add support for byte/word writes.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c | 33 -
1 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/hw/eepro100.c
QEMU sends frames smaller than 60 bytes to ethernet nics.
This should be fixed in the networking code because normally
such frames are rejected by real NICs and their emulations.
To avoid this behaviour, other NIC emulations pad received
frames. This patch enables this workaround for eepro100,
The general control register is a byte register.
Add support for byte reads.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 2332556..b51e391 100644
---
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index b51e391..500a3af 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1429,6 +1429,10 @@ static uint32_t
When DEBUG_EEPRO100 was enabled, unsupported writes were logged twice.
Now logging in eepro100_write1 and eepro100_write2 is similar to the
logging in eepro100_write4 (which already was correct).
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c | 14 +-
1 files
These patches clean some parts of the code, improve the code for
big endian hosts and guests, and add some more control / status
register access methods.
They also add the usual workaround for non-standard short frames
which are generated by QEMU's current networking code.
The new register
port is a 32 bit register, but may be written using 8 or 16 bit writes.
Add support for byte/word writes.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
On 03/31/2011 09:13 AM, Avishay Traeger wrote:
The current bandwidth calculation looks like this:
(block_mig_state.reads * BLOCK_SIZE)/ block_mig_state.total_time
total_time is currently the sum of the read request latencies. This is
not very accurate because block migration uses aio and so
Some recently added new code did not compile for w32 targets.
The functions qemu_iohandler_fill and qemu_iohandler_poll need
data type fd_set which is declared in winsock2.h for w32 targets.
Moving the functions from qemu-common.h to qemu_socket.h fixes
compilations for w32 without adding a new
On Thu, Mar 31, 2011 at 02:29:50PM -0500, Anthony Liguori wrote:
On 03/31/2011 02:18 PM, Peter Maydell wrote:
On 31 March 2011 20:01, Anthony Liguorianth...@codemonkey.ws wrote:
VGA is just another device. It happens to be that we treat VGA device
memory as something that behaves like ram
On 31 March 2011 21:23, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/31/2011 03:12 PM, Peter Maydell wrote:
Well, obviously you need to be able to revoke the permission
to use the fastpath pointer to the underlying memory. But you
need to be able to do that anyhow, to cover cases where
On 03/31/2011 04:26 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 02:29:50PM -0500, Anthony Liguori wrote:
On 03/31/2011 02:18 PM, Peter Maydell wrote:
On 31 March 2011 20:01, Anthony Liguorianth...@codemonkey.ws wrote:
VGA is just another device. It happens to be that we treat VGA
On Thu, Mar 31, 2011 at 04:32:44PM -0500, Anthony Liguori wrote:
On 03/31/2011 04:26 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 02:29:50PM -0500, Anthony Liguori wrote:
On 03/31/2011 02:18 PM, Peter Maydell wrote:
On 31 March 2011 20:01, Anthony Liguorianth...@codemonkey.ws wrote:
On Thu, Mar 31, 2011 at 10:32:11PM +0100, Peter Maydell wrote:
On 31 March 2011 21:23, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/31/2011 03:12 PM, Peter Maydell wrote:
Well, obviously you need to be able to revoke the permission
to use the fastpath pointer to the underlying memory.
On Thu, Mar 31, 2011 at 10:33:30PM +0200, Stefan Weil wrote:
QEMU sends frames smaller than 60 bytes to ethernet nics.
This should be fixed in the networking code because normally
such frames are rejected by real NICs and their emulations.
To avoid this behaviour, other NIC emulations pad
On 03/31/2011 04:37 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 04:32:44PM -0500, Anthony Liguori wrote:
On 03/31/2011 04:26 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 02:29:50PM -0500, Anthony Liguori wrote:
On 03/31/2011 02:18 PM, Peter Maydell wrote:
On 31 March 2011
On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
That seems like a clearer API, yes. I think it makes it much more
obvious what it's trying to achieve.
-- PMM
Maybe register_dma_area - its' not 100% virtio specific.
It's never been clear to me whether that's true or not. I've heard
On Thu, Mar 31, 2011 at 10:33:24PM +0200, Stefan Weil wrote:
Like other Intel devices, e100 (eepro100) uses little endian byte order.
This patch was tested with these combinations:
i386 host, i386 + mipsel guests (le-le)
mipsel host, i386 guest (le-le)
i386 host, mips + ppc guests (le-be)
On Thu, Mar 31, 2011 at 04:49:46PM -0500, Anthony Liguori wrote:
On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
That seems like a clearer API, yes. I think it makes it much more
obvious what it's trying to achieve.
-- PMM
Maybe register_dma_area - its' not 100% virtio specific.
It's
On 03/31/2011 06:42 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 04:49:46PM -0500, Anthony Liguori wrote:
On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
That seems like a clearer API, yes. I think it makes it much more
obvious what it's trying to achieve.
-- PMM
Maybe
On Thu, Mar 31, 2011 at 07:44:35PM -0500, Anthony Liguori wrote:
On 03/31/2011 06:42 PM, Michael S. Tsirkin wrote:
On Thu, Mar 31, 2011 at 04:49:46PM -0500, Anthony Liguori wrote:
On 03/31/2011 04:38 PM, Michael S. Tsirkin wrote:
That seems like a clearer API, yes. I think it makes it much
From: David Gibson d...@au1.ibm.com
Currently qemu_devtree_setprop() expects the new property value to be
given as a uint32_t *. While property values consisting of u32s are
common, in general they can have any bytestring value.
Therefore, this patch alters the function to take a void *
PowerPC and POWER chips since the POWER4 and 970 have a special
hypervisor mode, and a corresponding form of the system call
instruction which traps to the hypervisor.
qemu currently has stub implementations of hypervisor mode. That
is, the outline is there to allow qemu to run a PowerPC
This patch series adds a pseries machine to qemu, allowing it to
emulate IBM pSeries logical partitions. More specifically it
implements the interface defined by the PowerPC Architecture Platform
Requirements document (PAPR, or sPAPR for short).
Along the way we add a bunch of support for more
Currently the SLB information when emulating a PowerPC 970 is
storeed in a structure with the unhelpfully named fields 'tmp'
and 'tmp64'. While the layout in these fields does match the
description of the SLB in the architecture document, it is not
convenient either for looking up the SLB, or for
For a 64-bit PowerPC target, qemu correctly implements translation
through the segment lookaside buffer. Likewise it supports the
slbmte instruction which is used to load entries into the SLB.
However, it does not emulate the slbmfee and slbmfev instructions
which read SLB entries back into
This adds emulation support for the recent POWER7 cpu to qemu. It's far
from perfect - it's missing a number of POWER7 features so far, including
any support for VSX or decimal floating point instructions. However, it's
close enough to boot a kernel with the POWER7 PVR.
Signed-off-by: David
Currently, get_segment() has a variable called hash. However it doesn't
(quite) get the hash value for the ppc hashed page table. Instead it
gets the hash shifted - effectively the offset of the hash bucket within
the hash page table.
As well, as being different to the normal use of plain hash
On pSeries machines, operating systems can instantiate RTAS (Run-Time
Abstraction Services), a runtime component of the firmware which implements
a number of low-level, infrequently used operations. On logical partitions
under a hypervisor, many of the RTAS functions require hypervisor
privilege.
Traditionally, the segments used for the two-stage translation used on
powerpc MMUs were 256MB in size. This was the only option on all hash
page table based 32-bit powerpc cpus, and on the earlier 64-bit hash page
table based cpus. However, newer 64-bit cpus also permit 1TB segments
This patch
From: David Gibson d...@au1.ibm.com
qemu already includes support for the popcntb instruction introduced
in POWER5 (although it doesn't actually allow you to choose POWER5).
However, the logic is slightly incorrect: it will generate results
truncated to 32-bits when the CPU is in 32-bit mode.
This patch adds infrastructure to support interrupts from PAPR virtual IO
devices. This includes correctly advertising those interrupts in the
device tree, and implementing the H_VIO_SIGNAL hypercall, used to
enable and disable individual device interrupts.
Signed-off-by: David Gibson
The PURR (Processor Utilization Resource Register) is a register found
on recent POWER CPUs. The guts of implementing it at least enough to
get by are already present in qemu, however some of the helper
functions needed to actually wire it up are missing.
This patch adds the necessary glue, so
This patch adds several small utility hypercalls and RTAS methods to
the pSeries platform emulation. Specifically:
* 'display-character' rtas call
This just prints a character to the console, it's occasionally used
for early debug of the OS. The support includes a hack to make this
RTAS call
On ppc machines with hash table MMUs, the special purpose register SDR1
contains both the base address of the encoded size (hashed) page tables.
At present, we interpret the SDR1 value within the address translation
path. But because the encodings of the size for 32-bit and 64-bit are
different
PAPR defines an interrupt control architecture which is logically divided
into ICS (Interrupt Control Presentation, each unit is responsible for
presenting interrupts to a particular interrupt server, i.e. CPU) and
ICS (Interrupt Control Source, each unit responsible for one or more
hardware
This patch implements the PAPR specified Inter Virtual Machine Logical
LAN; that is the virtual hardware used by the Linux ibmveth driver.
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: David Gibson d...@au1.ibm.com
---
Makefile.target |2 +-
hw/spapr.c | 19 ++
On pSeries logical partitions, excepting the old POWER4-style full system
partitions, the guest does not have direct access to the hardware page
table. Instead, the pagetable exists in hypervisor memory, and the guest
must manipulate it with hypercalls.
However, our current pSeries emulation
1 - 100 of 110 matches
Mail list logo
