On Mon, Nov 16, 2009 at 04:02:20PM +0200, Avi Kivity wrote:
>> Something that is likely related, I am seeing reboot failures in
>> seabios's pmm_free. Immediately after loading gpxe, seabios is in an
>> endless loop there, likely due to memory corruption.
>>
>> This is with -smp 2, rebooting F
Anthony Liguori wrote:
> Kevin Wolf wrote:
> >We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
> >descriptors that don't need to be passed to children to stop this
> >misbehaviour.
> >
> >Signed-off-by: Kevin Wolf
> >
>
>pid = fork();
>if (pid == 0) {
>
Ian Molton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jamie Lokier wrote:
> > Ian Molton wrote:
> >> Heres my patch to virtio-console. The device is now specified like this:
> >>
> >> - -chardev file,path=/path/to/testfile,id=test
> >> - -device virtio-console-pci,chardev=test
>
Kevin Wolf wrote:
We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
descriptors that don't need to be passed to children to stop this misbehaviour.
Signed-off-by: Kevin Wolf
pid = fork();
if (pid == 0) {
int open_max = sysconf(_SC_OPEN_MAX), i;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
> Ian Molton wrote:
>> Heres my patch to virtio-console. The device is now specified like this:
>>
>> - -chardev file,path=/path/to/testfile,id=test
>> - -device virtio-console-pci,chardev=test
Note, I think the patch above is brok
Jamie Lokier wrote:
> Blue Swirl wrote:
> > On Mon, Nov 16, 2009 at 2:47 PM, Kevin Wolf wrote:
> > > Am 13.11.2009 22:05, schrieb Blue Swirl:
> > >> On Fri, Nov 13, 2009 at 5:17 PM, Kevin Wolf wrote:
> > >>> We're leaking file descriptors to child processes. Set FD_CLOEXEC on
> > >>> file
> > >>
Blue Swirl wrote:
> On Mon, Nov 16, 2009 at 2:47 PM, Kevin Wolf wrote:
> > Am 13.11.2009 22:05, schrieb Blue Swirl:
> >> On Fri, Nov 13, 2009 at 5:17 PM, Kevin Wolf wrote:
> >>> We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
> >>> descriptors that don't need to be passe
Mulyadi Santosa wrote:
> Hi Victor...
>
> On 11/13/09, Victor Vasilchenko wrote:
> > The only BIG question - what virtualization software can support MPI to
> > effectively work on cluster ?
> >
> > I am asking this question to QEMU team cause I believe QEMU can be the one.
> > If you have any id
Jamie Lokier wrote:
Gerd Hoffmann wrote:
On 11/16/09 20:24, Anthony Liguori wrote:
If we were going to introduce a light weight block protocol like this,
I'd rather it be implemented in SeaBIOS as a block driver.
Ok. That would mean to replace the option rom with a seabios patch
2009/11/16 Blue Swirl :
> On Mon, Nov 16, 2009 at 7:19 PM, Artyom Tarasenko
> wrote:
>> 2009/11/16 Blue Swirl :
>>> On Mon, Nov 16, 2009 at 1:47 PM, Artyom Tarasenko
>>> wrote:
2009/11/15 Blue Swirl :
> On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
> wrote:
>> 2009/11/14 Blu
Ian Molton wrote:
> Heres my patch to virtio-console. The device is now specified like this:
>
> - -chardev file,path=/path/to/testfile,id=test
> - -device virtio-console-pci,chardev=test
It'd be nice if some options on the qemu command line (or config file)
resulted in the guest kernel getting e
2009/11/16 Jamie Lokier :
> Artyom Tarasenko wrote:
>> I don't know, how the real sun4m reacts in the case where irq stays
>> on, not being cleared.
>> It can not be though that it would try to process irq for every next
>> tick. The CPU must have some time to clear the pending irq, so it must
>> b
Gerd Hoffmann wrote:
> On 11/16/09 20:24, Anthony Liguori wrote:
> >If we were going to introduce a light weight block protocol like this,
> >I'd rather it be implemented in SeaBIOS as a block driver.
>
> Ok. That would mean to replace the option rom with a seabios patch.
> The qemu code will be
Artyom Tarasenko wrote:
> I don't know, how the real sun4m reacts in the case where irq stays
> on, not being cleared.
> It can not be though that it would try to process irq for every next
> tick. The CPU must have some time to clear the pending irq, so it must
> be edge triggered too, at least in
Blue Swirl wrote:
> This patch makes the interrupts latch: ignore source clearing the
> interrupt. It seems be ~okay for my usual test setup, but does not
> help NetBSD 1.3.3. Some other NetBSD tests are changed, but they
> crashed before.
I'd expect the worst that would happen is "spurious interr
Artyom Tarasenko wrote:
> 2009/11/15 Blue Swirl :
> > On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
> > wrote:
> >> 2009/11/14 Blue Swirl :
> >>> On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko
> >>> wrote:
> According to NCR89C105 documentation
> http://www.ibiblio.org/pub/histor
On Mon, Nov 16, 2009 at 7:19 PM, Artyom Tarasenko
wrote:
> 2009/11/16 Blue Swirl :
>> On Mon, Nov 16, 2009 at 1:47 PM, Artyom Tarasenko
>> wrote:
>>> 2009/11/15 Blue Swirl :
On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
wrote:
> 2009/11/14 Blue Swirl :
>> On Sat, Nov 14, 20
--- On Mon, 11/16/09, Sergei Steshenko wrote:
> From: Sergei Steshenko
> Subject: Re: [Qemu-devel] problem building qemu-0.10.6 under SUSE-11.1 (was
> OK under SUSE-10.3)
> To: "Blue Swirl"
> Cc: qemu-devel@nongnu.org
> Date: Monday, November 16, 2009, 8:22 AM
>
>
> --- On Mon, 11/16/09, B
On 11/16/09 19:53, Paul Brook wrote:
We can also limit the amout of host memory we allow the guest to
consume, so uncooperative guests can't push the host into swap. This is
not implemented today, indicating that it hasn't been a problem so far.
Capping the amount of memory required for a tran
* Gerd Hoffmann [2009-11-16 14:42]:
> Hi,
>
> >>Suggestions for other guests which might be sensitive to changes like
> >>this? Maybe even some which don't work with the current lsi emulation?
> >
> >XP 64-bit, 2k3 32/64, 2k8 32/64
> >
> >64-bit is important because the DMA mode of the lsi dri
Gerd Hoffmann wrote:
On 11/16/09 20:24, Anthony Liguori wrote:
If we were going to introduce a light weight block protocol like this,
I'd rather it be implemented in SeaBIOS as a block driver.
Ok. That would mean to replace the option rom with a seabios patch.
The qemu code will be unmodifie
Hi,
Suggestions for other guests which might be sensitive to changes like
this? Maybe even some which don't work with the current lsi emulation?
XP 64-bit, 2k3 32/64, 2k8 32/64
64-bit is important because the DMA mode of the lsi driver is different
when the 64-bit versions of the win drive
On 11/16/09 20:24, Anthony Liguori wrote:
If we were going to introduce a light weight block protocol like this,
I'd rather it be implemented in SeaBIOS as a block driver.
Ok. That would mean to replace the option rom with a seabios patch.
The qemu code will be unmodified though (except for t
Anthony Liguori's patch fixes the problems with
vga display in graphical mode and SeaBIOS.
I only adapted some values for vga-pci.
Signed-off-by: Stefan Weil
---
hw/vga-pci.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index 234d581.
On Mon, 16 Nov 2009, Sebastian Herbszt wrote:
> malc wrote:
> > On Sat, 14 Nov 2009, Sebastian Herbszt wrote:
[..snip..]
> >
> > Neither is/was correct, does escaping $@ in rules make (i.e. \$@) have
> > any effect?
>
> Changing it to \$@ makes it compile again:
>
> $ grep MMD rules.mak
malc wrote:
On Sat, 14 Nov 2009, Sebastian Herbszt wrote:
v0.11.0-rc0-1630-g51cc2e7 fails to build on mingw with gcc version 3.4.5
(mingw32 special)
and GNU Make version 3.79.1.
gcc -I/home/sh/vm/qemu/v0.11.0-rc0-1630-g51cc2e7/slirp -Wold-style-definition
-I.
-I/home/sh/vm/qemu/v0.11.0-rc0-163
Gerd Hoffmann wrote:
Hi,
How about this one? extboot rom and interface are unmodified.
The windup in qemu is very different though. It is now implemented as
isa bus device (which is what extboot actually is). It is properly
integrated into qdev. It is much less invasive than the previous
Stefan Weil wrote:
malc schrieb:
On Sun, 15 Nov 2009, Gleb Natapov wrote:
On Sun, Nov 15, 2009 at 06:22:40PM +0300, malc wrote:
On Sun, 15 Nov 2009, Blue Swirl wrote:
On Sun, Nov 15, 2009 at 3:25 AM, malc wrote:
debian-503-i386-netinst.iso when booted on
* Gerd Hoffmann [2009-11-16 12:38]:
> On 11/11/09 17:38, Paul Brook wrote:
> >>>It may be that it's
> >>>hard/impossible to get both command queueing and zero-copy.
> >>
> >>I have it working.
> >
> >More likely you have a nasty hack that happens to work with the Linux
> >drivers.
>
> Linux wor
* Replace vill -> will.
* Comment was formatted to make it more readable
and to conform to the coding standard, too.
* Description of foo="" was completed.
Signed-off-by: Stefan Weil
---
configure | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/conf
On Monday 16 November 2009, Gerd Hoffmann wrote:
> On 11/11/09 17:38, Paul Brook wrote:
> >>> That cap is important.
> >>> For scsi-generic you probably don't have a choice because of the way
> >>> the kernel interface works.
> >>
> >> Exactly. And why is the cap important for scsi-disk if scsi-ge
malc schrieb:
> On Sun, 15 Nov 2009, Stefan Weil wrote:
>
>
>> malc schrieb:
>>
>>> On Sun, 15 Nov 2009, Gleb Natapov wrote:
>>>
>
> [..snip..]
>
>
>> Here is a summary of my analysis of this problem:
>>
>> Graphics mode memory (ram 0xe000 ...) is not mapped
>> in QEMU address
Signed-off-by: Gerd Hoffmann
---
Makefile|2 +-
pc-bios/optionrom/Makefile |2 +-
pc-bios/optionrom/extboot.S | 680 +++
3 files changed, 682 insertions(+), 2 deletions(-)
create mode 100644 pc-bios/optionrom/extboot.S
diff
Hi,
How about this one? extboot rom and interface are unmodified.
The windup in qemu is very different though. It is now implemented as
isa bus device (which is what extboot actually is). It is properly
integrated into qdev. It is much less invasive than the previous
version. The patch jus
booting from scsi + virtio works now.
usage: -device extboot,drive=
where is the name of your boot drive. You can either use the
names qemu assignes by default (virtio0, scsi0-hd0, ...) or explitly
name your drives via '-drive id=,...' and use that one.
Signed-off-by: Gerd Hoffmann
---
Makef
On 11/11/09 17:38, Paul Brook wrote:
That cap is important.
For scsi-generic you probably don't have a choice because of the way the
kernel interface works.
Exactly. And why is the cap important for scsi-disk if scsi-generic
does fine without?
With scsi-generic you're at the mercy of what th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
> Maybe ...
>
>-chardev socket,id=egd,host=egd.domain.tld,port=whatever
>-device virtio-rng,chardev=egd
I've had a go at modifying virtio-console.c to use these semantics,
attached below. I'd appreciate it if you could l
Victor Vasilchenko wrote:
Good day,
I've got an idea in my head and can't get rid of it - neither can I
find any solution on web.
The idea is to use the Virtualization Software with the purpose
OPPOSITE to it's natural way.
The practical example below will explain it completely:
1) we tak
2009/11/16 Blue Swirl :
> On Mon, Nov 16, 2009 at 1:47 PM, Artyom Tarasenko
> wrote:
>> 2009/11/15 Blue Swirl :
>>> On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
>>> wrote:
2009/11/14 Blue Swirl :
> On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko
> wrote:
>> According to N
To follow correctly what our bios ACPI tables say, we have to be able to program
our irqchips with GSI routing mappings. This support is already in qemu-kvm
Signed-off-by: Glauber Costa
---
kvm-all.c |6 ++-
kvm.h |3 +
target-i386/kvm.c | 118 +++
Now that we have all devices set up, this patch initializes the irqchip.
This is dependant on the io-thread, since we need someone to pull ourselves
out of the halted state.
I believe this should be the default when we are running over the io-thread.
Later on, I plan to post a patch that makes it
This patch provides the file apic-kvm.c, which implements a schim over
the kvm in-kernel APIC.
Signed-off-by: Glauber Costa
---
Makefile.target |2 +-
hw/apic-kvm.c | 157 +
hw/pc.c |6 ++-
hw/pc.h |2 +
k
It is actually not necessary to call a tpr function to save and load cr8,
as cr8 is part of the processor state, and thus, it is much easier
to just add it to CPUState.
As for apic base, wrap kvm usages, so we can call either the qemu device,
or the in kernel version.
Signed-off-by: Glauber Costa
We'll use it from inside the in-kernel apic chip, so get it into a header
file.
Signed-off-by: Glauber Costa
---
target-i386/cpu.h |4
target-i386/kvm.c |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index e5470f7..c671894
This patch provides the file i8259-kvm.c, which implements a schim over
the kvm in-kernel PIC.
Signed-off-by: Glauber Costa
---
Makefile.target |2 +-
hw/i8259-kvm.c | 112 +++
hw/pc.c |8 +++-
hw/pc.h |1 +
kvm-al
i8259 chip will use it, so provide it, and export it through pc.h
Signed-off-by: Glauber Costa
---
hw/apic.c |5 +
hw/pc.h |1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 87e7dc0..482bb1e 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -38
This patch provides the file ioapic-kvm.c, which implements a schim over
the kvm in-kernel IO APIC.
Signed-off-by: Glauber Costa
---
Makefile.target |2 +
hw/ioapic-kvm.c | 90 +++
hw/pc.c |7 -
hw/pc.h |2 +
k
Slightly modified version of a patch already included in qemu-kvm:
This is a patch actually written by Juan, which, according to him,
he plans on posting to qemu.git. Problem is that linux defines
u64 in a way that is type-uncompatible with uint64_t.
I am including it here, because it is a depend
This is the second version of the in-kernel irqchip patchset.
It is pretty straightforward, and basically the same thing that was
already in staging. Just now kvm_put_mp_state() became i386-specific,
and had to go into a header.
On 11/16/2009 06:21 PM, Blue Swirl wrote:
How exactly would you do that? The only way I see to do it would be
using void*, but I'm not sure if this really is an improvement.
Instead of sockaddr_in vs. sockaddr and the lame casts in between, we
could have QSockAddr which magically works.
> It looks like something is depending on this broken behaviour.
Or that I shouldn't have used bitwise "not" where boolean "not" were
actually meant. cpu_set_irq() is not the source of spurious
interrupts, sorry for the noise.
--- On Mon, 11/16/09, Blue Swirl wrote:
> From: Blue Swirl
> Subject: Re: [Qemu-devel] problem building qemu-0.10.6 under SUSE-11.1 (was
> OK under SUSE-10.3)
> To: "Sergei Steshenko"
> Cc: qemu-devel@nongnu.org
> Date: Monday, November 16, 2009, 7:54 AM
> On Mon, Nov 16, 2009 at 6:42 AM,
>
On Mon, Nov 16, 2009 at 2:47 PM, Kevin Wolf wrote:
> Am 13.11.2009 22:05, schrieb Blue Swirl:
>> On Fri, Nov 13, 2009 at 5:17 PM, Kevin Wolf wrote:
>>> We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
>>> descriptors that don't need to be passed to children to stop this
On Mon, Nov 16, 2009 at 1:47 PM, Artyom Tarasenko
wrote:
> 2009/11/15 Blue Swirl :
>> On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
>> wrote:
>>> 2009/11/14 Blue Swirl :
On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko
wrote:
> According to NCR89C105 documentation
> http:/
On Mon, Nov 16, 2009 at 6:42 AM, Sergei Steshenko wrote:
> Hello All,
>
> I've been routinely building QEMU up to (inclusive) version 0.10.6 on my
> SUSE-10.3 box - in the framework of my own AppsFromScratch.
>
> Over the weekend I've upgraded to SUSE-11.1 and now the build fails with
> these mess
We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
descriptors that don't need to be passed to children to stop this misbehaviour.
Signed-off-by: Kevin Wolf
---
block/raw-posix.c |2 +-
gdbstub.c |6 +++
kvm-all.c |2 +-
migration-tcp.c|
Paul Brook wrote:
>>> While sync appears attractive as a quick hack to achieve this, I think it
>>> is liable to be abused, and cause us serious pain long-term. If you need
>>> an easy solution then use ld/st (as with ARM VFP registers). If you want
>>> a good solution then fix whichever bit of TCG
On 11/16/2009 04:18 PM, Fernando Luis Vázquez Cao wrote:
Avi Kivity wrote:
On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote:
Kemari runs paired virtual machines in an active-passive configuration
and achieves whole-system replication by continuously copying the
state of the system (dirt
> > While sync appears attractive as a quick hack to achieve this, I think it
> > is liable to be abused, and cause us serious pain long-term. If you need
> > an easy solution then use ld/st (as with ARM VFP registers). If you want
> > a good solution then fix whichever bit of TCG makes accessing a
Can someone try with better explanation for offset calculation that is passed
to target_mmap() ? More specifically, I am facing an "invalid argument" error
while trying to load a simple elf binary. When debugged, it turned out that the
check "if(offset & ~TARGET_PAGE_MASK)" throws this error - l
Avi Kivity wrote:
On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote:
Kemari runs paired virtual machines in an active-passive configuration
and achieves whole-system replication by continuously copying the
state of the system (dirty pages and the state of the virtual devices)
from the act
On 11/16/2009 03:36 PM, Avi Kivity wrote:
On 11/14/2009 09:47 PM, Kevin O'Connor wrote:
Hi,
On Thu, Nov 12, 2009 at 01:20:58PM +0200, Naphtali Sprei wrote:
I've found a problem with the usage of SeaBIOS/gPXE in Qemu. The
scenario is when failing to boot from network and falling back to
bootin
Paul Brook wrote:
> On Thursday 22 October 2009, Aurelien Jarno wrote:
>
>> On Wed, Oct 21, 2009 at 03:52:22PM +0200, Ulrich Hecht wrote:
>>
>>> sync allows concurrent accesses to locations in memory through different
>>> TCG variables. This comes in handy when you are emulating CPU registe
On 11/14/2009 09:47 PM, Kevin O'Connor wrote:
Hi,
On Thu, Nov 12, 2009 at 01:20:58PM +0200, Naphtali Sprei wrote:
I've found a problem with the usage of SeaBIOS/gPXE in Qemu. The
scenario is when failing to boot from network and falling back to
booting from hard-disk (-boot nc). The cause
On 11/16/09 13:28, Ian Molton wrote:
I've done something similar (below)
My commandline looks like:
- -virtiorng dev=/dev/foo,rate=1234
I added some properties to my driver which are obviously then filled in
from the options code, and I do my init like this:
There is no need for a new -virt
Am 13.11.2009 22:05, schrieb Blue Swirl:
> On Fri, Nov 13, 2009 at 5:17 PM, Kevin Wolf wrote:
>> We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
>> descriptors that don't need to be passed to children to stop this
>> misbehaviour.
>
>> -c = accept(s, (struct soc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
> Hi,
Hi!
Thanks for your reply - I should have posted to say I'd partially solved
this. I have a question though,
> Use a chardev property (look at serial.c, "isa-serial" device).
>
> Then you'll configure it on the qemu com
I wrote:
> This patch makes xl create check whether qemu-dm has started
> correctly, and causes it to fail immediately with appropriate errors
> if not. There are other bugfixes too.
But I sent it to the wrong list.
Sorry,
Ian.
2009/11/15 Blue Swirl :
> On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
> wrote:
>> 2009/11/14 Blue Swirl :
>>> On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko
>>> wrote:
According to NCR89C105 documentation
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR89C105
Hi,
in qdev_init_chardev() the return value is picked based upon the name of
the device. For now, I've added a third 'if clause' to match for my
driver and pass through the CharDriverState * fron vl.c for my rng
driver, however I'd like to solve this properly.
Ignore qdev_init_chardev() ...
On 11/12/09 21:29, Mark McLoughlin wrote:
No doubt this is the worst idea ever, but the requirement is simple -
some way to iterate all NICs in the system.
Doesn't have net.c a list of all vlanclientstates it could use instead?
cheers,
Gerd
Hi,
diff --git a/hw/e1000.c b/hw/e1000.c
index 00f6a57..d9c9f79 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1107,11 +1107,11 @@ static int pci_e1000_init(PCIDevice *pci_dev)
checksum = (uint16_t) EEPROM_SUM - checksum;
d->eeprom_data[EEPROM_CHECKSUM_REG] = checksum;
-d->vc =
On 11/12/09 21:28, Mark McLoughlin wrote:
Rather than having each NIC create it's own client, let's create the
client early and pass it down to the NIC.
'-device $nic,net-client=$name' doesn't work ...
One advantage is that we can add parameters which only the client
knows about, without havi
Hi Victor...
On 11/13/09, Victor Vasilchenko wrote:
> The only BIG question - what virtualization software can support MPI to
> effectively work on cluster ?
>
> I am asking this question to QEMU team cause I believe QEMU can be the one.
> If you have any ideas or experiments or information - ple
74 matches
Mail list logo
