Hi Michael,
Workaround: get from savannah. This one should work.
git://git.savannah.nongnu.org/qemu.git
Best regards,
Roy
2010/10/20 Michael Crawford :
>> git clone http://git.qemu.org/qemu.git
>>
>> This initializes a repository in qemu/.git and starts downloading from
>> the git server.
>>
>>
> git clone http://git.qemu.org/qemu.git
>
> This initializes a repository in qemu/.git and starts downloading from
> the git server.
>
> After 60 or 70 mb - as seen via "du -s" it stops downloading. The
> "git clone" never completes.
After a long time I got the following. Perhaps someone had a
On 10/19/2010 7:22 PM, Balbir Singh wrote:
> * Anthony Liguori [2010-10-19 16:36:31]:
>
>> On 10/19/2010 01:36 PM, Balbir Singh wrote:
+qemu_mutex_lock(&(queue->lock));
+while (1) {
+ThreadletWork *work;
+int ret = 0;
+
+while (QTAILQ_
git clone http://git.qemu.org/qemu.git
This initializes a repository in qemu/.git and starts downloading from
the git server.
After 60 or 70 mb - as seen via "du -s" it stops downloading. The
"git clone" never completes.
How many mb should be in my .git directory?
Thanks,
Mike
--
Michael Da
On 10/19/2010 2:36 PM, Anthony Liguori wrote:
> On 10/19/2010 01:36 PM, Balbir Singh wrote:
>>> +qemu_mutex_lock(&(queue->lock));
>>> +while (1) {
>>> +ThreadletWork *work;
>>> +int ret = 0;
>>> +
>>> +while (QTAILQ_EMPTY(&(queue->request_list))&&
>>> +
* Venkateswararao Jujjuri (JV) [2010-10-19 14:00:24]:
> >
> > In the case that we just spawned the threadlet, the cond_signal is
> > spurious. If we need predictable scheduling behaviour,
> > qemu_cond_signal needs to happen with queue->lock held.
> >
> > I'd rewrite the function as
> >
> > /
* Arun R B [2010-10-19 23:13:20]:
> From: Gautham R Shenoy
>
> This patch makes the paio subsystem use the threadlet framework thereby
> decoupling asynchronous threading framework portion out of
> posix-aio-compat.c
>
> The patch has been tested with fstress.
>
> Signed-off-by: Gautham R She
* Anthony Liguori [2010-10-19 16:36:31]:
> On 10/19/2010 01:36 PM, Balbir Singh wrote:
> >>+qemu_mutex_lock(&(queue->lock));
> >>+while (1) {
> >>+ThreadletWork *work;
> >>+int ret = 0;
> >>+
> >>+while (QTAILQ_EMPTY(&(queue->request_list))&&
> >>+ (r
On Wed, 20 Oct 2010, acrux wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> i've this error only on ppc64 compiling qemu-0.13.0:
>
It was fixed by b1d6d51d958bc98f5b6faa4d1d527c785a9ba7d6 which is
apparently not in 0.13.0, you can probably cherry pick it.
> [...]
> CCi386-so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
i've this error only on ppc64 compiling qemu-0.13.0:
[...]
CCi386-softmmu/virtio-pci.o
CCi386-softmmu/vhost_net.o
CCi386-softmmu/virtio-9p.o
CCi386-softmmu/rwhandler.o
CCi386-softmmu/kvm-stub.o
CCi386-softmmu/usb-oh
On Wed, Oct 20, 2010 at 08:17:24AM +0900, Isaku Yamahata wrote:
> On Tue, Oct 19, 2010 at 04:05:28PM -0700, Wei Xu wrote:
> > Good work! One question here: any plan to put q35 and seabios into mainline?
>
> My plan is
> qemu part:
> 1. respin this patch. Mainly aer part. <<< I'm here
> 2. address
Isaku,
Sure I will send out patch after some cleanup. MSI using irq-in-kernel still
a little bit ugly:)
Wei
On 10/19/10 4:17 PM, "Isaku Yamahata" wrote:
> On Tue, Oct 19, 2010 at 04:05:28PM -0700, Wei Xu wrote:
>> Good work! One question here: any plan to put q35 and seabios into mainline?
>
On Tue, Oct 19, 2010 at 04:05:28PM -0700, Wei Xu wrote:
> Good work! One question here: any plan to put q35 and seabios into mainline?
My plan is
qemu part:
1. respin this patch. Mainly aer part. <<< I'm here
2. address bus reset and flr.
3. Then move on to q35 north/south bridge.
After 1 or 2,
On Wed, Oct 20, 2010 at 07:55:56AM +0900, Isaku Yamahata wrote:
> On Wed, Oct 20, 2010 at 12:40:49AM +0200, Michael S. Tsirkin wrote:
>
> > I think I suggested once a good way to implement this:
> >
> > - always make the bits w1c
> > - after config write:
> > if MHR is enabled, and you see that
Isaku,
Good work! One question here: any plan to put q35 and seabios into mainline?
FYI: I have made pcie plus q35 working on qemu-kvm, though on a little bit
old code base.
Wei
On 10/19/10 3:39 PM, "Isaku Yamahata" wrote:
> On Tue, Oct 19, 2010 at 11:07:34AM -0500, Adnan Khaleel wrote:
>> A
On Wed, Oct 20, 2010 at 12:40:49AM +0200, Michael S. Tsirkin wrote:
> I think I suggested once a good way to implement this:
>
> - always make the bits w1c
> - after config write:
> if MHR is enabled, and you see that error log is not empty and that bit is
> 0,
> this means that someone has
On Wed, Oct 20, 2010 at 07:36:37AM +0900, Isaku Yamahata wrote:
> On Tue, Oct 19, 2010 at 07:06:55PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Oct 20, 2010 at 12:19:47AM +0900, Isaku Yamahata wrote:
> > > On Tue, Oct 19, 2010 at 01:51:31PM +0200, Michael S. Tsirkin wrote:
> > > > On Tue, Oct 19,
On Tue, Oct 19, 2010 at 11:07:34AM -0500, Adnan Khaleel wrote:
> Are all these patches going to be integrated into the current qemu repository?
Eventually. Right now some of them are merged into Michael's pci branch.
It's up to Michael when he requests Anthony to pull the branch.
thanks,
>
> -A
On Tue, Oct 19, 2010 at 07:06:55PM +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 20, 2010 at 12:19:47AM +0900, Isaku Yamahata wrote:
> > On Tue, Oct 19, 2010 at 01:51:31PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Oct 19, 2010 at 06:06:27PM +0900, Isaku Yamahata wrote:
> > > > On uncorrectabl
On 10/19/2010 01:36 PM, Balbir Singh wrote:
+qemu_mutex_lock(&(queue->lock));
+while (1) {
+ThreadletWork *work;
+int ret = 0;
+
+while (QTAILQ_EMPTY(&(queue->request_list))&&
+ (ret != ETIMEDOUT)) {
+ret = qemu_cond_timedwait(&(queue->con
On Tue, Oct 19, 2010 at 04:22:23PM -0500, Anthony Liguori wrote:
> On 10/19/2010 04:15 PM, Stefan Weil wrote:
> >Am 19.10.2010 10:37, schrieb Michael S. Tsirkin:
> >>On Mon, Oct 18, 2010 at 09:11:55PM +0200, Stefan Weil wrote:
> >>>QEMU must only make sure that patching of the supported roms
> >>>w
On 10/19/2010 04:15 PM, Stefan Weil wrote:
Am 19.10.2010 10:37, schrieb Michael S. Tsirkin:
On Mon, Oct 18, 2010 at 09:11:55PM +0200, Stefan Weil wrote:
QEMU must only make sure that patching of the supported roms
with supported devices work.
I think that's what Anthony was saying too - make
On 10/19/2010 03:57 PM, Ayal Baron wrote:
Yeah, concurrent is a little trickier. Simple solution is for a
management tool to just do a stop + multiple snapshots + cont. It's
equivalent to what we'd do if we don't do it aio which is probably how
we'd do the first implementation.
But in the lon
Am 19.10.2010 10:37, schrieb Michael S. Tsirkin:
On Mon, Oct 18, 2010 at 09:11:55PM +0200, Stefan Weil wrote:
QEMU must only make sure that patching of the supported roms
with supported devices work.
I think that's what Anthony was saying too - make this depend
on a qdev property and set it on
PCI devices with different vendor or device ids sometimes share
the same rom code. Only the ids and the checksum
differs in a boot rom for such devices.
The i825xx ethernet controller family is a typical example
which is implemented in hw/eepro100.c. It uses at least
3 different device ids, so nor
On 10/19/2010 11:36 AM, Balbir Singh wrote:
> * Arun R B [2010-10-19 23:12:45]:
>
>> From: Aneesh Kumar K.V
>>
>> This patch creates a generic asynchronous-task-offloading infrastructure
>> named
>> threadlets. The core idea has been borrowed from the threading framework that
>> is being used b
- "Anthony Liguori" wrote:
> On 10/19/2010 11:54 AM, Ayal Baron wrote:
> > - "Anthony Liguori" wrote:
> >
> >
> >> On 10/19/2010 07:48 AM, Dor Laor wrote:
> >>
> >>> On 10/19/2010 04:11 AM, Chris Wright wrote:
> >>>
> * Juan Quintela (quint...@redhat.com) wrote:
>
On 10/19/2010 09:12 PM, Balbir Singh wrote:
> >Ideally you need
> >
> > s = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
> >
> > But qemu will need to wrap this around as well.
>
> Why? QEMU is never using thread cancellation.
Yes, I agree, in the longer run, cancellation is
* Paolo Bonzini [2010-10-19 21:01:03]:
> On 10/19/2010 08:36 PM, Balbir Singh wrote:
> >Ideally you need
> >
> > s = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
> >
> >But qemu will need to wrap this around as well.
>
> Why? QEMU is never using thread cancellation.
>
Yes, I a
On 10/19/2010 08:36 PM, Balbir Singh wrote:
Ideally you need
s = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
But qemu will need to wrap this around as well.
Why? QEMU is never using thread cancellation.
Paolo
* Arun R B [2010-10-19 23:12:45]:
> From: Aneesh Kumar K.V
>
> This patch creates a generic asynchronous-task-offloading infrastructure named
> threadlets. The core idea has been borrowed from the threading framework that
> is being used by paio.
>
> The reason for creating this generic infras
From: Aneesh Kumar K.V
This patch creates a generic asynchronous-task-offloading infrastructure named
threadlets. The core idea has been borrowed from the threading framework that
is being used by paio.
The reason for creating this generic infrastructure is so that other subsystems,
such as virt
From: Gautham R Shenoy
This patch makes the paio subsystem use the threadlet framework thereby
decoupling asynchronous threading framework portion out of
posix-aio-compat.c
The patch has been tested with fstress.
Signed-off-by: Gautham R Shenoy
Signed-off-by: Sripathi Kodi
---
posix-aio-comp
Hello,
This apparently has been neither applied, nor commented on. Could
either be done?
Samuel
contro...@[\]^_} shouldn't get the 'a' - 'A' offset for correct
translation. ESC is better simulated as escape key.
Signed-off-by: Samuel Thibault
diff --git a/ui/curses.c b/ui/curses.c
index ed
From: Gautham R Shenoy
Add helper functions to enable virtio-9p make use of the threadlets
infrastructure for offloading blocking tasks such as making posix calls on
to the helper threads and handle the post_posix_operations() from the
context of the iothread. This frees the vcpu thread to proces
Hi,
This is the v6 of the patch-series to have a generic asynchronous task
offloading framework (called threadlets) within qemu.
Request to consider pulling this series as discussed during the
Qemu-devel call.
V5 can be found here:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg43827.html
* Chris Wright (chr...@redhat.com) wrote:
> We were also able to video the speakers, and will send a note when the
> videos are available.
> (and thanks again to Andrew Cathrow for making this happen)
I don't think a note went out yet. The videos are available as well.
thanks,
-chris
On Wed, Oct 20, 2010 at 12:19:47AM +0900, Isaku Yamahata wrote:
> On Tue, Oct 19, 2010 at 01:51:31PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Oct 19, 2010 at 06:06:27PM +0900, Isaku Yamahata wrote:
> > > On uncorrectable error status register in pcie_aer_write_config().
> > > The register is RW
On 10/19/2010 11:54 AM, Ayal Baron wrote:
- "Anthony Liguori" wrote:
On 10/19/2010 07:48 AM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you are interested in coverin
- "Anthony Liguori" wrote:
> On 10/19/2010 07:48 AM, Dor Laor wrote:
> > On 10/19/2010 04:11 AM, Chris Wright wrote:
> >> * Juan Quintela (quint...@redhat.com) wrote:
> >>>
> >>> Please send in any agenda items you are interested in covering.
> >>
> >> - 0.13.X -stable handoff
> >> - 0.14 pl
Am 18.10.2010 17:53, schrieb Stefan Hajnoczi:
> The L1 table grow operation includes a size calculation that bumps up
> the new L1 table size in order to anticipate the size needs of vmstate
> data. This helps reduce the number of times that the L1 table has to be
> grown when vmstate data is appe
Are all these patches going to be integrated into the current qemu repository?
-AK
_
From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
To: Michael S. Tsirkin [mailto:m...@redhat.com]
Cc: qemu-devel@nongnu.org, skand...@cisco.com, etmar...@cisco.com,
we...@cisco.com, ad...@khaleel.us
S
Am 19.10.2010 um 17:04 schrieb Jan Kiszka :
> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
> latter is called periodically, the former will only be invoked when new
> characters arrive at the back-end. This caused problems to front-end
> drivers whenever they were unable
Am 19.10.2010 17:22, Alexander Graf wrote:
>
> Am 19.10.2010 um 17:04 schrieb Jan Kiszka :
>
>> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
>> latter is called periodically, the former will only be invoked when new
>> characters arrive at the back-end. This caused probl
On Tue, Oct 19, 2010 at 04:14:09PM +0200, Jan Kiszka wrote:
> Instead of preparing all traced args, jumping into the common trace
> function, even collecting a timestamp, do the check if a particular
> tracepoint is enabled inline. Also, mark the enabled case unlikely to
> motivate the compiler to
On Tue, Oct 19, 2010 at 3:32 PM, Ryan Harper wrote:
> Block hot unplug is racy since the guest is required to acknowlege the ACPI
> unplug event; this may not happen synchronously with the device removal
> command
>
> This series aims to close a gap where by mgmt applications that assume the
> bl
On Tue, Oct 19, 2010 at 05:12:11PM +0200, Jan Kiszka wrote:
> This is a more commonly used term, including the KVM in-kernel
> tracepoints. Only QEMU developers probably know the relation between
> cpu_in/out services and I/O port access.
>
> Signed-off-by: Jan Kiszka
> ---
> ioport.c | 12
On Tue, Oct 19, 2010 at 01:51:31PM +0200, Michael S. Tsirkin wrote:
> On Tue, Oct 19, 2010 at 06:06:27PM +0900, Isaku Yamahata wrote:
> > On uncorrectable error status register in pcie_aer_write_config().
> > The register is RW1CS, so making it writable and test-and-clear doesn't
> > work.
>
> Sur
0.13.X -stable
- Anthony will send note to qemu-devel on this
- move 0.13.X -stable to a separate tree
- driven independently of main qemu tree
- challenge is always in the porting and testing of backported fixes
- looking for volunteers
0.14
- would like to do this before end of the year
- 0.13 f
This is a more commonly used term, including the KVM in-kernel
tracepoints. Only QEMU developers probably know the relation between
cpu_in/out services and I/O port access.
Signed-off-by: Jan Kiszka
---
ioport.c | 12 ++--
trace-events |4 ++--
2 files changed, 8 insertions(+),
Instead of always assuming success for bdrv_aio_flush, actually do something
with the error. This respects the werror option and accordingly ignores the
error, reports it to the guest or stops the VM and retries after cont.
Ignoring the error is trivial, obviously. For stopping the VM and retrying
Until now, errors returned by bdrv_aio_flush were silently ignored, so that
from a guest point of view, FLUSH would never fail even if the data hasn't made
it to the host disk.
This applies the werror option also to flushes, so that by default errors are
reported back to the guest, and qemu can be
The next patch reuses this code, so put it in its own function.
Signed-off-by: Kevin Wolf
---
hw/ide/core.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 5ccb09c..6d8606e 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@
While not explicitly stated in the spec, it was observed on real systems
that enabling loopback testing on the pcnet controller disables
reception of external frames. And some legacy software relies on it, so
provide this behavior.
Signed-off-by: Jan Kiszka
---
hw/pcnet.c |5 +++--
1 files c
Move the buffer flush from mux_chr_read to mux_chr_can_read. While the
latter is called periodically, the former will only be invoked when new
characters arrive at the back-end. This caused problems to front-end
drivers whenever they were unable to read data immediately, e.g.
virtio-console attache
Block hot unplug is racy since the guest is required to acknowlege the ACPI
unplug event; this may not happen synchronously with the device removal command
This series aims to close a gap where by mgmt applications that assume the
block resource has been removed without confirming that the guest h
19/10/2010 10:32 +0100, Daniel P. Berrange wrote:
> On Mon, Oct 18, 2010 at 01:59:15PM -0500, Anthony Liguori wrote:
> > On 10/18/2010 12:30 PM, Oleg Sadov wrote:
> > >I don't understand reasons for such locale-default keyboard settings for
> > >qemu too, but may be it's useful for someone...
> > >
On Tue, Oct 19, 2010 at 03:29:51PM +0100, Richard W.M. Jones wrote:
> On Tue, Oct 19, 2010 at 03:59:36PM +0200, Jan Kiszka wrote:
> > Once we have "-trace events=...", defining the list of active
> > tracepoints before starting qemu will be trivial (e.g. via a config
> > file). Of course, this requ
This patch series decouples the detachment of a block device from the removal
of the backing pci-device. Removal of a hotplugged pci device requires the
guest to respond before qemu tears down the block device. In some cases, the
guest may not respond leaving the guest with continued access to the
Port qemu-kvm's
commit 4b62fff1101a7ad77553147717a8bd3bf79df7ef
Author: Huang Ying
Date: Mon Sep 21 10:43:25 2009 +0800
MCE: Relay UCR MCE to guest
UCR (uncorrected recovery) MCE is supported in recent Intel CPUs,
where some hardware error such as some memory error can be reporte
Am 19.10.2010 16:29, Richard W.M. Jones wrote:
> On Tue, Oct 19, 2010 at 03:59:36PM +0200, Jan Kiszka wrote:
>> Once we have "-trace events=...", defining the list of active
>> tracepoints before starting qemu will be trivial (e.g. via a config
>> file). Of course, this requires that all tracepoint
Add a function to find a drive by id string.
Changes since v1:
-Coding Style fix
Signed-off-by: Ryan Harper
---
blockdev.c | 13 +
blockdev.h |1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index ff7602b..5fc3b9b 100644
--- a/block
Am 19.10.2010 16:12, Daniel P. Berrange wrote:
> On Tue, Oct 19, 2010 at 03:46:35PM +0200, Jan Kiszka wrote:
>> Am 19.10.2010 15:30, Stefan Hajnoczi wrote:
>>> On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
One quirk I stumbled over quickly was the "disable" tag in trace-events.
>
On Tue, Oct 19, 2010 at 03:59:36PM +0200, Jan Kiszka wrote:
> Once we have "-trace events=...", defining the list of active
> tracepoints before starting qemu will be trivial (e.g. via a config
> file). Of course, this requires that all tracepoints are built-in...
Sorry that I've not been followin
On 19 October 2010 08:17, Alexander Graf wrote:
>
> Am 19.10.2010 um 02:10 schrieb Anthony Liguori :
>
>> On 10/18/2010 06:29 PM, Alexander Graf wrote:
A user will get a really nasty surprise if they think they can use a flag
or rely on QEMU to prevent a VM from doing something nasty wi
On Tue, Oct 19, 2010 at 04:03:15PM +0200, Jan Kiszka wrote:
> qemu_malloc instrumentations require linking against the trace objects.
>
> Signed-off-by: Jan Kiszka
> ---
> Makefile | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
Acked-by: Stefan Hajnoczi
Instead of preparing all traced args, jumping into the common trace
function, even collecting a timestamp, do the check if a particular
tracepoint is enabled inline. Also, mark the enabled case unlikely to
motivate the compiler to push the trace code out of the fastpath.
Signed-off-by: Jan Kiszka
Am 19.10.2010 15:52, Stefan Hajnoczi wrote:
> On Tue, Oct 19, 2010 at 2:36 PM, Daniel P. Berrange
> wrote:
>> On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
>>> Hi Stefan,
>>>
>>> just had a closer look at qemu's new tracing framework. Looks cool,
>>> though it leaves a bit room for
On Tue, Oct 19, 2010 at 03:46:35PM +0200, Jan Kiszka wrote:
> Am 19.10.2010 15:30, Stefan Hajnoczi wrote:
> > On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
> >> One quirk I stumbled over quickly was the "disable" tag in trace-events.
> >> It confused me first as qemu starts without an
On 10/19/2010 03:38 PM, Stefan Hajnoczi wrote:
bdrv_aio_freeze() or any mechanism to deal with pending requests in
the generic block code would be a good step for future "live" support
of other operations like truncate.
+ logical disk grow, etc.
--
error compiling committee.c: too many argume
> > Isaku Yamahata (14):
> > pci: introduce helper functions to test-and-{clear, set} mask in
> > configuration space
> > pci: introduce helper function to handle msi-x and msi.
> > pci: use pci_word_test_and_clear_mask() in pci_device_reset()
> > pci/bridge: fix pci_bridge_reset()
> >
On Tue, Oct 19, 2010 at 2:36 PM, Daniel P. Berrange wrote:
> On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
>> Hi Stefan,
>>
>> just had a closer look at qemu's new tracing framework. Looks cool,
>> though it leaves a bit room for improvements. ;)
>>
>> One quirk I stumbled over quick
qemu_malloc instrumentations require linking against the trace objects.
Signed-off-by: Jan Kiszka
---
Makefile | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 252c817..106a401 100644
--- a/Makefile
+++ b/Makefile
@@ -140,12 +140,12 @@
On Tue, Oct 19, 2010 at 2:46 PM, Jan Kiszka wrote:
> Am 19.10.2010 15:30, Stefan Hajnoczi wrote:
>> On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
>>> One quirk I stumbled over quickly was the "disable" tag in trace-events.
>>> It confused me first as qemu starts without any tracepoin
On Tue, Oct 19, 2010 at 02:44:35PM +0100, Stefan Hajnoczi wrote:
> On Tue, Oct 19, 2010 at 2:35 PM, Michael S. Tsirkin wrote:
> > On Tue, Oct 19, 2010 at 08:12:42AM -0500, Anthony Liguori wrote:
> >> On 10/19/2010 08:07 AM, Stefan Hajnoczi wrote:
> >> >Is there anything stopping this patch from be
Am 19.10.2010 15:30, Stefan Hajnoczi wrote:
> On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
>> One quirk I stumbled over quickly was the "disable" tag in trace-events.
>> It confused me first as qemu starts without any tracepoint enabled by
>> default and I thought I had to hack the f
On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
> One quirk I stumbled over quickly was the "disable" tag in trace-events.
> It confused me first as qemu starts without any tracepoint enabled by
> default and I thought I had to hack the file. Then I read the doc and
> wondered which exi
On 10/19/2010 08:27 AM, Avi Kivity wrote:
On 10/19/2010 03:22 PM, Anthony Liguori wrote:
I had assumed that this would involve:
qemu -hda windows.img
(qemu) snapshot ide0-disk0 snap0.img
1) create snap0.img internally by doing the equivalent of `qemu-img
create -f qcow2 -b windows.img snap
On 10/19/2010 02:58 PM, Dor Laor wrote:
On 10/19/2010 02:55 PM, Avi Kivity wrote:
On 10/19/2010 02:48 PM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you are interested in covering.
- 0.13.X -stab
Hi,
There is no problem to loop over all usb devices. But first of all I
don't want to loop on used, since then I miss any detached devices,
so I actually do want the same behavior of qdev_find_recursive, and
since it's already available, why rewrite it in a different
compilation unit?
Point
Hi,
+.help = "attach USB device 'bus.addr'",
+...@item usb_attach @var{devname}
/me sees a mismatch here.
There is still the use case question. Also note that this might have
unwanted side effects when drivers automagically attach/detach devices
like usb-host.
Having t
On 10/19/2010 07:48 AM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you are interested in covering.
- 0.13.X -stable handoff
- 0.14 planning
- threadlet work
- virtfs proposals
- Live snapshots
*
Call for Presentations
1st International QEMU Users Forum
March 18th, 2011, Grenoble, France
*
Deadlines:
Extended abstract
As a general comment, could you please try to split this patch
up, to make it easier to review? I did a pass over it but I am
still not understanding it completely.
My main concern is with the fact that we add more state
in notifiers that can easily get out of sync with users.
If we absolutely nee
On Tue, Oct 19, 2010 at 2:35 PM, Michael S. Tsirkin wrote:
> On Tue, Oct 19, 2010 at 08:12:42AM -0500, Anthony Liguori wrote:
>> On 10/19/2010 08:07 AM, Stefan Hajnoczi wrote:
>> >Is there anything stopping this patch from being merged?
>>
>> Michael, any objections? If not, I'll merge it.
>
> I
On Tue, Oct 19, 2010 at 08:12:42AM -0500, Anthony Liguori wrote:
> On 10/19/2010 08:07 AM, Stefan Hajnoczi wrote:
> >Is there anything stopping this patch from being merged?
>
> Michael, any objections? If not, I'll merge it.
I don't really understand what's going on there. The extra state in
n
’ from incompatible pointer type
/home/anthony/git/qemu/kvm.h:180: note: expected ‘target_phys_addr_t *’
but argument is of type ‘long unsigned int *’
make[1]: *** [kvm.o] Error 1
make: *** [subdir-i386-softmmu] Error 2
I've pushed my tree to http://repo.or.cz/w/qemu/aliguori.git
qemu-kvm-201
On Tue, Oct 19, 2010 at 2:33 PM, Anthony Liguori wrote:
> On 10/19/2010 08:27 AM, Avi Kivity wrote:
>>
>> On 10/19/2010 03:22 PM, Anthony Liguori wrote:
>>>
>>> I had assumed that this would involve:
>>>
>>> qemu -hda windows.img
>>>
>>> (qemu) snapshot ide0-disk0 snap0.img
>>>
>>> 1) create snap
On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
> Hi Stefan,
>
> just had a closer look at qemu's new tracing framework. Looks cool,
> though it leaves a bit room for improvements. ;)
>
> One quirk I stumbled over quickly was the "disable" tag in trace-events.
> It confused me first a
On Tue, Oct 19, 2010 at 06:06:27PM +0900, Isaku Yamahata wrote:
> Here is v5 of the pcie patch series.
> I hope I addressed the blockers.
> On uncorrectable error status register in pcie_aer_write_config().
> The register is RW1CS, so making it writable and test-and-clear doesn't
> work.
>
> new p
On Thu, Sep 30, 2010 at 03:01:52PM +0100, Stefan Hajnoczi wrote:
> Virtqueue notify is currently handled synchronously in userspace virtio.
> This prevents the vcpu from executing guest code while hardware
> emulation code handles the notify.
>
> On systems that support KVM, the ioeventfd mechanis
On 10/19/2010 07:48 AM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you are interested in covering.
- 0.13.X -stable handoff
- 0.14 planning
- threadlet work
- virtfs proposals
- Live snapshots
On 10/19/2010 03:22 PM, Anthony Liguori wrote:
I had assumed that this would involve:
qemu -hda windows.img
(qemu) snapshot ide0-disk0 snap0.img
1) create snap0.img internally by doing the equivalent of `qemu-img
create -f qcow2 -b windows.img snap0.img'
2) bdrv_flush('ide0-disk0')
3) bdrv
Hi Stefan,
just had a closer look at qemu's new tracing framework. Looks cool,
though it leaves a bit room for improvements. ;)
One quirk I stumbled over quickly was the "disable" tag in trace-events.
It confused me first as qemu starts without any tracepoint enabled by
default and I thought I ha
+USBDevice *usb_device_by_id(const char* id)
+{
+USBBus *bus;
+DeviceState *qdev;
+USBDevice *dev;
+
+QTAILQ_FOREACH(bus,&busses, next) {
+qdev = qdev_find_recursive(&bus->qbus, id);
+if (qdev != NULL) {
+dev = DO_UPCAST(USBDevice, qdev, qdev);
+
On 10/19/2010 08:07 AM, Stefan Hajnoczi wrote:
Is there anything stopping this patch from being merged?
Michael, any objections? If not, I'll merge it.
Regards,
Anthony Liguori
Thanks,
Stefan
- "Gerd Hoffmann" wrote:
> > +USBDevice *usb_device_by_id(const char* id)
> > +{
> > +USBBus *bus;
> > +DeviceState *qdev;
> > +USBDevice *dev;
> > +
> > +QTAILQ_FOREACH(bus,&busses, next) {
> > +qdev = qdev_find_recursive(&bus->qbus, id);
> > +if (qdev != NUL
On 10/19/2010 08:03 AM, Avi Kivity wrote:
On 10/19/2010 02:58 PM, Dor Laor wrote:
On 10/19/2010 02:55 PM, Avi Kivity wrote:
On 10/19/2010 02:48 PM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you a
On 10/19/2010 02:55 PM, Avi Kivity wrote:
On 10/19/2010 02:48 PM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you are interested in covering.
- 0.13.X -stable handoff
- 0.14 planning
- threadlet wor
On 10/19/2010 02:48 PM, Dor Laor wrote:
On 10/19/2010 04:11 AM, Chris Wright wrote:
* Juan Quintela (quint...@redhat.com) wrote:
Please send in any agenda items you are interested in covering.
- 0.13.X -stable handoff
- 0.14 planning
- threadlet work
- virtfs proposals
- Live snapshots
1 - 100 of 150 matches
Mail list logo
