On 22/02/2019 12:51, Jan Beulich wrote:
On 22.02.19 at 13:40, wrote:
>> There are several reasons why it's better:
>> a) kernel is able to perform device reset properly as it has bus
>> specific code that does this. There is even a comment in the code
>> mentioning that at the moment it
>>> On 22.02.19 at 13:40, wrote:
> On 22/02/2019 09:52, Jan Beulich wrote:
> On 20.02.19 at 19:19, wrote:
>>> On 20/02/2019 08:48, Jan Beulich wrote:
Some entity needs to decide whether to add the respective command
line option to the crash kernel's command line. It should be
On 22/02/2019 09:52, Jan Beulich wrote:
On 20.02.19 at 19:19, wrote:
>> On 20/02/2019 08:48, Jan Beulich wrote:
>>>
>>> Some entity needs to decide whether to add the respective command
>>> line option to the crash kernel's command line. It should be this same
>>> entity to tell Xen whether
>>> On 20.02.19 at 19:19, wrote:
> On 20/02/2019 08:48, Jan Beulich wrote:
>>
>> Some entity needs to decide whether to add the respective command
>> line option to the crash kernel's command line. It should be this same
>> entity to tell Xen whether to keep the IOMMU enabled while invoking
>>
>>> On 20.02.19 at 20:05, wrote:
> On 20/02/2019 08:55, Jan Beulich wrote:
>>
>> Everything, absolutely everything is possible as a cause for a crash.
>> I don't see why device isolation would matter here at all. Page table
>> corruption (be it IOMMU or CPU one) can be caused by
>>
On 20/02/2019 08:55, Jan Beulich wrote:
>
> Everything, absolutely everything is possible as a cause for a crash.
> I don't see why device isolation would matter here at all. Page table
> corruption (be it IOMMU or CPU one) can be caused by
> malfunctioning kernel code, entirely unrelated to what
On 20/02/2019 09:01, Jan Beulich wrote:
> But isn't it a valid question whether keeping interrupt remapping
> enabled is helpful or potentially making things worse? The
> description of the patch discusses the DMA translation aspects
> only. Unless the crash kernel would always operate in polling
On 20/02/2019 08:48, Jan Beulich wrote:
>
> Some entity needs to decide whether to add the respective command
> line option to the crash kernel's command line. It should be this same
> entity to tell Xen whether to keep the IOMMU enabled while invoking
> the crash kernel. I am merely guessing
>>> On 19.02.19 at 22:19, wrote:
> On 19/02/2019 07:43, Jan Beulich wrote:
>>
An option is left for compatibility with ancient crash kernels which
didn't like to have IOMMU active under their feet on boot.
Signed-off-by: Igor Druzhinin
>>> To provide a bit of extra
>>> On 19.02.19 at 13:31, wrote:
> On 19/02/2019 07:43, Jan Beulich wrote:
> On 18.02.19 at 19:30, wrote:
>>> On 18/02/2019 16:21, Igor Druzhinin wrote:
It's unsafe to disable IOMMU on a live system which is the case
if we're crashing since remapping hardware doesn't usually know
>>> On 19.02.19 at 13:08, wrote:
> On 19/02/2019 08:13, Jan Beulich wrote:
> On 18.02.19 at 17:21, wrote:
>>> Jan, Andrew, should we have this option here and, if so, what is the default
>>> value for it should be?
>>
>> I think the option should definitely be here (I can't even see what
>>
On 19/02/2019 07:43, Jan Beulich wrote:
>
>>> An option is left for compatibility with ancient crash kernels which
>>> didn't like to have IOMMU active under their feet on boot.
>>>
>>> Signed-off-by: Igor Druzhinin
>> To provide a bit of extra background, it turns out that in hindsight,
>>
On 19/02/2019 07:43, Jan Beulich wrote:
On 18.02.19 at 19:30, wrote:
>> On 18/02/2019 16:21, Igor Druzhinin wrote:
>>> It's unsafe to disable IOMMU on a live system which is the case
>>> if we're crashing since remapping hardware doesn't usually know what
>>> to do with ongoing bus
On 19/02/2019 08:13, Jan Beulich wrote:
On 18.02.19 at 17:21, wrote:
>
> First of all - please follow patch submission rules: They get sent _to_
> the list, with maintainers and others _cc_-ed.
>
>> It's unsafe to disable IOMMU on a live system which is the case
>> if we're crashing since
>>> On 18.02.19 at 17:21, wrote:
First of all - please follow patch submission rules: They get sent _to_
the list, with maintainers and others _cc_-ed.
> It's unsafe to disable IOMMU on a live system which is the case
> if we're crashing since remapping hardware doesn't usually know what
> to
>>> On 18.02.19 at 19:30, wrote:
> On 18/02/2019 16:21, Igor Druzhinin wrote:
>> It's unsafe to disable IOMMU on a live system which is the case
>> if we're crashing since remapping hardware doesn't usually know what
>> to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
>>
On 18/02/2019 16:21, Igor Druzhinin wrote:
> It's unsafe to disable IOMMU on a live system which is the case
> if we're crashing since remapping hardware doesn't usually know what
> to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
> etc. (depends on the firmware
It's unsafe to disable IOMMU on a live system which is the case
if we're crashing since remapping hardware doesn't usually know what
to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
etc. (depends on the firmware configuration) to signal these abnormalities.
This, in turn,
18 matches
Mail list logo
