[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 5/6] xen/riscv: introduce an implementation of macros from <asm/bug.h>
- To: Oleksii <oleksii.kurochko@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 1 Jun 2023 09:59:09 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2MoER1r269wAgXUNhYwrT5v4NEVmiygIQb8BKs0FnO4=; b=PQmkSWsYIu6eJz0knMwkTT8Tpfko4s0+fi33w53UydMfrtxAp7Qrwqsmd5e+UZhbHK9UrpE+kt/yi/bEQlwfUhuV/JuJLiz26umG/VS0BByH2f28FviMJChHRvewp6tFOJNXJazzt9vYdWScJzmoJmN2GchKemIq3x8luDceduhEChyHtx9TrabZQd0AcnpXJK7ti5l48hdo/TtxuW16dEM/ZyFwS6uvhtPlGNBghMlXPeuFQHIEcwdFGF9vE7LjEhNeDh3ZaBhjUB8IMMMJMEtSiH4ia1Ti4FXf9ZhJzSwD4R/gtbMjto9/jYU1LhpCbZ+A9mx4ov31SQQ0EYvnUg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mvc50qa/kGd9Yn+eALAAtKC7891w8lXp+E7YlpHnyXhcSYH60lSNP+ji5VGaL/f/YN8vpChW2Ip1HDBATxDMGvk2+puVsTObS58bBc63WNuinG6a46DWk7tL4C/7mwhqOiZkU41Filwq2IWnabEyo8XSF3l7XeGuswD/M7kGWT8W3e4rSArHCfs0TyDs+jLUg7lBrCSLe2ceNzQ49UepaUTNZVW3vHzNXv2O8QO7iLltYlWrm+XLdcdWSU6wTawJEPnpAssMSfwzqeXgZGgv8wgSvpdIQw1+LhT6+VD+iSgI7D+eYljpUrtJQNrnasq8JUhmPd0rqdPvbAFgrXILEQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Julien Grall <julien@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bob Eshleman <bobbyeshleman@xxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 01 Jun 2023 07:59:31 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 31.05.2023 22:06, Oleksii wrote:
> On Tue, 2023-05-30 at 18:00 +0200, Jan Beulich wrote:
>>> +static uint32_t read_instr(unsigned long pc)
>>> +{
>>> + uint16_t instr16 = *(uint16_t *)pc;
>>> +
>>> + if ( GET_INSN_LENGTH(instr16) == 2 )
>>> + return (uint32_t)instr16;
>>> + else
>>> + return *(uint32_t *)pc;
>>> +}
>>
>> As long as this function is only used on Xen code, it's kind of okay.
>> There you/we control whether code can change behind our backs. But as
>> soon as you might use this on guest code, the double read is going to
>> be a problem
> Will it be enough to add a comment that read_instr() should be used
> only on Xen code? Or it is needed to introduce some lock?
A comment will do for now. A lock would be problematic: It won't help
when the function is used on non-Xen code, and since you use this in
exception handling you may deadlock unless you carefully use a
recursive lock.
>> (I think; I wonder how hardware is supposed to deal with
>> the situation: Maybe they indeed fetch in 16-bit quantities?).
> I thought that it reads amount of bytes corresponded to i-cache size
> and then the pipeline tracks whether an instruction is 16 or 32 bit.
And what if an insn spans a cacheline boundary?
Jan
|
