i'd like to see that happen as well, in an open fashion, whereOn Sun, Nov 11, 2018 at 4:11 AM Alex Bradbury <a...@lowrisc.org> wrote:
> Hi Luke. I appreciate your frustration but I'd really like to keep
> this thread focused on the specific technical topics I raised.
everyone is invited to participate, and feels welcome. it would be
absolutely fantastic, to be able to have up-to-date information and
access to the resources and discussions that allow everyone to
participate.
except that's not the case, is it? and denying it and making excuses
is not going to help the situation get any better, is it? and
expecting people to WASTE THEIR TIME *reverse-engineering* private
closed discussions... and then because it's flat-out impossible to get
it right when the information and context isn't avaiable, i have
bullies fucking well REPEATEDLY poisoning discussions by saying
"you're wrong, you're wrong, but you don't know that because WE talked
about it on a PRIVATE list that YOU don't have access to, because
you're such an oh-so-high-and-mighty ethical little tosspot, har har
we had a real laugh about that one, at your expense, loserr"
so the question to ask is not "how* come you are civilised and
capable of staying within the bounds of technical discussion on other
forums: the real question is, what's different about *these* forums?
On Sun, 11 Nov 2018 at 18:31, Samuel Falvo II <sam....@gmail.com> wrote:
> Linux has a HAL. Windows uses a HAL. Most modern kernels rely upon a
> HAL-like "thing" at some level. That's an SBI but by a different
> name.
>
> It's clear that it's a valuable abstraction. The question is, I
> *think*, whether having a common interface across OSes is valuable.
I think you've hit the nail on the head. Assuming agreement on the
need for some sort of SBI, should it be scoped to _only_ provide code
necessary for first boot of a kernel and maybe providing some basic
platform-specific functionality (tlb shootdown etc) that isn't
(currently) defined in the spec. Or should it actively seek to
increase code reuse across different OSes and provide a level of
abstraction that reduces platform-specific code? e.g. abstracting the
PLIC or other platform interrupt controller. If you go that far, why
stop there? You could provide helper functionality for handling page
tables, or implement a range of other device drivers in M-mode
firmware.
Speccing the complete desired interface is the only way to go I think.
As Christoph suggests, having a RISC-V way of saving user-visible
extension state isn't a bad idea (though of course this may just be
one small part of supporting a custom extension). But someone needs to
define what the interface for doing that would look like. Requiring an
extra ecall to provide this functionality sounds expensive.
Under interpretation (b),
- Board level power-off is a complex thing that might require various
drivers (I²C, SPI, IPMI, ...) in order to talk to off-chip power
management ICs. Moving these drivers into M-mode firmware is a bad
idea IMHO, for the following reasons:
- More M-mode code *potentially* means more M-mode attack surface,
weakening the security of M-mode implementations.
- Bugs in M-mode code may be harder to patch than bugs in the S-mode
operating system, because the M-mode firmware might be stored on
special flash, or signed with the SoC vendor's key, etc.
- Having drivers in M-mode and S-mode for the same hardware may cause
some conflicts and race-conditions when both drivers access the same
hardware at the same time.
Kind regards,
Jonathan Neuschäfer
[1]: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md
[2]: S-mode shutdown code *could* be written like this:
start_poweroff_sequence();
sbi_shutdown();
// sbi_shutdown halts all harts
// the power-off sequence completes and the board is powered off
But that seems prone to timing problems, to me.
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20181111171431.GA2219%40latitude.
Best,
Alex
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH295WfxRtdipM-jUNX1YKjJuuUWaRbpq6Q9VW6iWzgz1rEQ%40mail.gmail.com.
I will keep a lite proposal about perf until RISC-V MC on Thursday unless
any of you are urged to know perf-related issues.
Alan
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20181112034328.GA24900%40andestech.com.
I've been following the recent discussions on SBI extensions with
great interest. Firstly, thank you to everyone who has been
contributing SBI proposals and documenting the current de facto SBI
standard.
I do have one request - could we all take a step back and try to
define the role and driving principles of the SBI? What problems
should it be solving? What problems shouldn't be solved via the SBI? I
understand once the framework is in place there's scope for people to
use it in a wide variety of ways, but it's really hard to judge the
various proposals without any clear definition of the SBI
requirements. Proposing incremental ABI additions seems like the wrong
way to go about development without agreeing this first.
The nearest thing we have to the guiding principles of the SBI is the
stated aim in the current privspec draft "Using a single SBI across
all SEE implementations allows a single OS binary image to run on any
SEE". The document currently proposes SBI calls for:
* Initialising, saving, and restoring user-mode state outside of the
standard FDQ extensions
* Inter-processor interrupts
* Clear timer interrupts
* Mask, unmask, and query the cause of external interrupts
(apparently, all access to the PLIC should be through the SBI?)
* Modifying the time/cycle/instret CSRs
* Scheduling timer interrupts
* TLB shootdown
This is quite an expansion over the current SBI (which seems to offer
a rather arbitrary subset of platform-specific functionality). I would
observe that none of the proposals to extend the SBI so far actually
cover all of these cases. Is that because there is disagreement over
whether the SBI should serve all these purposes, or are the proposals
simply incomplete?
Based on a recent software working group call, it seems there is a
desire for the SBI to ensure that a single kernel works across all
RISC-V implementations, including support for custom extensions (e.g.
save/restore of user-visible state as mentioned above). I'm concerned
that reaching this goal will require an increasing number of hooks
into the kernel effectively making the SBI a mini-OS. e.g. for the
tagged memory mechanism in lowRISC, saving/restoring the tagctrl
register is a necessary component of kernel support but it's also
necessary to modify the virtual memory system to support (at a
minimum) clearing tags on pages and propagating tags upon
copy-on-write.
Other questions/concerns/thoughts:
* Is there actually consensus amongst developers of S-mode code
(kernels, bootloaders etc) that the SBI is a desirable abstraction?
* Shouldn't there be an interface to allow S-mode code to control
delegation from M-mode (the SBI/SEE)? e.g. if my OS would prefer to
supply its own floating point emulation code. Or maybe an alternative
mechanism to swap out the M-mode handler code (as Ron has been
advocating)
* We currently have 3 base ISAs - RV32I, RV32E, RV64I. How is the SBI
intended to work in the case where a hart supports switching between
these? Surely an S-mode OS may be running with a different ISA variant
to the M-mode SBI/SEE? How is this handled?
* There are ideas floating around about SBI calls being more like
function calls (rather than the current ecall mechanism). Has anyone
written down how this would work?
How about we start by agreeing and enumerating the requirements, then
work our way up?
Thanks,
Alex
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH295VO1og3n6Z80GmL10a-f1MWbVxns3BJB5DXh1ohJWDfg%40mail.gmail.com.
Yes, it was unfortunately designed this way. Sigh. My question was why
does hardware expose such limitation that accessing timer/IPI should
only be done in M-mode? It could have only be one instruction of
CSR/MMIO read to get a timer counter, but now it has to call into SBI
and execute maybe one hundred instructions. This affects real-time
performance a lot.
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAP8PnuQZkDZRcRVUFWQsH73tfhLMoKONY8g-H1F86_WhTsqjzg%40mail.gmail.com.
Including ecall function ID dispatch logic?
On Mon, Nov 12, 2018, 7:34 PM Bruce Hoult <bruce...@sifive.com wrote:
--On Mon, Nov 12, 2018 at 5:21 AM, Bin Meng <bmen...@gmail.com> wrote:Yes, it was unfortunately designed this way. Sigh. My question was why
does hardware expose such limitation that accessing timer/IPI should
only be done in M-mode? It could have only be one instruction of
CSR/MMIO read to get a timer counter, but now it has to call into SBI
and execute maybe one hundred instructions. This affects real-time
performance a lot.If it's 100 instructions then someone is doing something very very wrong. Try 10.
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
Hi Bruce,
On Tue, Nov 13, 2018 at 12:41 PM Bruce Hoult <bruce...@sifive.com> wrote:
>
> Of course.
>
> Once you're in code that knows you're in an ECALL (via hardware vectoring or otherwise) that's just something like:
>
> lui t0,#ecallTableBase #or auipc
You need save t0 before using it, no?
> slli t1,a6,2 #3 for 64 bit
and t1, a6?
> add t0,t0,t1
> jr,nnn(t0) #lo bits of ecallTableBase, if not 4k aligned
> # called function does the mret
>
> That's five instructions.
>
Yes, for this particular part. But the called function (illegal
instruction handler in this case) to implement reading the mtimer
counter needs another bunch of instructions, including instruction
decoding, etc.
> You could do something like a "li t0,#nnn; blt a6,t0,heavyweight" to distinguish these simple calls from ones that actually need to save and restore registers. That makes it seven instructions.
Unless we write all ecall trap handlers in assembly codes, it's still
needed to do the blind register saving/restoring.
Hi Bruce,
On Tue, Nov 13, 2018 at 2:11 PM Bruce Hoult <bruce...@sifive.com> wrote:
>
> On Mon, Nov 12, 2018 at 9:12 PM, Bin Meng <bmen...@gmail.com> wrote:
>>
>> Hi Bruce,
>>
>> On Tue, Nov 13, 2018 at 12:41 PM Bruce Hoult <bruce...@sifive.com> wrote:
>> >
>> > Of course.
>> >
>> > Once you're in code that knows you're in an ECALL (via hardware vectoring or otherwise) that's just something like:
>> >
>> > lui t0,#ecallTableBase #or auipc
>>
>> You need save t0 before using it, no?
>
>
> Not if, as I specified below, SBI ecalls have the same/similar ABI as they would if they were in a C library.
>
Ah, I see. So that means the SBI handlers are allowed to only use
t0-t6 and a0-a7, right?
>>
>>
>> > slli t1,a6,2 #3 for 64 bit
>>
>> and t1, a6?
>
>
> *Certainly* not a6, as that has the index of the desired SBI call, and we don't modify it.
Typo, I think it should be a7.
>
>>
>>
>> > add t0,t0,t1
>> > jr,nnn(t0) #lo bits of ecallTableBase, if not 4k aligned
>> > # called function does the mret
>> >
>> > That's five instructions.
>> >
>>
>> Yes, for this particular part. But the called function (illegal
>> instruction handler in this case) to implement reading the mtimer
>> counter needs another bunch of instructions, including instruction
>> decoding, etc.
>
>
> I'm assuming here that you're making an explicit SBI call to get mtime, not handling an illegal instruction trap. Illegal instruction would definitely be a bit more heavy-weight with both decoding overheads and the necessity to save and restore everything it touches.
The issue here is that rdtime will trigger an illegel instruction
exception from user space, meaning M-mode SBI handler will need decode
and emulate the CSR instruction first before accessing to the real
mtime register, at least this is what QEMU virt does so far. I am not
sure if the virt model reflects the SiFive U540 hardware or not ...
> It's only an example. This is SBI between S mode and M mode, not the Linux BI between U mode and S mode. It doesn't have to be the same. In particular, I am proposing that calls do not have to preserve all registers.
>
OK, that doesn't matter. I think this proposal makes sense. So where
is your proposal posted?
> Illegal/unimplemented instructions from U mode are a COMPLETELY different thing to SBI, which is a call-like Binary Interface used by the Supervisor.
>
Yes I know. I was pointing out the truth that it could have been just
one instruction to get a timer counter value in an S-mode OS, but now
it has to execute way more instructions than that.
From UEFI perspective, I believe SBI would not become part of UEFI spec. But for the RISC-V ekd2 package, we would like to follow SBI spec and implement RISC-V SBI edk2 port.
From: atish patra [mailto:atis...@gmail.com]
Sent: Monday, November 12, 2018 2:31 PM
To: a...@lowrisc.org
Cc: sw-...@groups.riscv.org
Subject: Re: [sw-dev] SBI - taking a step back
Hi Alex,
Thanks for starting this topic. I believe you raised a very valid point.
IMHO, SBI should not become UEFI or a "mini" OS. I view SBI should provide
an interface for S mode that helps in maintaining a clear separation between privileged
mode & machine mode. It should include features that are absolutely necessary and would
need a hack to implement in supervisor mode. This is just my opinion.
As RISC-V is modern architecture and we all envision it to be used in various types of computing
devices, the idea with the proposal is to introduce minimal functions and keep them optional.
For example, if any embedded/iot devices doesn't need to use hart power management, they
can skip it and same supervisor OS will continue to work.
However, the primary goal is to have a proper function ID scheme & introduce version/feature check
capabilities at this point. That will help in adding any feature (i.e. absolutely necessary) in future.
Currently, it is not possible at all.
I am not sure if it will be helpful. But I can maintain a section of list of new feature suggestions in the
proposal. We can take a call if that feature is going to be added to SBI or not after it has been discussed
enough in public forums. But we need a continuous feedback/discussion on this so that we can finalize
a version of SBI at least.
On Sat, Nov 10, 2018 at 1:21 PM Alex Bradbury <a...@lowrisc.org> wrote:
I've been following the recent discussions on SBI extensions with
great interest. Firstly, thank you to everyone who has been
contributing SBI proposals and documenting the current de facto SBI
standard.
I do have one request - could we all take a step back and try to
define the role and driving principles of the SBI? What problems
should it be solving? What problems shouldn't be solved via the SBI? I
understand once the framework is in place there's scope for people to
use it in a wide variety of ways, but it's really hard to judge the
various proposals without any clear definition of the SBI
requirements. Proposing incremental ABI additions seems like the wrong
way to go about development without agreeing this first.
The nearest thing we have to the guiding principles of the SBI is the
stated aim in the current privspec draft "Using a single SBI across
all SEE implementations allows a single OS binary image to run on any
SEE". The document currently proposes SBI calls for:
* Initialising, saving, and restoring user-mode state outside of the
standard FDQ extensions
* Inter-processor interrupts
* Clear timer interrupts
* Mask, unmask, and query the cause of external interrupts
(apparently, all access to the PLIC should be through the SBI?)
* Modifying the time/cycle/instret CSRs
* Scheduling timer interrupts
* TLB shootdown
This is quite an expansion over the current SBI (which seems to offer
a rather arbitrary subset of platform-specific functionality). I would
observe that none of the proposals to extend the SBI so far actually
cover all of these cases. Is that because there is disagreement over
whether the SBI should serve all these purposes, or are the proposals
simply incomplete?
Based on a recent software working group call, it seems there is a
desire for the SBI to ensure that a single kernel works across all
RISC-V implementations, including support for custom extensions (e.g.
save/restore of user-visible state as mentioned above). I'm concerned
that reaching this goal will require an increasing number of hooks
into the kernel effectively making the SBI a mini-OS. e.g. for the
tagged memory mechanism in lowRISC, saving/restoring the tagctrl
register is a necessary component of kernel support but it's also
necessary to modify the virtual memory system to support (at a
minimum) clearing tags on pages and propagating tags upon
copy-on-write.
Other questions/concerns/thoughts:
* Is there actually consensus amongst developers of S-mode code
(kernels, bootloaders etc) that the SBI is a desirable abstraction?
* Shouldn't there be an interface to allow S-mode code to control
delegation from M-mode (the SBI/SEE)? e.g. if my OS would prefer to
supply its own floating point emulation code. Or maybe an alternative
mechanism to swap out the M-mode handler code (as Ron has been
advocating)
* We currently have 3 base ISAs - RV32I, RV32E, RV64I. How is the SBI
intended to work in the case where a hart supports switching between
these? Surely an S-mode OS may be running with a different ISA variant
to the M-mode SBI/SEE? How is this handled?
* There are ideas floating around about SBI calls being more like
function calls (rather than the current ecall mechanism). Has anyone
written down how this would work?
How about we start by agreeing and enumerating the requirements, then
work our way up?
Thanks,
Alex
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH295VO1og3n6Z80GmL10a-f1MWbVxns3BJB5DXh1ohJWDfg%40mail.gmail.com.
--
Regards,
Atish
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAELrHRDaF3oyKQoDLvHJ38x04QDiK9hQF0nuo2UsYnxqmEeM1A%40mail.gmail.com.