Re: [Xen-devel] Readonly GDT
On 10.04.13 at 02:43, H. Peter Anvin h...@zytor.com wrote: OK, thinking about the GDT here. The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As such, we probably don't want to allocate a full page to it for only that. This means that in order to create a readonly mapping we have to pack GDTs from different CPUs together in the same pages, *or* we tolerate that other things on the same page gets reflected in the same mapping. I think a read-only GDT is incompatible with exceptions delivered through task gates (i.e. double fault on 32-bit), so I would assume this needs to remain a 64-bit only thing. However, the packing solution has the advantage of reducing address space consumption which matters on 32 bits: even on i386 we can easily burn a megabyte of address space for 4096 processors, but burning 16 megabytes starts to hurt. Packing would have the additional benefit of Xen not needing to become a special case in yet another area (because pages containing live descriptor table entries need to be read-only for PV guests, and need to consist of only descriptor table entries). Jan ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] Readonly GDT
Right... the TSS does get written to during a task switch. Jan Beulich jbeul...@suse.com wrote: On 10.04.13 at 02:43, H. Peter Anvin h...@zytor.com wrote: OK, thinking about the GDT here. The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As such, we probably don't want to allocate a full page to it for only that. This means that in order to create a readonly mapping we have to pack GDTs from different CPUs together in the same pages, *or* we tolerate that other things on the same page gets reflected in the same mapping. I think a read-only GDT is incompatible with exceptions delivered through task gates (i.e. double fault on 32-bit), so I would assume this needs to remain a 64-bit only thing. However, the packing solution has the advantage of reducing address space consumption which matters on 32 bits: even on i386 we can easily burn a megabyte of address space for 4096 processors, but burning 16 megabytes starts to hurt. Packing would have the additional benefit of Xen not needing to become a special case in yet another area (because pages containing live descriptor table entries need to be read-only for PV guests, and need to consist of only descriptor table entries). Jan -- Sent from my mobile phone. Please excuse brevity and lack of formatting. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] Readonly GDT
On 04/10/2013 02:42 AM, Jan Beulich wrote: However, the packing solution has the advantage of reducing address space consumption which matters on 32 bits: even on i386 we can easily burn a megabyte of address space for 4096 processors, but burning 16 megabytes starts to hurt. Packing would have the additional benefit of Xen not needing to become a special case in yet another area (because pages containing live descriptor table entries need to be read-only for PV guests, and need to consist of only descriptor table entries). OK, so on 64 bits this sounds like a win all around, whereas it is not feasible on 32 bits (which means we don't really need to worry about burning address space.) So, anyone interested in implementing this for 64 bits? -hpa ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Readonly GDT
OK, thinking about the GDT here. The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As such, we probably don't want to allocate a full page to it for only that. This means that in order to create a readonly mapping we have to pack GDTs from different CPUs together in the same pages, *or* we tolerate that other things on the same page gets reflected in the same mapping. However, the packing solution has the advantage of reducing address space consumption which matters on 32 bits: even on i386 we can easily burn a megabyte of address space for 4096 processors, but burning 16 megabytes starts to hurt. It would be important to measure the performance impact on task switch, though. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Readonly GDT
On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote: OK, thinking about the GDT here. The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As such, we probably don't want to allocate a full page to it for only that. This means that in order to create a readonly mapping we have to pack GDTs from different CPUs together in the same pages, *or* we tolerate that other things on the same page gets reflected in the same mapping. What about grouping via nodes? However, the packing solution has the advantage of reducing address space consumption which matters on 32 bits: even on i386 we can easily burn a megabyte of address space for 4096 processors, but burning 16 megabytes starts to hurt. Having 4096 32 bit processors, you deserve what you get. ;-) -- Steve It would be important to measure the performance impact on task switch, though. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: Readonly GDT
On 04/09/2013 05:53 PM, Steven Rostedt wrote: On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote: OK, thinking about the GDT here. The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As such, we probably don't want to allocate a full page to it for only that. This means that in order to create a readonly mapping we have to pack GDTs from different CPUs together in the same pages, *or* we tolerate that other things on the same page gets reflected in the same mapping. What about grouping via nodes? Would be nicer for locality, although probably adds [even] more complexity. We don't really care about 32-bit NUMA anymore -- it keeps getting suggested for deletion, even. For 64-bit it might make sense to just reflect out of the percpu area even though it munches address space. However, the packing solution has the advantage of reducing address space consumption which matters on 32 bits: even on i386 we can easily burn a megabyte of address space for 4096 processors, but burning 16 megabytes starts to hurt. Having 4096 32 bit processors, you deserve what you get. ;-) Well, the main problem is that it might get difficult to make this a runtime thing; it more likely ends up being a compile-time bit. -hpa ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
