feat(pci,virtio): read x86 legacy IRQ via PCI config space by sunhaosheng · Pull Request #19 · arceos-org/axdriver_crates

sunhaosheng · 2026-03-10T06:31:14Z

Related Issue

On x86_64, a host-side TCP client could not complete a TCP echo exchange with a server running inside the system. The server never reported an accepted connection, the client blocked indefinitely, and the server could not be terminated with Ctrl+C. See the issue for full reproduction steps.

Description

This PR fixes x86 legacy IRQ discovery for VirtIO PCI devices.

Previously, the x86 path relied on derived or hardcoded IRQ assumptions, which do not reliably match the actual platform-assigned legacy INTx routing. On x86, the correct legacy IRQ should be taken from the PCI configuration space Interrupt Line register instead.

To support this, this PR adds a small PCI config-space accessor in axdriver_pci and uses it in axdriver_virtio to fetch the IRQ from PCI config space during device probing.

Implementation

This PR includes two changes:

Add PciConfigAccess to axdriver_pci
- This provides read/write access to arbitrary PCI configuration space registers through the existing ECAM/MMIO mapping.
- It is intended as a minimal helper for drivers that need config-space fields not exposed by virtio-drivers.
Update axdriver_virtio::probe_pci_device() on x86
- Accept a PciConfigAccess reference.
- Read the legacy IRQ from PCI config offset 0x3C (Interrupt Line).
- Reject invalid/unassigned values (0 and 0xff) on x86 instead of treating them as usable IRQs.

Additional Context

If this PR is merged, PR arceos-org/arceos#354 should be also merged to match the new axdriver_virtio::probe_pci_device() interface.

This change is based on the same fix direction used in x-kernel commit, where x86 VirtIO probing was changed to use the PCI Interrupt Line register instead of hardcoded IRQ derivation.

I kept this PR intentionally small so it can be reviewed independently from any follow-up work around MSI-X or higher-level interrupt handling.

AsakuraMizu

https://docs.rs/virtio-drivers/0.8.0/virtio_drivers/transport/pci/bus/trait.ConfigurationAccess.html

So if we upgrade virtio-drivers to at least version 0.8.0, it will provide an interface for accessing the configuration, and we will no longer need to write PciConfigAccess.

There is already a proposal about upgrading virtio-drivers: #17

@guoweikang What do you think? I suggest upgrading virtio-drivers to a recent version (depends on your requirement) first and then working on this PR.

sunhaosheng · 2026-03-16T01:35:48Z

https://docs.rs/virtio-drivers/0.8.0/virtio_drivers/transport/pci/bus/trait.ConfigurationAccess.html

So if we upgrade virtio-drivers to at least version 0.8.0, it will provide an interface for accessing the configuration, and we will no longer need to write PciConfigAccess.

There is already a proposal about upgrading virtio-drivers: #17

@guoweikang What do you think? I suggest upgrading virtio-drivers to a recent version (depends on your requirement) first and then working on this PR.

Thanks, that makes sense.

This PR was implemented against virtio-drivers 0.7.x, where I added PciConfigAccess as a local workaround to read the PCI Interrupt Line register on x86. If we upgrade to virtio-drivers >= 0.8.0, I agree it would be better to reuse the upstream configuration access interface and rework this PR on top of that.

Please see this pr:
#20

Add PciConfigAccess to axdriver_pci so drivers can read arbitrary PCI config registers, and use it in axdriver_virtio to fetch the legacy IRQ from the Interrupt Line register on x86. This avoids hardcoded IRQ derivation and matches the platform-assigned legacy INTx routing.

Cargo.toml

AsakuraMizu · 2026-03-18T02:05:07Z

axdriver_virtio/src/lib.rs

    root: &mut PciRoot<C>,
+    config: &C,


Oh I haven't think about this before in #20... These arguments are definitely redundant, and for the caller, it's hard to have a PciRoot and ConfigurationAccess at the same time (PciRoot::new takes ownership). I think we may send a PR to virtio-drivers to add a Deref<Target = C> impl for PciRoot<C>.

Since the configuration_access field was made public after the 0.13.0 crate was published to crates.io, a [patch.crates-io] entry pointing to the git HEAD is needed temporarily. This will be removed once a new version is released.

axdriver_virtio/src/lib.rs

- Remove the redundant parameter from , since now exposes as a public field (rcore-os/virtio-drivers#233). - Use directly on x86_64 instead. - Add to . - Bump dependency to 0.13.0 (patch via git for the public field).

equation314 · 2026-04-03T03:22:21Z

axdriver_virtio/src/lib.rs

+
+    #[cfg(not(target_arch = "x86_64"))]
+    let irq = {
+        #[cfg(target_arch = "loongarch64")]


Why not read Interrupt Line on no-x86 architectures?

We intentionally only read PCI Interrupt Line on x86_64.

Although the register exists in standard PCI config space, on our non-x86 targets we do not treat it as a reliable IRQ source. Those platforms use board/host-specific INTx routing, and in our current environments the IRQ is derived from the fixed platform mapping instead of the Interrupt Line register.

equation314 · 2026-04-03T04:49:57Z

axdriver_virtio/src/lib.rs

 ///
 /// If the device is recognized, returns the device type and a transport object
 /// for later operations. Otherwise, returns [`None`].
 pub fn probe_pci_device<H: VirtIoHal, C: ConfigurationAccess>(


The return value of this function now includes irq, which is inconsistent with probe_mmio_device. Why not let probe_mmio_device also return the IRQ number? Or use another method to obtain the IRQ number without breaking the interface?

The irq in the return type is not introduced by this change; it has been part of probe_pci_device since commit 59a8d70 (feat(virtio,net): irq).

This patch only changes how the PCI IRQ is derived on x86_64, not the function interface itself.

If you think we should also clean up the interface inconsistency with probe_mmio_device, I can send a follow-up change for that.

This was referenced Mar 10, 2026

feat(pci,virtio): read x86 legacy IRQ via PCI config space #18

Closed

fix(axdriver): pass PCI config accessor to VirtIO PCI probe arceos-org/arceos#354

Open

AsakuraMizu reviewed Mar 15, 2026

View reviewed changes

sunhaosheng-kylin added 4 commits March 18, 2026 09:47

fix fmt

c74f874

feat(pci,virtio): read x86 legacy IRQ via PCI config space

c10d32b

fix fmt

fbc301e

sunhaosheng force-pushed the for-tcp-fix-pr1 branch from 3c8d388 to fbc301e Compare March 18, 2026 01:47

refactor(virtio): reuse upstream PCI configuration access

9d56106

AsakuraMizu requested changes Mar 18, 2026

View reviewed changes

AsakuraMizu mentioned this pull request Mar 18, 2026

feat: expose configuration_access field in PciRoot rcore-os/virtio-drivers#233

Merged

sunhaosheng-kylin added 2 commits March 31, 2026 14:44

fix: remove redundant param in and bump virtio-drivers

5132974

- Remove the redundant parameter from , since now exposes as a public field (rcore-os/virtio-drivers#233). - Use directly on x86_64 instead. - Add to . - Bump dependency to 0.13.0 (patch via git for the public field).

fix inline

1e6bb5d

equation314 reviewed Apr 3, 2026

View reviewed changes

sunhaosheng requested a review from AsakuraMizu April 3, 2026 06:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(pci,virtio): read x86 legacy IRQ via PCI config space#19

feat(pci,virtio): read x86 legacy IRQ via PCI config space#19
sunhaosheng wants to merge 7 commits intoarceos-org:dev_oldfrom
sunhaosheng:for-tcp-fix-pr1

sunhaosheng commented Mar 10, 2026 •

edited

Loading

Uh oh!

AsakuraMizu left a comment

Uh oh!

sunhaosheng commented Mar 16, 2026 •

edited

Loading

Uh oh!

Uh oh!

AsakuraMizu Mar 18, 2026

Uh oh!

sunhaosheng Mar 31, 2026

Uh oh!

Uh oh!

equation314 Apr 3, 2026

Uh oh!

sunhaosheng Apr 3, 2026

Uh oh!

equation314 Apr 3, 2026

Uh oh!

sunhaosheng Apr 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

sunhaosheng commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related Issue

Description

Implementation

Additional Context

Uh oh!

AsakuraMizu left a comment

Choose a reason for hiding this comment

Uh oh!

sunhaosheng commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

AsakuraMizu Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

sunhaosheng Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

equation314 Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

sunhaosheng Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

equation314 Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

sunhaosheng Apr 3, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

sunhaosheng commented Mar 10, 2026 •

edited

Loading

sunhaosheng commented Mar 16, 2026 •

edited

Loading