CA-395093: miss physical-device-path xenstore key

[chunjiez]

read physical-device-path from xenstore directly, there is no synchronization between slave tapback process and xenopsd hotplug vbd-script, so, in some corner case, slave tapback process would miss physical-device-path xenstore watch event, then blktap io datapath fails to be established.

[chunjiez]

@MarkSymsCtx @TimSmithCtx @LunfanZhang @liulinC @stephenchengCloud

Could you please review the bug fix patch?

[stephenchengCloud]

I understand the patch is to read physical-device-path from xenstore.
The logic is added in function reconnect, I was wondering when reconnect is called?

[chunjiez]

@stephenchengCloud ,

I understand the patch is to read physical-device-path from xenstore. The logic is added in function reconnect, I was wondering when reconnect is called?

tapback master process (slave_domid == 0)

• Watches backend/vbd3 in XenStore — the top-level path.
• Spawn a tapback slave process

tapback slave process (slave_domid != 0)

• Only watches backend/vbd3/domid, that is to say, only watch domid's vbd event
• Maintain a list of VBD devices for domid

Once the tapback slave process starts/restarts, it does probe all domid's vbd devices by reading xenstore directly, during probing one vbd device, reconnect is called to establish io datapath.

In the old days, xenstore key physical-device is used to pass vbd device information.

After frankentap remove feature, xenstore key physical-device-path is used to pass vbd device information, here, reconnect misses physical-device-path, in some corner case, xenopsd hotplug vbd-script adds physical-device-path, but tapback slave process has not called xs_watch, so the event is missed, finally, vbd frontend part never reaches Connected state.

[stephenchengCloud]

The name reconnect is confusing. It's actually called on start the process.

[chunjiez]

@stephenchengCloud

The name reconnect is confusing. It's actually called on start the process.

During the lifecycle of a virtual machine, many events may occur, such as suspend and resume. VM suspend causes disconnection, and VM resume triggers reconnection, here, "reconnect" is right, I think.

[chunjiez]

@MarkSymsCtx @TimSmithCtx @LunfanZhang

Could you please review the PR?

[chunjiez]

mv https://github.com/csg-xenserver/blktap/pull/13

[stormi]

mv https://github.com/csg-xenserver/blktap/pull/13

Can you explain?

[chunjiez]

mv https://github.com/csg-xenserver/blktap/pull/13

Can you explain?

Now we do not use xapi-project repo to manage blktap, move the pull request to the correct repo.

[stormi]

mv https://github.com/csg-xenserver/blktap/pull/13

Can you explain?

Now we do not use xapi-project repo to manage blktap, move the pull request to the correct repo.

Sure, but it wasn't my understanding that you would stop contributing fixes to the upstream blktap.