Re: VMX status report. Xen:25256 & Dom0:d93dc5c...

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> > > xen-changeset:   25256
> > > Dom0:          linux.git  3.1.0-rc7 (commit: d93dc5c...)
> > 
> > Please update your dom0.
> 
> I think we can use 3.4-RCx kernel as dom0 when sending the report next time.

Excellent!
> 
> > >
> > ============================================================
> > =====
> > >
> > > New issue(1)
> > > ==============
> > > 1. cpu weight out of range error when create hvm domU
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1818
> > 
> > And what is the guest config? Does it have any cpu weights?
> 
> Added the config in the BZ.  It doesn't have any cpu weight in config. 
> Some other person also reported this issue in the mailing list several days ago.

I think some of the Citrix folks were going to take a look at this.

> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
> > > 3. [VT-D]fail to detach NIC from guest
> > 
> > Hmm, the last update is from a year ago. Are you sure this
> > is an issue?
> > 
> Yeah, it still exist.  It may be a similar issue with BZ# 1812.
> According to our recent testing, it something about VNC console.
> Also added some latest info in the BZ.
> 
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
> > > 4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
> > 
> > the bug talks about 2.6.32. Can you update it to include the
> > 3.4 (or 3.3) dmesg output?
> > 
> This is about 32bit Xen.
> As we don't test 32bit Xen for a long time, we may update it when we're free.
> 
> > > 5. [VT-D] device reset fail when create/destroy guest
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1752
> > 
> > Does this happen if you manually echo 1 > ../reset? And is this
> > an issue with the kernel if you upgrade it to 3.4-rc5?
> > 
> When doing 'echo 1 >../reset', I get the same error as list in the BZ.
> "/sys/bus/pci/devices/0000:09:00.0/reset returned -1: Invalid argument".

OK, so then the device can't do reset's properly. Is this the
physical adaptor or the virtual one?

> This bug only exists when we use 'pcistub' to hide a device.

Ok, so it looks like upstream Linux can't do this properly on that device.

> 
> > > 8. after detaching a VF from a guest, shutdown the guest is very slow
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > 
> > Where does it slow down? When bringing the NIC down or in specific
> > cases?
> > Is this an issue with if you are using a different guest (say Fedora Core 16?)
> > 
> We found it is related to 'stdgva' option in guest config file.
> If 'stdvga=1' and 'vnc=1', the guest is not slow when shutdown.
> If 'stdvga=0' and 'vnc=1', guest shutdown will be very slow.

What does turning standard VGA and VNC on mean to the guest? Doesn't that mean
that the VGA adapter is gone from the guest? And is this issue only
present if you have PCI devices in the guest? Meaning do you get this
if you boot a normal HVM guest and do 'stdvga=0' and 'vnc='1?