[RFC] Add initial support for FCR register

[jinankjain]

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:

• [x] 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.
• [x] All added/changed functionality has a corresponding unit/integration test.
• [x] All added/changed public-facing functionality has entries in the "Upcoming Release" section of CHANGELOG.md (if no such section exists, please create one).
• [x] Any newly added unsafe code is properly documented.

[andreeaflorescu]

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

[cperciva]

@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]

@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]

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]

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