similar to: implicit grant unmap hacking [was RE: Grant tables from dom0 userspace?]

Hi, In many places xen uses "unsigned long" instead of the l*_pgentry_t types to pass around page table entries. Here is a patch which fixes this in a number of places (mostly in shadow mode code). Thats what I''ve trapped in so far, maybe more of these patches follow. Fixing this is needed for adding PAE support to xen. In PAE paging mode the page table entries are 64 bit

Xen is compiled with no -O gcc option, meaning no optimization, and the compiler does the safest thing imaginable. This means that if a function, say vmx_world_save(), calls the same inline a bazillion times, the stack will have one block of local variables for each invocation of that function! Xen really should not be doing this. We could either uninline some of these functions, or try gcc -O2

Isn''t the writeable page table support intended only for non-translated domains? If so, shouldn''t fixup_page_fault() check for this, or the setting of the assist bit and the PG_translate be respectively validated? If not, aren''t there bits missing in ptwr_do_page_fault()? Jan _______________________________________________ Xen-devel mailing list

Make sure MFN read from pte is valid before accessing the page info structure associated with it. Drop guest-to-machine-physical translation from ptwr code. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-05-14/xen/arch/x86/mm.c =================================================================== --- 2007-05-14.orig/xen/arch/x86/mm.c 2007-05-14 13:43:50.000000000 +0200 +++

Hi there, I ran a test on an Apache server, the workload is a helloworld.c compiled cgi, very simple. OS is SLES 10. The stress tool is ab (apache bench). The performance looks big degration from native to Dom0: Running in prefork mode: Native Dom0 Performance(request/s) 3700 . 650 CPU%

Hi there, I ran a test on an Apache server, the workload is a helloworld.c compiled cgi, very simple. OS is SLES 10. The stress tool is ab (apache bench). The performance looks big degration from native to Dom0: Running in prefork mode: Native Dom0 Performance(request/s) 3700 . 650 CPU%

Is this PAE or non-PAE? Please can you try forceing emulation mode by toggling the "#if 0" in arch/x86/mm.c ptwr_do_page_fault The other thing to try is modifying set_pte_pfn_ma to call xen_l1_update rather than set_pte. You could try set_pte_at too. This will help narrow down the issue. Thanks, Ian > Keir, Ian, > With PCI mmconfig option on, and with the PCI express >

Hi, Xenoprof buffers are mapped into the kernel using direct_kernel_remap_pfn_range(). I need to unmap the buffer when it is not needed anymore. However, I could not find any function that unmaps pages previously mapped with direct_kernel_remap_pfn_range(). Any suggestion on how to do this? Thanks Renato _______________________________________________ Xen-devel mailing list

Hello All, I''m contemplating ways to avoid the domain_crash() in mm.c line ~615 without requiring new OS hooks. This crash occurs when the operating system writes a zero to the PTE for a grant mapping without an explicit Xen call to unmap. In hacking around, it seems the problem is this: When the mapping PTE gets squashed, Xen''s cleanup_writable_pagetable() has no way to find

This patch makes windows zoom in and out of a zero point on create/unmap. I've cleaned up the formatting/style to be consistent with the rest of compiz (eg adding spaces around operators, tabifying, using C style comments). This patch could use some more work. It should only apply to decorated toplevels, but right now it also affects XUL menus (I guess because they are not unmanaged like

On Fri, Sep 06, 2019 at 02:06:59PM +0200, Matthias Lange wrote: > The function virtqueue_add_split() DMA-maps the scatterlist buffers. In > case a mapping error occurs the already mapped buffers must be unmapped. > This happens by jumping to the 'unmap_release' label. > > In case of indirect descriptors the release is wrong and may leak kernel > memory. Because the

On Wed, May 13, 2020 at 01:13:40PM +0200, Borislav Petkov wrote: > On Tue, Apr 28, 2020 at 05:16:34PM +0200, Joerg Roedel wrote: > > @@ -302,9 +313,13 @@ void do_boot_page_fault(struct pt_regs *regs, unsigned long error_code) > > * - User faults > > * - Reserved bits set > > */ > > - if (error_code & (X86_PF_PROT | X86_PF_USER | X86_PF_RSVD)) { >

On Wed, May 13, 2020 at 01:30:11PM +0200, Joerg Roedel wrote: > Yeah, I had this this way in v2, but changed it upon you request[1] :) Yeah, I was wondering why this isn't a separate function - you like them so much. :-P > [1] https://lore.kernel.org/lkml/20200402114941.GA9352 at zn.tnic/ But that one didn't have the ghcb_fault check. Maybe it was being added later... :) Thx. --

----- Forwarded message from braindevices <notifications@github.com> ----- Subject: [libguestfs/libguestfs] is there a way to set discard=unmap when using guestmount? (#52) I cannot find anything in the document. This option is very important for dynamic qcow2 disks. Without out this the IO is super slow even on tmpfs only 3MB/s. Subject: Re: [libguestfs/libguestfs] is there a way to

Is it possible to make discard='unmap' the default for virtio-scsi disks? (Related, is it possible to make virtio-scsi the default disk type, rather than virtio-blk?) Thanks! -- ======================================================================== Ian Pilcher arequipeno@gmail.com -------- "I grew up before Mark Zuckerberg invented

On Thu, May 31, 2018 at 02:34:15PM -0500, Ian Pilcher wrote: > Is it possible to make discard='unmap' the default for virtio-scsi > disks? (Related, is it possible to make virtio-scsi the default disk > type, rather than virtio-blk?) This is really a question for whatever management tool you're using with libvirt, since it is essentially defining an opinionated usage policy.

On Fri, Jun 01, 2018 at 07:54:32AM -0500, Ian Pilcher wrote: > On 06/01/2018 05:19 AM, Daniel P. Berrangé wrote: > > On Thu, May 31, 2018 at 02:34:15PM -0500, Ian Pilcher wrote: > > > Is it possible to make discard='unmap' the default for virtio-scsi > > > disks? (Related, is it possible to make virtio-scsi the default disk > > > type, rather than

On Fri, Jun 01, 2018 at 08:37:30AM -0500, Ian Pilcher wrote: > On 06/01/2018 08:14 AM, Daniel P. Berrangé wrote: > > Yes, it inherits some defaults to libvirt and/or QEMU. If those are not > > suitable for some reason, then virt-manager needs to override it. The > > decision about whether to enable discard or not is a policy decision > > that doesn't have a single

On Thu, Oct 22, 2020 at 10:57:05 +0800, Han Han wrote: > Hello, > I find "discard":"unmap" is defaultly enabled in qemu cmdline(libvirt > v6.6, qemu v5.1): > XML: > <disk type="file" device="disk"> > <driver name="qemu" type="qcow2"/> > <source

If you're especially unlucky BOs would move around and their kmaps would end up pointing to something else in GART, then ioctl_pushbuf() would use the kmaps again corrupting textures or other pushbufs (the most noticeable symptom was a PFIFO_DMA_PUSHER from time to time). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 ++ 1