Re: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on HVMguestwith heavy workload

["Steven Hand" <steven.hand@xxxxxxxxxxxx>]

Just FYI - this is something I tested successfully last week. Not sure
if anything has been changed in recent changesets but worth checking
up - can you post the output from /var/log/xen/xend.log ?

Secondly: there is a known issue with save/restore of ballooned domains
(HVM or PV) where the balloning is done from within the guest (e.g.
by echoing to /proc/xen/balloon). Since this doesn't update the memory
target within xenstore, you'll end up 'reverting' the guest memory size to
that last set via xm mem-set. The 'fix' is not to do that, i.e. only use the
xm or XenAPI to request ballooning.


cheers,

S.




----- Original Message ----- 
From: "Zhao, Fan" <fan.zhao@xxxxxxxxx>
To: "Keir Fraser" <keir@xxxxxxxxxxxxx>; "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Cc: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>; "Ian Pratt" 
<Ian.Pratt@xxxxxxxxxxxx>; <xen-devel@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, April 11, 2007 5:24 PM
Subject: RE: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on 
HVMguestwith heavy workload

Hi Keir,
I noticed that with cset 14773, if I use xm mem-set to adjust the memory of 
hvm guest with balloon driver by xm mem-set, and then save the guest, the xm 
save will fail, so does xm migrate. A white window will pop up, and the 
guest still exists through xm li. So will your great fixes also include the 
fixing for this issue? Thanks!
Best regards,
Fan

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: 2007Äê4ÔÂ11ÈÕ 16:57
To: Zhai, Edwin
Cc: Tim Deegan; Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on 
HVMguest with heavy workload

FYI, the next changeset worth testing or fixing is r14795:6e7ef794cdbc. I've
made a *lot* of changes in the last 24 hours. I've tried a few save/restores
under block and net load with no observed problems.

-- Keir

On 11/4/07 08:20, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:

> On Tue, Apr 10, 2007 at 08:16:04PM +0100, Keir Fraser wrote:
> > On 10/4/07 17:47, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:
> >
> > > [PATCH][HVM] fix VNIF restore failure on HVM guest with heavy workload
> > >
> > > Signed-off-by: Zhai Edwin <edwin.zhai@xxxxxxxxx>
> > >
> > > VNIF has many intrs when save/restore with net workload, so need keep
> > > handler
> > > from intrs
> > What happens if an interrupt is being processed during save/restore? It
> > would be nice to know what the underlying bug is!
> If an pseudo PCI intr occurred after xen_suspend on cpu0, there is 
> definitely
> a
> crash. I copy this code from original PV driver code.
>
> > That said, it may well make sense to somehow disable interrupt handling
> > across save/restore. Unfortunately your patch is insufficient since we 
> > could
> > handle event-channel interrupts on any VCPU (the irq's affinity can be
> > changed outside our control if it is routed through the virtual IOAPIC, 
> > and
> > if e.g. the userspace irqbalance daemon is running).
> >
> > I wanted to use stop_machine_run() but unfortunately it isn't exported to
> > modules. :-( irq_disable() may do the right thing for us though.
> SMP is a headache for PV drv save/restore on HVM. Even we disable intr on 
> all
> cpus, PV driver on other cpu may still access low level service after
> xen_suspend on cpu0.
>
> smp_suspend is used for PV drv on PV domain, which is not suitable for HVM 
> as
> we
> need the transparency to guest.
>
> Do we need lightweight stop_machine_run in this case, i.e. make other cpu
> sleep?
>
>
> >  -- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel