[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared
On Mon, Jul 18, 2016 at 10:15 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote: > On 18/07/16 16:27, Andrew Cooper wrote: >> On 18/07/16 16:18, Tamas K Lengyel wrote: >>> On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap <george.dunlap@xxxxxxxxxx> >>> wrote: >>>> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel <tamas@xxxxxxxxxxxxx> >>>> wrote: >>>>>> I could go on in the analysis, but the point is that there's a morass >>>>>> of interactions here all of which need to be correct, which this patch >>>>>> does not address. You have a long way to go before sharing and altp2m >>>>>> can be safely used on the same gfn ranges. >>>>>> >>>>> Hi George, >>>>> certainly there are cornercases where if the user does not setup things in >>>>> the right order things can still go out of whack. My goal with this patch >>>>> is >>>>> not to address all of them. The goal of this patch is to not crash the >>>>> hypervisor when the user at least tries to experiment with it, which is >>>>> the >>>>> current state. So this patch improves the status quo. Also, both >>>>> mem_sharing >>>>> and altp2m is considered experimental/tech_preview, so the fact that their >>>>> combination is also experimental should be assumed as well. As I >>>>> explained, >>>>> with this patch in place there is at least one way they can be safely used >>>>> together if the user tracks unsharing requirements through mem_access and >>>>> does unsharing and fixup of the altp2m views manually. There are other >>>>> ways >>>>> where it would not be safe as after unsharing we don't know how the user >>>>> would want things to look in altp2ms. I don't think we want to start >>>>> guessing about that either so I will not be looking to implement that. So >>>>> I >>>>> don't agree with this reasoning being grounds for rejecting this patch >>>>> that >>>>> does incrementally improve the current state. >>>> So you keep saying "user"; I assume you mean whatever program is >>>> sitting in domain 0, which is going to be doing memsharing, altp2m, >>>> and memaccess stuff all at once? >>>> >>>> The altp2m code was not written for that purpose. It was written for >>>> *guest* administrators to use within the guest. >>> That's simply not true. It was written specifically to allow both >>> usecases - both internal *and* external. Mixing the use-cases was not >>> envisioned. >> >> Tamas is correct here. altp2m was specifically designed and implemented >> usable by both internal and external entities, irrespective of hardware >> support. >> >> Any modifications to the subsystem should maintain this property. > > Indeed; it was also designed to be robust when used with sharing > (although it was apparently never tested, because it's currently broken > in that respect). And it is this property that I'm trying to maintain, > both for internal and external users. > It was tested and the hypervisor crash was pointed out during the merging process of altp2m, but it was let in anyway as both mem_sharing and altp2m was considered experimental and thus this crash in a cornercase was deemed acceptable. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |