I've gone ahead and taken Moritoshi-san's original patch, and expanded it into a better one that also documents freecell --all:
https://www.redhat.com/archives/libvir-list/2011-April/msg00362.html

If libvirt rebases for 6.2, then this should be picked up automatically:

commit 0ddc8d0aebf2e727c78aa09a0f507766297f4e7c
Author: Eric Blake <eblake>
Date:   Wed Apr 6 11:27:06 2011 -0600

    docs: document freecell --all
    
    Based on a smaller patch developed by Moritoshi Oshiro:
    https://bugzilla.redhat.com/show_bug.cgi?id=693963
    
    * tools/virsh.pod (freecell): Mention all, and clarify that
    optional cellno requires --cellno.

Ouch - this is a regression.  Prior to bug 653530, 'virsh freecell 0' worked; now it requires 'virsh freecell --cellno 0'.

This isn't a documentation bug. This is in fact a *functional regression*.

The original syntax for querying a specific node was "virsh freecell <NODENUM>"

  # virsh freecell 0
  0: 71200 kB


but now it is requiring  "virsh freecell --cellno <NODENUM>"

  # virsh freecell 0
  error: unexpected data '0'
  # virsh freecell --cellno 0
  0: 172912 kB

We must fix virsh to support the original syntax.

Actually, it looks like this regression popped up during the rebase to newer upstream (upstream 0.8.5 is the first release with the regression), and not by the introduction of 'virsh freecell --all':

commit c1564268c4f08efbff672f4654b939c5196bc42c
Author: Eric Blake <eblake>
Date:   Tue Oct 19 10:27:02 2010 -0600

    virsh: improve help text where integers are expected
    
    * tools/virsh.c (opts_freecell, opts_memtune, opts_vcpupin)
    (opts_setvcpus, opts_setmaxmem, opts_setmem)
    (opts_migrate_setmaxdowntime): Use VSH_OT_INT when only an integer
    is expected.
    (vshCmddefHelp, vshCmddefGetData): Allow mandatory VSH_OT_INT
    arguments.

changed 'virsh freecell' from taking VSH_OT_DATA to VSH_OT_INT, then changed vshCmddefGetData to only recognize mandatory integer arguments (so what used to be allowed as an optional data argument that had to be parsed as an integer is now an optional integer argument, but optional integers aren't parsed properly).  I'm working on a patch.

Additional upstream patches to fix the regression:
https://www.redhat.com/archives/libvir-list/2011-April/msg00599.html

Those patches happen to also fix bug 691305 at the same time.

In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-April/msg00349.html

Test in below environment:
libvirt-0.8.7-18.el6.x86_64

# man virsh
...
 freecell optional { --cellno cellno | --all }
     Prints the available amount of memory on the machine or within a
     NUMA cell if cellno is provided.  If --all is provided instead of
     --cellno, then show the information on all NUMA cells.

# virsh help freecell
  NAME
    freecell - NUMA free memory

  SYNOPSIS
    freecell [--cellno <number>] [--all]

  DESCRIPTION
    display available free memory for the NUMA cell.

  OPTIONS
    --cellno <number>  NUMA cell number
    --all            show free memory for all NUMA cells


# virsh freecell --cellno 0
0: 6835284 kB

# virsh freecell  0
0: 6835300 kB

# virsh freecell
Total: 6834812 kB

# virsh freecell --all
    0:    6834424 kB
--------------------
Total:    6834424 kB

# virsh freecell --cellno
error: expected syntax: --cellno <number>

# virsh freecell  foo000
error: cell number has to be a number

According to above test and bug description, I notice ’man virsh‘ make a distinction between I<--cellno> and B<cellno>，But I wonder the cellno should be B<cellno> in the setentence 'if cellno is provided'. 

In bug description and design, # virsh freecell [cellno] and # virsh freecell [--cellno cellno] should be both supported. So if you describe I<cellno> in the setentence 'if cellno is provided', that will make us confused and think it may means I<--cellno>, thus only support # virsh freecell [--cellno cellno]. But it does not match the design.

Please help to confirm and make it more clear. Thanks

*** Bug 691305 has been marked as a duplicate of this bug. ***

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html