The following patch fixes 3 recent regressions and works around a 4th. - when debugger trap entry was re-factored the new code neglected to clear the trace bit in eflags on a trace trap, xc_ptrace now does that in user-land before continuing - a merge somewhere along the line removed a validation of the info pointer in xc_domain_getfullinfo thus causing a seg fault when called without info (xc_ptrace only wants the cpu context) - the page not validated case in get_page_type needs to be last, in the shadow mode code merge it was moved before the general type checking case - when one tried to do an L2 pin on a page with a self-reference xen would spin forever in cpu_relax. This patch returns it to the last case. - xen has started to use anonymous unions - this is not c99 compliant. As a workaround freebsd is no longer compiled with -std=c99 http://www.fsmware.com/xen/patches/050417/fixes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> - the page not validated case in get_page_type needs to be > last, in the shadow mode code merge it was moved before the > general type checking case - when one tried to do an L2 pin > on a page with a self-reference xen would spin forever in > cpu_relax. This patch returns it to the last case.Your proposal introduces a potantial SMP race, but we''re discussing a better fix. However, I''m not entirely sure we want to fully support the behaviour that you are relying on. Why can''t you pin the L2 page when its empty (as we do on Linux), before it contains the linear mapping? To fully support this behaviour in the general case, we''d need to handle arbitrary promotion of pages (e.g. L1->L2 when a linear mapping has been created to another L2 that has yet to be pinned). We have to do this for the shadow mode code to support uncooperative OSes, but I''m not sure we want to support this in the paravirtualized case as it complicates the code. Special casing self-referential linear mappings (which is what''s causing you the immediate problems) might be OK, but is there any reason why you can''t just do the pinning earlier? BTW: if its easy for you, please could you send the other patches through as separate bk export patches rather than bk send -- our scripts aren''t geared to handle the latter. Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Your proposal introduces a potantial SMP race, but we''re discussing a > better fix. > > However, I''m not entirely sure we want to fully support the behaviour > that you are relying on. Why can''t you pin the L2 page when its empty > (as we do on Linux), before it contains the linear mapping?I can and will. It was supported previously so I used it.> why you can''t just do the pinning earlier?I can. Per your request I''ve removed the change to mm.c in: http://www.fsmware.com/xen/patches/050417/fixes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I''ve broken the patch down into three separate patches at: http://www.fsmware.com/xen/patches/050418/ On 4/18/05, Kip Macy <kip.macy@gmail.com> wrote:> > Your proposal introduces a potantial SMP race, but we''re discussing a > > better fix. > > > > However, I''m not entirely sure we want to fully support the behaviour > > that you are relying on. Why can''t you pin the L2 page when its empty > > (as we do on Linux), before it contains the linear mapping? > > I can and will. It was supported previously so I used it. > > > why you can''t just do the pinning earlier? > I can. > > Per your request I''ve removed the change to mm.c in: > http://www.fsmware.com/xen/patches/050417/fixes >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel