tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Topics Expanded Polls

Export Group Data

Between

and

Re: [PATCH] Provide a simple introduction

+Kumar -- Regards, Atish

By atishp@... · #557 ·

Re: Update on meeting schedule (No meeting on 8th Feb 2021)

Here is the poll results until

By atishp@... · #556 ·

Re: Update on meeting schedule

Personally, I prefer evening/night time(PST) for the meeting as well. However, that would be inconvenient for folks in europe & EST. I think we will have this issue until Daylight saving starts(14th

By atishp@... · #555 ·

Re: RISC-V H-extension freeze consideration

I generally agree with Andrew. At the same time I'll also observe that, practically speaking, the AIA is coming soon and it very much directly interacts with the H extension. So waiting a little

By Greg Favor · #554 ·

Re: RISC-V H-extension freeze consideration

In other architectures, those devices are needlessly complex in part because they weren’t co-designed with the ISA. Yes, they can be independently designed, but possibly with regrettable

By andrew@... · #553 ·

Re: RISC-V H-extension freeze consideration

On all major architectures (x86 and ARM64), the virtualization-aware interrupt controllers and IOMMUs are totally independent from ISA virtualization support. We already the required ISA support

By Anup Patel · #552 ·

Re: RISC-V H-extension freeze consideration

* substantially greater utility Shouldn’t write emails on phone...

By andrew@... · #551 ·

Re: Update on meeting schedule

I am based in India (GMT+5:30). I am fine with current time slot and some of the proposed time slots in poll. Early morning of GMT+8 will be like mid-night for me so not feasible for me.

By Anup Patel · #550 ·

Re: RISC-V H-extension freeze consideration

I’m not in support of freezing it yet. My concern is that development of virtualization-aware interrupt controllers and IOMMUs will lead to reconsideration of some of the details. All of these items

By andrew@... · #549 ·

RISC-V H-extension freeze consideration

Hi All, The RISC-V H-extension v0.6.1 draft was released almost a year back in May 2020. There has been no changes in the H-extension specification since then. Meanwhile, we have RISC-V H-extension

By Anup Patel · #548 ·

Re: Update on meeting schedule

Myself, I'm Ok with an evening/night time for the meeting (not trying to speak at all for others). Maybe have the meeting alternate between early morning and evening/night? Although I suspect just a

By Greg Favor · #547 ·

Re: Update on meeting schedule

Hi Atish, I believe people here in GMT+8 will still prefer the current slot. It is 11pm, not good but manageable. All the slots are worse than this one. If we can't stick to the current one, Is it

By Siqi Zhao · #546 ·

Update on meeting schedule

Hi, As per the discussion in last meeting, we are planning to move the meeting to another time slot as 7am PST slot is going to be crowded. To avoid meeting fatigue, we are also planning to change

By atishp@... · #545 ·

Re: Partial summary of potential Embedded-2022 platform spec discussion

A key representative from this group needs to be selected to become part of the RVM profile definition discussions - to provide exactly this sort of input. Greg

By Greg Favor · #544 ·

Re: Partial summary of potential Embedded-2022 platform spec discussion

that is a good point. I suggest the platform group spend a little time figuring out the equivalence classes. We can eventually have more than two profiles but don't want dozens of standard

By mark · #543 ·

Re: Partial summary of potential Embedded-2022 platform spec discussion

There is still a desire to maintain source comparability. As well as that, vendous don't make "RTOS" SoCs. They make SoCs targetting embedded, which can run an RTOS, embedded OS or just

By Alistair Francis <alistair.francis@...> · #542 ·

Re: [RISC-V] [tech-privileged] [Announcement] Successful KVM RISC-V bring up on FPGA (Rocket core with H extension)

Sure. I will send that once I have the detailed instructions available in public domain. -- Regards, Atish

By atishp@... · #541 ·

Re: Partial summary of potential Embedded-2022 platform spec discussion

We also need to keep in mind what the marketing names will be for these platform specs - because ultimately that is what most people (outside of this group) will be using. Which probably means names

By Greg Favor · #540 ·

Re: Partial summary of potential Embedded-2022 platform spec discussion

Thanks Greg. Why do we want to include bare-metal ? There won't be any software compatibility between bare-metal software applications. Why do they need to comply with a specification that is not

By atishp@... · #539 ·

Re: Partial summary of potential Embedded-2022 platform spec discussion

I would prefer to have “visual” names while we work on this and move towards a neutral name as we near the review cycles (to remove some of the bias that we want initially).

By Philipp Tomsich · #538 ·

1301 - 1320 of 1857

Home Hashtags Subgroups Terms