Xen devel - Mar 2011 - [PATCH 0/5] x86: properly propagate errors to hypercall callee

Xen should not BUG() or crash when processing a hypercall and running
out of memory, but currently it does:

(XEN) Xen BUG at mm.c:83
(XEN) ----[ Xen-4.0.2_02-3.6  x86_64  debug=n  Tainted:  M   ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c4801f0a1b>] alloc_xen_pagetable+0x8b/0xa0
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: 0000000000000173   rcx: 0000000000000040
(XEN) rdx: 0000000000000040   rsi: 0000000000000000   rdi: ffff82c48022caa4
(XEN) rbp: ffff830193dd8000   rsp: ffff82c480477908   r8:  0000000000000001
(XEN) r9:  00ff00ff00ff00ff   r10: 0f0f0f0f0f0f0f0f   r11: 0000000000000000
(XEN) r12: 000ffffffffff000   r13: 0000000000193dd8   r14: ffff8300cbffb4f0
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000024275000   cr2: ffff8800068a1d80
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff82c480477908:
(XEN)    000ffffffffff000 ffff82c480161614 0000000000000010 ffff82c48015d631
(XEN)    000ffff830193dd8 ffff8300cba7d030 0000000100000000 0000000000000000
(XEN)    0000000000000000 0000000000000173 0000000000000173 00000000000001f3
(XEN)    0000000000000111 0000000000193dd8 0000000000000010 0000000000000000
(XEN)    ffff82c5487d8000 ffff83022fd82000 ffff82f60327bb00 ffff82c480161e0c
(XEN)    ffff83022fd82000 0000000000000001 0000000000193dd8 8010000193dd8077
(XEN)    ffff83022fd82000 ffff82c480165bda ffff83019563f000 ffff82c480164b1f
(XEN)    ffff83022fd82000 ffff8800507b7728 0000000000801077 0000000000000002
(XEN)    ffff83022fd82000 ffff8300cbe8e000 0000000000000008 8010000193dd8077
(XEN)    ffff8800068a1d80 ffff8300cbe8e000 0000000000000008 80100002268a1065
(XEN)    0000000000000000 ffff82c480165e06 0000000000000000 0000000000000000
(XEN)    ffff83022fd82000 ffff83022fd82000 ffff8800068a1d80 0000000000000005
(XEN)    0000000000000000 ffff82c4801662a1 ffff82c480477e78 0000000000000000
(XEN)    ffff82c480477e78 0000000000000089 0000000000000008 ffff82c480233540
(XEN)    0000000000000048 ffff82c480182d43 ffff83022fde0a70 ffff82f6032ad7a0
(XEN)    0000000000000048 0000000000000000 ffff8302000000d6 ffff82c480111007
(XEN)    0000000000000001 0000000000000008 ffff830100000010 000000d680477f28
(XEN)    ffff82c480477b98 ffff82c480477ca8 00000008032ad7a0 ffff82c480477e20
(XEN)    0000000000000000 ffff8800068a1d80 00ff82c480121418 0000000100000008
(XEN)    ffff82c480269203 0000000000000096 ffff83022fd82000 ffff82c480269200
(XEN) Xen call trace:
(XEN)    [<ffff82c4801f0a1b>] alloc_xen_pagetable+0x8b/0xa0
(XEN)    [<ffff82c480161614>] map_pages_to_xen+0x5e4/0xd10
(XEN)    [<ffff82c48015d631>] do_IRQ+0x291/0x600
(XEN)    [<ffff82c480161e0c>] update_xen_mappings+0xcc/0x170
(XEN)    [<ffff82c480165bda>] get_page_from_l1e+0x3fa/0x520
(XEN)    [<ffff82c480164b1f>] free_page_type+0x3af/0x690
(XEN)    [<ffff82c480165e06>] ptwr_emulated_update+0x106/0x450
(XEN)    [<ffff82c4801662a1>] ptwr_emulated_write+0x71/0xa0
(XEN)    [<ffff82c480182d43>] x86_emulate+0x4773/0xff10
(XEN)    [<ffff82c480111007>] do_xen_version+0x217/0x520
(XEN)    [<ffff82c48015d631>] do_IRQ+0x291/0x600
(XEN)    [<ffff82c4801716fc>] flush_area_mask+0x7c/0x130
(XEN)    [<ffff82c4801524ec>] context_switch+0x18c/0xec0
(XEN)    [<ffff82c480161fad>] get_page+0x2d/0x100
(XEN)    [<ffff82c48015bae0>] set_eoi_ready+0x0/0x40
(XEN)    [<ffff82c4801622eb>] ptwr_do_page_fault+0x1ab/0x200
(XEN)    [<ffff82c48012169a>] timer_softirq_action+0x21a/0x360
(XEN)    [<ffff82c48017d764>] do_page_fault+0x114/0x450
(XEN)    [<ffff82c4801f0605>] handle_exception_saved+0x2d/0x6b
(XEN)    
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at mm.c:83
(XEN) ****************************************

This patch set makes it so that not only the offending BUG() gets
eliminated, but also properly propagates the error to the guest,
so that the latter can take action (which will itself require quite
some changes to prevent crashing the guest in that situation,
particularly where utilizing Xen''s writeable page table support).

1: don''t BUG() post-boot in alloc_xen_pagetable()
2: run-time callers of map_pages_to_xen() must check for errors
3: make get_page_from_l1e() return a proper error code
4: make mod_l1_entry() return a proper error code
5: make mod_l2_entry() return a proper error code

All but the last are clear candidates for backporting to 4.1 and 4.0,
albeit for the former perhaps only after 4.1.0.

Signed-off-by: Jan Beulich <jbeulich@novell.com>


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

On 09/03/2011 10:53, "Jan Beulich" <JBeulich@novell.com> wrote:
> This patch set makes it so that not only the offending BUG() gets
> eliminated, but also properly propagates the error to the guest,
> so that the latter can take action (which will itself require quite
> some changes to prevent crashing the guest in that situation,
> particularly where utilizing Xen''s writeable page table support).
Presumably this is from shattering superpage mappings when per-page cache
attributes change in response to a guest mapping a page with, for example,
non-WB attributes?

It seems unfortunate to propagate this to guests. Perhaps we should be
making a memory pool for Xen''s 1:1 mappings, big enough to allow a 4kB
mapping of every page of RAM in the system, and allocate/free pagetables to
that pool? The overhead of this would be no more than 0.2% of system memory,
which seems reasonable to avoid an error case that is surely hard for a
guest to react to or fix.

An alternative might be to replace the x86_64 1:1 mapping with a mapping
cache. Could be transparent, demand faulting in parts of the 1:1 mapping.
But that seems a pain, possibly difficult for demand faults from IRQ
context, when the alternative is only a 0.2% space cost.

 -- Keir



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

>>> On 09.03.11 at 12:07, Keir Fraser <keir.xen@gmail.com> wrote:
> On 09/03/2011 10:53, "Jan Beulich" <JBeulich@novell.com>
wrote:
> 
>> This patch set makes it so that not only the offending BUG() gets
>> eliminated, but also properly propagates the error to the guest,
>> so that the latter can take action (which will itself require quite
>> some changes to prevent crashing the guest in that situation,
>> particularly where utilizing Xen''s writeable page table
support).
> 
> Presumably this is from shattering superpage mappings when per-page cache
> attributes change in response to a guest mapping a page with, for example,
> non-WB attributes?
Correct - observed with the radeon drm driver.
> It seems unfortunate to propagate this to guests. Perhaps we should be
> making a memory pool for Xen''s 1:1 mappings, big enough to allow a
4kB
> mapping of every page of RAM in the system, and allocate/free pagetables to
> that pool? The overhead of this would be no more than 0.2% of system
memory,
> which seems reasonable to avoid an error case that is surely hard for a
> guest to react to or fix.
I considered this too, but wasn''t convinced that''s a good
thing to
do, no matter that the overhead is only a very small percentage.
After all, one of the two points to make use of superpages is to
not waste memory needlessly on page tables, the more that on a
typical server you''d unlikely see many RAM pages get non-WB
caching attributes set on them.

That said, I nevertheless agree (and attempted to indicate that way
in the description) that the kernel side changes may be non-trivial.
Otoh, keeping the logic simple in Xen may also be beneficial.

And, not the least, even if you indeed want to go with the pool
approach you suggest, the changes in this patch set are likely
good to have independently - just that they wouldn''t need
backporting to 4.1 and 4.0 if they turn out to be mere cleanup.

Jan


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

On 09/03/2011 11:21, "Jan Beulich" <JBeulich@novell.com> wrote:
>>>> On 09.03.11 at 12:07, Keir Fraser <keir.xen@gmail.com>
wrote:
>> On 09/03/2011 10:53, "Jan Beulich"
<JBeulich@novell.com> wrote:
>> 
>>> This patch set makes it so that not only the offending BUG() gets
>>> eliminated, but also properly propagates the error to the guest,
>>> so that the latter can take action (which will itself require quite
>>> some changes to prevent crashing the guest in that situation,
>>> particularly where utilizing Xen''s writeable page table
support).
>> 
>> Presumably this is from shattering superpage mappings when per-page
cache
>> attributes change in response to a guest mapping a page with, for
example,
>> non-WB attributes?
> 
> Correct - observed with the radeon drm driver.
> 
>> It seems unfortunate to propagate this to guests. Perhaps we should be
>> making a memory pool for Xen''s 1:1 mappings, big enough to
allow a 4kB
>> mapping of every page of RAM in the system, and allocate/free
pagetables to
>> that pool? The overhead of this would be no more than 0.2% of system
memory,
>> which seems reasonable to avoid an error case that is surely hard for a
>> guest to react to or fix.
> 
> I considered this too, but wasn''t convinced that''s a good
thing to
> do, no matter that the overhead is only a very small percentage.
> After all, one of the two points to make use of superpages is to
> not waste memory needlessly on page tables, the more that on a
> typical server you''d unlikely see many RAM pages get non-WB
> caching attributes set on them.
> 
> That said, I nevertheless agree (and attempted to indicate that way
> in the description) that the kernel side changes may be non-trivial.
> Otoh, keeping the logic simple in Xen may also be beneficial.
The further problem is that this would change the guest interface from
pagetable updates from ''guaranteed to succeed if you have not made a
guest-side mistake'' to ''may spuriously fail in rare
cases''. That''s a big
difference!

I wonder what the scope of the problem really is. Mostly this cacheattr
stuff applies to memory allocated by a graphics driver I suppose, and
probably at boot time in dom0. I wonder how the bug was observed during dom0
boot given that Xen chooses a default dom0 memory allocation that leaves
enough memory free for a decent-sized dom0 SWIOTLB plus some extra slack on
top of that. Any idea how the Xen memory pool happened to be entirely empty
at the time radeon drm driver caused the superpage shattering to occur?

I''m not against turning the host crash into a guest crash (which I
think is
typically what is going to happen, although I suppose at least some Linux
driver-related mapping/remapping functions can handle failure) as this might
be an improvement when starting up non-dom0 driver domains for example. But
I think we should consider punting a resource error up to the guest as a
very bad thing and still WARN_ON or otherwise log the situation to
Xen''s own
console.

 -- Keir
> And, not the least, even if you indeed want to go with the pool
> approach you suggest, the changes in this patch set are likely
> good to have independently - just that they wouldn''t need
> backporting to 4.1 and 4.0 if they turn out to be mere cleanup.
> 
> Jan
> 


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

>>> On 09.03.11 at 14:44, Keir Fraser <keir.xen@gmail.com> wrote:
> I wonder what the scope of the problem really is. Mostly this cacheattr
> stuff applies to memory allocated by a graphics driver I suppose, and
> probably at boot time in dom0. I wonder how the bug was observed during
dom0
> boot given that Xen chooses a default dom0 memory allocation that leaves
> enough memory free for a decent-sized dom0 SWIOTLB plus some extra slack on
> top of that. Any idea how the Xen memory pool happened to be entirely empty
> at the time radeon drm driver caused the superpage shattering to occur?
This isn''t a boot time problem, it''s a run time one (and was
reported
to us as such). The driver does allocations (and cache attribute
changes) based on user mode (X) demands.
> I''m not against turning the host crash into a guest crash (which I
think is
> typically what is going to happen, although I suppose at least some Linux
> driver-related mapping/remapping functions can handle failure) as this
might
> be an improvement when starting up non-dom0 driver domains for example. But
I''m afraid that''s not only a question of driver domains doing
such.
With the addition of !is_hvm_domain() to l1_disallow_mask(), any
page in a HVM guest that its kernel chooses to make non-WB can
trigger the BUG() currently.

And, noting just now, there''s then a potential collision between
the kernel and tools/stubdom (qemu-dm) mapping the page - the
latter, mapping a page WB, would undo what the guest itself may
have requested earlier - imo the cache attr adjustment shouldn''t
be done if it''s not the owner of the page that''s doing the
mapping
(and quite probably the cache attr should be inherited by the non-
owner, though that raises the problem of updating mappings that
the non-owner may have established before the owner assigned
the non-default attr).
> I think we should consider punting a resource error up to the guest as a
> very bad thing and still WARN_ON or otherwise log the situation to
Xen''s own
> console.
Hmm, possibly.

Jan


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

On Wed, Mar 09, 2011 at 02:20:14PM +0000, Jan Beulich
wrote:
> >>> On 09.03.11 at 14:44, Keir Fraser <keir.xen@gmail.com>
wrote:
> > I wonder what the scope of the problem really is. Mostly this
cacheattr
> > stuff applies to memory allocated by a graphics driver I suppose, and
> > probably at boot time in dom0. I wonder how the bug was observed
during dom0
> > boot given that Xen chooses a default dom0 memory allocation that
leaves
> > enough memory free for a decent-sized dom0 SWIOTLB plus some extra
slack on
> > top of that. Any idea how the Xen memory pool happened to be entirely
empty
> > at the time radeon drm driver caused the superpage shattering to
occur?
> 
> This isn''t a boot time problem, it''s a run time one (and
was reported
> to us as such). The driver does allocations (and cache attribute
> changes) based on user mode (X) demands.
What version of radeon Xorg driver is this with? And what radeon card
was this observed with?
> 
> > I''m not against turning the host crash into a guest crash
(which I think is
> > typically what is going to happen, although I suppose at least some
Linux
> > driver-related mapping/remapping functions can handle failure) as this
might
> > be an improvement when starting up non-dom0 driver domains for
example. But
> 
> I''m afraid that''s not only a question of driver domains
doing such.
> With the addition of !is_hvm_domain() to l1_disallow_mask(), any
> page in a HVM guest that its kernel chooses to make non-WB can
> trigger the BUG() currently.
> 
> And, noting just now, there''s then a potential collision between
> the kernel and tools/stubdom (qemu-dm) mapping the page - the
> latter, mapping a page WB, would undo what the guest itself may
> have requested earlier - imo the cache attr adjustment shouldn''t
> be done if it''s not the owner of the page that''s doing
the mapping
> (and quite probably the cache attr should be inherited by the non-
> owner, though that raises the problem of updating mappings that
> the non-owner may have established before the owner assigned
> the non-default attr).
> 
> > I think we should consider punting a resource error up to the guest as
a
> > very bad thing and still WARN_ON or otherwise log the situation to
Xen''s own
> > console.
> 
> Hmm, possibly.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 09.03.11 at 16:10, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Mar 09, 2011 at 02:20:14PM +0000, Jan Beulich wrote:
>> >>> On 09.03.11 at 14:44, Keir Fraser
<keir.xen@gmail.com> wrote:
>> > I wonder what the scope of the problem really is. Mostly this
cacheattr
>> > stuff applies to memory allocated by a graphics driver I suppose,
and
>> > probably at boot time in dom0. I wonder how the bug was observed
during
> dom0
>> > boot given that Xen chooses a default dom0 memory allocation that
leaves
>> > enough memory free for a decent-sized dom0 SWIOTLB plus some extra
slack on
>> > top of that. Any idea how the Xen memory pool happened to be
entirely empty
>> > at the time radeon drm driver caused the superpage shattering to
occur?
>> 
>> This isn''t a boot time problem, it''s a run time one
(and was reported
>> to us as such). The driver does allocations (and cache attribute
>> changes) based on user mode (X) demands.
> 
> What version of radeon Xorg driver is this with? And what radeon card
> was this observed with?
Whatever is in openSUSE 11.4 - there''s an RPM named
xorg-x11-driver-video-radeonhd-1.3.0_20100512_80ba041-2.1.x86_64.rpm,
but I''m not certain that''s the one used. I didn''t ask
the reporter much,
since the symptom was quite obvious.

As to the card, this is what the native kernel spit out on his system:

[    3.234224] [drm] Initialized drm 1.1.0 20060810
[    3.264600] [drm] radeon defaulting to kernel modesetting.
[    3.264602] [drm] radeon kernel modesetting enabled.
[    3.267304] [drm] initializing kernel modesetting (RV710 0x1002:0x954F).
[    3.267480] [drm] register mmio base: 0xFE620000
[    3.267482] [drm] register mmio size: 65536
[    3.267628] [drm] Detected VRAM RAM=512M, BAR=256M
[    3.267629] [drm] RAM width 64bits DDR
[    3.267759] [drm] radeon: 512M of VRAM memory ready
[    3.267760] [drm] radeon: 512M of GTT memory ready.
[    3.267851] [drm] radeon: irq initialized.
[    3.267854] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    3.268462] [drm] Loading RV710 Microcode
[    3.320155] [drm] ring test succeeded in 1 usecs
[    3.320234] [drm] radeon: ib pool ready.
[    3.320284] [drm] ib test succeeded in 0 usecs
[    3.320286] [drm] Enabling audio support
[    3.320495] [drm] Radeon Display Connectors
[    3.320497] [drm] Connector 0:
[    3.320498] [drm]   VGA
[    3.320499] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c
0x7e4c
[    3.320500] [drm]   Encoders:
[    3.320502] [drm]     CRT2: INTERNAL_KLDSCP_DAC2
[    3.320503] [drm] Connector 1:
[    3.320503] [drm]   HDMI-A
[    3.320504] [drm]   HPD1
[    3.320506] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c
0x7e5c
[    3.320507] [drm]   Encoders:
[    3.320508] [drm]     DFP1: INTERNAL_UNIPHY
[    3.320509] [drm] Connector 2:
[    3.320509] [drm]   DVI-I
[    3.320510] [drm]   HPD4
[    3.320511] [drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c
0x7f1c
[    3.320513] [drm]   Encoders:
[    3.320513] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[    3.320514] [drm]     DFP2: INTERNAL_UNIPHY2
[    3.380804] [drm] Internal thermal controller without fan control
[    3.380837] [drm] radeon: power management initialized
[    3.461957] [drm] fb mappable at 0xD0142000
[    3.461958] [drm] vram apper at 0xD0000000
[    3.461959] [drm] size 7258112
[    3.461960] [drm] fb depth is 24
[    3.461961] [drm]    pitch is 6912
[    4.125246] [drm] Initialized radeon 2.7.0 20080528 for 0000:01:00.0 on minor
0

It doesn''t really tell me what card is being used.

Jan


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

>>> On 09.03.11 at 12:07, Keir Fraser <keir.xen@gmail.com> wrote:
> It seems unfortunate to propagate this to guests. Perhaps we should be
> making a memory pool for Xen''s 1:1 mappings, big enough to allow a
4kB
> mapping of every page of RAM in the system, and allocate/free pagetables to
> that pool? The overhead of this would be no more than 0.2% of system
memory,
> which seems reasonable to avoid an error case that is surely hard for a
> guest to react to or fix.
Before starting to look into eventual Linux side changes - do you
then have plans to go that pool route (which would make guest 
side recovery attempts pointless)?

Jan


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

On 11/03/2011 09:25, "Jan Beulich" <JBeulich@novell.com> wrote:
>>>> On 09.03.11 at 12:07, Keir Fraser <keir.xen@gmail.com>
wrote:
>> It seems unfortunate to propagate this to guests. Perhaps we should be
>> making a memory pool for Xen''s 1:1 mappings, big enough to
allow a 4kB
>> mapping of every page of RAM in the system, and allocate/free
pagetables to
>> that pool? The overhead of this would be no more than 0.2% of system
memory,
>> which seems reasonable to avoid an error case that is surely hard for a
>> guest to react to or fix.
> 
> Before starting to look into eventual Linux side changes - do you
> then have plans to go that pool route (which would make guest
> side recovery attempts pointless)?
Not really. I was thinking about having a Linux-style mempool for making
allocations more likely to succeed, but it''s all a bit ugly really.
It''ll be
interesting to see what you can do Linux-side, and whether it can pass
muster for the Linux maintainers. You might at least be able to make the io
remappings from device drivers failable (and maybe they are already).

 -- Keir
> Jan
> 


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

>>> On 11.03.11 at 10:45, Keir Fraser <keir.xen@gmail.com> wrote:
> On 11/03/2011 09:25, "Jan Beulich" <JBeulich@novell.com>
wrote:
> 
>>>>> On 09.03.11 at 12:07, Keir Fraser
<keir.xen@gmail.com> wrote:
>>> It seems unfortunate to propagate this to guests. Perhaps we should
be
>>> making a memory pool for Xen''s 1:1 mappings, big enough to
allow a 4kB
>>> mapping of every page of RAM in the system, and allocate/free
pagetables to
>>> that pool? The overhead of this would be no more than 0.2% of
system memory,
>>> which seems reasonable to avoid an error case that is surely hard
for a
>>> guest to react to or fix.
>> 
>> Before starting to look into eventual Linux side changes - do you
>> then have plans to go that pool route (which would make guest
>> side recovery attempts pointless)?
> 
> Not really. I was thinking about having a Linux-style mempool for making
> allocations more likely to succeed, but it''s all a bit ugly
really. It''ll be
> interesting to see what you can do Linux-side, and whether it can pass
> muster for the Linux maintainers. You might at least be able to make the io
> remappings from device drivers failable (and maybe they are already).
ioremap() in general can fail, but failure of the writing the page
table entries gets propagated to the caller only on the legacy
kernels iirc (due to the lack of a return value of the accessor for
pv-ops).

The problem at hand, however, is with the vm_insert_...()
functions, which use set_pte_at(), which again has no return
value, so it''ll need to be the accessors themselves to

(a) never utilize the writeable page tables feature on any path
that can alter cache attributes, and

(b) handle -ENOMEM from HYPERVISOR_update_va_mapping()
and HYPERVISOR_mmu_update() (without knowing much about
the context they''re being called in).

Jan


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

On 11/03/2011 10:44, "Jan Beulich" <JBeulich@novell.com> wrote:
> ioremap() in general can fail, but failure of the writing the page
> table entries gets propagated to the caller only on the legacy
> kernels iirc (due to the lack of a return value of the accessor for
> pv-ops).
> 
> The problem at hand, however, is with the vm_insert_...()
> functions, which use set_pte_at(), which again has no return
> value, so it''ll need to be the accessors themselves to
> 
> (a) never utilize the writeable page tables feature on any path
> that can alter cache attributes, and
> 
> (b) handle -ENOMEM from HYPERVISOR_update_va_mapping()
> and HYPERVISOR_mmu_update() (without knowing much about
> the context they''re being called in).
I can''t see changes like that getting upstream. Maybe okay if
you''re
prepared to carry the patch. Also I guess some callers may have trouble
handling the error no matter how far you punt it up the call chain.

 -- Keir



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

>>> On 09.03.11 at 11:53, "Jan Beulich"
<JBeulich@novell.com> wrote:
> 1: don''t BUG() post-boot in alloc_xen_pagetable()
> 2: run-time callers of map_pages_to_xen() must check for errors
I actually think that the first two should be considered for 4.0 and
4.1, as those are preventing a guest induced host crash. The other
three are more of enhancement type (propagating a meaningful
error to the calling guest).

Jan
> 3: make get_page_from_l1e() return a proper error code
> 4: make mod_l1_entry() return a proper error code
> 5: make mod_l2_entry() return a proper error code
> 
> All but the last are clear candidates for backporting to 4.1 and 4.0,
> albeit for the former perhaps only after 4.1.0.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>


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