On Wed, Sep 8, 2010 at 1:55 AM, Blue Swirl wrote:
> On Tue, Sep 7, 2010 at 2:43 AM, Amos Kong wrote:
>>
>> kvm upstream: 43e413f7db1a4a90671dda0b1d6c1f8cb30673ed KVM: Whitespace
>> changes to remove differences wrt kvm-updates/2.6.37
>> qemu upstream: cb93bbdd7db92e50ff5e60a346b23df68acae46b Fix
On Tue, Sep 07, 2010 at 10:43:38AM +0800, Amos Kong wrote:
> -- Forwarded message --
> From: Amos Kong
> Date: Tue, Sep 7, 2010 at 7:49 AM
> Subject: Guest hangs when I do general operation.
> To: 王箫
>
>
> kvm upstream: 43e413f7db1a4a90671dda0b1d6c1f8cb30673ed KVM: Whitespace
>
On Wed, 8 Sep 2010, Alexander Graf wrote:
>
> On 08.09.2010, at 00:48, malc wrote:
>
> > On Wed, 8 Sep 2010, Andreas F?rber wrote:
> >
> >> Am 07.09.2010 um 23:36 schrieb Alexander Graf:
> >>
> >>> On 07.09.2010, at 23:17, Andreas F?rber wrote:
> >>>
> Am 07.09.2010 um 13:53 schrieb Alex
From: Cam Macdonell
* Cam Macdonell (c...@cs.ualberta.ca) wrote:
> It seems it was the alignment value being passed back from
> pci_resource_alignment(). The return type is an int, which was
> causing value of 2GB to be sign extended to to 0x8000.
> Changing the return type to resour
It seems it was the alignment value being passed back from
pci_resource_alignment(). The return type is an int, which was
causing value of 2GB to be sign extended to to 0x8000.
Changing the return type to resource_size_t allows BAR values >= 2GB
to be successfully assigned.
diff --git
On 08.09.2010, at 00:48, malc wrote:
> On Wed, 8 Sep 2010, Andreas F?rber wrote:
>
>> Am 07.09.2010 um 23:36 schrieb Alexander Graf:
>>
>>> On 07.09.2010, at 23:17, Andreas F?rber wrote:
>>>
Am 07.09.2010 um 13:53 schrieb Alexander Graf:
> Since nobody else seems interested in m
On Wed, 8 Sep 2010, Andreas F?rber wrote:
> Am 07.09.2010 um 23:36 schrieb Alexander Graf:
>
> > On 07.09.2010, at 23:17, Andreas F?rber wrote:
> >
> > > Am 07.09.2010 um 13:53 schrieb Alexander Graf:
> > >
> > > > Since nobody else seems interested in maintaining PPC, let's change the
> > > >
On Tue, Sep 07, 2010 at 05:29:53PM -0500, Anthony Liguori wrote:
> If it were just one bit for just raw or not raw, wouldn't that be enough?
>
> Everything that isn't raw can be probed reliably so we really only need
> to distinguish between things that are probe-able and things that are
> not p
On 09/07/2010 04:35 PM, Christoph Hellwig wrote:
On Tue, Sep 07, 2010 at 11:12:15AM -0500, Anthony Liguori wrote:
IOW, what are valid values for backing_fmt? "raw" and "qed" are obvious
but what does it mean from a formal specification perspective to have
"vmdk"? Is that VMDK v3 or v4, wha
On 09/07/2010 11:25 AM, Anthony Liguori wrote:
On 09/07/2010 11:09 AM, Avi Kivity wrote:
On 09/07/2010 06:40 PM, Anthony Liguori wrote:
Need a checksum for the header.
Is that not a bit overkill for what we're doing? What's the benefit?
Make sure we're not looking at a header write inter
Am 07.09.2010 um 23:36 schrieb Alexander Graf:
On 07.09.2010, at 23:17, Andreas Färber wrote:
Am 07.09.2010 um 13:53 schrieb Alexander Graf:
Since nobody else seems interested in maintaining PPC, let's
change the
maintainer to myself. I keep a staging tree anyways and am
probably the
per
On 07.09.2010, at 23:17, Andreas Färber wrote:
> Am 07.09.2010 um 13:53 schrieb Alexander Graf:
>
>> Since nobody else seems interested in maintaining PPC, let's change the
>> maintainer to myself. I keep a staging tree anyways and am probably the
>> person touching most of that code these days.
On Tue, Sep 07, 2010 at 11:12:15AM -0500, Anthony Liguori wrote:
> IOW, what are valid values for backing_fmt? "raw" and "qed" are obvious
> but what does it mean from a formal specification perspective to have
> "vmdk"? Is that VMDK v3 or v4, what if there's a v5?
It might be better to just u
On 07.09.2010, at 20:21, Blue Swirl wrote:
> On Tue, Sep 7, 2010 at 11:53 AM, Alexander Graf wrote:
>> The e500 PCI controller isn't qdev'ified yet. This leads to severe issues
>> when running with -drive.
>>
>> To be able to use a virtio disk with an e500 VM, let's convert the PCI
>> controlle
Am 07.09.2010 um 13:53 schrieb Alexander Graf:
Since nobody else seems interested in maintaining PPC, let's change
the
maintainer to myself. I keep a staging tree anyways and am probably
the
person touching most of that code these days.
This changes the maintainer entry for working ppc targ
On 09/07/2010 02:25 PM, Blue Swirl wrote:
On Mon, Sep 6, 2010 at 10:04 AM, Stefan Hajnoczi
wrote:
QEMU Enhanced Disk format is a disk image format that forgoes features
found in qcow2 in favor of better levels of performance and data
integrity. Due to its simpler on-disk layout, it is pos
On Mon, Sep 6, 2010 at 10:04 AM, Stefan Hajnoczi
wrote:
> QEMU Enhanced Disk format is a disk image format that forgoes features
> found in qcow2 in favor of better levels of performance and data
> integrity. Due to its simpler on-disk layout, it is possible to safely
> perform metadata updates m
On Tue, Sep 7, 2010 at 12:31 PM, john cooper wrote:
> Failure by qemu to open a default config file isn't cause to
> error exit -- it just quietly continues on. After puzzling
> issues with otherwise opaque config file locations and
> startup handling numerous times, some help from qemu seemed
>
A lot of folks tend to reply to patches and suggest them for stable
which is certainly appreciated but is very difficult for me to track
reliably.
So here's another way to nominate a patch for inclusion in -stable:
http://wiki.qemu.org/Releases/0.13.0
Just copy/paste the template and fill out
On Tue, Sep 7, 2010 at 11:53 AM, Alexander Graf wrote:
> The e500 PCI controller isn't qdev'ified yet. This leads to severe issues
> when running with -drive.
>
> To be able to use a virtio disk with an e500 VM, let's convert the PCI
> controller over to qdev.
>
> Signed-off-by: Alexander Graf
>
On Tue, Sep 7, 2010 at 2:43 AM, Amos Kong wrote:
> -- Forwarded message --
> From: Amos Kong
> Date: Tue, Sep 7, 2010 at 7:49 AM
> Subject: Guest hangs when I do general operation.
> To: 王箫
>
>
> kvm upstream: 43e413f7db1a4a90671dda0b1d6c1f8cb30673ed KVM: Whitespace
> changes to
Hi Anthony,
The tx timer patches seem to be very stable, and generally a good cleanup,
and there's a fallback flag to get the old behaviour, so if there are
regressions it will be easy for people to diagnose.
Mergeable buffer support has been out for a long while with no comments.
e1000 patch is ve
On Tue, Aug 24, 2010 at 09:27:41PM +0800, Ken CC wrote:
> If pci addr provided from command line is bigger than 32,
> PCIBUS_MAX_DEVICES, return error -EINVAL.
>
> 32 << 3 | 7 == 256 (PCIBUS_MAX_FUNCTIONS)
> PCIBUS_MAX_FUNCTIONS = PCIBUS_MAX_DEVICES * PCI_FUNCTIONS_PER_DEVICE
Not really sure what
On Tue, Sep 07, 2010 at 11:50:38AM +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > Patch b0b900070c7cb29bbefb732ec00397abe5de6d73 made
> > TOR valuer incorrect: the spec says it should always
> > include the CRC field.
> > No one seems to use this field, but better to stick to spec.
On Tue, Aug 24, 2010 at 09:27:10PM +0800, Ken CC wrote:
> Check if devfn < PCIBUS_MAX_DEVICES * PCI_FUNCTIONS_PER_DEVICE
>
> Signed-off-by: Ken CC
> ---
> hw/pci.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index 9234fe3..fc4becd 100644
>
On Tue, Aug 24, 2010 at 09:28:11PM +0800, Ken CC wrote:
> PCI_FUNC_MAX is introduced by
> 6eab3de16d36c48a983366b09d0a0029a5260bc3
> and
> 6fa84913eccec4266a27c81ae88465f6790742b9
> which should be safe to rename to PCI_FUNCTIONS_PER_DEVICES.
>
> Signed-off-by: Ken CC
I liked the shorter name be
On Tue, Aug 24, 2010 at 09:25:26PM +0800, Ken CC wrote:
> And update the max function number used in struct PCIBus{} to
> PCIBUS_MAX_FUNCTIONS = PCI_FUNCTIONS_PER_DEVICE * PCIBUS_MAX_DEVICES
>
> TODO:
> according to Avi Kivity, PCIBus.devices[] should be renamed to functions[]
>
> Signed-off-
On Mon, Sep 06, 2010 at 04:46:14PM +0900, Isaku Yamahata wrote:
> This patch series implements pcie port switch emulators
> which is basic part for pcie/q35 support.
> This is for mst/pci tree.
>
> some random comments
> - pci bus reset
> As Anthony is cleaning up qdev reset stuff, so pci bus re
Bruno Cesar Ribas wrote:
> On Thu, Aug 26, 2010 at 09:44:32AM -0700, Venkateswararao Jujjuri (JV) wrote:
>> Bruno Cesar Ribas wrote:
>>> Hi,
>>>
>> [snip]
>> This quick test is with QEMU patches that are on mailing lists but not merged
>> into mainline.
>> Being said that, I don't think they really
hello, all
I am trying to configure a Shared-ISA multi-core architecture, and I
just configure the cpu_model with two different types,
one is core2duo, the other one is pentium3. ( some instruction set is
not supporting in pentium3 )
then I verify this architecture with a simple program that I exp
On 09/07/2010 11:09 AM, Avi Kivity wrote:
On 09/07/2010 06:40 PM, Anthony Liguori wrote:
Need a checksum for the header.
Is that not a bit overkill for what we're doing? What's the benefit?
Make sure we're not looking at a header write interrupted by a crash.
Couldn't hurt I guess. I d
On 09/07/2010 09:51 AM, Avi Kivity wrote:
/* if (features & QED_F_BACKING_FILE) */
uint32_t backing_file_offset; /* in bytes from start of header */
uint32_t backing_file_size; /* in bytes */
It's really the filename size, not the file size. Also, make a note
that it is not z
On 07/09/2010 13:10, Riku Voipio wrote:
On Tue, Sep 07, 2010 at 12:17:16PM +0200, Andrea Galeazzi wrote:
it seems that also maemo developers give up the beagleboard emulation,
so does anybody know anything about the progress status of the emulation
of it? Is still anyone working on it or doe
On 09/07/2010 06:40 PM, Anthony Liguori wrote:
Need a checksum for the header.
Is that not a bit overkill for what we're doing? What's the benefit?
Make sure we're not looking at a header write interrupted by a crash.
The L2 link '''should''' be made after the data is in place on
stora
On 09/07/2010 10:39 AM, Kevin Wolf wrote:
Am 07.09.2010 17:30, schrieb Anthony Liguori:
On 09/07/2010 10:20 AM, Kevin Wolf wrote:
Am 07.09.2010 17:11, schrieb Anthony Liguori:
Copy-on-read is, in many cases, a property of the backing file because
it suggests that the backing
On 09/07/2010 09:51 AM, Avi Kivity wrote:
I'll let Stefan address most of this.
uint32_t first_cluster; /* in clusters */
First cluster of what?
This should probably be header_size /* in clusters */ because that's
what it really means.
Need a checksum for the header.
Is th
Am 07.09.2010 17:30, schrieb Anthony Liguori:
> On 09/07/2010 10:20 AM, Kevin Wolf wrote:
>> Am 07.09.2010 17:11, schrieb Anthony Liguori:
>>> Copy-on-read is, in many cases, a property of the backing file because
>>> it suggests that the backing file is either very slow or potentially
>>> volatile
On 09/07/2010 10:20 AM, Kevin Wolf wrote:
Am 07.09.2010 17:11, schrieb Anthony Liguori:
On 09/07/2010 10:02 AM, Kevin Wolf wrote:
Am 07.09.2010 16:49, schrieb Anthony Liguori:
Shouldn't it be a runtime option? You can use the very same image with
copy-on-read or copy-on-writ
On 09/07/2010 10:09 AM, Stefan Hajnoczi wrote:
Right, so that argues for an incremental interface like I started with :-)
BTW, this whole discussion is also relevant for other background tasks like
online defragmentation so keep that use-case in mind too.
Right, I'm a little hesitant to g
On 09/07/2010 10:05 AM, Stefan Hajnoczi wrote:
On Tue, Sep 7, 2010 at 3:57 PM, Anthony Liguori
wrote:
On 09/07/2010 09:49 AM, Stefan Hajnoczi wrote:
On Tue, Sep 7, 2010 at 3:34 PM, Kevin Wolfwrote:
Am 07.09.2010 15:41, schrieb Anthony Liguori:
Hi,
We've go
Am 07.09.2010 17:11, schrieb Anthony Liguori:
> On 09/07/2010 10:02 AM, Kevin Wolf wrote:
>> Am 07.09.2010 16:49, schrieb Anthony Liguori:
>>
Shouldn't it be a runtime option? You can use the very same image with
copy-on-read or copy-on-write and it will behave the same (execpt for
>>
On 09/07/2010 10:03 AM, Daniel P. Berrange wrote:
On Tue, Sep 07, 2010 at 08:41:44AM -0500, Anthony Liguori wrote:
Hi,
We've got copy-on-read and image streaming working in QED and before
going much further, I wanted to bounce some interfaces off of the
libvirt folks to make sure our final
On Tue, Sep 7, 2010 at 4:00 PM, Anthony Liguori
wrote:
> On 09/07/2010 09:55 AM, Stefan Hajnoczi wrote:
>>
>> On Tue, Sep 7, 2010 at 3:51 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 09/07/2010 09:33 AM, Stefan Hajnoczi wrote:
>>>
On Tue, Sep 7, 2010 at 2:41 PM, Anthony Liguori
On 09/07/2010 10:02 AM, Kevin Wolf wrote:
Am 07.09.2010 16:49, schrieb Anthony Liguori:
Shouldn't it be a runtime option? You can use the very same image with
copy-on-read or copy-on-write and it will behave the same (execpt for
performance), so it's not an inherent feature of the image file
On Tue, Sep 07, 2010 at 08:41:44AM -0500, Anthony Liguori wrote:
> Hi,
>
> We've got copy-on-read and image streaming working in QED and before
> going much further, I wanted to bounce some interfaces off of the
> libvirt folks to make sure our final interface makes sense.
>
> Here's the basic
On Tue, Sep 7, 2010 at 3:57 PM, Anthony Liguori
wrote:
> On 09/07/2010 09:49 AM, Stefan Hajnoczi wrote:
>>
>> On Tue, Sep 7, 2010 at 3:34 PM, Kevin Wolf wrote:
>>
>>>
>>> Am 07.09.2010 15:41, schrieb Anthony Liguori:
>>>
Hi,
We've got copy-on-read and image streaming working i
On 09/07/2010 09:55 AM, Stefan Hajnoczi wrote:
On Tue, Sep 7, 2010 at 3:51 PM, Anthony Liguori
wrote:
On 09/07/2010 09:33 AM, Stefan Hajnoczi wrote:
On Tue, Sep 7, 2010 at 2:41 PM, Anthony Liguori
wrote:
The interface for copy-on-read is just an option within qemu-img
Am 07.09.2010 16:49, schrieb Anthony Liguori:
>> Shouldn't it be a runtime option? You can use the very same image with
>> copy-on-read or copy-on-write and it will behave the same (execpt for
>> performance), so it's not an inherent feature of the image file.
>>
>
> The way it's implemented i
On 09/07/2010 09:49 AM, Stefan Hajnoczi wrote:
On Tue, Sep 7, 2010 at 3:34 PM, Kevin Wolf wrote:
Am 07.09.2010 15:41, schrieb Anthony Liguori:
Hi,
We've got copy-on-read and image streaming working in QED and before
going much further, I wanted to bounce some interfaces off of the
l
On 09/07/2010 05:36 PM, Alexander Graf wrote:
Who are the maintainers to talk with? Anthony? Anybody else?
Anthony, Avi, Marcelo.
Post the patches against qemu.git, Marcelo or myself will apply them
against a staging branch (uq/master, for "upstream queue for qemu.git
master") and ask Ant
On Tue, Sep 7, 2010 at 3:51 PM, Anthony Liguori
wrote:
> On 09/07/2010 09:33 AM, Stefan Hajnoczi wrote:
>>
>> On Tue, Sep 7, 2010 at 2:41 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> The interface for copy-on-read is just an option within qemu-img create.
>>> Streaming, on the other hand, requires
On 09/06/2010 04:06 PM, Anthony Liguori wrote:
Another point worth mentioning is that our intention is to have a
formal specification of the format before merging. A start of that is
located at http://wiki.qemu.org/Features/QED
=Specification=
The file format looks like this:
+--
On 09/07/2010 09:34 AM, Kevin Wolf wrote:
Am 07.09.2010 15:41, schrieb Anthony Liguori:
Hi,
We've got copy-on-read and image streaming working in QED and before
going much further, I wanted to bounce some interfaces off of the
libvirt folks to make sure our final interface makes sense.
Her
On Tue, Sep 07, 2010 at 09:51:33AM -0400, Avi Kivity wrote:
> On 09/07/2010 03:23 PM, Alexander Graf wrote:
> >
> > I think we should get rid of kvm_nested and -enable-nesting. Instead, we
> > should enable the SVM bit in the "host" and "qemu64" cpu types, but not in
> > "kvm64". This way users
On 09/07/2010 09:33 AM, Stefan Hajnoczi wrote:
On Tue, Sep 7, 2010 at 2:41 PM, Anthony Liguori
wrote:
The interface for copy-on-read is just an option within qemu-img create.
Streaming, on the other hand, requires a bit more thought. Today, I have a
monitor command that does the followi
On Tue, Sep 7, 2010 at 3:34 PM, Kevin Wolf wrote:
> Am 07.09.2010 15:41, schrieb Anthony Liguori:
>> Hi,
>>
>> We've got copy-on-read and image streaming working in QED and before
>> going much further, I wanted to bounce some interfaces off of the
>> libvirt folks to make sure our final interface
On 07.09.2010, at 16:33, Roedel, Joerg wrote:
> On Tue, Sep 07, 2010 at 10:22:21AM -0400, Alexander Graf wrote:
>>
>> On 07.09.2010, at 16:20, Roedel, Joerg wrote:
>>
>>> On Tue, Sep 07, 2010 at 10:16:10AM -0400, Alexander Graf wrote:
Oh, because this is for qemu-kvm. Uh - how about a nice
On 09/07/2010 09:30 AM, Chris Wright wrote:
0.13 schedule
- RSN
- rc1 uploaded, tagged in git (and tag should actually be there now)
- announcement once it propagates
- 0.13.0 should be 1 week after rc1 announcement
- please check rc1 for any missing critical patches
qed
- concession that qcow2
On Tue, Sep 07, 2010 at 10:22:21AM -0400, Alexander Graf wrote:
>
> On 07.09.2010, at 16:20, Roedel, Joerg wrote:
>
> > On Tue, Sep 07, 2010 at 10:16:10AM -0400, Alexander Graf wrote:
> >> Oh, because this is for qemu-kvm. Uh - how about a nice little patch
> >> that makes things work in qemu.git
Am 07.09.2010 15:41, schrieb Anthony Liguori:
> Hi,
>
> We've got copy-on-read and image streaming working in QED and before
> going much further, I wanted to bounce some interfaces off of the
> libvirt folks to make sure our final interface makes sense.
>
> Here's the basic idea:
>
> Today, y
On Tue, Sep 7, 2010 at 2:41 PM, Anthony Liguori
wrote:
> The interface for copy-on-read is just an option within qemu-img create.
> Streaming, on the other hand, requires a bit more thought. Today, I have a
> monitor command that does the following:
>
> stream
>
> Which will try to stream the
On 09/07/2010 09:01 AM, Alexander Graf wrote:
I'm torn here too. Why not expose both? Have a qemu internal daemon available that gets a
sleep time as parameter and an external "pull sectors" command. We'll see which
one is more useful, but I don't think it's too much code to justify only having
0.13 schedule
- RSN
- rc1 uploaded, tagged in git (and tag should actually be there now)
- announcement once it propagates
- 0.13.0 should be 1 week after rc1 announcement
- please check rc1 for any missing critical patches
qed
- concession that qcow2 is complicated and hard to get right
- it's mu
On 07.09.2010, at 16:12, Roedel, Joerg wrote:
> On Tue, Sep 07, 2010 at 09:51:33AM -0400, Avi Kivity wrote:
>> On 09/07/2010 03:23 PM, Alexander Graf wrote:
>>>
>>> I think we should get rid of kvm_nested and -enable-nesting. Instead, we
>>> should enable the SVM bit in the "host" and "qemu64"
On 07.09.2010, at 16:20, Roedel, Joerg wrote:
> On Tue, Sep 07, 2010 at 10:16:10AM -0400, Alexander Graf wrote:
>> Oh, because this is for qemu-kvm. Uh - how about a nice little patch
>> that makes things work in qemu.git, leave out the -enable-nesting
>> piece and just keep the -enable-nesting b
On Tue, Sep 07, 2010 at 10:16:10AM -0400, Alexander Graf wrote:
> Oh, because this is for qemu-kvm. Uh - how about a nice little patch
> that makes things work in qemu.git, leave out the -enable-nesting
> piece and just keep the -enable-nesting backwards compat patch in
> qemu-kvm.git - or maybe ev
On Tue, Sep 07, 2010 at 10:14:46AM -0400, Alexander Graf wrote:
>
> On 07.09.2010, at 16:12, Roedel, Joerg wrote:
>
> > On Tue, Sep 07, 2010 at 09:51:33AM -0400, Avi Kivity wrote:
> >> On 09/07/2010 03:23 PM, Alexander Graf wrote:
> >>>
> >>> I think we should get rid of kvm_nested and -enable-
On 07.09.2010, at 16:12, Roedel, Joerg wrote:
> On Tue, Sep 07, 2010 at 09:51:33AM -0400, Avi Kivity wrote:
>> On 09/07/2010 03:23 PM, Alexander Graf wrote:
>>>
>>> I think we should get rid of kvm_nested and -enable-nesting. Instead, we
>>> should enable the SVM bit in the "host" and "qemu64"
On Tue, Sep 07, 2010 at 08:59:52AM -0400, Avi Kivity wrote:
> On 09/07/2010 03:55 PM, Alexander Graf wrote:
> >
> >> Was it broken? How?
> > When migrating inside l2 context, we're missing information. My idea back
> > then was to force the l1 guest out of l2 context every time we want to
> >
On 07.09.2010, at 15:41, Anthony Liguori wrote:
> Hi,
>
> We've got copy-on-read and image streaming working in QED and before going
> much further, I wanted to bounce some interfaces off of the libvirt folks to
> make sure our final interface makes sense.
>
> Here's the basic idea:
>
> Toda
On 09/06/2010 01:04 PM, Stefan Hajnoczi wrote:
QEMU Enhanced Disk format is a disk image format that forgoes features
found in qcow2 in favor of better levels of performance and data
integrity. Due to its simpler on-disk layout, it is possible to safely
perform metadata updates more efficiently
On 09/07/2010 03:23 PM, Alexander Graf wrote:
I think we should get rid of kvm_nested and -enable-nesting. Instead, we should enable the SVM bit in the
"host" and "qemu64" cpu types, but not in "kvm64". This way users are safe to
not use nested svm, but can choose to do so if they like.
Also
Hi,
We've got copy-on-read and image streaming working in QED and before
going much further, I wanted to bounce some interfaces off of the
libvirt folks to make sure our final interface makes sense.
Here's the basic idea:
Today, you can create images based on base images that are copy on
wr
On 09/07/2010 03:55 PM, Alexander Graf wrote:
Was it broken? How?
When migrating inside l2 context, we're missing information. My idea back then
was to force the l1 guest out of l2 context every time we want to migrate, but
I'm not sure this has happened.
I thought that was implemented,
On 07.09.2010, at 14:43, Avi Kivity wrote:
> On 09/07/2010 03:37 PM, Alexander Graf wrote:
>>
>>> Why do you lost migration?
>> Is that part fixed already? Joerg worked so hard on so many things that I
>> lost track of what works and what doesn't :).
>
> Was it broken? How?
When migrating in
On 09/07/2010 03:37 PM, Alexander Graf wrote:
Why do you lost migration?
Is that part fixed already? Joerg worked so hard on so many things that I lost
track of what works and what doesn't :).
Was it broken? How?
--
error compiling committee.c: too many arguments to function
This series is a synopsis of several patches correcting
problems found during use and test of the cpu model config
definitions, and usability in general.
Please review and apply.
-john
--
john.coo...@redhat.com
On 07.09.2010, at 14:35, Avi Kivity wrote:
> On 09/07/2010 03:33 PM, Alexander Graf wrote:
>>
>>> I agree that its much nicer for mgmt tools if svm/vmx CPU flags can just be
>>> toggled in the normal manner. Might we also want to have a enable/disable
>>> nesting flag, so we can mirror the way r
On 09/07/2010 03:33 PM, Alexander Graf wrote:
I agree that its much nicer for mgmt tools if svm/vmx CPU flags can just be
toggled in the normal manner. Might we also want to have a enable/disable
nesting flag, so we can mirror the way real hardware lets you disable virt
in the BIOS even when t
On 07.09.2010, at 14:30, Daniel P. Berrange wrote:
> On Tue, Sep 07, 2010 at 02:23:55PM +0200, Alexander Graf wrote:
>>
>> On 07.09.2010, at 13:27, Joerg Roedel wrote:
>>
>>> This patch changes the setting logic for the svm bit in
>>> qemu-kvm. The bit is now explicitly set on -enable-nesting
>
Hi
I tried to add a device to guest from upstream qemu monitor using
"device_add".
when i try to add VGA, vmware-svga..etc, from qemu monitor my qemu
monitor is aborted, Since these devices already registered.
I dont see a reason to kill monitor. I think abort() is a bit rough.
we need a bette
Add kvm emulated x2apic flag to config defined cpu models
and general support for such hypervisor emulated flags.
In addition to checking user request flags against the host
we also selectively check against kvm for emulated flags.
Signed-off-by: john cooper
---
diff --git a/hw/pc.c b/hw/pc.c
i
Allow an optional qemu_early_init_vcpu() such that
kvm_arch_get_supported_cpuid() can be used from
cpu_x86_register(). Without this minimal setup
kvm_arch_get_supported_cpuid() gags kvm_ioctl() via
passing a NULL initialized KVMState *.
Signed-off-by: john cooper
---
diff --git a/cpus.c b/cpus.
Failure by qemu to open a default config file isn't cause to
error exit -- it just quietly continues on. After puzzling
issues with otherwise opaque config file locations and
startup handling numerous times, some help from qemu seemed
justified.
In the case of a "?" pseudo filename arg to -readc
Correct archaic CPU model "model" field for Intel CPUs.
The old "model" values caused two known problems:
- Skype crashes on a winxp guest if model < 6, due to syscall vs.
sysenter confusion.
- 32 bit windows doesn't enable MSI support if model < 13.
After consulting wi
On Tue, Sep 07, 2010 at 02:23:55PM +0200, Alexander Graf wrote:
>
> On 07.09.2010, at 13:27, Joerg Roedel wrote:
>
> > This patch changes the setting logic for the svm bit in
> > qemu-kvm. The bit is now explicitly set on -enable-nesting
> > instead of masked out if the parameter is not supplied.
On 07.09.2010, at 13:27, Joerg Roedel wrote:
> This patch changes the setting logic for the svm bit in
> qemu-kvm. The bit is now explicitly set on -enable-nesting
> instead of masked out if the parameter is not supplied.
>
> Signed-off-by: Joerg Roedel
> ---
> target-i386/cpuid.c | 12 ++
Recenty a patch was committed to protect the first four bytes of an image to
avoid "converting" a probed raw image to a different format when a malicious
guest writes e.g. a qcow2 header to it.
This check relies on the assumption that all qiov entries are multiples of 512,
which isn't true in prac
Since nobody else seems interested in maintaining PPC, let's change the
maintainer to myself. I keep a staging tree anyways and am probably the
person touching most of that code these days.
This changes the maintainer entry for working ppc targets to myself.
Signed-off-by: Alexander Graf
---
MA
I would really appriciate if these would also make it for 0.13. Should I
create a separate pull tree for that?
The following changes since commit ba5e7f82169f32ab8163c707d97c799ca09f8924:
Izumi Tsutsui (1):
vnc: use bswapNN() rather than bswap_NN()
are available in the git repository at
This patch changes the setting logic for the svm bit in
qemu-kvm. The bit is now explicitly set on -enable-nesting
instead of masked out if the parameter is not supplied.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
di
The e500 PCI controller isn't qdev'ified yet. This leads to severe issues
when running with -drive.
To be able to use a virtio disk with an e500 VM, let's convert the PCI
controller over to qdev.
Signed-off-by: Alexander Graf
---
hw/ppce500_pci.c | 106 +
This patch adds the svm cpuid feature flags to the qemu
intialization path.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h |1 +
target-i386/cpuid.c | 50 +-
target-i386/kvm.c |3 +++
3 files changed, 45 insertions(+), 9 deletions(
The config data field on the e500 pci controller is in little endian, so we need
to enable byte swap there.
Signed-off-by: Alexander Graf
---
hw/ppce500_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 3fa42d2..629b242 1006
KVM on PowerPC used to have completely broken interrupt logic. Usually,
interrupts work by having a PIC that pulls a line up/down, so the CPU knows
that an interrupt is active. This line stays active until some action is
done to the PIC to release the line.
On KVM for PPC, we just checked if there
Hi,
this patch-set adds the svm cpuid feature flags to qemu-kvm. With this
patch-set the npt feature-flag can be presented to the guest so that it will
use nested-paging when emulated by the host kvm. Please review, comment and/or
apply these patches :-)
Thanks,
Joerg
This patch cleans the (stack-allocated) cpuid definition to
0 before actually initializing it.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 5fa0dd0..5735795 100644
---
On Tue, Sep 07, 2010 at 12:17:16PM +0200, Andrea Galeazzi wrote:
> it seems that also maemo developers give up the beagleboard emulation,
> so does anybody know anything about the progress status of the emulation
> of it? Is still anyone working on it or does the community aim to
> include it
On Sep 7, 2010, at 12:22 PM, Alexander Graf wrote:
>
> On 07.09.2010, at 09:38, Tristan Gingold wrote:
>
>>
>> On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:
>>
>>> Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
>>>
On 09/05/2010 10:10 AM, Avi Kivity wrote:
>> As a baby step, i
On 07.09.2010, at 09:38, Tristan Gingold wrote:
>
> On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:
>
>> Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
>>
>>> On 09/05/2010 10:10 AM, Avi Kivity wrote:
> As a baby step, is there any chance of publishing an automatic nightly
> Windo
1 - 100 of 110 matches
Mail list logo
