On 06/07/2013 12:29 AM, Frederic Konrad wrote:
> On 06/06/2013 15:59, Alexey Kardashevskiy wrote:
>> On 06.06.2013 22:44, Frederic Konrad wrote:
>>> On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug
yet.
>>
On 07.06.2013 0:29, Frederic Konrad wrote:
> On 06/06/2013 15:59, Alexey Kardashevskiy wrote:
>> On 06.06.2013 22:44, Frederic Konrad wrote:
>>> On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug
yet.
H
On 06/06/2013 15:59, Alexey Kardashevskiy wrote:
On 06.06.2013 22:44, Frederic Konrad wrote:
On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug
yet.
However we still want to hot plug disks.
As a workaround, we could add m
On 06.06.2013 22:44, Frederic Konrad wrote:
> On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
>> Hi!
>>
>> For the pseries platform (server PPC64) we do not support PCI hotplug
>> yet.
>> However we still want to hot plug disks.
>>
>> As a workaround, we could add multiple SCSI host devices
>> (vi
On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug yet.
However we still want to hot plug disks.
As a workaround, we could add multiple SCSI host devices (virtio-scsi-pci,
spapr-vscsi) without any disk attached and later (u
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug yet.
However we still want to hot plug disks.
As a workaround, we could add multiple SCSI host devices (virtio-scsi-pci,
spapr-vscsi) without any disk attached and later (using qemu console)
attach drives to them as we do w
On Mon, 2012-07-02 at 10:06 +1000, Alexey Kardashevskiy wrote:
> I already posted another patch with qemu_notify_event() in this mail
> thread later :)
Yup, just saw that, for some reason I got dropped from the CC list.
BTW. I told you there must be an existing mechanism for that :-)
Cheers,
Ben
On Mon, 2012-07-02 at 10:42 +1000, ronnie sahlberg wrote:
>
> Would it be possible to change the set-event-handlers functions to
> automatically call qemu_notify_event() when the descriptos change?
> To eliminate the need to call this function at all ?
That definitely sounds like the right thing
On Mon, 2012-07-02 at 10:06 +1000, Alexey Kardashevskiy wrote:
> > Won't that conflict with the business in coroutine-sigaltstack.c ?
>
> The code which touches SIGUSR2 does not compile on power.
Oh, we don't get the altstack coroutine stuff ? interesting...
> > Hrm... looking at it, it looks li
Hi,
As Paolo said,
I hit this with block/iscsi.c a few months back.
Then about a month back I recall something that looks alkmost
identical to this hit the IDE driver on the KVM list.
( At least the symptoms looked just like my symptoms, and the KVM guys
managed to bisect it down to the exact same
On 02/07/12 09:07, Benjamin Herrenschmidt wrote:
diff --git a/iohandler.c b/iohandler.c
index 3c74de6..54f4c48 100644
--- a/iohandler.c
+++ b/iohandler.c
@@ -77,6 +77,7 @@ int qemu_set_fd_handler2(int fd,
ioh->fd_write = fd_write;
ioh->opaque = o
> >> diff --git a/iohandler.c b/iohandler.c
> >> index 3c74de6..54f4c48 100644
> >> --- a/iohandler.c
> >> +++ b/iohandler.c
> >> @@ -77,6 +77,7 @@ int qemu_set_fd_handler2(int fd,
> >> ioh->fd_write = fd_write;
> >> ioh->opaque = opaque;
> >> ioh->deleted = 0;
> >> +
> Doesn't qemu remove an fd handler before closing the fd?
> If not that's the bug right there.
No, it's just marked deleted, removal is deferred. But that doesn't
change the fact that you need to wake up select. Ie. What happens is:
- eventfd gets you fd #x
- thread 1 selects() on it which s
Il 01/07/2012 16:46, Alexey Kardashevskiy ha scritto:
> On 01/07/12 23:40, Alexey Kardashevskiy wrote:
>> On 01/07/12 23:32, Paolo Bonzini wrote:
>>> Il 01/07/2012 13:06, Alexey Kardashevskiy ha scritto:
Doing MSI init stuff, QEMU-VFIO calls the same event_notifier_init()
(returns recycle
On 01/07/12 23:40, Alexey Kardashevskiy wrote:
> On 01/07/12 23:32, Paolo Bonzini wrote:
>> Il 01/07/2012 13:06, Alexey Kardashevskiy ha scritto:
>>> Doing MSI init stuff, QEMU-VFIO calls the same event_notifier_init()
>>> (returns recycled fd=XX what is correct but confuses) and
>>> qemu_set_fd_ha
On 01/07/12 23:32, Paolo Bonzini wrote:
> Il 01/07/2012 13:06, Alexey Kardashevskiy ha scritto:
>> Doing MSI init stuff, QEMU-VFIO calls the same event_notifier_init()
>> (returns recycled fd=XX what is correct but confuses) and
>> qemu_set_fd_handler() which adds a handler but select() does not pi
Il 01/07/2012 13:06, Alexey Kardashevskiy ha scritto:
> Doing MSI init stuff, QEMU-VFIO calls the same event_notifier_init()
> (returns recycled fd=XX what is correct but confuses) and
> qemu_set_fd_handler() which adds a handler but select() does not pick
> it up.
This sounds like a missing qemu_
On 01/07/12 22:43, Michael S. Tsirkin wrote:
> On Sun, Jul 01, 2012 at 09:06:20PM +1000, Alexey Kardashevskiy wrote:
>> QEMU from qemu.org/master (not qemu-kvm), linux host 3.4, ppc64.
>>
>> Shortly the problem is in the host kernel: closing a file in one thread does
>> not interrupt select() wait
On Sun, Jul 01, 2012 at 09:06:20PM +1000, Alexey Kardashevskiy wrote:
> QEMU from qemu.org/master (not qemu-kvm), linux host 3.4, ppc64.
>
> Shortly the problem is in the host kernel: closing a file in one thread does
> not interrupt select() waiting on the same file description in another thread
QEMU from qemu.org/master (not qemu-kvm), linux host 3.4, ppc64.
Shortly the problem is in the host kernel: closing a file in one thread does
not interrupt select() waiting on the same file description in another thread.
Longer story is:
I'll use VFIO as an example as I hit this when I was debug
2011/11/9 ad...@mmri.us :
> qemu-users is dead.
> You subscribe and nothing happens.
You mean http://tech.groups.yahoo.com/group/qemu-users/ is dead?
Try https://lists.nongnu.org/mailman/listinfo/qemu-discuss , then. :-)
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of
> I apologize for asking this question on the developers group, but the
> users group is dead.
https://lists.nongnu.org/mailman/listinfo/qemu-discuss
http://tech.groups.yahoo.com/group/qemu-users/
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
I apologize for asking this question on the developers group, but the
users group is dead.
I installed qemu on an IBM 366 Dual processor Rack server.
Qemu is very slow on this machine (Running Debian 6)
I used to use kqemu which made everything faster, but I see that kqemu
is not supported an
23 matches
Mail list logo
