On 11/02/2011 08:56 PM, Gerd Hoffmann wrote:
Hi,
static void usb_hub_detach(USBPort *port1)
pulled, In what cases, the usb hub will be suspended? and how to tell it
happened? thanks.
The guest enables the remote-wakeup feature. 'lspci -v' (within the
guest) shows it.
cheers,
Gerd
I don't know how to convert the guest virtual address to a guest
physical address. But I believe that the guest virtual address to
guest physical address mapping table should belong to the guest OS and
stay at guest context. So you should know where is the mapping
table in the guest OS by guest
On Wed, Nov 02, 2011 at 09:16:34AM +0200, Michael S. Tsirkin wrote:
> On Mon, Oct 31, 2011 at 05:06:49PM +1100, David Gibson wrote:
> > From: Eduard - Gabriel Munteanu
[snip]
> > @@ -744,21 +713,26 @@ static void dump_statistics(EEPRO100State * s)
> > * values which really matter.
> >
If a pflash image is found, then it is used for the system
firmware image.
If a pflash image is not initially found, then a read-only
pflash device is created using the -bios filename.
KVM cannot execute from a pflash region currently.
Therefore, when KVM is enabled, a (read-only) ram memory
regi
When read-only mode is enabled, no changes will be made
to the flash image in memory, and no bdrv_write calls will be
made.
For pflash_cfi01 (Intel), if the flash is in read-only mode
then the status register will signal block erase error or
program error when these operations are attempted.
For
Enable flash emulation in a PC system using pflash_cfi01.
v7:
* Do not add system firmware to qemu roms
* If kvm is enabled, copy pflash drive contents into a
read-only ram region, since kvm cannot currently execute
code from a pflash device.
* Rename pcflash.c to pc_sysfw.c
v6:
* Rebase for
On Wed, 2 Nov 2011 21:02:42 +0200, "Michael S. Tsirkin" wrote:
> MSIX spec requires that device can be operated with
> all vectors masked, by polling.
>
> So the following patchset (lightly tested) adds this
> ability: when driver reads ISR, the device
> recalls a pending notification, and return
On Wed, Nov 2, 2011 at 7:51 PM, Kevin Wolf wrote:
> Am 02.11.2011 07:01, schrieb Zhi Yong Wu:
>> Signed-off-by: Zhi Yong Wu
>> Signed-off-by: Stefan Hajnoczi
>> ---
>> block.c | 233
>> +++--
>> block.h | 1 +
>> block
On Wed, Nov 2, 2011 at 7:32 PM, Kevin Wolf wrote:
> Am 02.11.2011 07:01, schrieb Zhi Yong Wu:
>> Signed-off-by: Zhi Yong Wu
>> Signed-off-by: Stefan Hajnoczi
>> ---
>> block.c | 40
>> block.h | 4
>> block_int.h | 29
On 11/01/2011 02:36 AM, Corey Bryant wrote:
The default bridge that we attach to is br0. The thinking is that a distro
could preconfigure such an interface to allow out-of-the-box bridged networking.
Alternatively, if a user wants to use a different bridge, they can say:
qemu linux.img -net
I also tried this issue with Intel 82576EI NIC, and this normal VT-D NIC
doesn't have this detachment issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/875723
Title:
guest aborts when detaching
The Buildbot has detected a new failure on builder default_x86_64_fedora16
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_fedora16/builds/74
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_fedora
On 11/02/2011 05:48 AM, Zhi Yong Wu wrote:
On Wed, Oct 26, 2011 at 10:41 PM, Lucas Meneghel Rodrigues
wrote:
Hi folks:
We've captured a regression with floppy disk on recent qemu (and qemu-kvm,
after a code merge). We bisected it to be caused by:
commit 212ec7baa28cc9d819234fed1541fc1423cfe3
On Wed, Nov 02, 2011 at 09:11:57PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 02, 2011 at 06:56:55PM +0100, Alexander Graf wrote:
> > It gets us that downstreams can convert to the API for 1.0. It just
> > feels a lot more right to change APIs for a 1.0 release than a 1.1 release.
>
> Anyway,
On 11/02/2011 11:19 PM, Anthony Liguori wrote:
On 11/02/2011 05:16 PM, Frans de Boer wrote:
When compiling QEMU 0.15.x with the option --disable-cpu-emulation, I
get an
abort on fake-exec.c. It can't find the file exec.h.
QEMU does not have such an option. You're likely using qemu-kvm.
Regar
On 11/02/2011 05:16 PM, Frans de Boer wrote:
When compiling QEMU 0.15.x with the option --disable-cpu-emulation, I get an
abort on fake-exec.c. It can't find the file exec.h.
QEMU does not have such an option. You're likely using qemu-kvm.
Regards,
Anthony Liguori
Any solution/suggestion
When compiling QEMU 0.15.x with the option --disable-cpu-emulation, I
get an abort on fake-exec.c. It can't find the file exec.h.
Any solution/suggestion?
Regards, Frans.
On Tuesday 01 November 2011 19:43:53 Anthony Liguori wrote:
> Hi,
>
> I've just pushed the VERSION update so we are officially in hard freeze.
>
> I've cleared out my patch and pull request queues and processed everything
> I intend on processing for 1.0.
>
> If you're a contributor and have a q
Hi,
i forgot to address this concern:
Paolo Bonzini wrote:
> The page length is indeed 18 for IDE and 20 for SCSI. I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.
The SCSI client is supposed
On Wed, Nov 02, 2011 at 01:52:55PM +1030, Rusty Russell wrote:
> On Tue, 01 Nov 2011 17:20:06 -0500, Anthony Liguori
> wrote:
> > On 09/30/2011 12:26 AM, David Gibson wrote:
> > > Currently, virtio devices are usually presented to the guest as an
> > > emulated PCI device, virtio_pci. Although t
Hi,
i wrote:
> > So how is this altered to 0x12 in the further course of processing ?
Paolo Bonzini wrote:
> Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI. See hw/ide/atapi.c.
You convinced me.
But this does not explain yet the difference in behavior of
both groups of IDE DVD-ROMs. Why
On Mon, Oct 31, 2011 at 22:17, Max Filippov wrote:
> The following fixes for target-xtensa targeting 1.0 are available in the git
> repository at
>
> git://jcmvbkbc.spb.ru/dumb/qemu-xtensa.git xtensa
Thanks, pulled.
> Max Filippov (7):
> target-xtensa: mask out undefined bits of WINDOWBASE SR
On Mon, Oct 31, 2011 at 21:31, Stefan Weil wrote:
> Hi,
>
> this is a 3rd version of the patch series which adds support for
> QEMU on any host by using a TCG interpreter (TCI).
>
> Version 2 was sent to the list and is available here:
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg0250
On 11/02/2011 03:24 PM, Blue Swirl wrote:
On Wed, Nov 2, 2011 at 19:35, Anthony Liguori wrote:
For the record, I'm opposed to ever having a stable plugin API.
We aren't a closed source product. If people want to have to keep up with
our changing internal interfaces, they can get their code me
Blue Swirl wrote:
> On Tue, Nov 1, 2011 at 21:41, Anthony Liguori wrote:
>
>> On 11/01/2011 04:05 PM, Blue Swirl wrote:
>>
>>> Thanks, pulled and reverted libfdt patch.
>>>
>> Er, this broke the build:
>>
>> CCppc64-softmmu/spapr_pci.o
>> /home/anthony/git/qemu/hw/spapr_pci.c:
On Wed, Nov 2, 2011 at 19:35, Anthony Liguori wrote:
> On 11/02/2011 02:27 PM, Alexander Graf wrote:
>>
>> Peter Maydell wrote:
>>>
>>> On 2 November 2011 18:47, Alexander Graf wrote:
>>>
Jan Kiszka wrote:
> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
On 11/02/2011 02:59 PM, Blue Swirl wrote:
On Tue, Nov 1, 2011 at 21:41, Anthony Liguori wrote:
On 11/01/2011 04:05 PM, Blue Swirl wrote:
Thanks, pulled and reverted libfdt patch.
Er, this broke the build:
CCppc64-softmmu/spapr_pci.o
/home/anthony/git/qemu/hw/spapr_pci.c: In function
MSIX spec requires that device can be operated with
all vectors masked, by polling pending bits.
Add APIs to recall an msix notification, and make polling
mode possible in virtio-pci by clearing the
pending bits and setting ISR appropriately on ISR read.
Signed-off-by: Michael S. Tsirkin
---
hw/
Add constants for ISR bits values, and use them in virtio.
Signed-off-by: Michael S. Tsirkin
---
hw/virtio.c |7 ---
hw/virtio.h |5 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index 7011b5b..74627e4 100644
--- a/hw/virtio.c
+++ b/hw
On Wed, Nov 2, 2011 at 13:10, Anthony Liguori wrote:
> On 11/02/2011 08:08 AM, Max Filippov wrote:
>>
>> Hi.
>>
>>> If you're a contributor and have a question about a patch that didn't
>>> make
>>> the hard freeze, please feel free to ask about it, but at this point,
>>> it's
>>> very unlikely to
On Tue, Nov 1, 2011 at 21:41, Anthony Liguori wrote:
> On 11/01/2011 04:05 PM, Blue Swirl wrote:
>>
>> Thanks, pulled and reverted libfdt patch.
>
> Er, this broke the build:
>
> CC ppc64-softmmu/spapr_pci.o
> /home/anthony/git/qemu/hw/spapr_pci.c: In function ‘find_dev’:
> /home/anthony/git/q
On 2 November 2011 19:52, Paolo Bonzini wrote:
> (Also, the unchaining is safer, or even completely safe in system mode than
> it is with pthreads).
I don't think it's completely safe, you're just a bit less likely
to get bitten than if you're trying to run a linux-user-mode
multithreaded guest b
On 11/02/2011 07:01 PM, Peter Maydell wrote:
On 2 November 2011 17:45, Paolo Bonzini wrote:
The rest is always done in the iothread. The iothread will then
suspend/resume the VCPU thread around the unchaining, so what matters is (in
Unix parlance) signal-safety of the unchaining, not thread-sa
On 11/02/2011 07:05 PM, Thomas Schmitt wrote:
> The page length is indeed 18 for IDE and 20 for SCSI. I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.
This riddles me.
In hw/scsi-disk.c:mo
The boehm gc finds the program's stack starting pointer by
checking /proc/self/stat. Unfortunately, so far it reads
qemu's stack pointer which clearly is wrong.
So let's instead fake the file so the guest program sees the
right address.
Signed-off-by: Alexander Graf
---
linux-user/syscall.c |
There are a number of files in /proc that expose host information
to the guest program. This patch adds infrastructure to override
the open() syscall for guest programs to enable us to on the fly
generate guest sensible files.
Signed-off-by: Alexander Graf
---
linux-user/syscall.c | 52 +++
On 11/02/2011 02:27 PM, Alexander Graf wrote:
Peter Maydell wrote:
On 2 November 2011 18:47, Alexander Graf wrote:
Jan Kiszka wrote:
We should also be able to establish an EXPORT_SYMBOL concept, ie. only
export those functions that are supposed to be part of a component API.
Will be some wo
Peter Maydell wrote:
> On 2 November 2011 18:47, Alexander Graf wrote:
>
>> Jan Kiszka wrote:
>>
>>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>>> export those functions that are supposed to be part of a component API.
>>> Will be some work initially, but shoul
Gtk tries to read /proc/self/auxv to find its auxv table instead of
taking it from its own program memory space.
However, when running with linux-user, we see the host's auxv which
clearly exposes wrong information. so let's instead expose the guest
memory backed auxv tables via /proc/self/auxv as
glibc's pthread_attr_getstack tries to find the stack range from
/proc/self/maps. Unfortunately, /proc is usually the host's /proc
which means linux-user guests see qemu's stack there.
Fake the file with a constructed maps entry that exposes the guest's
stack range.
Signed-off-by: Alexander Graf
We create our own AUXV segment on stack and save a pointer to it.
However we don't save the length of it, so any code that wants to
do anything useful with it later on has to walk it again.
Instead, let's remember the length of our AUXV segment. This
simplifies later uses by a lot.
Signed-off-by:
When running linux-user programs in QEMU, the guest program can examine
itself by checking /proc/self/ files. And some libraries really do use
this!
Unfortunately, when checking /proc/self/ today, the guest program sees
the QEMU files, exposing wrong information to the guest program.
This patch s
On Wed, Nov 02, 2011 at 06:56:55PM +0100, Alexander Graf wrote:
> It gets us that downstreams can convert to the API for 1.0. It just
> feels a lot more right to change APIs for a 1.0 release than a 1.1 release.
Anyway, I hope at least what looks like the alignment bug
in eepro100 introduced by th
On 2 November 2011 18:47, Alexander Graf wrote:
> Jan Kiszka wrote:
>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>> export those functions that are supposed to be part of a component API.
>> Will be some work initially, but should be off long term, both to QEMU
>> in m
MSIX spec requires that device can be operated with
all vectors masked, by polling.
So the following patchset (lightly tested) adds this
ability: when driver reads ISR, the device
recalls a pending notification, and returns
pending status in the ISR register.
The polling driver can operate as fol
On 2011-11-02 19:50, Anthony Liguori wrote:
> On 11/02/2011 01:46 PM, Jan Kiszka wrote:
>> On 2011-11-02 19:34, Alexander Graf wrote:
>>> Anthony Liguori wrote:
On 11/02/2011 01:17 PM, Jan Kiszka wrote:
> On 2011-11-02 18:44, Fabien Chouteau wrote:
>> On 31/10/2011 14:12, Peter Maydell
On 11/02/2011 01:34 PM, Alexander Graf wrote:
Anthony Liguori wrote:
On 11/02/2011 01:17 PM, Jan Kiszka wrote:
On 2011-11-02 18:44, Fabien Chouteau wrote:
On 31/10/2011 14:12, Peter Maydell wrote:
On 29 October 2011 14:52, Alexander Graf wrote:
A lot of people seem to also have code that d
On 11/02/2011 01:46 PM, Jan Kiszka wrote:
On 2011-11-02 19:34, Alexander Graf wrote:
Anthony Liguori wrote:
On 11/02/2011 01:17 PM, Jan Kiszka wrote:
On 2011-11-02 18:44, Fabien Chouteau wrote:
On 31/10/2011 14:12, Peter Maydell wrote:
On 29 October 2011 14:52, Alexander Graf wrote:
A lot
Jan Kiszka wrote:
> On 2011-11-02 19:34, Alexander Graf wrote:
>
>> Anthony Liguori wrote:
>>
>>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>>
On 2011-11-02 18:44, Fabien Chouteau wrote:
> On 31/10/2011 14:12, Peter Maydell wrote:
>
>> On 29
On 2011-11-02 19:34, Alexander Graf wrote:
> Anthony Liguori wrote:
>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
On 31/10/2011 14:12, Peter Maydell wrote:
> On 29 October 2011 14:52, Alexander Graf wrote:
>> A lot of people seem to also
Anthony Liguori wrote:
> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>> On 31/10/2011 14:12, Peter Maydell wrote:
On 29 October 2011 14:52, Alexander Graf wrote:
> A lot of people seem to also have code that doesn't make sense
> upstream,
On 11/02/2011 01:17 PM, Jan Kiszka wrote:
On 2011-11-02 18:44, Fabien Chouteau wrote:
On 31/10/2011 14:12, Peter Maydell wrote:
On 29 October 2011 14:52, Alexander Graf wrote:
A lot of people seem to also have code that doesn't make sense
upstream, for example implementing a one-off device th
Need Help!
I am editing the Qemu source code to be able to catch every system call made by
the guest OS and which processes do those system calls.
I catch the system calls in the "void do_interrupt(CPUState *env1)"
(op_helper.c) function by accessing the exception index on the cpu environment
On 2011-11-02 18:44, Fabien Chouteau wrote:
> On 31/10/2011 14:12, Peter Maydell wrote:
>> On 29 October 2011 14:52, Alexander Graf wrote:
>>> A lot of people seem to also have code that doesn't make sense
>>> upstream, for example implementing a one-off device that only
>>> really matters for the
Hi,
i wrote:
> > The sense code is listed in MMC as:
> >B 00 06 I/O PROCESS TERMINATED
Paolo Bonzini wrote:
> Is it good or bad? :) I see it even in the very first command.
It does not indicate success. MMC only has the meager info above.
SPC-3 says in table 27 about sense key B:
"Bh : AB
On 2 November 2011 17:45, Paolo Bonzini wrote:
> The rest is always done in the iothread. The iothread will then
> suspend/resume the VCPU thread around the unchaining, so what matters is (in
> Unix parlance) signal-safety of the unchaining, not thread-safety.
The unchaining is neither signal-sa
On Wed, 2 Nov 2011, Paolo Bonzini wrote:
> On 11/02/2011 06:16 PM, malc wrote:
> > (mm)Timers have a possibility of running on a thread of their own which
> > might be schedulled on the CPU different from the thread that runs
> > emulated code, unchaining TBs and can (and will) fail in this case.
On 11/02/2011 06:16 PM, malc wrote:
(mm)Timers have a possibility of running on a thread of their own which
might be schedulled on the CPU different from the thread that runs
emulated code, unchaining TBs and can (and will) fail in this case.
This should not be a problem with dynticks+iothread
On 31/10/2011 14:12, Peter Maydell wrote:
> On 29 October 2011 14:52, Alexander Graf wrote:
>> A lot of people seem to also have code that doesn't make sense
>> upstream, for example implementing a one-off device that only
>> really matters for their own devboard which nobody else owns.
>> For suc
I am getting 'system_u:object_r:svirt_image_t:s0:c129,c783' on
'/var/lib/libvirt/images/vm01.img': Permission denied'
when I try to install using virt-manager.
#semanage fcontext -l | grep images
/var/lib/libvirt/images(/.*)? all files
system_u:object_r:svirt_imag
Richard Henderson wrote:
> The error being caused by the failure to copy the other half of
> the input to the output after having narrowed the deposit operation.
>
Thanks, this makes my ppc32 host work again :)
Alex
Anthony Liguori wrote:
> On 11/02/2011 12:56 PM, Alexander Graf wrote:
>> Michael S. Tsirkin wrote:
>>> On Tue, Nov 01, 2011 at 03:24:28PM -0500, Anthony Liguori wrote:
>>>
>>> What does it get us, applying it before freeze?
>>> It's an api change without new functionality.
>>> Seems better on -nex
Avi Kivity wrote:
> On 11/02/2011 08:23 PM, Alexander Graf wrote:
>
>>> Plus, remove the tachyons from your system.
>>>
>>>
>> Ah, yes. That helped a lot. Damn those tachyons!
>>
>
> They're still there.
>
> (I hate explaining a joke, but your system clock is an hour ahead)
>
On 11/02/2011 08:23 PM, Alexander Graf wrote:
> >
> > Plus, remove the tachyons from your system.
> >
>
> Ah, yes. That helped a lot. Damn those tachyons!
They're still there.
(I hate explaining a joke, but your system clock is an hour ahead)
--
error compiling committee.c: too many argument
Avi Kivity wrote:
> On 11/02/2011 07:12 PM, Avi Kivity wrote:
>
>> On 11/02/2011 08:10 PM, Alexander Graf wrote:
>>
>>> Anthony Liguori wrote:
>>>
On 09/27/2011 09:26 AM, Avi Kivity wrote:
> Has no business in hw/.
>
> Signed-off-by: Avi Kivity
>
On 11/02/2011 12:56 PM, Alexander Graf wrote:
Michael S. Tsirkin wrote:
On Tue, Nov 01, 2011 at 03:24:28PM -0500, Anthony Liguori wrote:
What does it get us, applying it before freeze?
It's an api change without new functionality.
Seems better on -next branch.
It gets us that downstreams can
On Wed, 2 Nov 2011, Fabien Chouteau wrote:
> On 02/11/2011 17:25, Paolo Bonzini wrote:
> > On 11/02/2011 04:38 PM, Fabien Chouteau wrote:
> >> Hello fellow Qemu aficionados,
> >>
> >> On Windows, Qemu sets the affinity mask in order to run all thread on
> >> CPU0, with this comment in the code (os
On 11/02/2011 07:12 PM, Avi Kivity wrote:
> On 11/02/2011 08:10 PM, Alexander Graf wrote:
> > Anthony Liguori wrote:
> > > On 09/27/2011 09:26 AM, Avi Kivity wrote:
> > >> Has no business in hw/.
> > >>
> > >> Signed-off-by: Avi Kivity
> > >
> > > Applied. Thanks.
> >
> > make: *** No rule to make
On 11/02/2011 08:10 PM, Alexander Graf wrote:
> Anthony Liguori wrote:
> > On 09/27/2011 09:26 AM, Avi Kivity wrote:
> >> Has no business in hw/.
> >>
> >> Signed-off-by: Avi Kivity
> >
> > Applied. Thanks.
>
> make: *** No rule to make target
> `/home/agraf/release/qemu/hw/event_notifier.c', need
On 02/11/2011 17:25, Paolo Bonzini wrote:
> On 11/02/2011 04:38 PM, Fabien Chouteau wrote:
>> Hello fellow Qemu aficionados,
>>
>> On Windows, Qemu sets the affinity mask in order to run all thread on
>> CPU0, with this comment in the code (os-win32.c:182):
>>
>> /* Note: cpu_interrupt() is cu
Anthony Liguori wrote:
> On 09/27/2011 09:26 AM, Avi Kivity wrote:
>> Has no business in hw/.
>>
>> Signed-off-by: Avi Kivity
>
> Applied. Thanks.
make: *** No rule to make target
`/home/agraf/release/qemu/hw/event_notifier.c', needed by
`event_notifier.o'. Stop.
make: *** Waiting for unfinished
Michael S. Tsirkin wrote:
> On Tue, Nov 01, 2011 at 03:24:28PM -0500, Anthony Liguori wrote:
>
>> On 10/31/2011 11:45 AM, Stefan Weil wrote:
>>
>>> Am 31.10.2011 07:06, schrieb David Gibson:
>>>
From: Eduard - Gabriel Munteanu
This updates the eepro100 device emulation
Am 02.11.2011 14:26, schrieb Nigel Horne:
Public bug reported:
The latest GIT version (e072ea2fd8fdceef64159b9596d3c15ce01bea91) fails
to compile.
Host: debian x86-64. gcc 4.6.2
...
CCcris-softmmu/pci-stub.o
...
In file included from /home/njh/src/qemu/hw/pci-stub.c:24:0:
./qmp-command
Am 02.11.2011 16:43, schrieb Stefan Hajnoczi:
> On Tue, Nov 1, 2011 at 6:06 PM, Marcelo Tosatti wrote:
>> On Thu, Oct 27, 2011 at 04:22:50PM +0100, Stefan Hajnoczi wrote:
>>> +static int stream_one_iteration(StreamBlockJob *s, int64_t sector_num,
>>> +void *buf, int
On 11/02/2011 05:26 PM, Thomas Schmitt wrote:
Hi,
Paolo Bonzini wrote:
I suggest trying with 1.0-rc (origin/master).
Am i on the right track with git clone git://git.qemu.org/qemu.git ?
Yes.
scsi-block uses
read+write for READ/WRITE CDBs and SG_IO for everything else.
That sounds scar
Am 17.10.2011 17:47, schrieb Stefan Hajnoczi:
> The bdrv_set_copy_on_read() function can be used to programmatically
> enable or disable copy-on-read for a block device. Later patches add
> the actual copy-on-read logic.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> block.c | 17
Am 17.10.2011 17:47, schrieb Stefan Hajnoczi:
> The block layer does not know about pending requests. This information
> is necessary for copy-on-read since overlapping requests must be
> serialized to prevent races that corrupt the image.
>
> Add a simple mechanism to enable/disable request trac
Hi,
Paolo Bonzini wrote:
> I suggest trying with 1.0-rc (origin/master).
Am i on the right track with git clone git://git.qemu.org/qemu.git ?
> scsi-block uses
> read+write for READ/WRITE CDBs and SG_IO for everything else.
That sounds scary to me. On real Linux systems it is not advisable t
On 11/02/2011 04:38 PM, Fabien Chouteau wrote:
Hello fellow Qemu aficionados,
On Windows, Qemu sets the affinity mask in order to run all thread on
CPU0, with this comment in the code (os-win32.c:182):
/* Note: cpu_interrupt() is currently not SMP safe, so we force
QEMU to run on a
On 11/02/2011 04:15 PM, Thomas Schmitt wrote:
Hi,
Stefan Hajnoczi wrote:
I actually suggest focussing just
on qemu.git/master because that is where developers mostly invest
their time.
I did now
git clone git://git.qemu.org/qemu.git
cd qemu&& ./configure&& make
I assume this binary i
On 11/02/2011 04:12 AM, Mark Wu wrote:
On 11/02/2011 01:13 AM, Corey Bryant wrote:
static int net_tap_init(QemuOpts *opts, int *vnet_hdr)
{
int fd, vnet_hdr_required;
@@ -433,8 +570,11 @@ int net_init_tap(QemuOpts *opts, Monitor *mon,
const char *name, VLANState *vlan
if (qemu_opt_get(opts, "i
Anthony Liguori writes:
> On 11/02/2011 05:22 AM, Aneesh Kumar K.V wrote:
>>
>> The following changes since commit e072ea2fd8fdceef64159b9596d3c15ce01bea91:
>>
>>Bump version to 1.0-rc0 (2011-11-01 19:37:01 -0500)
>>
>> are available in the git repository at:
>>git://repo.or.cz/qemu/v9fs.
On 11/02/2011 06:58 AM, Stefan Hajnoczi wrote:
On Tue, Nov 1, 2011 at 5:13 PM, Corey Bryant wrote:
+static bool has_vnet_hdr(int fd)
+{
+unsigned int features = 0;
+struct ifreq ifreq;
+
+if (ioctl(fd, TUNGETFEATURES,&features) == -1) {
+return false;
+}
+
+if (!(fea
On Tue, Nov 1, 2011 at 6:06 PM, Marcelo Tosatti wrote:
> On Thu, Oct 27, 2011 at 04:22:50PM +0100, Stefan Hajnoczi wrote:
>> +static int stream_one_iteration(StreamBlockJob *s, int64_t sector_num,
>> + void *buf, int max_sectors, int *n)
>> +{
>> + BlockDriverStat
Hello fellow Qemu aficionados,
On Windows, Qemu sets the affinity mask in order to run all thread on
CPU0, with this comment in the code (os-win32.c:182):
/* Note: cpu_interrupt() is currently not SMP safe, so we force
QEMU to run on a single CPU */
This was added by Fabrice Bellard i
Hi,
Stefan Hajnoczi wrote:
> I actually suggest focussing just
> on qemu.git/master because that is where developers mostly invest
> their time.
I did now
git clone git://git.qemu.org/qemu.git
cd qemu && ./configure && make
I assume this binary is the right one for my "AMD Athlon(tm) II X4 6
On Wed, 02 Nov 2011 07:42:16 -0500, Anthony Liguori wrote:
> On 11/02/2011 05:22 AM, Aneesh Kumar K.V wrote:
> >
> > The following changes since commit e072ea2fd8fdceef64159b9596d3c15ce01bea91:
> >
> >Bump version to 1.0-rc0 (2011-11-01 19:37:01 -0500)
> >
> > are available in the git reposito
Public bug reported:
The latest GIT version (e072ea2fd8fdceef64159b9596d3c15ce01bea91) fails
to compile.
Host: debian x86-64. gcc 4.6.2
...
CCcris-softmmu/pci-stub.o
...
In file included from /home/njh/src/qemu/hw/pci-stub.c:24:0:
./qmp-commands.h: At top level:
./qmp-commands.h:3:1: erro
Am 02.11.2011 09:36, schrieb Dong Xu Wang:
> From: Dong Xu Wang
>
> Fix coding style in block/cloop.c.
>
> v3: Split to 2 patches: one for fixing coding style, one for replacing free
> with
> g_free. And correct other 2 places with coding style problem.
> v2: Fix spelling: gfree->g_free.
>
On 11/02/2011 02:31 PM, Stefan Weil wrote:
Commit 2f9cba0c148af32fad6813480f5c92efe17c2d49 re-added mmtimer2
because it had existed before (it was called "dynticks" and the
default for w32) and was needed for Linux. It also added mmtimer, a
multimedia timer without rearm.
Yes, I missed that it
According to ISA, table 5-156, bits 32:NAREG/4 of the WINDOWSTART SR
must be zero.
Signed-off-by: Max Filippov
---
v1->v2 changes: fix commit log subject
---
target-xtensa/translate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-xtensa/translate.c b/target-xte
Am 02.11.2011 13:54, schrieb Paolo Bonzini:
On 10/31/2011 06:13 PM, Stefan Weil wrote:
They can't be more broken: I noticed today that QEMU on W32 aborts
with the default timer (mmtimer) very quickly.
Is there any reason why mmtimer2 is not the default (or indeed why
mmtimer and win32 exis
On 2 November 2011 13:10, Anthony Liguori wrote:
> On 11/02/2011 08:08 AM, Max Filippov wrote:
>> And also I'd like it to be clarified, whether I should consider myself
>> a contributor or a submaintainer.
>
> If you do PULL requests, you're a submaintainer :-)
Speaking as somebody who spent a wh
On 11/02/2011 02:00 PM, Michael S. Tsirkin wrote:
> When SCSI passthrough is being used by the guest with virtio-blk, the
> guest is not able to detect disk failures. This is because the status
> field is expected by the guest driver to include also the msg_status,
> host_status and driver_s
On 11/02/2011 08:08 AM, Max Filippov wrote:
Hi.
If you're a contributor and have a question about a patch that didn't make
the hard freeze, please feel free to ask about it, but at this point, it's
very unlikely to make it to 1.0.
My pull request for the xtensa
(http://lists.nongnu.org/archiv
Hi.
> If you're a contributor and have a question about a patch that didn't make
> the hard freeze, please feel free to ask about it, but at this point, it's
> very unlikely to make it to 1.0.
My pull request for the xtensa
(http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg03962.html)
h
On Wed, Nov 02, 2011 at 01:19:40PM +0100, Paolo Bonzini wrote:
> When SCSI passthrough is being used by the guest with virtio-blk, the
> guest is not able to detect disk failures. This is because the status
> field is expected by the guest driver to include also the msg_status,
> host_status and d
On 11/02/2011 03:46 AM, bharata@gmail.com wrote:
From: Bharata B Rao
apic id returned to guest kernel in ebx for cpuid(function=1) depends on
CPUX86State->cpuid_apic_id which gets populated after the cpuid information
is cached in the host kernel. This results in broken CPU topology in guest
Hi,
>> static void usb_hub_detach(USBPort *port1)
> pulled, In what cases, the usb hub will be suspended? and how to tell it
> happened? thanks.
The guest enables the remote-wakeup feature. 'lspci -v' (within the
guest) shows it.
cheers,
Gerd
On 11/02/2011 07:19 AM, Paolo Bonzini wrote:
When SCSI passthrough is being used by the guest with virtio-blk, the
guest is not able to detect disk failures. This is because the status
field is expected by the guest driver to include also the msg_status,
host_status and driver_status fields, but
1 - 100 of 152 matches
Mail list logo
