From: "Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH 3/5] Add support for receiving via receive buffers. While the Intel documentation claims this is unsupported, the OS X drivers use it, causing an assertion failure since rx buffer size is 0.
Date: Tue, 11 Aug 2009 23:15:09 +0200 [thread overview]
Message-ID: <20090811211509.GD10500@1und1.de> (raw)
In-Reply-To: <4A81D3F1.1040300@codemonkey.ws>
This adds support for some kind of receive buffers "flexible
mode". The Intel documentation as I read it claims that no such mode exist
for receive, but the fact that those (working with real hardware I
expect) drivers use it contradicts that...
This _definitely_ is necessary to support these AppleIntel8255x drivers.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
---
hw/eepro100.c | 27 ++++++++++++++++++++++++---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index f619d36..5620bc7 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -153,6 +153,14 @@ typedef struct {
char packet[MAX_ETH_FRAME_SIZE + 4];
} eepro100_rx_t;
+/* Receive buffer descriptor. */
+typedef struct {
+ uint32_t count;
+ uint32_t link;
+ uint32_t buffer;
+ uint32_t size;
+} eepro100_rbd_t;
+
typedef struct {
uint32_t tx_good_frames, tx_max_collisions, tx_late_collisions,
tx_underruns, tx_lost_crs, tx_deferred, tx_single_collisions,
@@ -218,6 +226,7 @@ typedef struct {
/* (ru_base + ru_offset) address the RFD in the Receive Frame Area. */
uint32_t ru_base; /* RU base address */
uint32_t ru_offset; /* RU address offset */
+ uint32_t rbd_addr;
uint32_t statsaddr; /* pointer to eepro100_stats_t */
eepro100_stats_t statistics; /* statistical counters */
#if 0
@@ -843,6 +852,7 @@ static void eepro100_ru_command(EEPRO100State * s, uint8_t val)
}
set_ru_state(s, ru_ready);
s->ru_offset = s->pointer;
+ s->rbd_addr = 0;
logout("val=0x%02x (rx start)\n", val);
break;
case RX_RESUME:
@@ -1512,7 +1522,19 @@ static ssize_t nic_receive(VLANClientState *vc, const uint8_t * buf, size_t size
cpu_physical_memory_read(s->ru_base + s->ru_offset, (uint8_t *) & rx,
offsetof(eepro100_rx_t, packet));
uint16_t rfd_command = le16_to_cpu(rx.command);
- uint16_t rfd_size = le16_to_cpu(rx.size);
+ uint32_t rfd_size = le16_to_cpu(rx.size);
+ uint32_t dst_addr = s->ru_base + s->ru_offset + offsetof(eepro100_rx_t, packet);
+ if (rfd_command & 8) {
+ // argh! Flexible mode. Intel docs say it is not support but the Mac OS driver uses it anyway.
+ eepro100_rbd_t rbd;
+ if (!s->rbd_addr)
+ s->rbd_addr = le32_to_cpu(rx.rx_buf_addr);
+ cpu_physical_memory_read(s->rbd_addr, (uint8_t *) & rbd, sizeof(rbd));
+ rfd_size = le32_to_cpu(rbd.size);
+ dst_addr = le32_to_cpu(rbd.buffer);
+ stl_phys(s->rbd_addr + offsetof(eepro100_rbd_t, count), size | 0x8000);
+ s->rbd_addr = le32_to_cpu(rbd.link);
+ }
assert(size <= rfd_size);
if (size < 64) {
rfd_status |= 0x0080;
@@ -1528,8 +1550,7 @@ static ssize_t nic_receive(VLANClientState *vc, const uint8_t * buf, size_t size
assert(!(s->configuration[18] & 4));
/* TODO: check stripping enable bit. */
//~ assert(!(s->configuration[17] & 1));
- cpu_physical_memory_write(s->ru_base + s->ru_offset +
- offsetof(eepro100_rx_t, packet), buf, size);
+ cpu_physical_memory_write(dst_addr, buf, size);
s->statistics.rx_good_frames++;
eepro100_fr_interrupt(s);
s->ru_offset = le32_to_cpu(rx.link);
--
1.6.4
next prev parent reply other threads:[~2009-08-11 21:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-09 21:14 [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches Reimar Döffinger
2009-08-10 4:36 ` Stefan Weil
2009-08-10 6:42 ` Reimar Döffinger
2009-08-17 7:47 ` Reimar Döffinger
2009-08-11 18:27 ` Reimar Döffinger
2009-08-11 20:26 ` Anthony Liguori
2009-08-11 21:13 ` [Qemu-devel] " Reimar Döffinger
2009-08-15 12:32 ` Reimar Döffinger
2009-08-11 21:14 ` [Qemu-devel] [PATCH 1/5] Setting the MDI SCBAck flag when interrupts for MDI are disabled is wrong, even if it does not seem to cause any real issue with known drivers Reimar Döffinger
2009-08-11 21:14 ` [Qemu-devel] [PATCH 2/5] Hack to make sure that drivers like AppleIntel8255x will not meddle with the RU/CU state when the ACK the interrupt with a 16 bit write Reimar Döffinger
2009-08-11 21:15 ` Reimar Döffinger [this message]
2009-08-11 23:04 ` [Qemu-devel] [PATCH 3/5] Add support for receiving via receive buffers. While the Intel documentation claims this is unsupported, the OS X drivers use it, causing an assertion failure since rx buffer size is 0 malc
2009-08-12 0:35 ` Reimar Döffinger
2009-08-12 17:34 ` malc
2009-08-12 18:24 ` Anthony Liguori
2009-08-13 13:25 ` Reimar Döffinger
2009-08-11 21:15 ` [Qemu-devel] [PATCH 4/5] Short frames do not exist, so remove code to handle them. Also expand packets that are smaller than the shor frame limit, otherwise the OS X network stack seems to discard them Reimar Döffinger
2009-08-11 21:15 ` [Qemu-devel] [PATCH 5/5] Set the RU state to ru_no_resources instead of asserting when we used up the last receive buffer. This should not usually happen with good drivers, but it can happen with the OS X drivers at least Reimar Döffinger
2009-08-12 8:53 ` [Qemu-devel] [PATCH 6/5] Implement the trivial diagnose CU and RU abort commands. These are necessary to make the device work with OpenSolaris 0609 (111b) Reimar Döffinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090811211509.GD10500@1und1.de \
--to=reimar.doeffinger@gmx.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).