On Thu, 7 Mar 2013 20:02:21 +0200
"Michael S. Tsirkin" wrote:
> virtio-s390 on kvm can use a cookie value passed to guest
s/virtio-s390/virtio-ccw/ (to avoid confusion with s390-virtio, which
was never specced)
> to optimize channel/VQ lookups.
> Document this.
>
> Signed-off-by: Michael S. Ts
On Fri, 2013-03-08 at 08:47 +0100, Paolo Bonzini wrote:
> Wasn't that a fix for the SeaBIOS VGA BIOS? The one in qemu.git is
> still built from the Bochs VGA BIOS.
No, it was for Bochs VGA BIOS.
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
--
dwmw2
smime.p7s
Description
On 07.03.2013 17:09, Paolo Bonzini wrote:
Il 07/03/2013 09:53, Peter Lieven ha scritto:
Then we can add bdrv_revalidate and, for block_resize, call
bdrv_revalidate+bdrv_truncate. For bs->growable = 0 &&
!bs->drv->bdrv_truncate, bdrv_truncate can just check that the actual
size is the same or b
Il 07/03/2013 17:21, Aurelien Jarno ha scritto:
>
> On the QEMU side, we should definitely have an autotest system trying to
> boot a few guests (and if possible with some !linux) to detect such
> issues. That's not something easy to do, maybe that could be a good
> GSoC project?
There is virt-te
Il 07/03/2013 21:24, David Woodhouse ha scritto:
> On Thu, 2013-03-07 at 16:56 +0100, Gerd Hoffmann wrote:
>>> and it doesn't need to be in git either IMHO.
>>
>> That one is a bit more tricky. The big advantage git has here is that
>> the update of a blob is not different from other updates. It
On 2013年03月08日 03:15, Michael S. Tsirkin wrote:
On Thu, Mar 07, 2013 at 08:00:29PM +0100, Andreas Färber wrote:
Am 07.03.2013 19:12, schrieb Michael S. Tsirkin:
On Thu, Mar 07, 2013 at 06:23:46PM +0100, Markus Armbruster wrote:
"Michael S. Tsirkin" writes:
On Thu, Mar 07, 2013 at 03:14:15PM
Hi all,
I initialized qemu-ga failed according the manul of
http://wiki.qemu.org/Features/QAPI/GuestAgent. My commands are here:
root@Blade3-01:/nfs# qemu-system-x86_64 vdisk.img -m 1024 -daemonize -vnc
localhost:1 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0
-device virtio-serial -dev
Michael,
Thanks for the fix.
There was another question which was lost in the thread.
I am testing virtio-net in two ways:
Old -net interface:
-net tap,ifname=tap0,script=qemu-ifup.sh \
-net nic,model=virtio,addr=0:0:0
(qemu) info network
hub 0
\ virtio-net-pci.0:
index=0,type=nic,model=vir
On 03/07/2013 06:52 PM, Michael S. Tsirkin wrote:
> On Thu, Mar 07, 2013 at 06:33:30PM +0800, Jason Wang wrote:
>> On 03/07/2013 06:25 PM, Michael S. Tsirkin wrote:
>>> On Thu, Mar 07, 2013 at 06:13:41PM +0800, Jason Wang wrote:
On 03/07/2013 06:04 PM, Michael S. Tsirkin wrote:
> On Thu, M
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
> On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
> > That change is definitely just build related - I don't see how it
> > could impact the final SeaBIOS binary. How did you conclude that this
> > commit is what fixes
Reviewed the patch, it is a pure remove of globals variable.
Reviewed-by: Wenchao Xia
> Move global variables into a struct so multiple thread pools can be
> supported in the future.
>
> This patch does not change thread-pool.h interfaces. There is still a
> global thread pool and it is not
On 6 March 2013 10:01, Alexander Graf wrote:
> We should translate AArch64 mode separately from AArch32 mode. In AArch64
> mode,
> registers look vastly different, instruction encoding is completely different,
> basically the system turns into a different machine.
>
> So let's do a simple if() in
On 6 March 2013 10:01, Alexander Graf wrote:
> @@ -699,25 +740,31 @@ static inline void cpu_clone_regs(CPUARMState *env,
> target_ulong newsp)
> static inline void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
> target_ulong *cs_base, int *flag
On 8 March 2013 07:37, Peter Crosthwaite wrote:
> Its all out of tree using out device tree driven machine instantiation
> but we are toying with the idea of moving away from that in favour of
> -device and friends (2100 less lines out of tree code for me), once
> the aforementioned fixes to sysbu
Ping.
Thanks,
AG
On Mon, Mar 4, 2013 at 7:29 AM, Anthony Green wrote:
> Here's version 8. This one includes Blue's typedef usage suggestion,
> and gen_tb_start()/gen_tb_end() as required by Peter Maydell's recent
> 'get rid of cpu_tb_unlink()' patch series.
>
> Please consider this version fo
On Fri, Mar 8, 2013 at 1:41 AM, Peter Maydell wrote:
> On 7 March 2013 20:45, Peter Crosthwaite wrote:
>>> Case four: "we really don't expect anybody to be trying to wire this
>>> up dynamically", which would apply to things like the on-cpu peripherals
>>> for some ARM cores.
>>
>> What ARM cores
Rather than have everyone call pci_bridge_map_irq() themselves and
come up with incorrect mapping functions let's use the default PCI
defined swizzle function unless told otherwise. Then we can also
clean out the duplicate function in pci_bridge_dev. Tested with an
assigned device behind a PCIe s
The PCI bridge spec defines a default swizzle for translating INTx
IRQs from secondary bus to primary. Use this by default for any
bridge that doesn't set a function.
Signed-off-by: Alex Williamson
---
hw/pci/pci_bridge.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw
pci_bridge_dev_map_irq_fn() is identical to pci_swizzle_map_irq_fn(),
which is now the default for all PCI bridges. We can therefore remove
this function and the pci_bridge_map_irq() call that used it.
Signed-off-by: Alex Williamson
---
hw/pci_bridge_dev.c |9 -
1 file changed, 9 de
On Thu, Mar 07, 2013 at 12:31:00PM -0700, Alex Williamson wrote:
> On Thu, 2013-03-07 at 21:22 +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 07, 2013 at 12:17:11PM -0700, Alex Williamson wrote:
> > > On Thu, 2013-03-07 at 20:49 +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Mar 07, 2013 at 11:
On Thu, Mar 07, 2013 at 09:18:48PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Mar 07, 2013 at 06:23:46PM +0100, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
> >> >> And
On Thu, 2013-03-07 at 16:56 +0100, Gerd Hoffmann wrote:
> > and it doesn't need to be in git either IMHO.
>
> That one is a bit more tricky. The big advantage git has here is that
> the update of a blob is not different from other updates. It is just
> a pull request. Keeping source+binaries in
On Thu, Mar 07, 2013 at 08:57:52PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > libvirt has a long-standing bug: when removing the device,
> > it can request removal but does not know when the
> > removal completes. Add an event so we can fix this in a robust way.
> >
> >
"Michael S. Tsirkin" writes:
> On Thu, Mar 07, 2013 at 06:23:46PM +0100, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
>> >> Andreas Färber writes:
>> >>
>> >> > Am 07.03.2013 11:07, schrieb Michael S. Tsirk
"Michael S. Tsirkin" writes:
> libvirt has a long-standing bug: when removing the device,
> it can request removal but does not know when the
> removal completes. Add an event so we can fix this in a robust way.
>
> Signed-off-by: Michael S. Tsirkin
Speaking as the acting QMP maintainer, just t
On Thu, 2013-03-07 at 21:22 +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 07, 2013 at 12:17:11PM -0700, Alex Williamson wrote:
> > On Thu, 2013-03-07 at 20:49 +0200, Michael S. Tsirkin wrote:
> > > On Thu, Mar 07, 2013 at 11:29:46AM -0700, Alex Williamson wrote:
> > > > Just like root ports, I thi
This bug was fixed in the package qemu-kvm - 1.2.0+noroms-
0ubuntu2.12.10.3
---
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.3) quantal-proposed; urgency=low
[ Nikolaus Rath ]
* fix-usb-passthrough.patch: fix problems with accessing some host
USB devices (Closes: 683983) (LP: #103372
The verification of this Stable Release Update has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression
On Thu, Mar 07, 2013 at 12:17:11PM -0700, Alex Williamson wrote:
> On Thu, 2013-03-07 at 20:49 +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 07, 2013 at 11:29:46AM -0700, Alex Williamson wrote:
> > > Just like root ports, I think these are supposed to be direct mapped.
> > >
> > > Signed-off-by
On Thu, 2013-03-07 at 20:49 +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 07, 2013 at 11:29:46AM -0700, Alex Williamson wrote:
> > Just like root ports, I think these are supposed to be direct mapped.
> >
> > Signed-off-by: Alex Williamson
>
> Hmm, very strange. Why not using standard pci bridg
On Thu, Mar 07, 2013 at 08:00:29PM +0100, Andreas Färber wrote:
> Am 07.03.2013 19:12, schrieb Michael S. Tsirkin:
> > On Thu, Mar 07, 2013 at 06:23:46PM +0100, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >>> On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
Am 07.03.2013 19:12, schrieb Michael S. Tsirkin:
> On Thu, Mar 07, 2013 at 06:23:46PM +0100, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>>> On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
Andreas Färber writes:
> Am 07.03.2013 11:07, schrieb Micha
Aurelien Jarno wrote:
> > > We probably want update the build process to build the blobs by default
> >
> > Earlier in this thread it's been stated that this often produces
> > subtly broken blobs...
>
> Would it be possible to have a testsuite to validate such blobs.
The coreboot project has a
On Thu, Mar 07, 2013 at 11:29:46AM -0700, Alex Williamson wrote:
> Just like root ports, I think these are supposed to be direct mapped.
>
> Signed-off-by: Alex Williamson
Hmm, very strange. Why not using standard pci bridge logic?
Any idea?
> ---
> hw/xio3130_downstream.c |7 +++
> hw
On Thu, Mar 07, 2013 at 11:29:19AM -0700, Alex Williamson wrote:
> For some reason we recurse to fire the INTx routing notifier for each
> child of a bus, for each possible device of a bus. That means that if
> we add a root port, the notifier gets called for that bridge 256
> times. If we add an
libvirt has a long-standing bug: when removing the device,
it can request removal but does not know when the
removal completes. Add an event so we can fix this in a robust way.
Signed-off-by: Michael S. Tsirkin
---
At Anthony's request, reposting with a corrected subject.
Sorry about the noise.
Just like root ports, I think these are supposed to be direct mapped.
Signed-off-by: Alex Williamson
---
hw/xio3130_downstream.c |7 +++
hw/xio3130_upstream.c |7 +++
2 files changed, 14 insertions(+)
diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c
index 7f00bc8
For some reason we recurse to fire the INTx routing notifier for each
child of a bus, for each possible device of a bus. That means that if
we add a root port, the notifier gets called for that bridge 256
times. If we add an upstream switch behind that root port, 256^2. But
of course we need a d
I cannot reproduce it anymore on master. One option we now have without
building it ourselves is using 1.4.0 from Ubuntu's raring derivate.
Would you consider that stable enough for production use (the qemu
package, not raring)?
--
You received this bug notification because you are a member of qe
commit 55e5c2850 breaks CPU not found return value, and returns
CPU corresponding to the last non NULL env.
Fix it by returning CPU only if env is not NULL, otherwise CPU is
not found and function should return NULL.
Signed-off-by: Igor Mammedov
---
exec.c | 2 +-
1 file changed, 1 insertion(+),
On Thu, Mar 07, 2013 at 06:23:46PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
> >> Andreas Färber writes:
> >>
> >> > Am 07.03.2013 11:07, schrieb Michael S. Tsirkin:
> >> >> On Thu, Mar 07, 2013 at 10:
On Thu, Mar 07, 2013 at 11:39:21AM -0600, Anthony Liguori wrote:
> Markus Armbruster writes:
>
> > "Michael S. Tsirkin" writes:
> >
> >> libvirt has a long-standing bug: when removing the device,
> >> it can request removal but does not know when the
> >> removal completes. Add an event so we ca
virtio-s390 on kvm can use a cookie value passed to guest
to optimize channel/VQ lookups.
Document this.
Signed-off-by: Michael S. Tsirkin
---
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index 72d956c..91aed06 100644
--- a/virtio-spec.lyx
+++ b/virtio-spec.lyx
@@ -10627,7 +10626,252 @@ Guest-
Am 21.02.2013 16:26, schrieb Andreas Färber:
> Hello,
>
> A long-standing patch of mine, applied for 1.4, attempted to fix dependency
> issues observed when adding MegaSAS emulation to pci.mak.
>
> As it turns out that patch was wrong. This mini-series reverts it and adds a
> cleanup to avoid tha
@Alex,
in a
armhf precise container
on a
raring host with qemu-user-static version 1.4.0+dfsg-1expubuntu2
a libreoffice build has now been going for 6 days with no failures
yet. (How long does that thing go on? :)
Unless you say otherwise I'm now going to shift to looking into the
javac f
Anthony Liguori writes:
> Markus Armbruster writes:
>
>> Anthony Liguori writes:
>>
>>> Markus Armbruster writes:
>>>
Peter Maydell writes:
>>> [and I don't think "this device
>>> can be added via the monitor but not the command line"
>>> counts as co
Andreas Färber writes:
> Am 07.03.2013 17:44, schrieb Anthony Liguori:
>> Andreas Färber writes:
>>
>>> Am 07.03.2013 17:27, schrieb Christian Borntraeger:
> It's a bug in both virtio-ccw that features=0 when get_features is
> called. You can also tell this with:
>
> [10:02 AM]
Markus Armbruster writes:
> "Michael S. Tsirkin" writes:
>
>> libvirt has a long-standing bug: when removing the device,
>> it can request removal but does not know when the
>> removal completes. Add an event so we can fix this in a robust way.
>
> This is *v4*. I think you should respin to avo
"Michael S. Tsirkin" writes:
> On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
>> Andreas Färber writes:
>>
>> > Am 07.03.2013 11:07, schrieb Michael S. Tsirkin:
>> >> On Thu, Mar 07, 2013 at 10:55:23AM +0100, Markus Armbruster wrote:
>> >>> "Michael S. Tsirkin" writes:
>> >
"Michael S. Tsirkin" writes:
> libvirt has a long-standing bug: when removing the device,
> it can request removal but does not know when the
> removal completes. Add an event so we can fix this in a robust way.
This is *v4*. I think you should respin to avoid confusing Anthony's
tools. Recomm
"Michael S. Tsirkin" writes:
> On Thu, Mar 07, 2013 at 10:44:18AM -0600, Anthony Liguori wrote:
>> Andreas Färber writes:
>>
>> > Am 07.03.2013 17:27, schrieb Christian Borntraeger:
>> >>> It's a bug in both virtio-ccw that features=0 when get_features is
>> >>> called. You can also tell this
Am 07.03.2013 17:44, schrieb Anthony Liguori:
> Andreas Färber writes:
>
>> Am 07.03.2013 17:27, schrieb Christian Borntraeger:
It's a bug in both virtio-ccw that features=0 when get_features is
called. You can also tell this with:
[10:02 AM] anthony@titi:~/git/qemu/hw/s390x$
Markus Armbruster writes:
> Anthony Liguori writes:
>
>> Markus Armbruster writes:
>>
>>> Peter Maydell writes:
>> [and I don't think "this device
>> can be added via the monitor but not the command line"
>> counts as consistent or coherent...]
>
>
Il 07/03/2013 13:41, Stefan Hajnoczi ha scritto:
> This patch series changes the global thread pool to a one ThreadPool per
> AioContext model. We still only use the main loop AioContext so in practice
> there is just one ThreadPool. But this opens the door to refactoring the
> block
> layer (wh
Stefan Hajnoczi, le Thu 07 Mar 2013 10:38:26 +0100, a écrit :
> On Wed, Mar 06, 2013 at 02:15:25PM +0100, Samuel Thibault wrote:
> > Stefan Hajnoczi, le Wed 06 Mar 2013 13:29:37 +0100, a écrit :
> > > On Tue, Mar 05, 2013 at 05:35:10PM +0100, Samuel Thibault wrote:
> > > Unfortunately net/socket.c
Anthony Liguori writes:
> Markus Armbruster writes:
>
>> Peter Maydell writes:
> [and I don't think "this device
> can be added via the monitor but not the command line"
> counts as consistent or coherent...]
no_user applies equally to -device and
> In general having blobs in our allegedly source tarball is pretty ugly.
> Either it's a
> source release or it isn't. We can do a release-of-blobs tarball too if we
> want,
> but it doesn't need to be in the source tarball and it doesn't need to be in
> git
> either IMHO.
I think it is very c
On Thu, Mar 07, 2013 at 10:44:18AM -0600, Anthony Liguori wrote:
> Andreas Färber writes:
>
> > Am 07.03.2013 17:27, schrieb Christian Borntraeger:
> >>> It's a bug in both virtio-ccw that features=0 when get_features is
> >>> called. You can also tell this with:
> >>>
> >>> [10:02 AM] anthony@t
libvirt has a long-standing bug: when removing the device,
it can request removal but does not know when the
removal completes. Add an event so we can fix this in a robust way.
Signed-off-by: Michael S. Tsirkin
---
Changes from v3:
- Document that we only emit events for devices with
a
Il 07/03/2013 09:50, Kevin Wolf ha scritto:
> Am 06.03.2013 um 21:39 hat Paolo Bonzini geschrieben:
>> Il 06/03/2013 20:03, Peter Lieven ha scritto:
>>> Am 06.03.2013 19:48, schrieb Jeff Cody:
On Wed, Mar 06, 2013 at 07:31:51PM +0100, Paolo Bonzini wrote:
> Il 06/03/2013 19:14, Jeff Cody h
On Thu, Mar 07, 2013 at 11:02:07AM -, Helge Rausch wrote:
> When a block-stream is initiated via QMP and the QMP socket is closed on
> client side before the job is finished, QEMU crashes with a buffer
> overflow, somewhere at the end of the streaming process.
>
> Without QMP I can stream via
Andreas Färber writes:
> Am 07.03.2013 17:27, schrieb Christian Borntraeger:
>>> It's a bug in both virtio-ccw that features=0 when get_features is
>>> called. You can also tell this with:
>>>
>>> [10:02 AM] anthony@titi:~/git/qemu/hw/s390x$ grep
>>> DEFINE_VIRTIO_NET_FEATURES *
>>> virtio-ccw.
Christian Borntraeger writes:
>> You're misreading how this works.
>>
>> Host features are set based on command line arguments. This is
>> advertised to the guest. The vdev->get_config() call then sanitizes
>> features. For instance, look at:
>>
>> static uint32_t virtio_net_get_features(Vir
On 07.03.2013, at 17:27, Christian Borntraeger wrote:
>> You're misreading how this works.
>>
>> Host features are set based on command line arguments. This is
>> advertised to the guest. The vdev->get_config() call then sanitizes
>> features. For instance, look at:
>>
>> static uint32_t vir
On Thu, Mar 07, 2013 at 04:20:48PM +0100, Paolo Bonzini wrote:
> Il 07/03/2013 14:32, Michael S. Tsirkin ha scritto:
> > +#ifdef DEBUG_ARCH_INIT
> > +#define DPRINTF(fmt, ...) \
> > +do { fprintf(stdout, "arch_init: " fmt, ## __VA_ARGS__); } while (0)
>
> These need to be adjusted, but it can
Am 07.03.2013 17:27, schrieb Christian Borntraeger:
>> It's a bug in both virtio-ccw that features=0 when get_features is
>> called. You can also tell this with:
>>
>> [10:02 AM] anthony@titi:~/git/qemu/hw/s390x$ grep DEFINE_VIRTIO_NET_FEATURES
>> *
>> virtio-ccw.c:DEFINE_VIRTIO_NET_FEATURES(
On Thu, Mar 07, 2013 at 03:14:15PM +0100, Markus Armbruster wrote:
> Andreas Färber writes:
>
> > Am 07.03.2013 11:07, schrieb Michael S. Tsirkin:
> >> On Thu, Mar 07, 2013 at 10:55:23AM +0100, Markus Armbruster wrote:
> >>> "Michael S. Tsirkin" writes:
> >>>
> On Wed, Mar 06, 2013 at 02:57
> You're misreading how this works.
>
> Host features are set based on command line arguments. This is
> advertised to the guest. The vdev->get_config() call then sanitizes
> features. For instance, look at:
>
> static uint32_t virtio_net_get_features(VirtIODevice *vdev, uint32_t features)
> {
On Fri, Mar 08, 2013 at 12:03:15AM +0800, Peter Maydell wrote:
> On 7 March 2013 23:56, Gerd Hoffmann wrote:
> > Peter Maydell wrote:
> >> In general having blobs in our allegedly source tarball is pretty
> >> ugly. Either it's a source release or it isn't. We can do a
> >> release-of-blobs tarbal
On 8 March 2013 00:09, Anthony Liguori wrote:
> What is -devices help trying to show? Devices that are valid to for a
> user to pass? Hint: on a PC, the only thing that's valid to add are
> devices that implement a certain bus type. In fact, it depends on the
> bus model.
Yeah, I think part of
Signed-off-by: Igor Mammedov
---
v2:
- fixed indentation
- replaced error message. Suggested-By: Andreas Färber
---
hw/qdev-properties.c | 33 +
hw/qdev-properties.h | 10 ++
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-p
On Thu, Mar 07, 2013 at 10:33:49AM -0500, Jeff Cody wrote:
> On Thu, Mar 07, 2013 at 03:50:56PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Mar 06, 2013 at 09:48:33AM -0500, Jeff Cody wrote:
> > > This adds the ability to update the headers in a VHDX image, including
> > > generating a new MS-compati
On Thu, Mar 07, 2013 at 08:57:06AM -0500, Kevin O'Connor wrote:
> On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
> > On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
> > > That change is definitely just build related - I don't see how it
> > > could impact the final
On Thu, Mar 07, 2013 at 10:23:54AM -0500, Jeff Cody wrote:
> On Thu, Mar 07, 2013 at 03:30:44PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Mar 06, 2013 at 09:48:11AM -0500, Jeff Cody wrote:
> > > +ret = bdrv_pread(bs->file, s->bat_offset, s->bat, s->bat_rt.length);
> > > +
> > > +for (i = 0;
Gerd Hoffmann writes:
> Hi,
>
>> For mice, we have a monitor command mouse_set to select the active one.
>> Useful for keyboards, too? I dimly recall somebody trying something
>> like that in the past.
>
> Don't feel like doing that now.
>
> First, isn't important enough IMHO.
>
> Second, I'm
Markus Armbruster writes:
> Peter Maydell writes:
[and I don't think "this device
can be added via the monitor but not the command line"
counts as consistent or coherent...]
>>>
>>> no_user applies equally to -device and device_add.
>>
>> In the codebase a
Il 07/03/2013 09:53, Peter Lieven ha scritto:
>>
>> Then we can add bdrv_revalidate and, for block_resize, call
>> bdrv_revalidate+bdrv_truncate. For bs->growable = 0 &&
>> !bs->drv->bdrv_truncate, bdrv_truncate can just check that the actual
>> size is the same or bigger as the one requested, and
Il 07/03/2013 15:00, Don Slutz ha scritto:
> Turns out that this is not the normal kind of issue. Newer seabios
> works, older does not:
>
> good * 88cb66e (HEAD, tag: rel-1.7.2.1, origin/1.7.2-stable,
> 1.7.2-stable) seabios: Add a dummy PCI slot to irq mapping funct
> good * 985a9d3 seabios
On Thu, Mar 07, 2013 at 04:59:05PM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2013 at 09:48:43AM -0500, Jeff Cody wrote:
> > @@ -958,12 +960,150 @@ exit:
> > return ret;
> > }
> >
> > +/*
> > + * Allocate a new payload block at the end of the file.
> > + *
> > + * Allocation will happe
Christian Borntraeger writes:
> On 05/03/13 17:48, Alexander Graf wrote:
>> On 02/06/2013 12:47 AM, Jesse Larrew wrote:
>>> Currently, the config size for virtio devices is hard coded. When a new
>>> feature is added that changes the config size, drivers that assume a static
>>> config size will
On 7 March 2013 23:56, Gerd Hoffmann wrote:
> Peter Maydell wrote:
>> In general having blobs in our allegedly source tarball is pretty
>> ugly. Either it's a source release or it isn't. We can do a
>> release-of-blobs tarball too if we want, but it doesn't need
>> to be in the source tarball
>
>
On Wed, Mar 06, 2013 at 09:48:43AM -0500, Jeff Cody wrote:
> @@ -958,12 +960,150 @@ exit:
> return ret;
> }
>
> +/*
> + * Allocate a new payload block at the end of the file.
> + *
> + * Allocation will happen at 1MB alignment inside the file
> + *
> + * Returns the file offset start of the
Il 07/03/2013 14:32, Michael S. Tsirkin ha scritto:
> Move RAM migration code from arch_init to savevm-ram.
>
> Signed-off-by: Michael S. Tsirkin
> ---
>
> Note: this is on top of Juan's pull request
>
> Changes from v1:
> - renamed source file, rebased on top of migration.next as
> s
Hi,
> In general having blobs in our allegedly source tarball is pretty
> ugly. Either it's a source release or it isn't. We can do a
> release-of-blobs tarball too if we want, but it doesn't need
> to be in the source tarball
This is easily doable, just an update to scripts/make-release to spe
On 7 March 2013 20:45, Peter Crosthwaite wrote:
>> Case four: "we really don't expect anybody to be trying to wire this
>> up dynamically", which would apply to things like the on-cpu peripherals
>> for some ARM cores.
>
> What ARM cores were you thinking here exactly? We are already doing
> dynam
On 03/07/2013 01:23 AM, Jason Wang wrote:
> Sometimes, we need track the state when guest is just about to start after
> migration. There's not a accurate state available which do this accurately
> (consider qemu may started with -S in destination).
s/may/may be/
and yes, libvirt _always_ starts
Hi,
> For mice, we have a monitor command mouse_set to select the active one.
> Useful for keyboards, too? I dimly recall somebody trying something
> like that in the past.
Don't feel like doing that now.
First, isn't important enough IMHO.
Second, I'm busy cleaning up console + display code
On Thu, Mar 07, 2013 at 03:50:56PM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2013 at 09:48:33AM -0500, Jeff Cody wrote:
> > This adds the ability to update the headers in a VHDX image, including
> > generating a new MS-compatible GUID, and checksum.
> >
> > Signed-off-by: Jeff Cody
> > ---
On Thu, Mar 07, 2013 at 03:30:44PM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 06, 2013 at 09:48:11AM -0500, Jeff Cody wrote:
> > +#define leguid_to_cpus(guid) do { \
> > +le32_to_cpus(&(guid)->data1); \
> > +le16_to_cpus(&(guid)->data2); \
> > +le16_to_cpus(&(guid)->data3); } while (0)
Il 07/03/2013 14:32, Michael S. Tsirkin ha scritto:
> +#ifdef DEBUG_ARCH_INIT
> +#define DPRINTF(fmt, ...) \
> +do { fprintf(stdout, "arch_init: " fmt, ## __VA_ARGS__); } while (0)
These need to be adjusted, but it can be a follow-up.
Paolo
> +#else
> +#define DPRINTF(fmt, ...) \
> +do {
On 03/07/2013 01:32 AM, Doug Goldstein wrote:
The goal is to support an 'includedir' to include all files within a
directory specified in the bridge.conf file. The rationale is to allow
libvirt to be able to configure interfaces to for use by unprivileged
users by just simply generating a new c
On 7 March 2013 19:56, Gerd Hoffmann wrote:
>> We don't even ship any upstream blobs in the debian qemu _source_
>> package: we repack upstream qemu.tar.gz by removing these blobs.
>
> That's a bit over the top for my taste as the release tarballs include
> both source and blobs.
qemu-linaro's s
On 03/07/13 08:57, Kevin O'Connor wrote:
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
That change is definitely just build related - I don't see how it
could impact the final SeaBIOS binary. How did you conclude
On 03/07/13 08:02, Don Slutz wrote:
On 03/07/13 03:43, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
>On Thu, Mar 07, 2013 at 12:12:08AM +0100, Aurelien Jarno wrote:
> >On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote:
[snip]
Maybe I am do
On 03/07/13 03:43, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
>On Thu, Mar 07, 2013 at 12:12:08AM +0100, Aurelien Jarno wrote:
> >On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote:
[snip]
Maybe I am doing something wrong or there is a bug
On 7 March 2013 18:21, wrote:
> I did a dig through the archive for linux-user patches
> that have slipped through during my inactivity. The ones
> in this patchset appear good and pass smoketest.
> linux-user: correct semctl() and shmctl()
This one's not correct, I'm afraid -- see my comment
On Wed, Mar 06, 2013 at 09:48:33AM -0500, Jeff Cody wrote:
> This adds the ability to update the headers in a VHDX image, including
> generating a new MS-compatible GUID, and checksum.
>
> Signed-off-by: Jeff Cody
> ---
> block/vhdx.c | 165
>
Hi all,
recently I've tried to teach megasas MSI/MSI-X. While it works
perfectly under Linux, Windows refuses to.
With really strange symptoms:
Windows Vista will BSOD when both MSI/MSI-X registers are present,
and Windows 7 will hang as Windows (apparently) thinks MSI/MSI-X is
enabled, wher
On Wed, Mar 06, 2013 at 09:48:11AM -0500, Jeff Cody wrote:
> +#define leguid_to_cpus(guid) do { \
> +le32_to_cpus(&(guid)->data1); \
> +le16_to_cpus(&(guid)->data2); \
> +le16_to_cpus(&(guid)->data3); } while (0)
This should be a function. Please avoid macros.
> +static const ms_guid
Gerd Hoffmann writes:
> There is no need for anybody outside ui/input.c to access the
> struct elements. Move the definitions, leaving only the typedefs
> in the header files.
No-brainer (assuming it compiles).
Reviewed-by: Markus Armbruster
1 - 100 of 197 matches
Mail list logo
