virtio-queue: kani proofs for virtio queue #363
Conversation
priyasiddharth
requested review from
alexandruag,
andreeaflorescu,
jiangliu,
slp,
stsquad,
epilys and
stefano-garzarella
as code owners
This simplifies the logic for the existing need_notification proof and makes it more general accounting for both when notification is needed and when it is not. Signed-off-by: Siddharth Priya <[email protected]>
1. Verify enable_notification logic 2. Verify when driver should send notification to device 3. Verify when driver should not send notification to device 4. Verify that set_next_used method actually changes the next_used field in memory Signed-off-by: Siddharth Priya <[email protected]>
priyasiddharth
force-pushed
the
main
branch
from
edd1731 to
24dc553
Compare
|
@MatiasVara FYI |
epilys
changed the title
| let ProofContext { mut queue, memory } = kani::any(); | ||
| let result = queue.set_notification(&memory, false /* disable notification */); | ||
| if !queue.event_idx_enabled { | ||
| // Check for Sec 2.7.10 |
There was a problem hiding this comment.
Sec, should be Spec right?
Also the test doc talks about Specification (VirtIO 1.3, Section 2.7.7: "Used Buffer Notification Suppression") what 2.7.10 is? Is related to virtio 1.3?
Please be more verbose with that references.
There was a problem hiding this comment.
I think here you could add that Section 2.7.10 of the Virtio spec explains how the device can indicates to the driver that notifications are not required when adding buffers into the avail right.
| } | ||
| } | ||
|
|
||
| /// # Specification (VirtIO 1.3, Section 2.7.7.2: "Device Requirements: Used Buffer Notification Suppression") |
There was a problem hiding this comment.
The commit 4a8b048 description is not really clear to me.
It seems now this function don't test only the suppression, so should we update this documentation?
There was a problem hiding this comment.
I think the proof is testing both w/wo suppression. I think the comment should only mention about the notification.
| mem: &M, | ||
| order: Ordering, | ||
| ) -> Result<u16, Error> { | ||
| // This can not overflow an u64 since it is working with relatively small numbers compar |
There was a problem hiding this comment.
| // This can not overflow an u64 since it is working with relatively small numbers compar | |
| // This can not overflow an u64 since it is working with relatively small numbers compared |
| // - true, if there are pending entries in the `idx` field of the | ||
| // avail ring | ||
| // - false, if there are no pending entries in the `idx` field of the | ||
| // avail ring The check for pending entries is done by comparing the |
There was a problem hiding this comment.
| // avail ring The check for pending entries is done by comparing the | |
| // avail ring. The check for pending entries is done by comparing the |
| mem.load::<u16>(queue.used_ring, order) | ||
| .map(u16::from_le) | ||
| .map_err(Error::GuestMemory) | ||
| } |
| #[kani::unwind(0)] | ||
| fn verify_set_notification_false() { | ||
| let ProofContext { mut queue, memory } = kani::any(); | ||
| let result = queue.set_notification(&memory, false /* disable notification */); |
There was a problem hiding this comment.
Can't we use kany::any to cover the potential values of the second parameter of set_notification()? This would prevent having two proofs.
| /// This proof checks that: | ||
| /// - If there are pending entries in the avail ring (avail_idx != next_avail), | ||
| /// `enable_notification` returns true. | ||
| /// - If there are no pending entries (avail_idx == next_avail), it returns false. |
There was a problem hiding this comment.
I think VirtIO 1.3, Section 2.7.6.1 states that avail_idx is always >= than next_avail. Although, it is correct that enable_notification() checks only if they are different.
Summary of the PR
This PR adds new Kani proofs for virtio queue mainly around notification logic.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
git commit -s), and the commit message has max 60 characters for thesummary and max 75 characters for each description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafecode is properly documented.