Re: [Qemu-devel] [PATCH v2 5/6] e1000: Choose which set of props to migrate

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/

Re: [Qemu-devel] [PATCH 3/3] e1000: Old machine types, turn new subsection off

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

Re: [Qemu-devel] [PATCH 0/3] e1000 migration changes for 2.12

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 >

Re: [Qemu-devel] [PULL 00/18] Net patches

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

Re: [Qemu-devel] [PULL 00/18] Net patches

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

[Qemu-devel] [PATCH v3 REPOST] net: Transmit zero UDP checksum as 0xFFFF

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

Re: [Qemu-devel] [PATCH v3] net: Transmit zero UDP checksum as 0xFFFF

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

[Qemu-devel] [PATCH v3] net: Transmit zero UDP checksum as 0xFFFF

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

Re: [Qemu-devel] [PATCH v2] net: Transmit zero UDP checksum as 0xFFFF

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

[Qemu-devel] [PATCH v2] net: Transmit zero UDP checksum as 0xFFFF

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 +++---

Re: [Qemu-devel] [PATCH] net: Transmit zero UDP checksum as 0xFFFF

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

Re: [Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e

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

[Qemu-devel] [PATCH] net: Transmit zero UDP checksum as 0xFFFF

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

[Qemu-devel] [PATCH 2/2] e1000: Separate TSO and non-TSO contexts, fixing UDP TX corruption

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/

[Qemu-devel] [PATCH 1/2] e1000, e1000e: Move per-packet TX offload flags out of context state

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

[Qemu-devel] [PATCH 0/2] e1000: Correct TX offload context handling

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

[Qemu-devel] [PATCH v2 2/2] e1000e: Add e1000-ng devices

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

[Qemu-devel] [PATCH v2 0/2] e1000e: Reimplement e1000 as a variant of e1000e

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 |

[Qemu-devel] [PATCH v2 1/2] e1000e: Infrastructure for e1000-ng

, 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

[Qemu-devel] [PATCH 1/2] e1000e: Infrastructure for e1000-ng

, 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

[Qemu-devel] [PATCH 0/2] e1000e: Reimplement e1000 as a variant of e1000e

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

[Qemu-devel] [PATCH 2/2] e1000e: Add e1000-ng devices

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

Re: [Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

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, > >

[Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

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

[Qemu-devel] [RFC v2] e1000: Faulty tx checksum offload corrupts packets

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 +++--

[Qemu-devel] [RFC] e1000: Faulty tx checksum offload corrupts packets

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

Re: [Qemu-devel] New iotest repros failures on virtio external snapshot with iothread

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

[Qemu-devel] New iotest repros failures on virtio external snapshot with iothread

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

Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

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

Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

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

Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

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

Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

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. > >

Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

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. > >

Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

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 &

[Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread

> 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.

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

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

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

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

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

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) > {

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

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>

Re: [Qemu-devel] [PATCH] virtio: Report real progress in VQ aio poll handler

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

Re: [Qemu-devel] virtio-scsi-pci iothread spins at 100%

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

Re: [Qemu-devel] virtio-scsi-pci iothread spins at 100%

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

Re: [Qemu-devel] virtio-scsi-pci iothread spins at 100%

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.):

Re: [Qemu-devel] virtio-scsi-pci iothread spins at 100%

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

[Qemu-devel] virtio-scsi-pci iothread spins at 100%

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

Re: [Qemu-devel] [PATCH] char: drop data written to a disconnected pty

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

Re: [Qemu-devel] [libvirt] char: Logging serial pty output when disconnected

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

[Qemu-devel] [PATCH] char: drop data written to a disconnected pty

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 +

Re: [Qemu-devel] [libvirt] char: Logging serial pty output when disconnected

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.

[Qemu-devel] char: Logging serial pty output when disconnected

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

Re: [Qemu-devel] Virtual Machine Generation ID

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

Re: [Qemu-devel] Virtual Machine Generation ID

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: >> >>

Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k

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

Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k

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'

[Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k

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

Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes

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

Re: [Qemu-devel] Virtual Machine Generation ID

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

[Qemu-devel] [PATCH v2] qcow2: Add cache-size=max option to optimize caches for performance

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

Re: [Qemu-devel] [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes

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

[Qemu-devel] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes

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

[Qemu-devel] Virtual Machine Generation ID

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?

Re: [Qemu-devel] [Xen-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

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 >

[Qemu-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

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

Re: [Qemu-devel] [PATCH for-2.5] piix: Document coreboot-specific RAM size config register

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

[Qemu-devel] [PATCH] linux-user: Fix ioctl cmd type mismatch on 64-bit targets

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

[Qemu-devel] [PATCH] mips64-linux-user: Fix definition of struct sigaltstack

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

[Qemu-devel] [PATCH] linux-user: Return correct errno for unsupported netlink socket

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

[Qemu-devel] Invalid data memory access on qemu-ppc

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

[Qemu-devel] [Qemu] [PATCH] Allow booting large Coreboot image as BIOS

. 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

Re: [Qemu-devel] getfd monitor command broken

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

[Qemu-devel] getfd monitor command broken

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.

[Qemu-devel] Re: [PATCH 1/2] macvtap: rework object lifetime rules

-off-by: Arnd Bergmann a...@arndb.de This works for me. Acked-by: Ed Swierk eswi...@aristanetworks.com

Re: [Qemu-devel] [PATCH 0/7] KVM SMP support, early version

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

Re: [Qemu-devel] [PATCH 0/7] KVM SMP support, early version

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

Re: [Qemu-devel] PreP kernels boot using Qemu

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

Re: [Qemu-devel] merging kqemu into mainline kernel?

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

[Qemu-devel] [PATCH] Memory corruption after OHCI reset

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

Re: [Qemu-devel] Classic Mac OS

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

Re: [Qemu-devel] Rewritten Linux kernel loader

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

[Qemu-devel] OpenHackWare hacking

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

[Qemu-devel] Building OpenHackWare (qemu-system-ppc firmware)

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

Re: [Qemu-devel] Building OpenHackWare (qemu-system-ppc firmware)

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

[Qemu-devel] Linux 2.6 kernel on PPC

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

Re: [Qemu-devel] [PATCH] don't require a disk image for network boot

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-devel] [PATCH] Fix crash after char device read returns 0

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

[Qemu-devel] Re: [PATCH] LinuxBIOS support: map BIOS into ISA address space as RAM instead of ROM

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

[Qemu-devel] [PATCH] LinuxBIOS support: map BIOS into ISA address space as RAM instead of ROM

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

[Qemu-devel] [PATCH] Updated bochs bios.bin fixes SYSLINUX hanging

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

[Qemu-devel] Re: Recent BIOS breaks SYSLINUX with -nographic

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

[Qemu-devel] Re: Recent BIOS breaks SYSLINUX

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

Re: [Qemu-devel] [PATCH] PIIX4 SMBus host, EEPROM device emulation

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-devel] Unidirectional pipe support

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),

[Qemu-devel] OHCI for i386

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

Re: [Qemu-devel] Fastest TCP/IP Stack

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

[Qemu-devel] PCI IRQ routing problems

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:

[Qemu-devel] [PATCH] Support for large LinuxBIOS images

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

[Qemu-devel] [PATCH] Set RAM size in i440FX PCI configuration

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

Re: [Qemu-devel] pronunciation of Qemu

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.

Re: [Qemu-devel] [PATCH] -redir revisited

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

[Qemu-devel] [PATCH] Allow user to configure -net user subnet

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   2   >