+Kumar -- Regards, Atish

Here is the poll results until

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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).