Re: hardware domain and control domain separation

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.06.2025 23:18, Jason Andryuk wrote:
> On 2025-06-25 01:32, Jan Beulich wrote:
>> On 24.06.2025 22:14, Jason Andryuk wrote:
>>> On 2025-06-24 01:25, Jan Beulich wrote:
>>>> On 24.06.2025 00:51, Stefano Stabellini wrote:
>>>>> On Mon, 23 Jun 2025, Demi Marie Obenour wrote:
>>>>>> On 6/23/25 11:44, Jan Beulich wrote:
>>>>>>> On 21.06.2025 02:41, Stefano Stabellini wrote:
>>>>>>> Also a more fundamental question I was wondering about: If Control had
>>>>>>> full privilege, nothing else in the system ought to be able to interfere
>>>>>>> with it. Yet then how does that domain communicate with the outside
>>>>>>> world? It can't have PV or Virtio drivers after all. And even if its
>>>>>>> sole communication channel was a UART, Hardware would likely be able to
>>>>>>> interfere.
>>>>>
>>>>> There are well-established methods for implementing domain-to-domain
>>>>> communication that are free from interference, such as using carefully
>>>>> defined rings on static shared memory. I believe one of these techniques
>>>>> involves placing the indexes on separate pages and mapping them
>>>>> read-only from one of the two domains.
>>>>
>>>> How's that going to help with the backend refusing service, which I view
>>>> as one "method" of interference? Or else, what exactly does "interference"
>>>> mean in this context? (More generally, I think it is necessary to very
>>>> clearly define terminology used. Without such, words can easily mean
>>>> different things to different people.)
>>>
>>> Yes, there are different kids of interference.  We are concerned about a 
>>> domain blocking another domain.  The main example is an ioreq blocking a 
>>> vCPU.  The blocked domain is unable to recover on its own.
>>
>> On which insns an ioreq server may kick in can be well known. A kernel
>> can therefore, in principle, come with recovery code, just like it can ...
> 
> The case I am thinking of is QEMU providing a virtio device to a domain. 
>   The domain has to write to a MMIO area in a BAR to notify QEMU.  From 
> my understanding, that vCPU is blocked in Xen until QEMU responds to the 
> ioreq.  I don't see how any recovery code is possible, but I may be 
> missing something.

Hmm, yes, no idea now what I was thinking when I wrote the earlier reply.

Jan