Re: [Qemu-devel] [Xen-devel] Re: [PATCH] xen-mapcache: Fix rlimit set size.

Re: [Qemu-devel] [Xen-devel] Re: [PATCH] xen-mapcache: Fix rlimit set size.

[Jan Beulich]

>>> Stefano Stabellini 08/03/11 12:01 AM >>> 
>if (rlimit_as.rlim_max < MCACHE_MAX_SIZE) { 

This condition minimally needs to include what Anthony's original version had.

>if (qemu is priviledged) { 
>rlimit_as.rlim_max = RLIM_INFINITY; 
>rlimit_as.rlim_cur = RLIM_INFINITY; 
>} else { 
>print a warning 
>mapcache->max_mcache_size = rlimit_as.rlim_cur - NON_MCACHE_MEMORY_SIZE; 
>rlimit_as.rlim_cur = rlimit_as.rlim_max; 
>} 
>} else { 

Not printing a warning here means that there are still cases where the
fuzzy upper bound may not be precise enough anymore (hence causing
silent failure). I think the privileged case needs to be handled without
any other surrounding condition, and the warning ought to be prinited
in any case in the non-privileged case.

>rlimit_as.rlim_cur = rlimit_as.rlim_max; 
>} 

Jan

Re: [Xen-devel] Re: [PATCH] xen-mapcache: Fix rlimit set size.

[Jan Beulich]

>>> Stefano Stabellini 08/03/11 12:01 AM >>> 
>if (rlimit_as.rlim_max < MCACHE_MAX_SIZE) { 

This condition minimally needs to include what Anthony's original version had.

>if (qemu is priviledged) { 
>rlimit_as.rlim_max = RLIM_INFINITY; 
>rlimit_as.rlim_cur = RLIM_INFINITY; 
>} else { 
>print a warning 
>mapcache->max_mcache_size = rlimit_as.rlim_cur - NON_MCACHE_MEMORY_SIZE; 
>rlimit_as.rlim_cur = rlimit_as.rlim_max; 
>} 
>} else { 

Not printing a warning here means that there are still cases where the
fuzzy upper bound may not be precise enough anymore (hence causing
silent failure). I think the privileged case needs to be handled without
any other surrounding condition, and the warning ought to be prinited
in any case in the non-privileged case.

>rlimit_as.rlim_cur = rlimit_as.rlim_max; 
>} 

Jan

Re: [Qemu-devel] [Xen-devel] Re: [PATCH] xen-mapcache: Fix rlimit set size.

[Stefano Stabellini]

On Wed, 3 Aug 2011, Jan Beulich wrote:
> >>> Stefano Stabellini 08/03/11 12:01 AM >>> 
> >if (rlimit_as.rlim_max < MCACHE_MAX_SIZE) { 
> 
> This condition minimally needs to include what Anthony's original version had.

right


> >if (qemu is priviledged) { 
> >rlimit_as.rlim_max = RLIM_INFINITY; 
> >rlimit_as.rlim_cur = RLIM_INFINITY; 
> >} else { 
> >print a warning 
> >mapcache->max_mcache_size = rlimit_as.rlim_cur - NON_MCACHE_MEMORY_SIZE; 
> >rlimit_as.rlim_cur = rlimit_as.rlim_max; 
> >} 
> >} else { 
> 
> Not printing a warning here means that there are still cases where the
> fuzzy upper bound may not be precise enough anymore (hence causing
> silent failure). I think the privileged case needs to be handled without
> any other surrounding condition, and the warning ought to be prinited
> in any case in the non-privileged case.

good idea

> 
> >rlimit_as.rlim_cur = rlimit_as.rlim_max; 
> >} 

Re: [Xen-devel] Re: [PATCH] xen-mapcache: Fix rlimit set size.

[Stefano Stabellini]

On Wed, 3 Aug 2011, Jan Beulich wrote:
> >>> Stefano Stabellini 08/03/11 12:01 AM >>> 
> >if (rlimit_as.rlim_max < MCACHE_MAX_SIZE) { 
> 
> This condition minimally needs to include what Anthony's original version had.

right


> >if (qemu is priviledged) { 
> >rlimit_as.rlim_max = RLIM_INFINITY; 
> >rlimit_as.rlim_cur = RLIM_INFINITY; 
> >} else { 
> >print a warning 
> >mapcache->max_mcache_size = rlimit_as.rlim_cur - NON_MCACHE_MEMORY_SIZE; 
> >rlimit_as.rlim_cur = rlimit_as.rlim_max; 
> >} 
> >} else { 
> 
> Not printing a warning here means that there are still cases where the
> fuzzy upper bound may not be precise enough anymore (hence causing
> silent failure). I think the privileged case needs to be handled without
> any other surrounding condition, and the warning ought to be prinited
> in any case in the non-privileged case.

good idea

> 
> >rlimit_as.rlim_cur = rlimit_as.rlim_max; 
> >} 

hvm_domain_use_pirq() breaks device passthru on xen-4.1

[Wei Huang]

Hi Stefano,

The recent patch you put into xen-4.1-testing.hg broke device passthru 
on Windows. I bisected the changesets and it turned out to be 23092. The 
NIC can't get the IP address correctly. Changset 23091 worked fine.

Regarding your patch, do we need to differentiate pv-on-hvm guests from 
others? The Windows VM I used is unmodified. I think 
hvm_domain_use_pirq() returned an incorrect answer for such guests.

Thanks,
-Wei

Re: hvm_domain_use_pirq() breaks device passthru on xen-4.1

[Jan Beulich]

>>> On 04.08.11 at 20:44, Wei Huang <wei.huang2@amd.com> wrote:
> Hi Stefano,
> 
> The recent patch you put into xen-4.1-testing.hg broke device passthru 
> on Windows. I bisected the changesets and it turned out to be 23092. The 
> NIC can't get the IP address correctly. Changset 23091 worked fine.

With that I'm not really certain whether I should push the merge fix for
my mis-merge of what became 23573:584c2e5e03d9 and the prior
23550:fb5f0febeddc.

Thoughts?

Jan

> Regarding your patch, do we need to differentiate pv-on-hvm guests from 
> others? The Windows VM I used is unmodified. I think 
> hvm_domain_use_pirq() returned an incorrect answer for such guests.
> 
> Thanks,
> -Wei
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 

Re: hvm_domain_use_pirq() breaks device passthru on xen-4.1

[Stefano Stabellini]

On Thu, 4 Aug 2011, Wei Huang wrote:
> Hi Stefano,
> 
> The recent patch you put into xen-4.1-testing.hg broke device passthru 
> on Windows. I bisected the changesets and it turned out to be 23092. The 
> NIC can't get the IP address correctly. Changset 23091 worked fine.
> 
> Regarding your patch, do we need to differentiate pv-on-hvm guests from 
> others? The Windows VM I used is unmodified. I think 
> hvm_domain_use_pirq() returned an incorrect answer for such guests.

The problem is that when qemu enables MSIs for a pt device on behalf of
the guest physdev_map_pirq is called and pirq_emuirq is set to IRQ_PT.
>From that point on hvm_domain_use_pirq is going to return true
incorrectly.
Before 23092 we would also check for the event channel to be bound
before returning true in hvm_domain_use_pirq, but that turns out to be a
problem if a PV on HVM guest disables and unbinds the event channel.

I think that reverting 23092 is the simplest thing to do here, then we
need to find a different way to distinguish MSIs that have to be
injected using the emulated path and the ones that have to be injected
using the PV path.