haviour similar to the old behaviour.
>
> Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Acked-by: Ed Swierk <eswi...@gmail.com>
> ---
> hw/net/e1000.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/hw/net/
On Tue, Mar 27, 2018 at 10:28 AM, Paolo Bonzini wrote:
> On 27/03/2018 18:47, Dr. David Alan Gilbert wrote:
>>> So if the subsection is absent you
>>> have to migrate either tx.tso_props or tx.props, depending on s->tx.cptse.
>> Do you mean when sending you have to decide
On Tue, Mar 27, 2018 at 7:26 AM, Dr. David Alan Gilbert
wrote:
> If I understand correctly the d6244b description, there's two pieces of
> state (TSO and non-TSO) where there used to be only one.
> Now, with the new format we migrate both pieces of state, but lets think
>
On Mon, Jan 8, 2018 at 7:10 AM, Eric Blake <ebl...@redhat.com> wrote:
>
> On 01/08/2018 07:30 AM, Ed Swierk via Qemu-devel wrote:
>
> > Applied, thanks.
> >
> > PS: just noticed, but "Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>"
> > i
precation information of -tftp, -bootp, -redir
and -smb (2017-12-22 10:06:05 +0800)
>
>
>
> --------
Applied, thanks.
PS: just noticed, but "Ed Swierk via Qemu-d
the expected
value is always 0x.)
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
v3:
(Reposted to fix patch format)
Leave net_tx_pkt_update_ip_checksums() alone since it's only computing
a partial sum of the IP pseudo-header.
Rename wrapper to net_checksum_finish_nozero() for c
On Wed, Nov 15, 2017 at 7:55 PM, Eric Blake <ebl...@redhat.com> wrote:
>
> On 11/15/2017 09:07 PM, Ed Swierk via Qemu-devel wrote:
>
> This part below...
>
> >
> > v3:
> >
> > Leave net_tx_pkt_update_ip_checksums() alone since it's only comput
at every caller.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000.c | 2 +-
hw/net/net_rx_pkt.c| 2 +-
hw/net/net_tx_pkt.c| 2 +-
hw/net/vmxnet3.c | 3 ++-
include/net/checksum.h | 6 ++
5 files changed, 11 insertions(+), 4 deletions(-)
diff --gi
On Tue, Nov 14, 2017 at 6:57 PM, Ed Swierk <eswi...@skyportsystems.com> wrote:
> diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
> index 20b2549..dc95f12 100644
> --- a/hw/net/net_tx_pkt.c
> +++ b/hw/net/net_tx_pkt.c
> @@ -126,12 +126,12 @@ void net_tx_pkt_updat
the expected
value is always 0x.)
v2:
Add a wrapper net_checksum_finish_hdr() rather than duplicating the
logic at every caller.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000.c | 2 +-
hw/net/net_rx_pkt.c| 2 +-
hw/net/net_tx_pkt.c| 6 +++---
On Tue, Nov 14, 2017 at 6:10 PM, Jason Wang <jasow...@redhat.com> wrote:
>
>
> On 2017年11月15日 07:25, Ed Swierk wrote:
>>
>> The checksum algorithm used by IPv4, TCP and UDP allows a zero value
>> to be represented by either 0x and 0x. But per RFC
On Thu, Nov 9, 2017 at 5:53 AM, Daniel P. Berrange wrote:
> My fear is that this approach of building a new e1000-ng device in
> parallel with having the existing e1000 device is going to cause
> long term pain, possibly never getting to a state where the e1000-ng
> device
on a UDP
datagram. Doing this on IPv4 packets and TCP segments is unnecessary
but legal.
(While it is tempting to make the substitution in
net_checksum_finish(), that function is also used by receivers to
verify checksums, and in that case the expected value is always
0x.)
Signed-off-by: Ed Swierk
rrupt data before sending
it out a physical interface.)
Correct this by tracking the TSO context independently of the non-TSO
context, and selecting the appropriate context based on the TSE flag
in each transmit data descriptor.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/
offload, using the parameters in
the appropriate context.
Move these flags out of struct e1000x_txd_props, which is otherwise
dedicated to storing values from a context descriptor, and into the
per-packet TX struct.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e
erous,
as e1000e ignores most of the context parameters supplied by the guest
and does its own thing, which is only sometimes correct. Taming e1000e
is a project for another day. The change to e1000e here is a baby step
in that direction.)
Then we separate the e1000 TSO and non-TSO contexts, which f
mal testing, but should work well
enough to start experimenting with e1000-ng devices with a variety of
guest OSes.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000e.c | 111 +--
hw/net/e1000e_cor
ate and e1000_vmstate
- got savevm/loadvm working with e1000-ng
- leave MSI enabled for e1000-ng (though guest drivers seem to ignore it)
Ed Swierk (2):
e1000e: Infrastructure for e1000-ng
e1000e: Add e1000-ng devices
hw/net/e1000e.c |
, no functional changes.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000e.c | 166 ++-
hw/net/e1000e_core.c | 131 +++-
hw/net/e1000e_core.h | 13 ++--
3 files changed, 209 inse
, no functional changes.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000e.c | 186 ---
hw/net/e1000e_core.c | 131
hw/net/e1000e_core.h | 13 ++--
3 files changed, 217 inse
can easily start trying
out e1000-ng with their favorite guest OS. That means accepting (for
now) known deficiencies in the new e1000-ng devices, which can be
addressed by myself and (hopefully) others in follow-up patches. Does
that sound reasonable?
Ed Swierk (2):
e1000e: Infrastructure for e1
ies, this version does not handle migration. But
it should work well enough to start testing e1000-ng devices with a
variety of guest OSes.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000e.c | 50 +
hw/net/e1000e_cor
On Mon, Oct 23, 2017 at 8:28 PM, Jason Wang <jasow...@redhat.com> wrote:
>
> On 2017å¹´10æ24æ¥ 08:22, Ed Swierk wrote:
> > (Another layer of icing on the cake is that QEMU ignores the
> > requirement that a UDP checksum computed as zero be sent as 0x,
> >
the packet data). Is this
divergence intentional? Is there a reason not to change e1000e as long
as I'm trying to make e1000 more datasheet-conformant?
Not ready for prime time, but nonetheless
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000
ntentional? Is there a reason not to change e1000e as long
as I'm trying to make e1000 more datasheet-conformant?
Not ready for prime time, but nonetheless
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
hw/net/e1000.c | 183 +++--
The transmit checksum offload implementation in QEMU's e1000 device is
deficient and causes packet data corruption in some situations.
According to the Intel 8254x software developer's manual[1], the
device maintains two separate contexts: the TCP segmentation offload
context includes parameters
On Thu, Mar 30, 2017 at 4:06 PM, John Snow <js...@redhat.com> wrote:
> On 03/29/2017 10:01 PM, Ed Swierk via Qemu-devel wrote:
>> * 2.9.0-rc2
>> - guest, virtio-blk, iothread, single snapshot create+commit:
>> "include/block/aio.h:457: aio_enable_external: Asserti
Parts of qemu's block code have changed a lot in recent months but are
not well exercised by current tests.
Subtle bugs have crept in causing assertion failures, hangs and other
crashes in a variety of situations: immediately on start, on first
guest activity, on external snapshot create or
On Wed, Mar 22, 2017 at 2:19 AM, Fam Zheng <f...@redhat.com> wrote:
> On Tue, 03/21 06:05, Ed Swierk wrote:
>> Actually running snapshot_blkdev command in the text monitor doesn't
>> trigger this assertion (I mixed up my notes). Instead it's triggered
>> by the foll
On Tue, Mar 21, 2017 at 5:50 AM, Fam Zheng <f...@redhat.com> wrote:
> On Tue, 03/21 05:20, Ed Swierk wrote:
>> On Mon, Mar 20, 2017 at 10:26 PM, Fam Zheng <f...@redhat.com> wrote:
>> > On Fri, 03/17 09:55, Ed Swierk wrote:
>> >> I'm running into th
On Mon, Mar 20, 2017 at 10:26 PM, Fam Zheng <f...@redhat.com> wrote:
> On Fri, 03/17 09:55, Ed Swierk wrote:
>> I'm running into the same problem taking an external snapshot with a
>> virtio-blk drive with iothread, so it's not specific to virtio-scsi.
>> Run a
On Fri, Mar 17, 2017 at 12:27 PM, Paolo Bonzini wrote:
> And this is a fix, but I have no idea why/how it works and what else it
> may break.
>
> Patches 1 and 2 are pretty obvious and would be the first step towards
> eliminating aio_disable/enable_external altogether.
>
>
On Fri, Mar 17, 2017 at 12:27 PM, Paolo Bonzini wrote:
> And this is a fix, but I have no idea why/how it works and what else it
> may break.
>
> Patches 1 and 2 are pretty obvious and would be the first step towards
> eliminating aio_disable/enable_external altogether.
>
>
On Fri, Mar 17, 2017 at 10:15 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>
> On 17/03/2017 18:11, Paolo Bonzini wrote:
>>
>>
>> On 17/03/2017 17:55, Ed Swierk wrote:
>>> I'm running into the same problem taking an external snapshot with a
&
> 0' failed.
whereas without the iothread the assertion failure does not occur.
--Ed
On Thu, Mar 16, 2017 at 5:26 PM, Ed Swierk <eswi...@skyportsystems.com> wrote:
> With this change on top of 2.9.0-rc0, I am able to boot a Linux guest
> from a virtio-scsi drive with an iothread, e.g.
On Mar 16, 2017 23:02, "Fam Zheng" <f...@redhat.com> wrote:
On Thu, 03/16 17:26, Ed Swierk wrote:
> On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng <f...@redhat.com> wrote:
> > After the AioContext lock push down, there is a race between
> > virtio_scsi_dat
On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote:
> After the AioContext lock push down, there is a race between
> virtio_scsi_dataplane_start and those "assert(s->ctx &&
> s->dataplane_started)", because the latter doesn't isn't wrapped in
> aio_context_acquire.
>
> Reproducer
On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote:
> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> index e7466d3..4939f1f 100644
> --- a/hw/scsi/virtio-scsi.c
> +++ b/hw/scsi/virtio-scsi.c
> ...
> bool virtio_scsi_handle_event_vq(VirtIOSCSI *s, VirtQueue *vq)
> {
scsi_handle_*_vq to
> their callers - and wrap the broken assertions in.
>
> Signed-off-by: Fam Zheng <f...@redhat.com>
Verified this fixes the assertion failure on 2.9.0-rc0.
Tested-by: Ed Swierk <eswi...@skyportsystems.com>
nothing if no event is pending. As a result aio_poll() will spin on
> the "non-empty" VQ and take 100% host CPU.
>
> Fix this by reporting actual progress from virtio queue aio handlers.
>
> Reported-by: Ed Swierk <eswi...@skyportsystems.com>
> Signed-off-by: Fam Zheng &l
On Thu, Feb 9, 2017 at 2:12 AM, Fam Zheng wrote:
> This should fix it:
>
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01874.html
I tested this patch and found it fixes the problem. Thanks for the
speedy response!
--Ed
On Wed, Feb 8, 2017 at 6:52 PM, Fam Zheng wrote:
> This means virtio-scsi event vq handler is returning true but actually no
> progress is made. Can you try the following patch to see if it's because a
> stalled cache of VQ index?
>
> diff --git a/hw/virtio/virtio.c
On Wed, Feb 8, 2017 at 5:47 PM, Fam Zheng wrote:
> No, something is wrong. The polling shouldn't keep running when there is no
> I/O
> activity.
>
> Can you try "perf top" to see what poll handlers are spinning?
Samples: 288K of event 'cycles', Event count (approx.):
On Wed, Feb 8, 2017 at 8:33 AM, Ed Swierk <eswi...@skyportsystems.com> wrote:
> Recently I noticed that when I configure a virtio-scsi-pci device
> using an iothread, as soon as the guest virtio-scsi driver loads, the
> iothread spins at 100%:
>
> -object iothread,id=iot
Recently I noticed that when I configure a virtio-scsi-pci device
using an iothread, as soon as the guest virtio-scsi driver loads, the
iothread spins at 100%:
-object iothread,id=iothread1 -device virtio-scsi-pci,iothread=iothread1
This occurs whether or not a disk is attached, with either
On Tue, Jan 31, 2017 at 6:06 AM, Marc-André Lureau wrote:
> I think this can be confusing if some backends silently drop the data (under
> disconnected state), while other don't. Perhaps we should have instead a new
> common chardev property "hup-drop" ? (suggestions for
On Tue, Jan 31, 2017 at 7:34 AM, Paolo Bonzini wrote:
>
>
> On 31/01/2017 04:39, Daniel P. Berrange wrote:
>> I don't think so - retrying in this way is pointless IMHO - it is just
>> going to get the same result on every retry on 99% of occassions.
>
> Just to provide the
like virsh console happens to be
connected.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
qemu-char.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-char.c b/qemu-char.c
index 676944a..ccb6923 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1528,7 +
On Fri, Jan 27, 2017 at 1:40 AM, Daniel P. Berrange <berra...@redhat.com> wrote:
> On Thu, Jan 26, 2017 at 05:07:16PM -0800, Ed Swierk wrote:
>> Currently qemu_chr_fe_write() calls qemu_chr_fe_write_log() only for
>> data consumed by the backend chr_write function.
Interactive access to a guest serial console can be enabled by hooking
the serial device to a pty backend, e.g. -device
isa-serial,chardev=cs0 -chardev pty,id=cs0. With libvirt this can be
configured via .
Output from the same serial device can also be logged to a file by
adding logfile=/somefile
on guest to run code to read out the new fw cfg.
> Thus guest can not reliably detect that host didn't update the gen id -
> new one might be there in fw cfg but not yet read.
>
> RSDP never changes during guest lifetime so the issue does
> not occur.
>
> On Tue, Jan 17, 2017
gt;> >>
>> >>Hi Michael,
>> >>
>> >>I’m well on my way to implementing this, but I am really new to the
>> >>QEMU code base and am struggling with some concepts. Please see
>> >> below:
>> >>
On Mon, Oct 24, 2016 at 2:21 PM, Eric Blake wrote:
> How are you getting max_transfer == 65536? I can't reproduce it with
> the following setup:
>
> $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
> $ qemu-io -f qcow2 -c 'w 7m 1k' file
> $ qemu-io -f qcow2 -c 'w -z
On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake <ebl...@redhat.com> wrote:
> On 10/20/2016 07:24 PM, Ed Swierk wrote:
>> Changing max_transfer in the normal write case to
>> MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_BOUNCE_BUFFER) appears to fix
>> the problem, but I don'
Shortly after I start qemu 2.7.0 with a qcow2 disk image created with
-o cluster_size=1048576, it prints the following and dies:
block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <=
s->cluster_size' failed.
I narrowed the problem to bdrv_co_do_pwrite_zeroes(), called by
On Fri, Oct 7, 2016 at 6:46 AM, Frank Myhr wrote:
> On 10/07/2016 06:56 AM, Alberto Garcia wrote:
>>
>> I would like to know what's the use case you (Frank, Ed)
>> are thinking about:
>
>
>> - Are we talking about command-line options, QMP, or both?
>
>
> Command-line options
On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Thu, Sep 15, 2016 at 05:23:28PM -0700, Ed Swierk wrote:
>> I'm wondering what it will take to finish up work on vmgenid.
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2016-0
the entire virtual disk.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
block/qcow2.c| 16 +---
docs/qcow2-cache.txt | 10 --
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 91ef4df..6f3a6ed 100644
--- a/block
On Tue, Oct 4, 2016 at 7:31 AM, Alberto Garcia wrote:
> That might be a lot of memory if the image is big. 1 TB qcow2 image ==
> 128 MB L2 cache.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1377735#c2
>
> If we want to add this feature, I think I'd rather make it
and cluster size. The resulting
default cache size is just large enough to service random accesses in
the entire image.
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
---
block/qcow2.c | 5 ++---
block/qcow2.h | 4
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/block/qco
I'm wondering what it will take to finish up work on vmgenid.
https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05599.html
It appears all of the designs explored through the 19 iterations were
problematic in some way. Is any of them vaguely acceptable to all
involved in the discussions?
On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev <d...@openvz.org> wrote:
> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
> >> Windows 8, 10 and Server 2012 guests hang intermittently while booting
>
r to me why it works, or if it's just papering
over a bug elsewhere, or if there are any possible side effects.
Suggested-by: Andrew Jones <drjo...@redhat.com>
Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 6eac66d..c891b67 100644
--- a/h
why coreboot did
that. I assume it was a mistake, and the original code was supposed to
be reading the DRB[0-7] registers (offsets 0x60-0x67).
Document that coreboot-specific register offset in a macro and a
comment, for future reference.
Cc: Ed Swierk eswi...@skyportsystems.com
Cc: Richard
the comparison
to fail and resulting in lots of spurious Unsupported ioctl errors.
Changing the target_cmd field in the ioctl_entries list to a signed int
causes those values to be sign-extended as well during the comparison.
Signed-off-by: Ed Swierk eswi...@skyportsystems.com
---
linux-user/syscall.c | 2
Without this fix, qemu segfaults when emulating the sigaltstack syscall,
because it incorrectly treats the ss_flags field as 64 bits rather than 32
bits.
Signed-off-by: Ed Swierk eswi...@skyportsystems.com
---
linux-user/mips64/target_signal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion
This fixes Cannot open audit interface - aborting. when the
EAFNOSUPPORT errno differs between the target and host
architectures (e.g. mips target and x86_64 host).
Signed-off-by: Ed Swierk eswi...@skyportsystems.com
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
I'm using the ppc-linux-user target to run processes in a Debian
Wheezy filesystem I built using multistrap. I built qemu from
yesterday's head of the git tree.
When I try to run a Python JSON database called jsonstore, I qemu-ppc
barfs with an Invalid data memory access, with the invalid address
.
Both of these changes are the result of random hacking rather than any
real understanding of the issues involved. I'd appreciate any better
ideas.
Signed-off-by: Ed Swierk eswi...@aristanetworks.com
---
hw/pc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/pc.c b/hw
On Mon, Feb 22, 2010 at 12:51 PM, Luiz Capitulino
lcapitul...@redhat.com wrote:
How do you reproduce it?
Here's a test program that reproduces the problem. Start qemu with
-chardev socket,id=monitor,path=/tmp/qemu-monitor,server,nowait -mon
chardev=monitor,mode=readline
and run check_getfd
Commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d seems to have broken
the getfd monitor command in qemu 0.12.
tcp_chr_read() calls tcp_chr_recv(), which checks whether the received
message includes an SCM_RIGHTS header, and if so, stores the received
fd in the CharDriverState struct.
-off-by: Arnd Bergmann a...@arndb.de
This works for me.
Acked-by: Ed Swierk eswi...@aristanetworks.com
On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa glom...@redhat.com wrote:
This is an early version of smp support in kvm that kinda works.
Can you please elaborate on smp support? The KVM FAQ makes some
rather broad claims about smp support already:
Does KVM support SMP hosts?
Yes.
Does
On Mon, Nov 30, 2009 at 4:31 PM, Ed Swierk eswi...@aristanetworks.com wrote:
On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa glom...@redhat.com wrote:
This is an early version of smp support in kvm that kinda works.
Can you please elaborate on smp support? The KVM FAQ makes some
rather broad
On 10/28/07, Rob Landley [EMAIL PROTECTED] wrote:
Hmmm... All the kernels I've built for this project are static. In theory I
can add ne.irq=9 to the kernel command line, but in practice it doesn't
seem to work. Nor does ne.0.irq=9 or irq=9
However, when I hardwire dev-irq=9; into the
On 8/16/07, Christian MICHON [EMAIL PROTECTED] wrote:
blame it on gmail. this is the default behaviour.
it's obviously not intended...
At the risk of drifting further off-topic, I'd just point out that you
can press Ctrl-End in the Gmail message window before you type your
reply.
--Ed
When the USB OHCI controller starts, a periodic end-of-frame routine
writes to a chunk of memory set aside by the device driver. If the
machine reboots or the OS kexecs, the controller continues writing
even though the memory is no longer owned by the device driver,
causing random, mysterious
On Monday 21 May 2007 03:40:12 Markus Hitter wrote:
Somewhere in the FAQs, the state of Classic Mac OS ist mentioned as
it is being worked on. Is this still true, is it possible to join
the effort?
I'm not aware of anyone currently working on classic Mac OS support. PowerPC
system emulation
On Wednesday 16 May 2007 14:31:38 H. Peter Anvin wrote:
As rewritten, it should follow the current version of the Linux boot
protocol specification and recommendations. As a side benefit, it no
longer relies on load_linux.S; instead I have a small code generator
which can be used to set up an
The attached patch addresses a few problems in OpenHackWare:
- The return value from the OpenFirmware read function should not exceed the
actual file size by more than one block; otherwise the Linux kernel's
initramfs routines get confused by the extra junk and reject the initramfs.
- The
I'm having trouble building OpenHackWare (the firmware for qemu-system-ppc)
from source on a PPC machine running Fedora 6, using either gcc 4.1.1 or gcc
3.4.6. I'm using the source tarball
http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4.1.tar.bz2,
with the patch
On Thursday 19 April 2007 09:58:30 Daniel Jacobowitz wrote:
I posted some other patches for OpenHackWare when I was experimenting
with OpenBSD; I think this is the one you need, to the linker script:
-.rodata: { *(.rodata) } bios
+.rodata: { *(.rodata*) } bios
Works
Has anyone succeeded in booting a Linux 2.6 kernel on Qemu PPC? If so,
what distribution did you use?
Thanks,
--Ed
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On 2/15/07, Thomas Petazzoni [EMAIL PROTECTED] wrote:
BTW, is there a reason why a disk image is required when using the
-kernel option ?
In the following case: -kernel vmlinuz -append nfsroot=blabla, we
could boot over the network, without the need for any disk image, but
Qemu wants to have a
qemu 0.9.0 on Linux crashes with SIGSEGV after read() on a char device
returns 0, which occurs if the char device is a fifo and the writer
closes the file.
In this case, fd_chr_read() and stdio_read() react by removing the IO
handler and freeing it. Unfortunately main_loop_wait() is unprepared
On 2/13/07, Ed Swierk [EMAIL PROTECTED] wrote:
This patch changes qemu to map the BIOS into ISA address space as RAM
instead of ROM, allowing LinuxBIOS to run on qemu with no further
modifications (although the DRAM size is still not detected properly).
Unfortunately this isn't the right
LinuxBIOS writes the IRQ routing table (PIRQ) to 0xf000 and then reads
it back to verify the write. Currently qemu maps the top 128 KB of the
BIOS into ISA address space (0xe000 - 0x) as ROM, which causes the
write to fail, preventing Linux from finding interrupt routing info.
This patch
The latest bochs bios (bochs-20070105 snapshot) seems to fix the
SYSLINUX hanging issue. The bios.bin is attached.
--Ed
bios.bin.bz2
Description: BZip2 compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
On 2/5/07, Ed Swierk [EMAIL PROTECTED] wrote:
I'm attempting to boot a Linux disk image with the SYSLINUX boot
loader using the -nographic option. On the latest qemu CVS, the boot
loader hangs before printing Ready and booting the kernel. But if I
use the same version of qemu with the BIOS from
On 2/5/07, Ed Swierk [EMAIL PROTECTED] wrote:
I'm attempting to boot a Linux disk image with the SYSLINUX boot
loader using the -nographic option. On the latest qemu CVS, the boot
loader hangs before printing Ready and booting the kernel. But if I
use the same version of qemu with the BIOS from
Here's a revised patch with the mmap stuff removed. I'll refine the
persistence support, but in the meantime the EEPROM device is usable
even if it forgets its contents when qemu exits.
--Ed
Index: qemu-0.8.2/hw/acpi.c
===
---
qemu allows redirecting the monitor to a named pipe (fifo): if you
specify -monitor pipe:/my/fifo, it opens /my/fifo and uses it for
communication in both directions.
Unfortunately pipes are unidirectional on Linux. The pipe(7) man page
says: Portability notes: On some systems (but not Linux),
After spending some time trying to figure out why the emulated UHCI
USB controller is so slow, I switched uhci_usb_init() in hw/pc.c to
ohci_usb_init(). To my delight, Linux booted up and detected the
controller on the first try, and accessing an emulated block device is
2 to 3 times faster.
It
On 9/14/06, Joseph Miller [EMAIL PROTECTED] wrote:
I'm running a terminal server under qemu with kqemu compiled into my kernel
under the -kernel-kqemu for fastest performance. What is the most efficient
method of -net ? I was using -net user with OpenVPN to connect to my
internal LAN, but I
Linux 2.6.17 running on the latest qemu snapshot is unable to route
IRQs to more than 4 network interfaces when running without ACPI, and
is limited to 2 network interfaces with ACPI enabled.
With 8 network interfaces and ACPI disabled, I get the following
kernel output during boot:
The attached patch makes two changes needed to boot Linux on qemu with
a large (256KB) LinuxBIOS image instead of the built-in BIOS:
- Increases the space set aside for the BIOS from 256KB to 2MB; this
could of course be increased further, but 2MB seems to be the largest
EEPROM hardware
Currently qemu's i440FX PCI bridge emulation code does not set the
registers indicating the amount of RAM installed in each DIMM slot.
LinuxBIOS relies on this information to properly set up RAM before
booting Linux.
The attached patch sets a i440FX configuration register indicating the
highest
On 6/28/06, Paul Robinson [EMAIL PROTECTED] wrote:
How should you pronounce Qemu?
FYI, my best guess is Q (as in the letter Q) followed by the first 2
syllables of emulator.
That's how I've always pronounced it, but I've also heard people say
kee-moo, which I have to admit is kind of cute.
On 6/5/06, René Korthaus [EMAIL PROTECTED] wrote:
I researched current qemu cvs and found out that the patch was
integrated not complete but to 95%. There are two lines in slirp/
misc.c that need a change (patch attached). Tested to work with Mac
OS X host and debian guest i could reach the
In environments where the 10.0.2.0/24 subnet is already used for
another purpose, it's useful to be able to configure a different -net
user (slirp) subnet, such as 192.168.100.0/24.
The attached patch adds a subnet option to -user net. Currently only
/24 subnets (mask 255.255.255.0) are
1 - 100 of 115 matches
Mail list logo