[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 17/17] hw/block/nvme: change controller pci id

From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 17/17] hw/block/nvme: change controller pci id
Date: Mon, 7 Sep 2020 11:33:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 9/7/20 11:20 AM, Klaus Jensen wrote:
> On Sep  7 10:58, Klaus Jensen wrote:
>> On Sep  7 10:36, Philippe Mathieu-Daudé wrote:
>>> On 9/7/20 9:23 AM, Klaus Jensen wrote:
>>>> On Sep  7 04:28, Philippe Mathieu-Daudé wrote:
>>>>> +David in case
>>>>> On 9/4/20 4:19 PM, Klaus Jensen wrote:
>>>>>> From: Klaus Jensen <k.jensen@samsung.com>
>>>>>> There are two reasons for changing this:
>>>>>>   1. The nvme device currently uses an internal Intel device id.
>>>>>>   2. Since commits "nvme: fix write zeroes offset and count" and "nvme:
>>>>>>      support multiple namespaces" the controller device no longer has
>>>>>>      the quirks that the Linux kernel think it has.
>>>>>>      As the quirks are applied based on pci vendor and device id, change
>>>>>>      them to get rid of the quirks.
>>>>>> To keep backward compatibility, add a new 'x-use-intel-id' parameter to
>>>>>> the nvme device to force use of the Intel vendor and device id. This is
>>>>>> off by default but add a compat property to set this for 5.1 machines
>>>>>> and older.
>>>>> So now what happens if you start a 5.1 machine with a recent kernel?
>>>>> Simply the kernel will use unnecessary quirks, or are there more
>>>>> changes in behavior?
>>>> Yes, the kernel will then just apply unneccesary quirks, these are:
>>>>   1. NVME_QUIRK_IDENTIFY_CNS which says that the device does not support
>>>>      anything else than values 0x0 and 0x1 for CNS (Identify Namespace and
>>>>      Identify Namespace). With multiple namespace support, this just
>>>>      means that the kernel will "scan" namespaces instead of using
>>>>      "Active Namespace ID list" (CNS 0x2).
>>>>   2. NVME_QUIRK_DISABLE_WRITE_ZEROES. The nvme device started out with a
>>>>      broken Write Zeroes implementation which has since been fixed in
>>>>      commit 9d6459d21a6e ("nvme: fix write zeroes offset and count").
>>> OK thanks. Can you amend that information in the commit
>>> description please?
>> Yes, absolutely.
> By the way. Is it correct use of an 'x-' parameter here - since it is
> something that we might remove in the future? I was unable to find any
> documentation on the purpose of the 'x-' prefix, but I was guessing it
> was for stuff like this.

Probably not. 'x-' is for unstable debugging/testing features.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]