Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Add initial support for FCR register #96

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jinankjain
Copy link

@jinankjain jinankjain commented Aug 29, 2023

Summary of the PR

The goal of this pull request is to add enough FCR support to satisfy the requirement of FreeBSD. Thus, only adding support for clearing RX and TX queue while omitting other features such as Fifo enable/disable.

I would like to get the community feedback on:

  • Whether it is required to add support for other FCR bits?
  • Handling serial state change such that it does not break live migration like scenarios?

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

  • All commits in this PR are signed (with git commit -s), and the commit
    message has max 60 characters for the summary and max 75 characters for each
    description line.
  • All added/changed functionality has a corresponding unit/integration
    test.
  • All added/changed public-facing functionality has entries in the "Upcoming
    Release" section of CHANGELOG.md (if no such section exists, please create one).
  • Any newly added unsafe code is properly documented.

In order to add support for controlling FIFO using
FIFO control register we need to persist the state of FCR.
Thus, add FCR to state of serial console.

Signed-off-by: Jinank Jain <[email protected]>
Currently I am handling partial writes to FIFO control register
which deals with clearing RX/TX queues. There are other bits
which deals with disabling/enabling FIFO along with setting
different ITL mode. I think those can be added a later point
when the need arises for it.

This should fix the behavior from FreeBSD's point of view.

Signed-off-by: Jinank Jain <[email protected]>
@andreeaflorescu
Copy link
Member

@cperciva is this something that would help with the FreeBsd use case?

@@ -542,6 +546,13 @@ impl<T: Trigger, EV: SerialEvents, W: Write> Serial<T, EV, W> {
}
// We want to enable only the interrupts that are available for 16550A (and below).
IER_OFFSET => self.interrupt_enable = value & IER_UART_VALID_BITS,
FCR_OFFSET => {
if value & FCR_FIFO_RESET_RX != 0 || value & FCR_FIFO_RESET_TX != 0 {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused by this. Resetting the RX buffer isn't the same thing as resetting the TX buffer.

@cperciva
Copy link

cperciva commented Sep 5, 2023

@andreeaflorescu We have a workaround in FreeBSD right now, but yes it would be good to have the FCR fixed so we don't need the workaround.

@andreeaflorescu
Copy link
Member

@andreeaflorescu We have a workaround in FreeBSD right now, but yes it would be good to have the FCR fixed so we don't need the workaround.

Yap, I remember that you had a workaround, I was wondering if this would help with removing the workaround 😄

@cperciva
Copy link

cperciva commented Sep 5, 2023

Yap, I remember that you had a workaround, I was wondering if this would help with removing the workaround 😄

This particular workaround is fairly lightweight -- we check if flushing the FIFO resulted in the queue being empty, and if not we drain it byte by byte -- so we'll probably keep it around for a bit in case it helps with other systems. I've seen the printf triggered on some EC2 instances too, so (unless you can tell me that Nitro uses rust-vmm in its firmware?) it's probably going to be useful to keep it there anyway.

@cperciva
Copy link

cperciva commented Sep 5, 2023

But if you mean "will this make the workaround path stop being used when FreeBSD boots on Firecracker", I think the answer is yes. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants