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
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Wednesday, December 7, 2016 12:51 AM
> To: KY Srinivasan ; vkuzn...@redhat.com
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org
> Subject: move hyperv CHANNELMSG_UNLOAD f
18 matches
Mail list logo
