o 2.11 or old machine types) we've
> got to choose what to migrate in the main structure.
>
> If we're using the subsection migrate 'props' in the main structure.
> If we're not using the subsection then migrate the last one
> that changed, which gives b
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 which set to send in the
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
> about what happens if we
On Mon, Jan 8, 2018 at 7:10 AM, Eric Blake 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 "
> > is a bit of an odd Author string to end up in git commit l
-redir
and -smb (2017-12-22 10:06:05 +0800)
>
>
>
> --------
Applied, thanks.
PS: just noticed, but "Ed Swierk via Qemu-devel "
is a bit of an odd Author string to end up in gi
e the expected
value is always 0x.)
Signed-off-by: Ed Swierk
---
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 clarity.
v2:
Add
On Wed, Nov 15, 2017 at 7:55 PM, Eric Blake 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 computing
> > a partial sum
e
logic at every caller.
Signed-off-by: Ed Swierk
---
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 --git a/hw/net/e1000.c b/hw/n
On Tue, Nov 14, 2017 at 6:57 PM, Ed Swierk 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_update_ip_checksums(struct N
case 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
---
hw/net/e1000.c | 2 +-
hw/net/net_rx_pkt.c| 2 +-
hw/net/net_tx_pkt.c| 6 +++---
hw/net/vmxnet3.c
On Tue, Nov 14, 2017 at 6:10 PM, Jason Wang 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 768, a zero
>> UDP checksum
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 can replace the e1000 de
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
tch the corrupt 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
---
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
---
hw/net/e1000.c | 30
1000e. ("Used" is generous,
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 a
minimal testing, but should work well
enough to start experimenting with e1000-ng devices with a variety of
guest OSes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 111 +--
hw/net/e1000e_core
1000e_vmstate 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
, no functional changes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 166 ++-
hw/net/e1000e_core.c | 131 +++-
hw/net/e1000e_core.h | 13 ++--
3 files changed, 209 insertions(+), 101 deletions(-)
diff
, no functional changes.
Signed-off-by: Ed Swierk
---
hw/net/e1000e.c | 186 ---
hw/net/e1000e_core.c | 131
hw/net/e1000e_core.h | 13 ++--
3 files changed, 217 insertions(+), 113 deletions(-)
diff --git a
and folks 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: Infrastruct
es, 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
---
hw/net/e1000e.c | 50 +
hw/net/e1000e_core.c | 120 ++-
On Mon, Oct 23, 2017 at 8:28 PM, Jason Wang 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,
> > since zero is a special value
hinks is best by digging into 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
---
hw/net/e1000.c | 183
ata). 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
---
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 f
On Thu, Mar 30, 2017 at 4:06 PM, John Snow 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: Assertion
>> `ctx->exter
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 commit
On Wed, Mar 22, 2017 at 2:19 AM, Fam Zheng 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 following seq
On Tue, Mar 21, 2017 at 5:50 AM, Fam Zheng wrote:
> On Tue, 03/21 05:20, Ed Swierk wrote:
>> On Mon, Mar 20, 2017 at 10:26 PM, Fam Zheng wrote:
>> > On Fri, 03/17 09:55, Ed Swierk wrote:
>> >> I'm running into the same problem taking an external snapshot
On Mon, Mar 20, 2017 at 10:26 PM, Fam Zheng 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 Linux guest on qemu ma
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.
>
> However I got patch 3 m
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.
>
> However I got patch 3 m
On Fri, Mar 17, 2017 at 10:15 AM, Paolo Bonzini 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
>>> virtio-blk drive
sable_cnt > 0' failed.
whereas without the iothread the assertion failure does not occur.
--Ed
On Thu, Mar 16, 2017 at 5:26 PM, Ed Swierk 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.
>
> qemu-sys
On Mar 16, 2017 23:02, "Fam Zheng" wrote:
On Thu, 03/16 17:26, Ed Swierk wrote:
> 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 &
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 is simply booting a
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)
> {
> -virtio_scsi
e_*_vq to
> their callers - and wrap the broken assertions in.
>
> Signed-off-by: Fam Zheng
Verified this fixes the assertion failure on 2.9.0-rc0.
Tested-by: Ed Swierk
ing. 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
> Signed-off-by: Fam Zheng
Tested-by: Ed Swierk
> ---
> hw/block/dataplane/vir
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 b/hw/virtio/virtio.c
> index 63
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.): 57149970643
Overhead Shared
On Wed, Feb 8, 2017 at 8:33 AM, Ed Swierk 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=iothread1 -device virtio-scsi-pci,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
pol
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 better name welcome)
Ei
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 full context, the retry
lient like virsh console happens to be
connected.
Signed-off-by: Ed Swierk
---
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 +1528,7 @@ static int pty_chr_
On Fri, Jan 27, 2017 at 1:40 AM, Daniel P. Berrange 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. With the pty backend,
>> pty_
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
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 at 06:26:57AM
t;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 Oct 5, 2016, at 6:29 PM, Michael S. Tsirkin
>> >>
&g
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 8003584 2093056' file
>
On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake 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't pretend to understand
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
bdrv_ali
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 alone are sufficient
On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirkin 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-01/msg05599.html
>
> W
r the entire virtual disk.
Signed-off-by: Ed Swierk
---
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/qcow2.c
+++ b/block/qc
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 explicit.
I agree explici
e 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
---
block/qcow2.c | 5 ++---
block/qcow2.h | 4
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 91
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? Or
On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev 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
> >> on Xen 4.5.3 wi
It's not clear 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
Signed-off-by: Ed Swierk
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 6eac66d..c891b67 100644
--- a/hw/net/e1000.c
+++ b/hw/n
dn't find out 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.
>
>
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
---
linux-user/mips64/target_signal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user
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
---
linux-user/syscall.c | 2 +-
1 file
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
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
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 addres
r than mapping it from the
full ROM image.
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
---
hw/pc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff
On Mon, Feb 22, 2010 at 12:51 PM, Luiz Capitulino
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 /tmp/qemu-monitor. It w
On Mon, Feb 22, 2010 at 12:51 PM, Luiz Capitulino
wrote:
> On Fri, 19 Feb 2010 10:21:41 -0800
> Ed Swierk wrote:
>
>> Commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d seems to have broken
>> the getfd monitor command in qemu 0.12.
>
> Does it work with current master?
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. tcp_chr_read()
> only need for nonblocking operations.
>
> Signed-off-by: Arnd Bergmann
This works for me.
Acked-by: Ed Swierk
On Mon, Nov 30, 2009 at 4:31 PM, Ed Swierk wrote:
> On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa 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 a
On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa 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 KVM support SMP g
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;" in
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
On 7/27/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
> I'm not sure if it's supposed to be able to run yaboot, but it doesn't
> seem to. I've tried running the netboot images (which are just a zImage
> containing kernel+initrd) and I think I had problems with that too --
> but at least that was a
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 corr
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 emulati
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
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 OpenF
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
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 pc-bios/ohw.dif
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
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'
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
to
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 chan
On 2/9/07, Paul Brook <[EMAIL PROTECTED]> wrote:
I've very little sympathy (read: none) for people who "accidentally" break
things by running them as root.
Sure, but there are plenty of other ways to accidentally mess up the
permissions of a disk image file. A while back I had to strace qemu to
This change fixes the SYSLINUX hang. Thanks!
--Ed
On 2/8/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/02/08 22:17:34
Modified files:
pc-bios: bios.diff bios.bin
Log message:
On 2/6/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
The latest bochs bios (bochs-20070105 snapshot) seems to fix the
SYSLINUX hanging issue. The bios.bin is attached.
Oops--this is BIOS-bochs-legacy. BIOS-bochs-latest still breaks SYSLINUX.
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
http://lists.nongnu.org/mailman/l
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
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
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 0.8.2, it boots just
fine.
For a simple test
This patch fixes an apparent typo in hw/usb.h.
--Ed
Index: qemu-snapshot-2007-02-02_05/hw/usb.h
===
--- qemu-snapshot-2007-02-02_05.orig/hw/usb.h
+++ qemu-snapshot-2007-02-02_05/hw/usb.h
@@ -164,7 +164,7 @@ struct USBPacket {
US
On 1/31/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
It doesn't apply for current CVS. Could you please update the patch?
I would also prefer to have enums instead of raw constants in all those
case statements.
Here you go.
--Ed
diff -BurN qemu-snapshot-2007-01-22_05.orig/hw/acpi.c qemu-snapsh
Windows 2000 boots and PC Wizard 2007 displays the following
information under the Mainboard category:
> SMBus/i2c Bus : Yes
>> General Information
Device : 82371AB/EB/MB PIIX4/E/M Power Management Controller
Revision : 0
Frequency : 16 KHz
Address : 0xB100
>> Device
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-0
1 - 100 of 132 matches
Mail list logo
