ject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
>
> Olaf Hering writes:
>
> > On Thu, Dec 15, Vitaly Kuznetsov wrote:
> >
> >> vmbus_wait_for_unload() may be receiving a message (not necessarily
> the
> >> CHANNELMSG_UNLOAD_RESPONSE,
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> -> K. Y., but these words were written before I implemented
> vmbus_wait_for_unload(), to me they just explain how we read messages.
Another question for KY:
In my testing, while busy-looping in vmbus_wait_for_unload, I see a few
"message_type==1, hdr->msg
Olaf Hering writes:
> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
>> vmbus_wait_for_unload() may be receiving a message (not necessarily the
>> CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same
>> CPU it runs and in this case wrmsrl() makes sense. In other cases it
>> does noth
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> vmbus_wait_for_unload() may be receiving a message (not necessarily the
> CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same
> CPU it runs and in this case wrmsrl() makes sense. In other cases it
> does nothing (neither good nor bad).
Olaf Hering writes:
> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
>> We actually need to read the reply and empty the message slot to make
>> unload happen. And reading on a different CPU may not work, see:
>>
>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/09733
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> We actually need to read the reply and empty the message slot to make
> unload happen. And reading on a different CPU may not work, see:
>
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html
Does the following se
Olaf Hering writes:
> On Thu, Dec 15, Olaf Hering wrote:
>
>> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>>
>> > I see a number of minor but at least one major issue against such move:
>> > At least for some Hyper-V versions (2012R2 for example)
>> > CHANNELMSG_UNLOAD_RESPONSE is delivered to the C
Olaf Hering writes:
> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
>> I see a number of minor but at least one major issue against such move:
>> At least for some Hyper-V versions (2012R2 for example)
>> CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent
>> CHANNELMSG_REQUESTOF
On Thu, Dec 15, Olaf Hering wrote:
> On Thu, Dec 15, Vitaly Kuznetsov wrote:
>
> > I see a number of minor but at least one major issue against such move:
> > At least for some Hyper-V versions (2012R2 for example)
> > CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent
> > C
On Thu, Dec 15, Vitaly Kuznetsov wrote:
> I see a number of minor but at least one major issue against such move:
> At least for some Hyper-V versions (2012R2 for example)
> CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent
> CHANNELMSG_REQUESTOFFERS and on kdump we may not
Olaf Hering writes:
> KY,
>
> if a hyperv VM crashes alot of work must be done to prepare the
> environment for the kdump kernel. This approach is different compared to
> all the other VM types, or baremetal. Since the just crashed kernel is
> per definition unreliable all that work should be don
ject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
>
> On Wed, Dec 07, KY Srinivasan wrote:
>
> > May be a better solution might be to have a new mechanism to indicate
> > to the host that all state of the previous incarnation of the kernel
> > needs to be
On Wed, Dec 07, KY Srinivasan wrote:
> May be a better solution might be to have a new mechanism to indicate
> to the host that all state of the previous incarnation of the kernel
> needs to be cleaned up. This will be close to what we have on
> hardware.
That would be cool, but until this appea
ject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
>
> On Wed, Dec 07, KY Srinivasan wrote:
>
> > Is there a mechanism for stashing away state that can be retrieved in
> > the context of the execed kernel.
>
> I have to find out. To simplify things th
On Wed, Dec 07, KY Srinivasan wrote:
> Is there a mechanism for stashing away state that can be retrieved in
> the context of the execed kernel.
I have to find out. To simplify things the new approach may only be used
in the kdump case, which already passes various info in cmdline. Most
likely th
ject: RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
>
> Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan
> :
>
> >Yes; I had played with this approach a while ago. The issue is that the
> >host knows about a
> >bunch of in memory state that will b
Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan :
>Yes; I had played with this approach a while ago. The issue is that the
>host knows about a
>bunch of in memory state that will be different in the kexec kernel.
>For instance if we did all
>the cleanup as part of the boot sequence, we wi
erv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
>
> KY,
>
> if a hyperv VM crashes alot of work must be done to prepare the
> environment for the kdump kernel. This approach is different compared to
> all the other VM types, or baremetal. Since the just crashed kern
KY,
if a hyperv VM crashes alot of work must be done to prepare the
environment for the kdump kernel. This approach is different compared to
all the other VM types, or baremetal. Since the just crashed kernel is
per definition unreliable all that work should be done within the kdump
kernel because
19 matches
Mail list logo
