Re: issues upgrading to 4.13

[Andrew Parker <andrew%pmk1.net@localhost>]

I see the same problem with 100% xenstored CPU using the latest xentools411.  
NetBSD PV domUs launch just fine, but Fedora HVM domUs never make it past the 
SeaBIOS boot phase.  I'm able to reliably reproduce the issue.

This behavior goes away for me after backing out the XSA-115-c xenstored 
patches (also requires removing XSA322-c and XSA325 to get a working build for 
now).  Perhaps this may help with debugging xentools413 as well.

On Monday, 18 January 2021 22:15:26 EST Mark Davies wrote:
> On 18/01/21 9:40 pm, Manuel Bouyer wrote:
> > looks like a descriptor that appears always ready when there's nothing to
> > do with it. I fear this will requires getting in the code to debug.
> 
> yeah.  I took a quick look at the xenstored sources and unfortunately
> I'm at a loss as to where to start.
> 
> I did however have a play with a test machine and can see it happening
> on a dom0 with just xenstored and xenconsoled running - no domu's started.
> 
> And I did try enabling XENSTORED_TRACE but that wasn't very informative,
> the loop just became:
> 
> 
>    428      1 xenstored poll(0x7321d32e0000, 0x7, 0xffffffff) = 2
>    428      1 xenstored __clock_gettime50(0x3, 0x7f7fffe25720) = 0
>    428      1 xenstored write(0x3, 0x7f7fffe25260, 0x54) = 84
>        "wrl: dom    0      0  msec      10000 credit     1000000 reserve
>          "
>    428      1 xenstored poll(0x7321d32e0000, 0x7, 0xffffffff) = 2
>    428      1 xenstored __clock_gettime50(0x3, 0x7f7fffe25720) = 0
>    428      1 xenstored write(0x3, 0x7f7fffe25260, 0x54) = 84
>        "wrl: dom    0      0  msec      10000 credit     1000000 reserve
>          "
>    428      1 xenstored poll(0x7321d32e0000, 0x7, 0xffffffff) = 2
>    428      1 xenstored __clock_gettime50(0x3, 0x7f7fffe25720) = 0
>    428      1 xenstored write(0x3, 0x7f7fffe25260, 0x54) = 84
>        "wrl: dom    0      0  msec      10000 credit     1000000 reserve
>          "
> 
> 
> cheers
> mark