Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver
ping On 11/17/2017 10:08 AM, Oleksandr Andrushchenko wrote: ping On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote: Hi, all! Foreword This RFC is aimed to introduce support of para-virtualized sound frontend driver for Xen [1] and gather opinions from the relevant communities (ALSA, Xen). It implements the protocol from [2] with the following limitations: - mute/unmute is not supported - get/set volume is not supported Volume control is not supported for the reason that most of the use-cases (at the moment) are based on scenarios where unprivileged OS (e.g. Android, AGL etc) uses software mixers. Both capture and playback are supported. The relevant backend is implemented as a user-space application [3] and uses accompanying helper library [4]. Both frontend driver and backend were tested on real HW running Xen hypervisor (Renesas R-Car ARM based H3/M3 boards, x86). Discussion == During the first attempt to upstream the driver [5] number of comments and concerns were raised, one of the biggest flaws in the design were questioned by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of synchronization between frontend and backend during capture/playback. Two options were discussed: “In design of ALSA PCM core, drivers are expected to synchronize to actual hardwares for semi-realtime data transmission. The synchronization is done by two points: 1) Interrupts to respond events from actual hardwares. 2) Positions of actual data transmission in any serial sound interfaces of actual hardwares. “ and finally a change to the existing protocol was suggested: “In 'include/xen/interface/io/sndif.h', there's no functionalities I described the above: 1. notifications from DomU to Dom0 about the size of period for interrupts from actual hardwares. Or no way from Dom0 to DomU about the configured size of the period. 2. notifications of the interrupts from actual hardwares to DomU.” This is implemented as a change to the sndif protocol [8] and allows removing period emulation: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend (in Linux implementation). Sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. Along with these changes other comments on the driver were addressed, e.g. split into smaller chunks, moved the driver from misc to xen etc. Hope, this helps to get the full picture of what was discussed and makes it possible to move forward. Waiting for your valuable comments, Thank you, Oleksandr [1] https://github.com/andr2000/linux/commits/snd_upstream_v1 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h [3] https://github.com/xen-troops/snd_be [4] https://github.com/xen-troops/libxenbe [5] https://lkml.org/lkml/2017/8/7/363 [6] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html [7] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed ___ Xen-devel mailing list xen-de...@lists.xen.org https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 11.12.17 at 12:06, wrote: > On 11/12/17 09:14, Jan Beulich wrote: > On 08.12.17 at 13:42, wrote: >>> On 12/08/2017 02:18 PM, Jan Beulich wrote: >>> On 24.10.17 at 12:19, wrote: > HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed > to a > DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart > (and > hence with the original altp2m design, where domains are allowed - with > the > proper altp2m access rights - to alter these settings), in the absence of > an > official position on the issue from the original altp2m designers. I continue to disagree with this reasoning. I'm afraid I'm not really willing to allow widening the badness, unless altp2m was formally documented security-unsupported. >>> Going the DOMCTL route here would have been the (much easier) solution, >>> and in fact, as stated before, there has been an attempt to do so - >>> however, IIRC Andrew has insisted that we should take care to use >>> consistent access privilege across altp2m operations. >> Andrew, is that the case (I don't recall anything like that)? > > My suggestion was that we don't break usecases. The Intel usecase > specifically is for an in-guest entity to have full control of all > altp2m functionality, and this is fine (security wise) when permitted to > do so by the toolstack. IOW you mean that such guests would be considered "trusted", i.e. whatever bad they can do is by definition not a security concern. If so, that's fine of course, provided the default mode is secure (which it looks like it is by virtue of altp2m being disabled altogether by default). Yet I don't think I know of a place where this is being spelled out. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] x86/xen: supply rsdp address in boot params for pvh guests
>>> On 08.12.17 at 16:11, wrote: > Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212 > which should have been 0x020c. This part of the description has become partly stale now with the new patch 3. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 11/12/17 09:14, Jan Beulich wrote: On 08.12.17 at 13:42, wrote: >> On 12/08/2017 02:18 PM, Jan Beulich wrote: >> On 24.10.17 at 12:19, wrote: HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and hence with the original altp2m design, where domains are allowed - with the proper altp2m access rights - to alter these settings), in the absence of an official position on the issue from the original altp2m designers. >>> I continue to disagree with this reasoning. I'm afraid I'm not really >>> willing to allow widening the badness, unless altp2m was formally >>> documented security-unsupported. >> Going the DOMCTL route here would have been the (much easier) solution, >> and in fact, as stated before, there has been an attempt to do so - >> however, IIRC Andrew has insisted that we should take care to use >> consistent access privilege across altp2m operations. > Andrew, is that the case (I don't recall anything like that)? My suggestion was that we don't break usecases. The Intel usecase specifically is for an in-guest entity to have full control of all altp2m functionality, and this is fine (security wise) when permitted to do so by the toolstack. ~Andrew > >> This was followed by a lengthy xen-devel discussion and several >> unsuccessful attempts to obtain an official position from the original >> contributors, at which point (after several months), as also discussed >> at the Xen Developer Summit in Budapest, we decided to press on in the >> direction that had seemed the most compatible with the original altp2m >> design. (Please correct me if I'm misremembering or misunderstanding >> something.) >> >> So at this point it looks like we're stuck again: we're happy to go in >> any direction the maintainers decide is the best, but we do need to >> decide on one. >> >> FWIW, Tamas (CC added) has added code to restrict where altp2m calls can >> come from (although that's not XSM code). >> >> Please let us know how to proceed. > I've given my suggestion already: Now that we have SUPPORT.md, > submit a patch to add altp2m there (not sure if it was in the part of > George's series that was left out for the moment), stating it's > security unsupported. With that's I still wouldn't like the addition by > this patch, but I also wouldn't object to this widening of an already > bad situation anymore: Anyone wanting to alter that support status > would first need to deal with the too wide exposure of some of the > operations. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How to make tracking CPU cache-miss on Xen?
On Mon, Dec 11, 2017 at 5:59 AM, Minjun Hong wrote: > Hello, I'm working on the 'credit scheduler' of Xen. > And I need to compare CPU cache misses between original Xen and my patching > version. > But I failed all attempt even if I have tried many methods by googling. > When I typed 'perf list' with my 'perf' compiled by source code in the > current kernel source code, it said: > >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ ./perf list >> List of pre-defined events (to be used in -e): >> msr/pperf/ [Kernel PMU event] >> msr/smi/ [Kernel PMU event] >> msr/tsc/ [Kernel PMU event] >> power/energy-cores/[Kernel PMU event] >> power/energy-gpu/ [Kernel PMU event] >> power/energy-pkg/ [Kernel PMU event] >> power/energy-psys/ [Kernel PMU event] >> power/energy-ram/ [Kernel PMU event] >> rNNN [Raw hardware event >> descriptor] >> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event >> descriptor] >>(see 'man perf-list' on how to encode it) >> mem:[/len][:access] [Hardware breakpoint] >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ > > > > Since there is no HW event in contrast with native environment, I should try > 'Raw hardware event descriptor' option. > According to 'Intel® 64 and IA-32 Architectures Software Developer’s Manual > Volume 3B: System Programming Guide', I used 'r412e' raw hardware event to > get LLC Misses which is in '18.2.1.2 Pre-defined Architectural Performance > Events' section of the guide, > but I found out my 'perf' does not support the feature: > >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ sudo ./perf stat -e >> r412e sleep 1 >> Performance counter stats for 'sleep 1': >> r412e >>1.002120111 seconds time elapsed >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ > > > I could not understand why I cannot find out the number of cache-misses. > When I did googling, I did not think there would be a problem because there > were a lot of posts to get cache-misses in the Xen environment. It sounds like what you might want is the vPMU functionality. CC'ing Boris Ostrovsky, who has worked on vPMU functionality before. However, are you sure that you want to be reading cache misses from the guest? It seems like that is *probably* OK, but another option would be to instrument Xen to read and provide that information. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
On 11/12/17 10:06, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
>> On 08/12/17 08:03, Tim Deegan wrote:
>>> It should be possible to do something like the misconfigured-entry bit
>>> trick by _allocating_ the memory up-front and building the p2m entries
>>> but only making them usable by the {IO}MMUs on first access. That
>>> would make these early p2m walks shorter (because they can skip whole
>>> subtrees that aren't marked present yet) without making major changes
>>> to domain build or introducing run-time failures.
>> I am not aware of any way on Arm to misconfigure an entry. We do have
>> valid and access bits, although they will affect the IOMMU as well. So
>> it will not be possible to get page-table sharing with this "feature"
>> enabled.
> How would you intend to solve the IOMMU part of the problem with
> PoD? As was pointed out before - IOMMU and PoD are incompatible
> on x86.
Not only that.
The use of an IOMMU is incompatible with any HAP scheme using EPT/NPT
violations to trigger hypervisor work, and will remain the case until
such time as IOMMUs gain restartable pagefaults. The chances of this
happening are tantamount to zero, due to timing requirements in the
PCI(e) spec.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
Hi, On 08/12/17 10:56, George Dunlap wrote: > On 12/07/2017 07:21 PM, Marc Zyngier wrote: >> On 07/12/17 18:06, George Dunlap wrote: >>> On 12/07/2017 04:58 PM, Marc Zyngier wrote: On 07/12/17 16:44, George Dunlap wrote: > On 12/07/2017 04:04 PM, Julien Grall wrote: >> Hi Jan, >> >> On 07/12/17 15:45, Jan Beulich wrote: >> On 07.12.17 at 15:53, wrote: On 07/12/17 13:52, Julien Grall wrote: There is exactly one case where set/way makes sense, and that's when you're the only CPU left in the system, your MMU is off, and you're about to go down. >>> >>> With this and ... >>> On top of bypassing the coherency, S/W CMOs do not prevent lines from migrating from one CPU to another. So you could happily be flushing by S/W, and still end up with dirty lines in your cache. Success! >>> >>> ... this I wonder what value emulating those insns then has in the first >>> place. Can't you as well simply skip and ignore them, with the same >>> (bad) result? >> >> The result will be much much worst. Here a concrete example with a Linux >> Arm 32-bit: >> >> 1) Cache enabled >> 2) Decompress >> 3) Nuke cache (S/W) >> 4) Cache off >> 5) Access new kernel >> >> If you skip #3, the decompress data may not have reached the memory, so >> you would access stall data. >> >> This would effectively mean we don't support Linux Arm 32-bit. > > So Marc said that #3 "doesn't make sense", since although it might be > the only cpu on in the system, you're not "about to go down"; but Linux > 32-bit is doing that anyway. "Doesn't make sense" on an ARMv7+ with SMP. That code dates back to ARMv4, and has been left untouched ever since. "If it ain't broke..." > It sounds like from the slides the purpose of #3 might be to get stuff > out of the D-cache into the I-cache. But why is the cache turned off? Linux mandates that the kernel in entered with the MMU off. Which has the effect of disabling the caches too (VIVT caches and all that jazz). > And why doesn't Linux use the VA-based flushes rather than the S/W > flushes? Linux/arm64 does. Changing the 32bit port to use VA CMOs would probably break stuff from the late 90s, so that's not going to happen. These days, I tend to pick my battles... ;-) >>> >>> OK, so let me try to state this "forwards" for those of us not familiar >>> with the situation: >>> >>> 1. Linux expects to start in 'linear' mode, with the MMU disabled. >>> >>> 2. On ARM, disabling the MMU disables caching (!). But disabling >>> caching doesn't flush the cache; it just means the cache is bypassed (!). >>> >>> 3. Which means for Linux on ARM, after unzipping the kernel image, you >>> need to flush the cache before disabling the MMU and starting Linux proper >>> >>> 4. For historical reasons, 32-bit ARM Linux uses the S/W instructions to >>> flush the cache. This still works on 32-bit hardware, and so the Linux >>> maintainers are loathe to change it, even though more reliable VA-based >>> instructions are available (?). >> >> It also works on 64bit HW. It is just not easily virtualizable, which is >> why we've removed all S/W from the 64bit Linux port a while ago. > > From the diagram in your talk, it looked like the "flush the cache" > operation *doesn't* work anywhere that has a "system cache", even on > bare metal. What Marc probably meant is that they still work *within the architectural limits* that s/w operations provide: - S/W CMOs are not broadcasted, so in a live SMP system they are probably not doing what you expect them to do. This isn't an issue for a 32-bit Linux kernel decompressor, because this is UP still at this point. - S/W CMOs are optional to implement for system caches. As Marc mentioned, there are not many 32-bit systems with a system cache out there. And on those systems you can still boot an uncompressed kernel or use gzip-ed kernel and let the bootloader (grub, U-Boot) decompress it. On the other hand there seem to be a substantial number of (older) 32-bit systems where VA CMOs have issues. The problem now is that for the "32-bit kernel on a 64-bit hypervisor" cache those two assumptions are not true: The system has multiple CPUs running already, also 64-bit hardware is much more likely to have system caches. So this is mostly a virtualization problem and thus should be solved here. To help assessing the benefits of adding PoD to Xen: I did some tracing on Friday with a 32-bit kernel on a (64-bit) Juno with KVM. I see *four* full cache cleans very early on each boot (first s/w op + caches turned on, twice), plus one cache clean when each (v)CPU is brought online (due to the initial "turn MMU and cache on" operation). During the runtime of the kernel there are no s/w ops, except for (v)CPU off/on-lining (echo [01] >
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
>>> On 11.12.17 at 12:11, wrote:
> On 11/12/17 10:06, Jan Beulich wrote:
> On 08.12.17 at 15:38, wrote:
>>> On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entries
but only making them usable by the {IO}MMUs on first access. That
would make these early p2m walks shorter (because they can skip whole
subtrees that aren't marked present yet) without making major changes
to domain build or introducing run-time failures.
>>> I am not aware of any way on Arm to misconfigure an entry. We do have
>>> valid and access bits, although they will affect the IOMMU as well. So
>>> it will not be possible to get page-table sharing with this "feature"
>>> enabled.
>> How would you intend to solve the IOMMU part of the problem with
>> PoD? As was pointed out before - IOMMU and PoD are incompatible
>> on x86.
>
> Not only that.
>
> The use of an IOMMU is incompatible with any HAP scheme using EPT/NPT
> violations to trigger hypervisor work,
For many forms of "hypervisor work" I agree, but our misconfig
scheme demonstrates that there are exceptions where the IOMMU
continues to work fine.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 08.12.17 at 13:42, wrote: > On 12/08/2017 02:18 PM, Jan Beulich wrote: > On 24.10.17 at 12:19, wrote: >>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a >>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart >>> (and >>> hence with the original altp2m design, where domains are allowed - with the >>> proper altp2m access rights - to alter these settings), in the absence of an >>> official position on the issue from the original altp2m designers. >> >> I continue to disagree with this reasoning. I'm afraid I'm not really >> willing to allow widening the badness, unless altp2m was formally >> documented security-unsupported. > > Going the DOMCTL route here would have been the (much easier) solution, > and in fact, as stated before, there has been an attempt to do so - > however, IIRC Andrew has insisted that we should take care to use > consistent access privilege across altp2m operations. Andrew, is that the case (I don't recall anything like that)? > This was followed by a lengthy xen-devel discussion and several > unsuccessful attempts to obtain an official position from the original > contributors, at which point (after several months), as also discussed > at the Xen Developer Summit in Budapest, we decided to press on in the > direction that had seemed the most compatible with the original altp2m > design. (Please correct me if I'm misremembering or misunderstanding > something.) > > So at this point it looks like we're stuck again: we're happy to go in > any direction the maintainers decide is the best, but we do need to > decide on one. > > FWIW, Tamas (CC added) has added code to restrict where altp2m calls can > come from (although that's not XSM code). > > Please let us know how to proceed. I've given my suggestion already: Now that we have SUPPORT.md, submit a patch to add altp2m there (not sure if it was in the part of George's series that was left out for the moment), stating it's security unsupported. With that's I still wouldn't like the addition by this patch, but I also wouldn't object to this widening of an already bad situation anymore: Anyone wanting to alter that support status would first need to deal with the too wide exposure of some of the operations. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct
>>> On 08.12.17 at 20:05, wrote: > On 12/8/2017 12:49 AM, Jan Beulich wrote: >> I'm not convinced of re-using E820 types here. I can see that this >> might ease the consumption in Linux, but I don't think there should >> be any connection to x86 aspects here - the data being supplied is >> x86-agnostic, and Linux'es placement of the header is also making >> no connection to x86 (oddly enough, the current placement in the >> Xen tree does, for a reason which escapes me). >> >> I could also imagine reasons to add new types without them being >> sanctioned by whoever maintains E820 type assignments. > > So there are three aspects to discuss here. > > 1) The addition of the "E820_TYPE_xxx" comment. I am fine with just > changing that to "mapping type" and leaving it as something to be > coordinated between the hypervisor and the guest OS being started by > that hypervisor. > > 2) x86 vs x86-agnostic. While I'm trying to keep this interface generic > in terms of guest OS (like Linux, FreeBSD, possible other guests in the > future) and hypervisor type (Xen, QEMU/KVM, etc), I was actually under > the impression that we are dealing with an ABI that is very much x86 > specific. > > The canonical document describing the ABI > (https://xenbits.xen.org/docs/unstable/misc/pvh.html) is titled "x86/HVM > direct boot ABI" and goes on to describe an interface in very > x86-specific terms. i.e. The ebx register must contain a pointer, cs, > ds, es must be set a certain way, etc. > > That is probably why Xen's placement of the header file is in a x86 > section of the tree. And also why there already exist a number of "x86" > references in the existing header file. A quick grep of the existing > header file will show lines like: > > "C representation of the x86/HVM start info layout" > "Start of day structure passed to PVH guests and to HVM guests in %ebx" > "Xen on x86 will always try to place all the data below the 4GiB" > > If at some point in the future someone decides to implement a similar > ABI for a different CPU architecture while re-using this same > hvm_start_info struct, then this header will have to be redone a bit > anyway. But I'm not aware of any other such ABI that exists or is > currently in the works. Anything like this being in the works elsewhere doesn't mean much. Otherwise you'd advocate for anyone introducing something new on a single architecture only to ignore all portability concerns. My fundamental point here is that within the currently defined structures there's nothing x86 specific, no matter that a few comments are mentioning x86 (and in at least two of the three cases for obvious [implementation] reasons rather than to explain why this interface can/should be x86 only). > 3) The (packed) layout of the hvm_memmap_table_entry struct. I did > initially consider just making this a new structure that did not > necessarily match struct e820_entry in its array layout. But, it's not > just the consumer that has an easier time digesting it in the e820_entry > array format. It's also the producer side (QEMU for instance) where code > already exists to lay out this information in e820_entry array format. > And since this is all x86 specific anyway, it just seemed like I would > be needlessly making more work for both ends by inventing a completely > new memory map layout just for the sake of being different. Especially > when there doesn't seem to be anything terribly broken about the > existing e820_entry array format as a general purpose memory map. The brokenness is the mis-alignment of every other array member. This doesn't matter on x86, but it would matter on any architecture requiring strict alignment. Furthermore please note that in the canonical headers you can't even express what you want: Use of #pragma pack or the packed attribute is prohibited there - we demand that the headers can be used by any C89-compatible compiler (lately there have been a few extensions requiring C99, but these need to be opted in for by consumers, which imo is not an option here). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
On 12/11/2017 11:10 AM, Andre Przywara wrote: > Hi, > > On 08/12/17 10:56, George Dunlap wrote: >> On 12/07/2017 07:21 PM, Marc Zyngier wrote: >>> On 07/12/17 18:06, George Dunlap wrote: On 12/07/2017 04:58 PM, Marc Zyngier wrote: > On 07/12/17 16:44, George Dunlap wrote: >> On 12/07/2017 04:04 PM, Julien Grall wrote: >>> Hi Jan, >>> >>> On 07/12/17 15:45, Jan Beulich wrote: >>> On 07.12.17 at 15:53, wrote: > On 07/12/17 13:52, Julien Grall wrote: > There is exactly one case where set/way makes sense, and that's when > you're the only CPU left in the system, your MMU is off, and you're > about to go down. With this and ... > On top of bypassing the coherency, S/W CMOs do not prevent lines from > migrating from one CPU to another. So you could happily be flushing by > S/W, and still end up with dirty lines in your cache. Success! ... this I wonder what value emulating those insns then has in the first place. Can't you as well simply skip and ignore them, with the same (bad) result? >>> >>> The result will be much much worst. Here a concrete example with a Linux >>> Arm 32-bit: >>> >>> 1) Cache enabled >>> 2) Decompress >>> 3) Nuke cache (S/W) >>> 4) Cache off >>> 5) Access new kernel >>> >>> If you skip #3, the decompress data may not have reached the memory, so >>> you would access stall data. >>> >>> This would effectively mean we don't support Linux Arm 32-bit. >> >> So Marc said that #3 "doesn't make sense", since although it might be >> the only cpu on in the system, you're not "about to go down"; but Linux >> 32-bit is doing that anyway. > > "Doesn't make sense" on an ARMv7+ with SMP. That code dates back to > ARMv4, and has been left untouched ever since. "If it ain't broke..." > >> It sounds like from the slides the purpose of #3 might be to get stuff >> out of the D-cache into the I-cache. But why is the cache turned off? > > Linux mandates that the kernel in entered with the MMU off. Which has > the effect of disabling the caches too (VIVT caches and all that jazz). > >> And why doesn't Linux use the VA-based flushes rather than the S/W >> flushes? > > Linux/arm64 does. Changing the 32bit port to use VA CMOs would probably > break stuff from the late 90s, so that's not going to happen. These > days, I tend to pick my battles... ;-) OK, so let me try to state this "forwards" for those of us not familiar with the situation: 1. Linux expects to start in 'linear' mode, with the MMU disabled. 2. On ARM, disabling the MMU disables caching (!). But disabling caching doesn't flush the cache; it just means the cache is bypassed (!). 3. Which means for Linux on ARM, after unzipping the kernel image, you need to flush the cache before disabling the MMU and starting Linux proper 4. For historical reasons, 32-bit ARM Linux uses the S/W instructions to flush the cache. This still works on 32-bit hardware, and so the Linux maintainers are loathe to change it, even though more reliable VA-based instructions are available (?). >>> >>> It also works on 64bit HW. It is just not easily virtualizable, which is >>> why we've removed all S/W from the 64bit Linux port a while ago. >> >> From the diagram in your talk, it looked like the "flush the cache" >> operation *doesn't* work anywhere that has a "system cache", even on >> bare metal. > > What Marc probably meant is that they still work *within the > architectural limits* that s/w operations provide: > - S/W CMOs are not broadcasted, so in a live SMP system they are > probably not doing what you expect them to do. This isn't an issue for a > 32-bit Linux kernel decompressor, because this is UP still at this point. > - S/W CMOs are optional to implement for system caches. As Marc > mentioned, there are not many 32-bit systems with a system cache out > there. Right, that's what I said -- on any 32-bit system with a system cache, which doesn't implement the S/W functionality, then using S/W to flush the cache won't work, even on bare metal. > And on those systems you can still boot an uncompressed kernel or > use gzip-ed kernel and let the bootloader (grub, U-Boot) decompress it. > On the other hand there seem to be a substantial number of (older) > 32-bit systems where VA CMOs have issues. OK, good to know. > The problem now is that for the "32-bit kernel on a 64-bit hypervisor" > cache those two assumptions are not true: The system has multiple CPUs > running already, also 64-bit hardware is much more likely to have system > caches. > So this is mostly a virtualization problem and thus should be solved here. Right. > To help assessing the benefits of adding PoD to
Re: [Xen-devel] [PATCH v3 4/4] x86/xen: supply rsdp address in boot params for pvh guests
On 11/12/17 11:09, Jan Beulich wrote: On 08.12.17 at 16:11, wrote: >> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212 >> which should have been 0x020c. > > This part of the description has become partly stale now with the > new patch 3. Indeed. I'll wait for other comments before sending out a new version. Thanks, Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-sid test] 72629: trouble: blocked/broken/pass
flight 72629 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72629/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops broken test-amd64-amd64-i386-sid-netboot-pygrubbroken build-armhf-pvopsbroken build-i386 broken test-amd64-amd64-amd64-sid-netboot-pvgrub broken build-armhf broken build-armhf-pvops 4 host-install(4) broken REGR. vs. 72515 build-armhf 4 host-install(4) broken REGR. vs. 72515 test-amd64-amd64-i386-sid-netboot-pygrub 4 host-install(4) broken REGR. vs. 72515 test-amd64-amd64-amd64-sid-netboot-pvgrub 4 host-install(4) broken REGR. vs. 72515 build-i386-pvops 4 host-install(4) broken REGR. vs. 72515 build-i3864 host-install(4) broken REGR. vs. 72515 Tests which did not succeed, but are not blocking: test-amd64-i386-i386-sid-netboot-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a test-amd64-i386-amd64-sid-netboot-pygrub 1 build-check(1) blocked n/a baseline version: flight 72515 jobs: build-amd64 pass build-armhf broken build-i386 broken build-amd64-pvopspass build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-sid-netboot-pvgrubbroken test-amd64-i386-i386-sid-netboot-pvgrub blocked test-amd64-i386-amd64-sid-netboot-pygrub blocked test-armhf-armhf-armhf-sid-netboot-pygrubblocked test-amd64-amd64-i386-sid-netboot-pygrub broken sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
>>> On 08.12.17 at 15:38, wrote:
> On 08/12/17 08:03, Tim Deegan wrote:
>> It should be possible to do something like the misconfigured-entry bit
>> trick by _allocating_ the memory up-front and building the p2m entries
>> but only making them usable by the {IO}MMUs on first access. That
>> would make these early p2m walks shorter (because they can skip whole
>> subtrees that aren't marked present yet) without making major changes
>> to domain build or introducing run-time failures.
>
> I am not aware of any way on Arm to misconfigure an entry. We do have
> valid and access bits, although they will affect the IOMMU as well. So
> it will not be possible to get page-table sharing with this "feature"
> enabled.
How would you intend to solve the IOMMU part of the problem with
PoD? As was pointed out before - IOMMU and PoD are incompatible
on x86.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 12:12 PM, Jan Beulich wrote: On 11.12.17 at 12:06, wrote: >> On 11/12/17 09:14, Jan Beulich wrote: >> On 08.12.17 at 13:42, wrote: On 12/08/2017 02:18 PM, Jan Beulich wrote: On 24.10.17 at 12:19, wrote: >> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed >> to a >> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart >> (and >> hence with the original altp2m design, where domains are allowed - with >> the >> proper altp2m access rights - to alter these settings), in the absence >> of an >> official position on the issue from the original altp2m designers. > I continue to disagree with this reasoning. I'm afraid I'm not really > willing to allow widening the badness, unless altp2m was formally > documented security-unsupported. Going the DOMCTL route here would have been the (much easier) solution, and in fact, as stated before, there has been an attempt to do so - however, IIRC Andrew has insisted that we should take care to use consistent access privilege across altp2m operations. >>> Andrew, is that the case (I don't recall anything like that)? >> >> My suggestion was that we don't break usecases. The Intel usecase >> specifically is for an in-guest entity to have full control of all >> altp2m functionality, and this is fine (security wise) when permitted to >> do so by the toolstack. > > IOW you mean that such guests would be considered "trusted", i.e. > whatever bad they can do is by definition not a security concern. I'm not sure what you mean by "trusted". If implemented correctly, altp2m and mem_access shouldn't give the guest any more permissions than it has already. The main risk would be if there were bugs in the functionality that allowed security issues. You argued that we should keep PV linear pagetables, before knowing that NetBSD used them, in spite of having discovered two *actual* vulnerabilities in the implementation. I don't really see how this is different. We obviously need to go though the code with a fine-toothed comb before we say that we'll give security support to the mode where we allow a guest agent to modify altp2m access. Since we can control whether this functionality is exposed to the guest or not, we can specify whether we provide security support for toolstack altp2m access vs guest altp2m access. > If so, that's fine of course, provided the default mode is secure > (which it looks like it is by virtue of altp2m being disabled altogether > by default). Yet I don't think I know of a place where this is being > spelled out. SUPPORT.md has "Alternative p2m" listed as "tech preview", which would mean "not security supported". Maybe that needs an "altp2m" tag somewhere so it's easier to grep for? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How to make tracking CPU cache-miss on Xen?
Thanks for your answer, George. What I want ultimately is cache misses from the guest, but even I could not get the cache misses from dom0 also. That's why I'm confused as I know, it should be possible to get cache-misses from dom0 (is it right??). I already enabled CONFIG_XEN_HAVE_VPMU of current kernel to get cache misses. Is there anything what I miss during Xen install? Minjun Hong On Mon, Dec 11, 2017 at 7:54 PM, George Dunlap wrote: > On Mon, Dec 11, 2017 at 5:59 AM, Minjun Hong wrote: > > Hello, I'm working on the 'credit scheduler' of Xen. > > And I need to compare CPU cache misses between original Xen and my > patching > > version. > > But I failed all attempt even if I have tried many methods by googling. > > When I typed 'perf list' with my 'perf' compiled by source code in the > > current kernel source code, it said: > > > >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ ./perf list > >> List of pre-defined events (to be used in -e): > >> msr/pperf/ [Kernel PMU event] > >> msr/smi/ [Kernel PMU event] > >> msr/tsc/ [Kernel PMU event] > >> power/energy-cores/[Kernel PMU event] > >> power/energy-gpu/ [Kernel PMU event] > >> power/energy-pkg/ [Kernel PMU event] > >> power/energy-psys/ [Kernel PMU event] > >> power/energy-ram/ [Kernel PMU event] > >> rNNN [Raw hardware event > >> descriptor] > >> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event > >> descriptor] > >>(see 'man perf-list' on how to encode it) > >> mem:[/len][:access] [Hardware > breakpoint] > >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ > > > > > > > > Since there is no HW event in contrast with native environment, I should > try > > 'Raw hardware event descriptor' option. > > According to 'Intel® 64 and IA-32 Architectures Software Developer’s > Manual > > Volume 3B: System Programming Guide', I used 'r412e' raw hardware event > to > > get LLC Misses which is in '18.2.1.2 Pre-defined Architectural > Performance > > Events' section of the guide, > > but I found out my 'perf' does not support the feature: > > > >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ sudo ./perf stat -e > >> r412e sleep 1 > >> Performance counter stats for 'sleep 1': > >> r412e > >>1.002120111 seconds time elapsed > >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ > > > > > > I could not understand why I cannot find out the number of cache-misses. > > When I did googling, I did not think there would be a problem because > there > > were a lot of posts to get cache-misses in the Xen environment. > > It sounds like what you might want is the vPMU functionality. CC'ing > Boris Ostrovsky, who has worked on vPMU functionality before. > > However, are you sure that you want to be reading cache misses from > the guest? It seems like that is *probably* OK, but another option > would be to instrument Xen to read and provide that information. > > -George > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 11.12.17 at 13:50, wrote: > On 12/11/2017 12:12 PM, Jan Beulich wrote: > On 11.12.17 at 12:06, wrote: >>> My suggestion was that we don't break usecases. The Intel usecase >>> specifically is for an in-guest entity to have full control of all >>> altp2m functionality, and this is fine (security wise) when permitted to >>> do so by the toolstack. >> >> IOW you mean that such guests would be considered "trusted", i.e. >> whatever bad they can do is by definition not a security concern. > > I'm not sure what you mean by "trusted". If implemented correctly, > altp2m and mem_access shouldn't give the guest any more permissions than > it has already. The main risk would be if there were bugs in the > functionality that allowed security issues. Hmm, maybe I'm mis-reading the code, but mem_access.c:set_mem_access() looks to be using the requested access rights verbatim, i.e. without applying tool stack imposed restrictions (hypervisor ones look to be honored by deriving base permissions from the p2m type first). > You argued that we should keep PV linear pagetables, before knowing that > NetBSD used them, in spite of having discovered two *actual* > vulnerabilities in the implementation. I don't really see how this is > different. It's quite the opposite to me - I don't see the similarity. On this thread we're talking about new functionality, and how far to expose it. PV linear page tables had been there (and considered supported) for years, so removing the functionality or even only calling it unsupported all of the sudden didn't seem right at all. Even for altp2m as a whole I don't think it's mature enough for us to not be able to declare parts of it not security supported. >> If so, that's fine of course, provided the default mode is secure >> (which it looks like it is by virtue of altp2m being disabled altogether >> by default). Yet I don't think I know of a place where this is being >> spelled out. > > SUPPORT.md has "Alternative p2m" listed as "tech preview", which would > mean "not security supported". Maybe that needs an "altp2m" tag > somewhere so it's easier to grep for? Ah - indeed I had searched for altp2m only. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] x86/xen: supply rsdp address in boot params for pvh guests
* Juergen Gross wrote: > On 11/12/17 11:09, Jan Beulich wrote: > On 08.12.17 at 16:11, wrote: > >> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212 > >> which should have been 0x020c. > > > > This part of the description has become partly stale now with the > > new patch 3. > > Indeed. I'll wait for other comments before sending out a new version. Looks good to me now, and I've applied the series to tip:x86/boot. I have removed this stale sentence from patch #4. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How to make tracking CPU cache-miss on Xen?
On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong wrote: > > Thanks for your answer, George. > > What I want ultimately is cache misses from the guest, but even I could not > get the cache misses from dom0 also. > That's why I'm confused as I know, it should be possible to get cache-misses > from dom0 (is it right??). > I already enabled CONFIG_XEN_HAVE_VPMU of current kernel to get cache misses. > Is there anything what I miss during Xen install? > If this is for a research project, I would suggest you to write your own code to monitor the cache misses for domU. This could be faster, since it's not complicated to do so. IIRC, PMU in Xen can only monitor the cache misses when VCPUs are pinned to cores. Best Regards, Meng --- Meng Xu Ph.D. Candidate in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ > > > On Mon, Dec 11, 2017 at 7:54 PM, George Dunlap wrote: >> >> On Mon, Dec 11, 2017 at 5:59 AM, Minjun Hong wrote: >> > Hello, I'm working on the 'credit scheduler' of Xen. >> > And I need to compare CPU cache misses between original Xen and my patching >> > version. >> > But I failed all attempt even if I have tried many methods by googling. >> > When I typed 'perf list' with my 'perf' compiled by source code in the >> > current kernel source code, it said: >> > >> >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ ./perf list >> >> List of pre-defined events (to be used in -e): >> >> msr/pperf/ [Kernel PMU event] >> >> msr/smi/ [Kernel PMU event] >> >> msr/tsc/ [Kernel PMU event] >> >> power/energy-cores/[Kernel PMU event] >> >> power/energy-gpu/ [Kernel PMU event] >> >> power/energy-pkg/ [Kernel PMU event] >> >> power/energy-psys/ [Kernel PMU event] >> >> power/energy-ram/ [Kernel PMU event] >> >> rNNN [Raw hardware event >> >> descriptor] >> >> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event >> >> descriptor] >> >>(see 'man perf-list' on how to encode it) >> >> mem:[/len][:access] [Hardware breakpoint] >> >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ >> > >> > >> > >> > Since there is no HW event in contrast with native environment, I should >> > try >> > 'Raw hardware event descriptor' option. >> > According to 'Intel® 64 and IA-32 Architectures Software Developer’s Manual >> > Volume 3B: System Programming Guide', I used 'r412e' raw hardware event to >> > get LLC Misses which is in '18.2.1.2 Pre-defined Architectural Performance >> > Events' section of the guide, >> > but I found out my 'perf' does not support the feature: >> > >> >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ sudo ./perf stat -e >> >> r412e sleep 1 >> >> Performance counter stats for 'sleep 1': >> >> r412e >> >>1.002120111 seconds time elapsed >> >> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ >> > >> > >> > I could not understand why I cannot find out the number of cache-misses. >> > When I did googling, I did not think there would be a problem because there >> > were a lot of posts to get cache-misses in the Xen environment. >> >> It sounds like what you might want is the vPMU functionality. CC'ing >> Boris Ostrovsky, who has worked on vPMU functionality before. >> >> However, are you sure that you want to be reading cache misses from >> the guest? It seems like that is *probably* OK, but another option >> would be to instrument Xen to read and provide that information. >> >> -George > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 03:36 PM, Jan Beulich wrote: On 11.12.17 at 13:50, wrote: >> On 12/11/2017 12:12 PM, Jan Beulich wrote: >> On 11.12.17 at 12:06, wrote: My suggestion was that we don't break usecases. The Intel usecase specifically is for an in-guest entity to have full control of all altp2m functionality, and this is fine (security wise) when permitted to do so by the toolstack. >>> >>> IOW you mean that such guests would be considered "trusted", i.e. >>> whatever bad they can do is by definition not a security concern. >> >> I'm not sure what you mean by "trusted". If implemented correctly, >> altp2m and mem_access shouldn't give the guest any more permissions than >> it has already. The main risk would be if there were bugs in the >> functionality that allowed security issues. > > Hmm, maybe I'm mis-reading the code, but > mem_access.c:set_mem_access() looks to be using the requested > access rights verbatim, i.e. without applying tool stack imposed > restrictions (hypervisor ones look to be honored by deriving > base permissions from the p2m type first). Quite likely I'm not grasping the full meaning of your objection, however the added code is merely another interface to already existing core code - so while admittedly there's room for improvement for the EPT code below it, this patch really only extends the scope of altp2m's existing version of set_mem_access() (which currently works on a single page). In that, it at least doesn't seem to make things worse (it's really just an optimization - whatever badness this code can cause with a single call, can already be achieved exactly with a sequence of xc_altp2m_set_mem_access() calls). Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 01:36 PM, Jan Beulich wrote: On 11.12.17 at 13:50, wrote: >> On 12/11/2017 12:12 PM, Jan Beulich wrote: >> On 11.12.17 at 12:06, wrote: My suggestion was that we don't break usecases. The Intel usecase specifically is for an in-guest entity to have full control of all altp2m functionality, and this is fine (security wise) when permitted to do so by the toolstack. >>> >>> IOW you mean that such guests would be considered "trusted", i.e. >>> whatever bad they can do is by definition not a security concern. >> >> I'm not sure what you mean by "trusted". If implemented correctly, >> altp2m and mem_access shouldn't give the guest any more permissions than >> it has already. The main risk would be if there were bugs in the >> functionality that allowed security issues. > > Hmm, maybe I'm mis-reading the code, but > mem_access.c:set_mem_access() looks to be using the requested > access rights verbatim, i.e. without applying tool stack imposed > restrictions (hypervisor ones look to be honored by deriving > base permissions from the p2m type first). Right, so one thing that would need to be fixed is to enumerate which things should work with what. At the moment it looks like toolstack mem_access functionality is simply incompatible with altp2m mem_access functionality. If you want to use toolstack mem_access, don't enable guest altp2m mem_access. If they were both needed to run at the same time, we could 1) prevent the guest from modifying the "host p2m" (altp2m index 0) and 2) make sure the altp2m entries were at least as strict as the host p2m entries. >> You argued that we should keep PV linear pagetables, before knowing that >> NetBSD used them, in spite of having discovered two *actual* >> vulnerabilities in the implementation. I don't really see how this is >> different. > > It's quite the opposite to me - I don't see the similarity. On this > thread we're talking about new functionality, and how far to > expose it. PV linear page tables had been there (and considered > supported) for years, so removing the functionality or even only > calling it unsupported all of the sudden didn't seem right at all. Well the idea of calling it unsupported was assuming that there weren't many people using it; finding out that NetWare, and in particular NetBSD, still used it changes the situation quite a bit. What I remember you actually saying at the time was, "We have functionality already, I don't see why we don't make it secure rather than removing it." The same kind of argument would seem to apply here: We have functionality that allows a guest agent to manipulate its altp2m access rights; why we don't make it secure rather than removing it? I certainly agree we shouldn't call it security supported until it's had a thorough audit; and I wouldn't do that work unless there was someone who actually wanted that support. But leaving the code in a state that could be given security support whenever someone wants to pick it up makes some sense (as long as it doesn't open up new attacks for guests not using that feature). -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: > On 12/11/2017 03:36 PM, Jan Beulich wrote: > On 11.12.17 at 13:50, wrote: >>> On 12/11/2017 12:12 PM, Jan Beulich wrote: >>> On 11.12.17 at 12:06, wrote: > My suggestion was that we don't break usecases. The Intel usecase > specifically is for an in-guest entity to have full control of all > altp2m functionality, and this is fine (security wise) when permitted to > do so by the toolstack. IOW you mean that such guests would be considered "trusted", i.e. whatever bad they can do is by definition not a security concern. >>> >>> I'm not sure what you mean by "trusted". If implemented correctly, >>> altp2m and mem_access shouldn't give the guest any more permissions than >>> it has already. The main risk would be if there were bugs in the >>> functionality that allowed security issues. >> >> Hmm, maybe I'm mis-reading the code, but >> mem_access.c:set_mem_access() looks to be using the requested >> access rights verbatim, i.e. without applying tool stack imposed >> restrictions (hypervisor ones look to be honored by deriving >> base permissions from the p2m type first). > > Quite likely I'm not grasping the full meaning of your objection, > however the added code is merely another interface to already existing > core code - so while admittedly there's room for improvement for the EPT > code below it, this patch really only extends the scope of altp2m's > existing version of set_mem_access() (which currently works on a single > page). In that, it at least doesn't seem to make things worse (it's > really just an optimization - whatever badness this code can cause with > a single call, can already be achieved exactly with a sequence of > xc_altp2m_set_mem_access() calls). I think Jan was saying that he would ideally like to remove *all* guest access to altp2m functionality, even what's currently there. The more extra features we make available to guests, the harder it will be in the future to argue to remove it all. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 02:51 PM, George Dunlap wrote: > On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: >> On 12/11/2017 03:36 PM, Jan Beulich wrote: >> On 11.12.17 at 13:50, wrote: On 12/11/2017 12:12 PM, Jan Beulich wrote: On 11.12.17 at 12:06, wrote: >> My suggestion was that we don't break usecases. The Intel usecase >> specifically is for an in-guest entity to have full control of all >> altp2m functionality, and this is fine (security wise) when permitted to >> do so by the toolstack. > > IOW you mean that such guests would be considered "trusted", i.e. > whatever bad they can do is by definition not a security concern. I'm not sure what you mean by "trusted". If implemented correctly, altp2m and mem_access shouldn't give the guest any more permissions than it has already. The main risk would be if there were bugs in the functionality that allowed security issues. >>> >>> Hmm, maybe I'm mis-reading the code, but >>> mem_access.c:set_mem_access() looks to be using the requested >>> access rights verbatim, i.e. without applying tool stack imposed >>> restrictions (hypervisor ones look to be honored by deriving >>> base permissions from the p2m type first). >> >> Quite likely I'm not grasping the full meaning of your objection, >> however the added code is merely another interface to already existing >> core code - so while admittedly there's room for improvement for the EPT >> code below it, this patch really only extends the scope of altp2m's >> existing version of set_mem_access() (which currently works on a single >> page). In that, it at least doesn't seem to make things worse (it's >> really just an optimization - whatever badness this code can cause with >> a single call, can already be achieved exactly with a sequence of >> xc_altp2m_set_mem_access() calls). > > I think Jan was saying that he would ideally like to remove *all* guest > access to altp2m functionality, even what's currently there. The more > extra features we make available to guests, the harder it will be in the > future to argue to remove it all. ...so the real question we're trying to decide here is: Should the guest be allowed access to altp2m functionality -- in particular the mem_access functionality? If so, then your new hypercall should probably be HVMOP (as Andy suggested). If not, then it should be something else, and someone should change the existing HVMOP to a DOMCTL. Andy and Tamas have argued that the 'guest agent' is an important use case and should be supported, and I'm inclined to agree with them. Jan seems partly to be afraid that the guest altp2m mem_access functionality is *currently* not mature enough to be security supported; and partly to be afraid that it can never be mature enough to be security supported. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 11.12.17 at 15:50, wrote: > On 12/11/2017 01:36 PM, Jan Beulich wrote: > On 11.12.17 at 13:50, wrote: >>> You argued that we should keep PV linear pagetables, before knowing that >>> NetBSD used them, in spite of having discovered two *actual* >>> vulnerabilities in the implementation. I don't really see how this is >>> different. >> >> It's quite the opposite to me - I don't see the similarity. On this >> thread we're talking about new functionality, and how far to >> expose it. PV linear page tables had been there (and considered >> supported) for years, so removing the functionality or even only >> calling it unsupported all of the sudden didn't seem right at all. > > Well the idea of calling it unsupported was assuming that there weren't > many people using it; finding out that NetWare, and in particular > NetBSD, still used it changes the situation quite a bit. > > What I remember you actually saying at the time was, "We have > functionality already, I don't see why we don't make it secure rather > than removing it." The same kind of argument would seem to apply here: > We have functionality that allows a guest agent to manipulate its altp2m > access rights; why we don't make it secure rather than removing it? That's a good option, but the patch here doesn't do so. Instead it increases the amount of code that will later need auditing / altering. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/setup: do not relocate Xen over current Xen image placement
On Thu, Dec 07, 2017 at 04:51:32AM -0700, Jan Beulich wrote: > >>> On 04.12.17 at 11:24, wrote: > > --- a/xen/arch/x86/setup.c > > +++ b/xen/arch/x86/setup.c > > @@ -962,7 +962,12 @@ void __init noreturn __start_xen(unsigned long mbi_p) > > } > > else > > end = 0; > > -if ( end > s ) > > + > > +/* > > + * Is the region size greater than zero and does it begins > > begin Yep. > > + * above or at the end of current Xen image placement? > > Without being a native speaker I think this commonly is "at or > above", not the other way around. But I'd be happy to be told > that this other form is equally frequently being used. OK. > > + */ > > +if ( (end > s) && (end - reloc_size >= _end - _start) ) > > In your earlier mails following v1 you had __pa(_end) here on the > right side. Why is this _end - _start again now (which is 2Mb too > little imo with the current XEN_IMG_OFFSET value)? (end - reloc_size + XEN_IMG_OFFSET >= __pa(_end)) and (end - reloc_size >= _end - _start) are equal. You should remember that there is nothing to copy between 0 and XEN_IMG_OFFSET. Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 11.12.17 at 15:46, wrote: > Quite likely I'm not grasping the full meaning of your objection, > however the added code is merely another interface to already existing > core code - so while admittedly there's room for improvement for the EPT > code below it, this patch really only extends the scope of altp2m's > existing version of set_mem_access() (which currently works on a single > page). In that, it at least doesn't seem to make things worse (it's > really just an optimization - whatever badness this code can cause with > a single call, can already be achieved exactly with a sequence of > xc_altp2m_set_mem_access() calls). That's true. Yet as just said in reply to George, any addition (like the one here) increases the amount of code needing auditing (and perhaps changing) before it could reach fully supported state. This is what I dislike. However, I've also said earlier that I wouldn't stand in the way of doing additions like the one here as long as the code is properly documented as security unsupported. As you've certainly seen, George has meanwhile pointed out that this is already the case. Hence while I won't ack any extension of the badness, I also won't argue against it (at least not in a way preventing the code from going in). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 11.12.17 at 15:51, wrote: > On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: >> On 12/11/2017 03:36 PM, Jan Beulich wrote: >> On 11.12.17 at 13:50, wrote: On 12/11/2017 12:12 PM, Jan Beulich wrote: On 11.12.17 at 12:06, wrote: >> My suggestion was that we don't break usecases. The Intel usecase >> specifically is for an in-guest entity to have full control of all >> altp2m functionality, and this is fine (security wise) when permitted to >> do so by the toolstack. > > IOW you mean that such guests would be considered "trusted", i.e. > whatever bad they can do is by definition not a security concern. I'm not sure what you mean by "trusted". If implemented correctly, altp2m and mem_access shouldn't give the guest any more permissions than it has already. The main risk would be if there were bugs in the functionality that allowed security issues. >>> >>> Hmm, maybe I'm mis-reading the code, but >>> mem_access.c:set_mem_access() looks to be using the requested >>> access rights verbatim, i.e. without applying tool stack imposed >>> restrictions (hypervisor ones look to be honored by deriving >>> base permissions from the p2m type first). >> >> Quite likely I'm not grasping the full meaning of your objection, >> however the added code is merely another interface to already existing >> core code - so while admittedly there's room for improvement for the EPT >> code below it, this patch really only extends the scope of altp2m's >> existing version of set_mem_access() (which currently works on a single >> page). In that, it at least doesn't seem to make things worse (it's >> really just an optimization - whatever badness this code can cause with >> a single call, can already be achieved exactly with a sequence of >> xc_altp2m_set_mem_access() calls). > > I think Jan was saying that he would ideally like to remove *all* guest > access to altp2m functionality, even what's currently there. The more > extra features we make available to guests, the harder it will be in the > future to argue to remove it all. With one slight correction: all _uncontrolled_ access is what I'd like to see removed. Right now this could arguably indeed mean all access, as it is all uncontrolled (afaict). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How to make tracking CPU cache-miss on Xen?
On 12/11/2017 09:36 AM, Meng Xu wrote: > On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong wrote: >> Thanks for your answer, George. >> >> What I want ultimately is cache misses from the guest, but even I could not >> get the cache misses from dom0 also. >> That's why I'm confused as I know, it should be possible to get cache-misses >> from dom0 (is it right??). >> I already enabled CONFIG_XEN_HAVE_VPMU of current kernel to get cache >> misses. Is there anything what I miss during Xen install? >> > If this is for a research project, I would suggest you to write your > own code to monitor the cache misses for domU. This could be faster, > since it's not complicated to do so. > > IIRC, PMU in Xen can only monitor the cache misses when VCPUs are > pinned to cores. Counters are virtualized for guests (including dom0) so I am not sure pinning is required. Pinning is only needed when you try to collect counters for full system. OTOH, when a VCPU is migrated you start running with a new cache, something to keep in mind. > > > Best Regards, > > Meng > > --- > Meng Xu > Ph.D. Candidate in Computer and Information Science > University of Pennsylvania > http://www.cis.upenn.edu/~mengxu/ >> >> On Mon, Dec 11, 2017 at 7:54 PM, George Dunlap wrote: >>> On Mon, Dec 11, 2017 at 5:59 AM, Minjun Hong wrote: Hello, I'm working on the 'credit scheduler' of Xen. And I need to compare CPU cache misses between original Xen and my patching version. But I failed all attempt even if I have tried many methods by googling. When I typed 'perf list' with my 'perf' compiled by source code in the current kernel source code, it said: > nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ ./perf list > List of pre-defined events (to be used in -e): > msr/pperf/ [Kernel PMU event] > msr/smi/ [Kernel PMU event] > msr/tsc/ [Kernel PMU event] > power/energy-cores/[Kernel PMU event] > power/energy-gpu/ [Kernel PMU event] > power/energy-pkg/ [Kernel PMU event] > power/energy-psys/ [Kernel PMU event] > power/energy-ram/ [Kernel PMU event] > rNNN [Raw hardware event > descriptor] > cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event > descriptor] >(see 'man perf-list' on how to encode it) > mem:[/len][:access] [Hardware breakpoint] > nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ Since there is no HW event in contrast with native environment, I should try 'Raw hardware event descriptor' option. According to 'Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide', I used 'r412e' raw hardware event to get LLC Misses which is in '18.2.1.2 Pre-defined Architectural Performance Events' section of the guide, but I found out my 'perf' does not support the feature: > nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ sudo ./perf stat -e > r412e sleep 1 > Performance counter stats for 'sleep 1': > r412e >1.002120111 seconds time elapsed > nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ I could not understand why I cannot find out the number of cache-misses. When I did googling, I did not think there would be a problem because there were a lot of posts to get cache-misses in the Xen environment. Are you sure VPMU is enabled? It is off by default, you need 'vpmu' boot option for Xen. What does dmesg | grep Performance in the guest that you are trying to profile say? -boris >>> It sounds like what you might want is the vPMU functionality. CC'ing >>> Boris Ostrovsky, who has worked on vPMU functionality before. >>> >>> However, are you sure that you want to be reading cache misses from >>> the guest? It seems like that is *probably* OK, but another option >>> would be to instrument Xen to read and provide that information. >>> >>> -George >> >> >> ___ >> Xen-devel mailing list >> Xen-devel@lists.xenproject.org >> https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))
On Thu, Dec 07, 2017 at 05:02:02AM -0700, Jan Beulich wrote: > >>> On 04.12.17 at 11:24, wrote: > > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442 > > (x86: make Xen early boot code relocatable) is not reliable. Potentially > > its value may fall below PFN_DOWN(__pa(_end)) > > Under what (perhaps just theoretical) conditions? It seems to imply > to me that we'd be moved Xen downwards if this was to happen, in > which case I'd suggest to simply skip the relocation instead (we > really only ever want to move Xen upwards). Not always. If __pa(__image_base__) > xen_phys_start and even if xen_phys_start < __pa(_end) then we are still moving upwards. That is why we should change the condition. And we have to reference to something constant not to the moving one. Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How to make tracking CPU cache-miss on Xen?
On Mon, Dec 11, 2017 at 3:05 PM, Boris Ostrovsky wrote: > On 12/11/2017 09:36 AM, Meng Xu wrote: >> On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong wrote: >>> Thanks for your answer, George. >>> >>> What I want ultimately is cache misses from the guest, but even I could not >>> get the cache misses from dom0 also. >>> That's why I'm confused as I know, it should be possible to get >>> cache-misses from dom0 (is it right??). >>> I already enabled CONFIG_XEN_HAVE_VPMU of current kernel to get cache >>> misses. Is there anything what I miss during Xen install? >>> >> If this is for a research project, I would suggest you to write your >> own code to monitor the cache misses for domU. This could be faster, >> since it's not complicated to do so. >> >> IIRC, PMU in Xen can only monitor the cache misses when VCPUs are >> pinned to cores. > > Counters are virtualized for guests (including dom0) so I am not sure > pinning is required. Pinning is only needed when you try to collect > counters for full system. > > OTOH, when a VCPU is migrated you start running with a new cache, > something to keep in mind. Well if his goal was to measure cache misses based on different Xen scheduling algorithms, that might be the point. :-) Minjun: BTW, it's standard on this list to quote inline (as I'm doing), rather than top-posting (having your reply at the top and the original mail entirely beneath it). Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 02:58 PM, Jan Beulich wrote: On 11.12.17 at 15:50, wrote: >> On 12/11/2017 01:36 PM, Jan Beulich wrote: >> On 11.12.17 at 13:50, wrote: You argued that we should keep PV linear pagetables, before knowing that NetBSD used them, in spite of having discovered two *actual* vulnerabilities in the implementation. I don't really see how this is different. >>> >>> It's quite the opposite to me - I don't see the similarity. On this >>> thread we're talking about new functionality, and how far to >>> expose it. PV linear page tables had been there (and considered >>> supported) for years, so removing the functionality or even only >>> calling it unsupported all of the sudden didn't seem right at all. >> >> Well the idea of calling it unsupported was assuming that there weren't >> many people using it; finding out that NetWare, and in particular >> NetBSD, still used it changes the situation quite a bit. >> >> What I remember you actually saying at the time was, "We have >> functionality already, I don't see why we don't make it secure rather >> than removing it." The same kind of argument would seem to apply here: >> We have functionality that allows a guest agent to manipulate its altp2m >> access rights; why we don't make it secure rather than removing it? > > That's a good option, but the patch here doesn't do so. Instead it > increases the amount of code that will later need auditing / > altering. Right, but that's because their goal isn't to get guest support working. It doesn't sound like they particularly care about HVMOP / DOMCTL at all; rather, it's Andy who has insisted that it be extended in line with the current interface, for such a time as someone wants to use the guest altp2m hypercalls. First of all, I agree with Andy, that we should make interfaces consistent. If we have altp2m_set_mem_access is an HVMOP, then altp2m_set_mem_access_multi should be an HVMOP. If on the other hand we don't want altp2m_set_mem_access_multi as an HVMOP, then we should change altp2m_set_mem_access into a DOMCTL as well. At the moment I prefer the first option, because one of Xen's historical "niches" is support for quirky additional security features. It seems to me that having a functioning, but non-audited / security supported feature in place, such that people can come along and fix it up (rather than implementing it from scratch) puts us in a better position -- providing, of course, that having the functionality available in "tech preview" status doesn't add significant risk to normal users. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 03:05 PM, Jan Beulich wrote: On 11.12.17 at 15:51, wrote: >> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: >>> On 12/11/2017 03:36 PM, Jan Beulich wrote: >>> On 11.12.17 at 13:50, wrote: > On 12/11/2017 12:12 PM, Jan Beulich wrote: > On 11.12.17 at 12:06, wrote: >>> My suggestion was that we don't break usecases. The Intel usecase >>> specifically is for an in-guest entity to have full control of all >>> altp2m functionality, and this is fine (security wise) when permitted to >>> do so by the toolstack. >> >> IOW you mean that such guests would be considered "trusted", i.e. >> whatever bad they can do is by definition not a security concern. > > I'm not sure what you mean by "trusted". If implemented correctly, > altp2m and mem_access shouldn't give the guest any more permissions than > it has already. The main risk would be if there were bugs in the > functionality that allowed security issues. Hmm, maybe I'm mis-reading the code, but mem_access.c:set_mem_access() looks to be using the requested access rights verbatim, i.e. without applying tool stack imposed restrictions (hypervisor ones look to be honored by deriving base permissions from the p2m type first). >>> >>> Quite likely I'm not grasping the full meaning of your objection, >>> however the added code is merely another interface to already existing >>> core code - so while admittedly there's room for improvement for the EPT >>> code below it, this patch really only extends the scope of altp2m's >>> existing version of set_mem_access() (which currently works on a single >>> page). In that, it at least doesn't seem to make things worse (it's >>> really just an optimization - whatever badness this code can cause with >>> a single call, can already be achieved exactly with a sequence of >>> xc_altp2m_set_mem_access() calls). >> >> I think Jan was saying that he would ideally like to remove *all* guest >> access to altp2m functionality, even what's currently there. The more >> extra features we make available to guests, the harder it will be in the >> future to argue to remove it all. > > With one slight correction: all _uncontrolled_ access is what I'd like > to see removed. Right now this could arguably indeed mean all > access, as it is all uncontrolled (afaict). Well at the moment all guest altp2m functionality is disabled unless the toolstack has set the appropriate HVM param. Is that not sufficient? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 05:54 PM, George Dunlap wrote: > On 12/11/2017 03:05 PM, Jan Beulich wrote: > On 11.12.17 at 15:51, wrote: >>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: On 12/11/2017 03:36 PM, Jan Beulich wrote: On 11.12.17 at 13:50, wrote: >> On 12/11/2017 12:12 PM, Jan Beulich wrote: >> On 11.12.17 at 12:06, wrote: My suggestion was that we don't break usecases. The Intel usecase specifically is for an in-guest entity to have full control of all altp2m functionality, and this is fine (security wise) when permitted to do so by the toolstack. >>> >>> IOW you mean that such guests would be considered "trusted", i.e. >>> whatever bad they can do is by definition not a security concern. >> >> I'm not sure what you mean by "trusted". If implemented correctly, >> altp2m and mem_access shouldn't give the guest any more permissions than >> it has already. The main risk would be if there were bugs in the >> functionality that allowed security issues. > > Hmm, maybe I'm mis-reading the code, but > mem_access.c:set_mem_access() looks to be using the requested > access rights verbatim, i.e. without applying tool stack imposed > restrictions (hypervisor ones look to be honored by deriving > base permissions from the p2m type first). Quite likely I'm not grasping the full meaning of your objection, however the added code is merely another interface to already existing core code - so while admittedly there's room for improvement for the EPT code below it, this patch really only extends the scope of altp2m's existing version of set_mem_access() (which currently works on a single page). In that, it at least doesn't seem to make things worse (it's really just an optimization - whatever badness this code can cause with a single call, can already be achieved exactly with a sequence of xc_altp2m_set_mem_access() calls). >>> >>> I think Jan was saying that he would ideally like to remove *all* guest >>> access to altp2m functionality, even what's currently there. The more >>> extra features we make available to guests, the harder it will be in the >>> future to argue to remove it all. >> >> With one slight correction: all _uncontrolled_ access is what I'd like >> to see removed. Right now this could arguably indeed mean all >> access, as it is all uncontrolled (afaict). > > Well at the moment all guest altp2m functionality is disabled unless the > toolstack has set the appropriate HVM param. Is that not sufficient? Furthermore, the parameters allow setting dom0-access only (courtesy of Tamas' aforementioned patches). Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On Mon, Dec 11, 2017 at 8:05 AM, Jan Beulich wrote: On 11.12.17 at 15:51, wrote: >> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: >>> On 12/11/2017 03:36 PM, Jan Beulich wrote: >>> On 11.12.17 at 13:50, wrote: > On 12/11/2017 12:12 PM, Jan Beulich wrote: > On 11.12.17 at 12:06, wrote: >>> My suggestion was that we don't break usecases. The Intel usecase >>> specifically is for an in-guest entity to have full control of all >>> altp2m functionality, and this is fine (security wise) when permitted to >>> do so by the toolstack. >> >> IOW you mean that such guests would be considered "trusted", i.e. >> whatever bad they can do is by definition not a security concern. > > I'm not sure what you mean by "trusted". If implemented correctly, > altp2m and mem_access shouldn't give the guest any more permissions than > it has already. The main risk would be if there were bugs in the > functionality that allowed security issues. Hmm, maybe I'm mis-reading the code, but mem_access.c:set_mem_access() looks to be using the requested access rights verbatim, i.e. without applying tool stack imposed restrictions (hypervisor ones look to be honored by deriving base permissions from the p2m type first). >>> >>> Quite likely I'm not grasping the full meaning of your objection, >>> however the added code is merely another interface to already existing >>> core code - so while admittedly there's room for improvement for the EPT >>> code below it, this patch really only extends the scope of altp2m's >>> existing version of set_mem_access() (which currently works on a single >>> page). In that, it at least doesn't seem to make things worse (it's >>> really just an optimization - whatever badness this code can cause with >>> a single call, can already be achieved exactly with a sequence of >>> xc_altp2m_set_mem_access() calls). >> >> I think Jan was saying that he would ideally like to remove *all* guest >> access to altp2m functionality, even what's currently there. The more >> extra features we make available to guests, the harder it will be in the >> future to argue to remove it all. > > With one slight correction: all _uncontrolled_ access is what I'd like > to see removed. Right now this could arguably indeed mean all > access, as it is all uncontrolled (afaict). > But it is controlled. Unless you specifically allow the guest access to the interface (ie altp2m=1 in the xl config) the guest can't do anything with it. And if you do that, it is likely because you have an in-guest agent that works in tandem with an out-of-guest agent coordinating what to protect and how. You use the in-guest agent for performance-sensitive monitoring while you can use the out-of-guest agent to protect the in-guest agent. Of course, this is not a requirement but what I *think* the setup was that the interface was designed for as there is specific ability to decide which page permission violation goes to the guest (with #VE) and which goes to the toolstack. Plus even if the interface is enabled, it is only available to the guest kernel. If it's a malicious guest kernel the worst it should be able to do is crash itself (for example by allocating a ton of altp2m tables and running out of shadow memory). But I don't think you need the altp2m interface for a guest kernel to crash itself. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On 12/11/2017 06:00 PM, Tamas K Lengyel wrote: >>> I think Jan was saying that he would ideally like to remove *all* guest >>> access to altp2m functionality, even what's currently there. The more >>> extra features we make available to guests, the harder it will be in the >>> future to argue to remove it all. >> >> With one slight correction: all _uncontrolled_ access is what I'd like >> to see removed. Right now this could arguably indeed mean all >> access, as it is all uncontrolled (afaict). >> > > But it is controlled. Unless you specifically allow the guest access > to the interface (ie altp2m=1 in the xl config) the guest can't do > anything with it. And if you do that, it is likely because you have an > in-guest agent that works in tandem with an out-of-guest agent > coordinating what to protect and how. You use the in-guest agent for > performance-sensitive monitoring while you can use the out-of-guest > agent to protect the in-guest agent. Of course, this is not a > requirement but what I *think* the setup was that the interface was > designed for as there is specific ability to decide which page > permission violation goes to the guest (with #VE) and which goes to > the toolstack. Plus even if the interface is enabled, it is only > available to the guest kernel. If it's a malicious guest kernel the > worst it should be able to do is crash itself (for example by > allocating a ton of altp2m tables and running out of shadow memory). > But I don't think you need the altp2m interface for a guest kernel to > crash itself. That's precisely how we envision possible use cases as well. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu wrote: > From: Razvan Cojocaru > > For the default EPT view we have xc_set_mem_access_multi(), which > is able to set an array of pages to an array of access rights with > a single hypercall. However, this functionality was lacking for the > altp2m subsystem, which could only set page restrictions for one > page at a time. This patch addresses the gap. > > HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a > DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and > hence with the original altp2m design, where domains are allowed - with the > proper altp2m access rights - to alter these settings), in the absence of an > official position on the issue from the original altp2m designers. > > Signed-off-by: Razvan Cojocaru > Signed-off-by: Petre Pircalabu FWIW the approach looks good to me here. You mainly need an x86 maintainer's ack and a toolstack maintainer's ack (of which I am neither). -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu wrote: > From: Razvan Cojocaru > > For the default EPT view we have xc_set_mem_access_multi(), which > is able to set an array of pages to an array of access rights with > a single hypercall. However, this functionality was lacking for the > altp2m subsystem, which could only set page restrictions for one > page at a time. This patch addresses the gap. > > HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a > DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and > hence with the original altp2m design, where domains are allowed - with the > proper altp2m access rights - to alter these settings), in the absence of an > official position on the issue from the original altp2m designers. > > Signed-off-by: Razvan Cojocaru > Signed-off-by: Petre Pircalabu FWIW the approach looks good to me here. You mainly need an x86 maintainer's ack and a toolstack maintainer's ack (of which I am neither). -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
>>> On 11.12.17 at 16:54, wrote: > On 12/11/2017 03:05 PM, Jan Beulich wrote: > On 11.12.17 at 15:51, wrote: >>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote: On 12/11/2017 03:36 PM, Jan Beulich wrote: On 11.12.17 at 13:50, wrote: >> On 12/11/2017 12:12 PM, Jan Beulich wrote: >> On 11.12.17 at 12:06, wrote: My suggestion was that we don't break usecases. The Intel usecase specifically is for an in-guest entity to have full control of all altp2m functionality, and this is fine (security wise) when permitted to do so by the toolstack. >>> >>> IOW you mean that such guests would be considered "trusted", i.e. >>> whatever bad they can do is by definition not a security concern. >> >> I'm not sure what you mean by "trusted". If implemented correctly, >> altp2m and mem_access shouldn't give the guest any more permissions than >> it has already. The main risk would be if there were bugs in the >> functionality that allowed security issues. > > Hmm, maybe I'm mis-reading the code, but > mem_access.c:set_mem_access() looks to be using the requested > access rights verbatim, i.e. without applying tool stack imposed > restrictions (hypervisor ones look to be honored by deriving > base permissions from the p2m type first). Quite likely I'm not grasping the full meaning of your objection, however the added code is merely another interface to already existing core code - so while admittedly there's room for improvement for the EPT code below it, this patch really only extends the scope of altp2m's existing version of set_mem_access() (which currently works on a single page). In that, it at least doesn't seem to make things worse (it's really just an optimization - whatever badness this code can cause with a single call, can already be achieved exactly with a sequence of xc_altp2m_set_mem_access() calls). >>> >>> I think Jan was saying that he would ideally like to remove *all* guest >>> access to altp2m functionality, even what's currently there. The more >>> extra features we make available to guests, the harder it will be in the >>> future to argue to remove it all. >> >> With one slight correction: all _uncontrolled_ access is what I'd like >> to see removed. Right now this could arguably indeed mean all >> access, as it is all uncontrolled (afaict). > > Well at the moment all guest altp2m functionality is disabled unless the > toolstack has set the appropriate HVM param. Is that not sufficient? Together with someone enabling it rendering the system unsupported, I can live with that (as said elsewhere). I'm probably just not going to ack any patch similar to the one here (but I won't object to someone else doing so). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.1 test] 117058: trouble: blocked/broken/fail/pass
flight 117058 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117058/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf-xsm broken build-armhf broken build-armhf-pvops 4 host-install(4)broken REGR. vs. 116145 build-i3864 host-install(4)broken REGR. vs. 116145 build-amd64-pvops 4 host-install(4)broken REGR. vs. 116145 build-i386-pvops 4 host-install(4)broken REGR. vs. 116145 build-amd64 4 host-install(4)broken REGR. vs. 116145 build-amd64-xsm 4 host-install(4)broken REGR. vs. 116145 build-i386-xsm4 host-install(4)broken REGR. vs. 116145 build-armhf 4 host-install(4)broken REGR. vs. 116145 build-armhf-xsm 4 host-install(4)broken REGR. vs. 116145 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-a
Re: [Xen-devel] [PATCH v5 0/4] xenfb: Enablement for Windows PV HID frontend
On Fri, Nov 03, 2017 at 11:56:27AM +, Owen Smith wrote: > Improve the input device model in xenfb, by updating the > Qemu input handlers and adding a feature to allow for > raw (unscaled) absolute coordinates to be represented. > > Changes: > * use keycodedb to generate qcode to linux input mapping > * move rescaling to the mouse_event handler > * add activate for raw_pointer devices > > Owen Smith (3): > ui: generate qcode to linux mappings > xenfb: Use Input Handlers directly > xenfb: Add [feature|request]-raw-pointer > xenfb: activate input handlers for raw pointer devices The patch series looks good to me: Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 117061: trouble: blocked/broken/pass
flight 117061 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117061/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf-xsm broken build-armhf broken build-armhf 4 host-install(4)broken REGR. vs. 117011 build-armhf-pvops 4 host-install(4)broken REGR. vs. 117011 build-amd64 4 host-install(4)broken REGR. vs. 117011 build-amd64-pvops 4 host-install(4)broken REGR. vs. 117011 build-i3864 host-install(4)broken REGR. vs. 117011 build-i386-xsm4 host-install(4)broken REGR. vs. 117011 build-i386-pvops 4 host-install(4)broken REGR. vs. 117011 build-amd64-xsm 4 host-install(4)broken REGR. vs. 117011 build-armhf-xsm 4 host-install(4)broken REGR. vs. 117011 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-a
Re: [Xen-devel] [PATCH v3 2/3] xen/pt: Pass the whole msi addr/data to Xen
On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote:
> Previously, some fields (reserved or unalterable) are filtered by
> Qemu. This fields are useless for the legacy interrupt format.
> However, these fields are may meaningful (for intel platform)
> for the interrupt of remapping format. It is better to pass the whole
> msi addr/data to Xen without any filtering.
>
> The main reason why we want this is QEMU doesn't have the knowledge
> to decide the interrupt format after we introduce vIOMMU inside Xen.
> Passing the whole msi message down and let arch-specific vIOMMU to
> decide the interrupt format.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> v3:
> - new
> ---
> hw/xen/xen_pt_msi.c | 47 ---
> 1 file changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
> index 6d1e3bd..f7d6e76 100644
> --- a/hw/xen/xen_pt_msi.c
> +++ b/hw/xen/xen_pt_msi.c
> @@ -47,25 +47,6 @@ static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
> return addr_hi & 0xff00;
> }
>
> -static uint32_t msi_gflags(uint32_t data, uint64_t addr)
> -{
> -uint32_t result = 0;
> -int rh, dm, dest_id, deliv_mode, trig_mode;
> -
> -rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
> -dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
> -dest_id = msi_dest_id(addr);
> -deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
> -trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> -
> -result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
> -| (dm << XEN_PT_GFLAGS_SHIFT_DM)
> -| (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
> -| (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
> -
> -return result;
> -}
> -
> static inline uint64_t msi_addr64(XenPTMSI *msi)
> {
> return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
> @@ -160,23 +141,20 @@ static int msi_msix_update(XenPCIPassthroughState *s,
> bool masked)
> {
> PCIDevice *d = &s->dev;
> -uint8_t gvec = msi_vector(data);
> -uint32_t gflags = msi_gflags(data, addr);
> +uint32_t gflags = masked ? 0 : (1u << XEN_PT_GFLAGSSHIFT_UNMASKED);
> int rc = 0;
> uint64_t table_addr = 0;
>
> -XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
> - " (entry: %#x)\n",
> - is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
> +XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x addr %"PRIx64
> + " data %#x gflags %#x (entry: %#x)\n",
> + is_msix ? "-X" : "", pirq, addr, data, gflags, msix_entry);
>
> if (is_msix) {
> table_addr = s->msix->mmio_base_addr;
> }
>
> -gflags |= masked ? 0 : (1u << XEN_PT_GFLAGSSHIFT_UNMASKED);
> -
> -rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
> - pirq, gflags, table_addr);
> +rc = xc_domain_update_msi_irq(xen_xc, xen_domid, pirq, addr,
> + data, gflags, table_addr);
Are you trying to modifie an existing API? That is not going to work. We
want to be able to build QEMU against older version of Xen, and it
should work as well.
>
> if (rc) {
> XEN_PT_ERR(d, "Updating of MSI%s failed. (err: %d)\n",
> @@ -199,8 +177,6 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
> bool is_binded)
> {
> PCIDevice *d = &s->dev;
> -uint8_t gvec = msi_vector(data);
> -uint32_t gflags = msi_gflags(data, addr);
> int rc = 0;
>
> if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
> @@ -208,12 +184,13 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
> }
>
> if (is_binded) {
> -XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
> - is_msix ? "-X" : "", pirq, gvec);
> -rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
> +XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, addr %"PRIx64", data
> %#x\n",
> + is_msix ? "-X" : "", pirq, addr, data);
> +rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, pirq, addr, data);
Same here, this build against older version of Xen, but I don't think an
older libxc (like from Xen 4.10) is going to correctly with this new
arguments.
> if (rc) {
> -XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: %d,
> gvec: %#x)\n",
> - is_msix ? "-X" : "", errno, pirq, gvec);
> +XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: %d, "
> + "addr: %"PRIx64", data: %#x)\n",
> + is_msix ? "-X" : "", errno, pirq, addr, data);
> return rc;
> }
> }
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request
On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote:
> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
> Interrupt Remapping -> Interrupt Request Formats On Intel 64
> Platforms, fields of MSI data register have changed. This patch
> avoids wrongly regarding a remappable format interrupt request as
> an interrupt binded with a pirq.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> v3:
> - clarify the interrupt format bit is Intel-specific, then it is
> improper to define MSI_ADDR_IF_MASK in a common header.
> ---
> hw/i386/xen/xen-hvm.c | 10 +-
> hw/pci/msi.c | 5 +++--
> hw/pci/msix.c | 4 +++-
> hw/xen/xen_pt_msi.c | 2 +-
> include/hw/xen/xen.h | 2 +-
> stubs/xen-hvm.c | 2 +-
> 6 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index 8028bed..52dc8af 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -145,8 +145,16 @@ void xen_piix_pci_write_config_client(uint32_t address,
> uint32_t val, int len)
> }
> }
>
> -int xen_is_pirq_msi(uint32_t msi_data)
> +int xen_is_pirq_msi(uint32_t msi_addr_lo, uint32_t msi_data)
> {
> +/* If the MSI address is configured in remapping format, the MSI will not
> + * be remapped into a pirq. This 'if' test excludes Intel-specific
> + * remappable msi.
> + */
> +#define MSI_ADDR_IF_MASK 0x0010
I don't think that is the right place for a define, they also exist
outside of the context of the function.
That define would be better at the top of this file, I think. (There is
probably a better place in the common headers, but I'm not sure were.)
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 117059: trouble: blocked/broken/fail/pass
flight 117059 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117059/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf-xsm broken build-armhf broken build-armhf-pvops 4 host-install(4)broken REGR. vs. 116920 build-armhf 4 host-install(4)broken REGR. vs. 116920 build-amd64-xsm 4 host-install(4)broken REGR. vs. 116920 build-amd64-pvops 4 host-install(4)broken REGR. vs. 116920 build-amd64 4 host-install(4)broken REGR. vs. 116920 build-i386-pvops 4 host-install(4)broken REGR. vs. 116920 build-i386-xsm4 host-install(4)broken REGR. vs. 116920 build-i3864 host-install(4)broken REGR. vs. 116920 build-armhf-xsm 4 host-install(4)broken REGR. vs. 116920 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd6
[Xen-devel] [linux-linus test] 117062: trouble: blocked/broken/pass
flight 117062 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/117062/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386 broken build-armhf-pvopsbroken test-arm64-arm64-libvirt-xsm broken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf-xsm broken build-armhf broken test-arm64-arm64-xl-xsm broken build-armhf-pvops 4 host-install(4)broken REGR. vs. 115643 build-i3864 host-install(4)broken REGR. vs. 115643 build-amd64-xsm 4 host-install(4)broken REGR. vs. 115643 build-amd64 4 host-install(4)broken REGR. vs. 115643 build-i386-pvops 4 host-install(4)broken REGR. vs. 115643 build-amd64-pvops 4 host-install(4)broken REGR. vs. 115643 build-i386-xsm4 host-install(4)broken REGR. vs. 115643 build-armhf-xsm 4 host-install(4)broken REGR. vs. 115643 build-armhf 4 host-install(4)broken REGR. vs. 115643 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1
[Xen-devel] [seabios test] 117056: trouble: blocked/broken
flight 117056 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/117056/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64 broken build-i386-pvops broken build-amd64-xsm 4 host-install(4)broken REGR. vs. 115539 build-i386-xsm4 host-install(4)broken REGR. vs. 115539 build-i386-pvops 4 host-install(4)broken REGR. vs. 115539 build-amd64 4 host-install(4)broken REGR. vs. 115539 build-amd64-pvops 4 host-install(4)broken REGR. vs. 115539 build-i3864 host-install(4)broken REGR. vs. 115539 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a version targeted for testing: seabios 844b86464a5cbfffb62b87808632018ca250d867 baseline version: seabios 0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea Last test of basis 115539 2017-11-03 20:48:58 Z 37 days Failing since115733 2017-11-10 17:19:59 Z 31 days 48 attempts Testing same since 117014 2017-12-08 19:11:23 Z2 days3 attempts People who touched revisions under test: Kevin O'Connor Paul Menzel Stefan Berger jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-qemuu-nested-amdblocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-win10-i386 blocked test-amd64-i386-xl-qemuu-win10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
Hi,
On 12/10/2017 03:22 PM, Tim Deegan wrote:
At 14:38 + on 08 Dec (1512743913), Julien Grall wrote:
On 08/12/17 08:03, Tim Deegan wrote:
+1 for avoiding the full majesty of PoD if you don't need it.
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entries
but only making them usable by the {IO}MMUs on first access. That
would make these early p2m walks shorter (because they can skip whole
subtrees that aren't marked present yet) without making major changes
to domain build or introducing run-time failures.
I am not aware of any way on Arm to misconfigure an entry. We do have
valid and access bits, although they will affect the IOMMU as well. So
it will not be possible to get page-table sharing with this "feature"
enabled.
How unfortunate. How does KVM's demand-population scheme handle the IOMMU?
From what I have heard, when using IOMMU all the memory is pinned. They
also don't share page-tables.
But I am not a KVM expert, maybe Andre/Marc can confirm here?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 117057: trouble: blocked/broken
flight 117057 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117057/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken test-arm64-arm64-xl-xsm broken build-armhf broken build-armhf 4 host-install(4)broken REGR. vs. 116956 build-amd64 4 host-install(4)broken REGR. vs. 116956 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9 baseline version: xen 43550972395f9a3a48bb4086a0faf0f8d442e37d Last test of basis 116956 2017-12-07 23:02:27 Z3 days Testing same since 117015 2017-12-08 22:03:21 Z2 days8 attempts People who touched revisions under test: Andre Przywara Andre Przywara Julien Grall Julien Grall Stefano Stabellini jobs: build-amd64 broken build-armhf broken build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-amd64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-armhf broken broken-step build-armhf host-install(4) broken-step build-amd64 host-install(4) Not pushing. commit 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9 Author: Andre Przywara Date: Thu Dec 7 16:14:08 2017 + ARM: VGIC: move gic_remove_irq_from_queues() gic_remove_irq_from_queues() was not only misnamed, it also has the wrong abstraction, as it should not live in gic.c. Move it into vgic.c and vgic.h, where it belongs to, and rename it on the way. Signed-off-by: Andre Przywara Reviewed-by: Stefano Stabellini commit 9630c5ae363b4cbf8eb61366530f40c80680af4d Author: Julien Grall Date: Wed Dec 6 14:51:37 2017 + xen/arm: gic-v3: Bail out if gicv3_cpu_init fail When system registers are not enabled, all the access to them will trap in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only on success. As the rest of the code (e.g gicv3_hyp_init) relies on system register, it is better to bail out directly. This will save time on debugging early boot issue on GICv3 platform. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini commit ac2d8d402370f6f93f82871f3b34ddb9a9ccae05 Author: Julien Grall Date: Wed Nov 29 17:46:35 2017 + xen/arm: Surround HSR_SYSREG macro value with () The value of the macro HCR_SYSREG is not surrounded by (). This means the behavior may change depend on how it is used. Thanksfully recent GCC will issue a warning for that. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini commit b819187a15ecea7fe00cffded1bf454b8a6d7dd2 Author: Andre Przywara Date: Thu Oct 19 13:48:37 2017 +0100 ARM: vGIC: fix nr_irq definition The global variable "nr_irqs" is used for x86 and some common Xen code. To make the latter work easily for ARM, it was #defined to NR_IRQS. This not only violated the common habit of capitalizing macros, but also caused issues if one wanted to use a rather innocent "nr_irqs" as a local variable name or as a function parameter. Drop the optimization and make nr_irqs a normal variable for ARM also. Signed-off-by: Andre Przywara commit 2e9b1c655f060b5c4e68bc8499f02253babe1bbc Author: An
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
Hi Jan,
On 12/11/2017 10:06 AM, Jan Beulich wrote:
On 08.12.17 at 15:38, wrote:
On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entries
but only making them usable by the {IO}MMUs on first access. That
would make these early p2m walks shorter (because they can skip whole
subtrees that aren't marked present yet) without making major changes
to domain build or introducing run-time failures.
I am not aware of any way on Arm to misconfigure an entry. We do have
valid and access bits, although they will affect the IOMMU as well. So
it will not be possible to get page-table sharing with this "feature"
enabled.
How would you intend to solve the IOMMU part of the problem with
PoD? As was pointed out before - IOMMU and PoD are incompatible
on x86.
I am not sure why you ask about PoD here when I acknowledge I will look
at a different solution. And again, misconfiguring an entry is not
possible on Arm.
But to answer your question, IOMMU will neither be supported with PoD
nor access/valid bit solution. And that's fine because S/W are not
easily virtualizable, I take that as a hint for "All the features may
not be available when using S/W in a guest".
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
On 12/11/2017 11:10 AM, Andre Przywara wrote: Hi, Hi Andre, But on the other hand we had PoD naturally already in KVM, so this came at no cost. So I believe it would be worth to investigate what the actual impact is on booting a 32-bit kernel, with emulating s/w ops like KVM does (see below), but cleaning the *whole VA space*. If this is somewhat acceptable (I assume we have no more than 2GB for a typical ARM32 guest), it might be worth to ignore PoD, at least for now and to solve this problem (and the IOMMU consequences). I am fairly surprised you think I came up with this solution without any investigation. I actually clearly stated it in my first e-mail that Linux is not able to bring up CPU with a flush of the "whole VA space". At the moment, Linux 32-bit as a 1 second timeout to bring up a secondary CPU. In that second we need to do at least a full flush (I think there are a second). In the case of Xen Arm32, the domain heap (where domain memory belongs) is not mapped in the hypervisor. So you end up to do mapping for every page-table and final memory. To that, you add the cost of doing cache maintenance. Then, you finally add the potential cost preemption (vCPU might be schedule out). During my initial investigation, I was not able to boot Dom0 with 512MB. I tried to optimize the mapping path, but it didn't show much improvement in general. Regarding the IOMMU consequences, S/W ops are not easily virtualizable. If you use them, then it is the price to pay. It is better than not been able to boot current kernel or randomly crashing. Cheers, -- Julien Grall, ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct
On 08/12/2017 09:49, Jan Beulich wrote: >> + * The layout of each entry in the memory map table is as follows and no >> + * padding is used between entries in the array: >> + * >> + * 0 ++ >> + *| addr | Base address >> + * 8 ++ >> + *| size | Size of mapping >> + * 16 ++ >> + *| type | E820_TYPE_xxx >> + * 20 +| > I'm not convinced of re-using E820 types here. I can see that this > might ease the consumption in Linux, but I don't think there should > be any connection to x86 aspects here - the data being supplied is > x86-agnostic, and Linux'es placement of the header is also making > no connection to x86 (oddly enough, the current placement in the > Xen tree does, for a reason which escapes me). FWIW, e820 types are now part of the ACPI standard. So using them is not necessarily related to x86, and reasonably x86-agnostic. Paolo > I could also imagine reasons to add new types without them being > sanctioned by whoever maintains E820 type assignments. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 117082: trouble: blocked/broken
flight 117082 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117082/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken test-arm64-arm64-xl-xsm broken build-armhf broken build-armhf 4 host-install(4)broken REGR. vs. 116956 build-amd64 4 host-install(4)broken REGR. vs. 116956 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9 baseline version: xen 43550972395f9a3a48bb4086a0faf0f8d442e37d Last test of basis 116956 2017-12-07 23:02:27 Z3 days Testing same since 117015 2017-12-08 22:03:21 Z3 days9 attempts People who touched revisions under test: Andre Przywara Andre Przywara Julien Grall Julien Grall Stefano Stabellini jobs: build-amd64 broken build-armhf broken build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-amd64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-armhf broken broken-step build-armhf host-install(4) broken-step build-amd64 host-install(4) Not pushing. commit 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9 Author: Andre Przywara Date: Thu Dec 7 16:14:08 2017 + ARM: VGIC: move gic_remove_irq_from_queues() gic_remove_irq_from_queues() was not only misnamed, it also has the wrong abstraction, as it should not live in gic.c. Move it into vgic.c and vgic.h, where it belongs to, and rename it on the way. Signed-off-by: Andre Przywara Reviewed-by: Stefano Stabellini commit 9630c5ae363b4cbf8eb61366530f40c80680af4d Author: Julien Grall Date: Wed Dec 6 14:51:37 2017 + xen/arm: gic-v3: Bail out if gicv3_cpu_init fail When system registers are not enabled, all the access to them will trap in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only on success. As the rest of the code (e.g gicv3_hyp_init) relies on system register, it is better to bail out directly. This will save time on debugging early boot issue on GICv3 platform. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini commit ac2d8d402370f6f93f82871f3b34ddb9a9ccae05 Author: Julien Grall Date: Wed Nov 29 17:46:35 2017 + xen/arm: Surround HSR_SYSREG macro value with () The value of the macro HCR_SYSREG is not surrounded by (). This means the behavior may change depend on how it is used. Thanksfully recent GCC will issue a warning for that. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini commit b819187a15ecea7fe00cffded1bf454b8a6d7dd2 Author: Andre Przywara Date: Thu Oct 19 13:48:37 2017 +0100 ARM: vGIC: fix nr_irq definition The global variable "nr_irqs" is used for x86 and some common Xen code. To make the latter work easily for ARM, it was #defined to NR_IRQS. This not only violated the common habit of capitalizing macros, but also caused issues if one wanted to use a rather innocent "nr_irqs" as a local variable name or as a function parameter. Drop the optimization and make nr_irqs a normal variable for ARM also. Signed-off-by: Andre Przywara commit 2e9b1c655f060b5c4e68bc8499f02253babe1bbc Author: An
Re: [Xen-devel] [RFC] xen/arm: Suspend to RAM Support in Xen for ARM
On Wed, 9 Aug 2017, Mirela Simonovic wrote: > This document contains our draft proposal for implementing "suspend to RAM" > support for ARM in Xen, as discussed during the last Xen ARM community call. > It covers the basic suspend to RAM mechanism based on ARM PSCI standard, > that would allow individual guests and Xen itself to suspend. > > We would appreciate your feedback. > > Signed-off-by: Mirela Simonovic I am really sorry, for the very late reply. This email fell through the cracks. In general, if I forget about an email, please send a follow up to help me remember :-) Do you have an more up-to-date proposal or is this still the latest? From an high level, it looks good, only one minor comment: don't call it "hotplug" because usually in the Xen community hotplug means adding more vcpus or removing vcpus at runtime (removing entirely, not suspending). But the approach looks good to me. > --- > docs/misc/arm/suspend-to-ram.txt | 210 > +++ > 1 file changed, 210 insertions(+) > create mode 100644 docs/misc/arm/suspend-to-ram.txt > > diff --git a/docs/misc/arm/suspend-to-ram.txt > b/docs/misc/arm/suspend-to-ram.txt > new file mode 100644 > index 00..ec8080fc64 > --- /dev/null > +++ b/docs/misc/arm/suspend-to-ram.txt > @@ -0,0 +1,210 @@ > +% Suspend to RAM Support in Xen for ARM > +% Revision 1.0 > + > + > +Overview > + > + > +Suspend to RAM (in the following text 'suspend') for ARM in Xen should be > +coordinated using ARM PSCI standard [1]. > + > +EL1/2 should suspend in the following order: > +1) Unprivileged guests (DomUs) suspend > +2) Privileged guest (Dom0) suspends > +3) Xen suspends > + > +Since this proposal is focused on implementing PSCI-based suspend mechanisms > in > +Xen, communication with or among the guests is not covered by this document. > +The order of suspending the guests is assumed to be guaranteed by the > software > +running in EL1. > + > +- > +Suspending Guests > +- > + > +Suspend procedure for a guest consists of the following: > +1) Suspending devices > +2) Suspending non-boot CPUs > +3) System suspend, performed by the boot CPU > + > +Each guest should suspend the devices it owns. Suspending of devices is not > +covered by this document. The document covers only mechanisms for suspending > +non-boot CPUs, as well as the system suspend. > + > +Guests should suspend their non-boot vCPUs using the hotplug mechanism. > +Virtual CPUs should be put offline using the already implemented PSCI > vCPU_OFF > +call (prefix 'v' is added to distinguish PSCI calls made by guests to Xen, > which > +affect virtual machines; as opposed to PSCI calls made by Xen to the EL3, > which > +can affect power state of the physical machine). > + > +After suspending its non-boot vCPUs a guest should finalize the suspend by > +making the vSYSTEM_SUSPEND PSCI call. The resume address is specified by the > +guest via the vSYSTEM_SUSPEND entry_point_address argument. The > vSYSTEM_SUSPEND > +call is currently not implemented in Xen. > + > +It is expected that a guest leaves enabled all interrupts that should wake it > +up. Other interrupts should be disabled by the guest prior to calling > +vSYSTEM_SUSPEND. > + > +After an unprivileged guest suspends, Xen will not suspend. Xen would suspend > +only after the Dom0 completes the system suspend. > + > +-- > +Suspending Xen > +-- > + > +Xen should start suspending itself upon receiving the vSYSTEM_SUSPEND call > +from the last running guest (Dom0). At that moment all physical CPUs are > still > +online (taking offline a vCPU or suspending a VM does not affect physical > CPUs). > +Xen shall now put offline the non-boot pCPUs by making the CPU_OFF PSCI call > +to EL3. The CPU_OFF PSCI function is currently not implemented in Xen. > + > +After putting offline the non-boot cores Xen must save the context and > finalize > +suspend by invoking SYSTEM_SUSPEND PSCI call, which is passed to EL3. > +The resume point of Xen is specified by the entry_point_address argument of > the > +SYSTEM_SUSPEND call. The SYSTEM_SUSPEND function and context saving is not > +implemented in Xen for ARM today. > + > + > +Resuming Xen > + > + > +Xen must be resumed prior to any software running in EL1. Starting from the > +resume point, Xen should restore the context and resume Dom0. Dom0 shall > always > +be resumed whenever Xen resumes. > +The whole Xen resume flow for the ARM architecture has to be implemented. > + > +--- > +Resuming Guests > +--- > + > +Resume of the privileged guest (Dom0) is always following the Xen resume. > + > +An unprivileged guest shall resume once a device it owns triggers a wake-up > +interrupt, regardless of whether Xen was suspended when the wake-up interrupt > +was triggered. If Xen was suspended, it is assumed that Dom0 will be running > +before the DomU guest starts to r
Re: [Xen-devel] [PATCH v3 for-next 1/4] xen/arm: domain_build: Clean-up insert_11_bank
On Wed, 1 Nov 2017, Julien Grall wrote:
> - Remove spurious ()
> - Add missing spaces
> - Turn 1 << to 1UL <<
> - Rename spfn to smfn and switch to mfn_t
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
>
> Cc: Stefano Stabellini
>
> Changes in v2:
> - Remove double space
> - s/spfn/smfn/ and switch to mfn_t
> ---
> xen/arch/arm/domain_build.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bf29299707..5532068ab1 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -50,6 +50,8 @@ struct map_range_data
> /* Override macros from asm/page.h to make them work with mfn_t */
> #undef virt_to_mfn
> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> +#undef page_to_mfn
> +#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
>
> //#define DEBUG_11_ALLOCATION
> #ifdef DEBUG_11_ALLOCATION
> @@ -104,16 +106,16 @@ static bool insert_11_bank(struct domain *d,
> unsigned int order)
> {
> int res, i;
> -paddr_t spfn;
> +mfn_t smfn;
> paddr_t start, size;
>
> -spfn = page_to_mfn(pg);
> -start = pfn_to_paddr(spfn);
> -size = pfn_to_paddr((1 << order));
> +smfn = page_to_mfn(pg);
> +start = mfn_to_maddr(smfn);
> +size = pfn_to_paddr(1UL << order);
>
> D11PRINT("Allocated %#"PRIpaddr"-%#"PRIpaddr" (%ldMB/%ldMB, order %d)\n",
> start, start + size,
> - 1UL << (order+PAGE_SHIFT-20),
> + 1UL << (order + PAGE_SHIFT - 20),
> /* Don't want format this as PRIpaddr (16 digit hex) */
> (unsigned long)(kinfo->unassigned_mem >> 20),
> order);
> @@ -126,7 +128,7 @@ static bool insert_11_bank(struct domain *d,
> goto fail;
> }
>
> -res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
> +res = guest_physmap_add_page(d, _gfn(mfn_x(smfn)), smfn, order);
> if ( res )
> panic("Failed map pages to DOM0: %d", res);
>
> @@ -167,7 +169,8 @@ static bool insert_11_bank(struct domain *d,
> */
> if ( start + size < bank->start && kinfo->mem.nr_banks <
> NR_MEM_BANKS )
> {
> -memmove(bank + 1, bank, sizeof(*bank)*(kinfo->mem.nr_banks - i));
> +memmove(bank + 1, bank,
> +sizeof(*bank) * (kinfo->mem.nr_banks - i));
> kinfo->mem.nr_banks++;
> bank->start = start;
> bank->size = size;
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 for-next 2/4] xen/arm32: mm: Rework is_xen_heap_page to avoid nameclash
On Wed, 1 Nov 2017, Julien Grall wrote:
> The arm32 version of the function is_xen_heap_page currently define a
> variable _mfn. This will lead to a compiler when use typesafe MFN in a
> follow-up patch:
>
> called object '_mfn' is not a function or function pointer
>
> Fix it by renaming the local variable _mfn to mfn_.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
>
> Cc: Stefano Stabellini
>
> Changes in v3:
> - Fix typo in the commit message
> ---
> xen/include/asm-arm/mm.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index cd6dfb54b9..737a429409 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -140,9 +140,9 @@ extern vaddr_t xenheap_virt_start;
> #ifdef CONFIG_ARM_32
> #define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
> #define is_xen_heap_mfn(mfn) ({ \
> -unsigned long _mfn = (mfn); \
> -(_mfn >= mfn_x(xenheap_mfn_start) &&\
> - _mfn < mfn_x(xenheap_mfn_end));\
> +unsigned long mfn_ = (mfn); \
> +(mfn_ >= mfn_x(xenheap_mfn_start) &&\
> + mfn_ < mfn_x(xenheap_mfn_end));\
> })
> #else
> #define is_xen_heap_page(page) ((page)->count_info & PGC_xen_heap)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 for-next 4/4] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN
On Wed, 1 Nov 2017, Julien Grall wrote: > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make __page_to_mfn and __mfn_to_page return mfn_t by default. > > Only reasonable clean-ups are done in this patch because it is > already quite big. So some of the files now override page_to_mfn and > mfn_to_page to avoid using mfn_t. > > Lastly, domain_page_to_mfn is also converted to use mfn_t given that > most of the callers are now switched to _mfn(domain_page_to_mfn(...)). > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > > Andrew suggested to drop IS_VALID_PAGE in xen/tmem_xen.h. His comment > was: > > "/sigh This is tautological. The definition of a "valid mfn" in this > case is one for which we have frametable entry, and by having a struct > page_info in our hands, this is by definition true (unless you have a > wild pointer, at which point your bug is elsewhere). > > IS_VALID_PAGE() is only ever used in assertions and never usefully, so > instead I would remove it entirely rather than trying to fix it up." > > I can remove the function in a separate patch at the begining of the > series if Konrad (TMEM maintainer) is happy with that. > > Cc: Stefano Stabellini > Cc: Julien Grall > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Tim Deegan > Cc: Wei Liu > Cc: Razvan Cojocaru > Cc: Tamas K Lengyel > Cc: Paul Durrant > Cc: Boris Ostrovsky > Cc: Suravee Suthikulpanit > Cc: Jun Nakajima > Cc: Kevin Tian > Cc: George Dunlap > Cc: Gang Wei > Cc: Shane Wang > > Changes in v3: > - Rebase on the latest staging and fix some conflicts. Tags > haven't be retained. > - Switch the printf format to PRI_mfn > > Changes in v2: > - Some part have been moved in separate patch > - Remove one spurious comment > - Convert domain_page_to_mfn to use mfn_t > --- > xen/arch/arm/domain_build.c | 2 -- > xen/arch/arm/kernel.c | 2 +- > xen/arch/arm/mem_access.c | 2 +- > xen/arch/arm/mm.c | 8 > xen/arch/arm/p2m.c | 10 ++ > xen/arch/x86/cpu/vpmu.c | 4 ++-- > xen/arch/x86/domain.c | 21 +++-- > xen/arch/x86/domain_page.c | 6 +++--- > xen/arch/x86/domctl.c | 2 +- > xen/arch/x86/hvm/dm.c | 2 +- > xen/arch/x86/hvm/dom0_build.c | 6 +++--- > xen/arch/x86/hvm/emulate.c | 6 +++--- > xen/arch/x86/hvm/hvm.c | 16 > xen/arch/x86/hvm/ioreq.c| 6 +++--- > xen/arch/x86/hvm/stdvga.c | 2 +- > xen/arch/x86/hvm/svm/svm.c | 4 ++-- > xen/arch/x86/hvm/viridian.c | 6 +++--- > xen/arch/x86/hvm/vmx/vmcs.c | 2 +- > xen/arch/x86/hvm/vmx/vmx.c | 10 +- > xen/arch/x86/hvm/vmx/vvmx.c | 6 +++--- > xen/arch/x86/mm.c | 6 -- > xen/arch/x86/mm/guest_walk.c| 6 +++--- > xen/arch/x86/mm/hap/guest_walk.c| 2 +- > xen/arch/x86/mm/hap/hap.c | 6 -- > xen/arch/x86/mm/hap/nested_ept.c| 2 +- > xen/arch/x86/mm/mem_sharing.c | 5 - > xen/arch/x86/mm/p2m-ept.c | 4 > xen/arch/x86/mm/p2m-pod.c | 6 -- > xen/arch/x86/mm/p2m.c | 6 -- > xen/arch/x86/mm/paging.c| 6 -- > xen/arch/x86/mm/shadow/private.h| 16 ++-- > xen/arch/x86/numa.c | 2 +- > xen/arch/x86/physdev.c | 2 +- > xen/arch/x86/pv/callback.c | 6 -- > xen/arch/x86/pv/descriptor-tables.c | 10 -- > xen/arch/x86/pv/dom0_build.c| 6 ++ > xen/arch/x86/pv/domain.c| 6 -- > xen/arch/x86/pv/emul-gate-op.c | 6 -- > xen/arch/x86/pv/emul-priv-op.c | 10 -- > xen/arch/x86/pv/grant_table.c | 6 -- > xen/arch/x86/pv/ro-page-fault.c | 6 -- > xen/arch/x86/smpboot.c | 6 -- > xen/arch/x86/tboot.c| 4 ++-- > xen/arch/x86/traps.c| 4 ++-- > xen/arch/x86/x86_64/mm.c| 6 ++ > xen/common/domain.c | 4 ++-- > xen/common/grant_table.c| 6 ++ > xen/common/kimage.c | 6 -- > xen/common/memory.c | 6 ++ > xen/common/page_alloc.c | 6 ++ > xen/common/tmem.c | 2 +- > xen/common/tmem_xen.c | 4 > xen/common/trace.c | 6 ++ > xen/common/vmap.c
Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN
On Thu, 9 Nov 2017, Jan Beulich wrote: > >>> On 09.11.17 at 16:48, wrote: > > On 09/11/17 15:47, Jan Beulich wrote: > > On 09.11.17 at 16:39, wrote: > >>> What I meant is you would replace the 4 occurrences by > >>> mfn_to_page(_mfn(...)). If you are happy with that, then fine. > >> > >> Oh, sure, that's a fine intermediate state, which we have all over > >> the place right now. It's clear that it'll take a while to fully carry > >> through typesafeness to everywhere. > > > > Would you be fine with other part of Xen too? If so, I can have a go at > > removing completely __page_to_mfn/__mfn_to_page. > > Oh, if you want to go that extra mile, that's certainly fine with me. FYI I committed the first two patches (which are ARM only). I'll leave to other to commit the other two. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN
Hi Stefano, On 12/11/2017 11:37 PM, Stefano Stabellini wrote: On Thu, 9 Nov 2017, Jan Beulich wrote: On 09.11.17 at 16:48, wrote: On 09/11/17 15:47, Jan Beulich wrote: On 09.11.17 at 16:39, wrote: What I meant is you would replace the 4 occurrences by mfn_to_page(_mfn(...)). If you are happy with that, then fine. Oh, sure, that's a fine intermediate state, which we have all over the place right now. It's clear that it'll take a while to fully carry through typesafeness to everywhere. Would you be fine with other part of Xen too? If so, I can have a go at removing completely __page_to_mfn/__mfn_to_page. Oh, if you want to go that extra mile, that's certainly fine with me. FYI I committed the first two patches (which are ARM only). I'll leave to other to commit the other two. Thank you! The rest of the series is going to be reworked to fully drop __page_to_mfn/__mfn_to_page. Not sure I will resend it though. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
Hi Stefano,
On 12/08/2017 10:43 PM, Stefano Stabellini wrote:
On Fri, 8 Dec 2017, Julien Grall wrote:
On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 06/12/17 12:27, Julien Grall wrote:
> > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > > Hi Andrew,
> > > >
> > > > On 23/11/17 18:49, Andrew Cooper wrote:
> > > > > On 23/11/17 18:32, Julien Grall wrote:
> > > > > > This new function will be used in a follow-up patch to copy
data to
> > > > > > the
> > > > > > guest
> > > > > > using the IPA (aka guest physical address) and then clean
the cache.
> > > > > >
> > > > > > Signed-off-by: Julien Grall
> > > > > > ---
> > > > > > xen/arch/arm/guestcopy.c | 10 ++
> > > > > > xen/include/asm-arm/guest_access.h | 6 ++
> > > > > > 2 files changed, 16 insertions(+)
> > > > > >
> > > > > > diff --git a/xen/arch/arm/guestcopy.c
b/xen/arch/arm/guestcopy.c
> > > > > > index be53bee559..7958663970 100644
> > > > > > --- a/xen/arch/arm/guestcopy.c
> > > > > > +++ b/xen/arch/arm/guestcopy.c
> > > > > > @@ -110,6 +110,16 @@ unsigned long raw_copy_from_guest(void
*to,
> > > > > > const
> > > > > > void __user *from, unsigned le
> > > > > > COPY_from_guest | COPY_linear);
> > > > > > }
> > > > > > +unsigned long copy_to_guest_phys_flush_dcache(struct
domain *d,
> > > > > > + paddr_t gpa,
> > > > > > + void *buf,
> > > > > > + unsigned int
len)
> > > > > > +{
> > > > > > + /* P2M is shared between all vCPUs, so the vCPU used
does not
> > > > > > matter.
> > > > > > */
> > > > >
> > > > > Be very careful with this line of thinking. It is only works
after
> > > > > DOMCTL_max_vcpus has succeeded, and before that point, it is a
latent
> > > > > NULL pointer dereference.
> > > >
> > > > I really don't expect that function been used before
DOMCT_max_vcpus is
> > > > set.
> > > > It is only used for hardware emulation or Xen loading image into
the
> > > > hardware
> > > > domain memory. I could add a check d->vcpus to be safe.
> > > >
> > > > >
> > > > > Also, what about vcpus configured with alternative views?
> > > >
> > > > It is not important because the underlying call is
get_page_from_gfn
> > > > that does
> > > > not care about the alternative view (that function take a domain
in
> > > > parameter). I can update the comment.
> > > Since this is a new function, would it make sense to take a struct
> > > vcpu* as parameter, instead of a struct domain* ?
> >
> > Well, I suggested this patch this way because likely everyone will
use with
> > d->vcpus[0]. And then you would have to wonder why d->vcpus[0] and
not
> > d->vcpus[1]...
>
> Thinking a bit more to this, it might be better/safer to pass either a
domain
> or a vCPU to copy_guest. I can see 2 solutions:
> 1# Introduce a union that use the same parameter:
> union
> {
> struct
> {
> struct domain *d;
> } ipa;
> struct
> {
> struct vcpu *v;
> } gva;
> }
> The structure here would be to ensure that it is clear that
only
> domain (resp. vcpu) should be used with ipa (resp. gva).
>
> 2# Have 2 parameters, vcpu and domain.
>
> Any opinions?
I think that would be clearer. You could also add a paddr_t/vaddr_t
correspondingly inside the union maybe.
Well, you will have nameclash happening I think.
And vaddr_t and paddr_t are confusing because you don't know which address you
speak about (guest vs hypervisor). At least ipa/gpa, gva are known naming.
That's not what I meant. ipa and gva are good names.
I was suggesting to put an additional address field inside the union to
avoid the issue with paddr_t and vaddr_t discussed elsewhere
(alpine.DEB.2.10.1712081313070.8052@sstabellini-ThinkPad-X260).
I am happy either way, it was just a suggestion.
Actually looking at it. It will not be that handy to have the
paddr_t/vaddr_t inside the union. Mostly because of the common code
using the address parameter.
I could add another union for the address, but I
Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
On Tue, 12 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 12/08/2017 10:43 PM, Stefano Stabellini wrote:
> > On Fri, 8 Dec 2017, Julien Grall wrote:
> > > On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
> > >On Fri, 8 Dec 2017, Julien Grall wrote:
> > >> On 06/12/17 12:27, Julien Grall wrote:
> > >> > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > >> > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > >> > > > Hi Andrew,
> > >> > > >
> > >> > > > On 23/11/17 18:49, Andrew Cooper wrote:
> > >> > > > > On 23/11/17 18:32, Julien Grall wrote:
> > >> > > > > > This new function will be used in a follow-up patch to
> > > copy data to
> > >> > > > > > the
> > >> > > > > > guest
> > >> > > > > > using the IPA (aka guest physical address) and then
> > > clean the cache.
> > >> > > > > >
> > >> > > > > > Signed-off-by: Julien Grall
> > >> > > > > > ---
> > >> > > > > > xen/arch/arm/guestcopy.c | 10 ++
> > >> > > > > > xen/include/asm-arm/guest_access.h | 6 ++
> > >> > > > > > 2 files changed, 16 insertions(+)
> > >> > > > > >
> > >> > > > > > diff --git a/xen/arch/arm/guestcopy.c
> > > b/xen/arch/arm/guestcopy.c
> > >> > > > > > index be53bee559..7958663970 100644
> > >> > > > > > --- a/xen/arch/arm/guestcopy.c
> > >> > > > > > +++ b/xen/arch/arm/guestcopy.c
> > >> > > > > > @@ -110,6 +110,16 @@ unsigned long
> > > raw_copy_from_guest(void *to,
> > >> > > > > > const
> > >> > > > > > void __user *from, unsigned le
> > >> > > > > > COPY_from_guest |
> > > COPY_linear);
> > >> > > > > > }
> > >> > > > > > +unsigned long
> > > copy_to_guest_phys_flush_dcache(struct domain *d,
> > >> > > > > > + paddr_t
> > > gpa,
> > >> > > > > > + void
> > > *buf,
> > >> > > > > > + unsigned
> > > int len)
> > >> > > > > > +{
> > >> > > > > > + /* P2M is shared between all vCPUs, so the vCPU
> > > used does not
> > >> > > > > > matter.
> > >> > > > > > */
> > >> > > > >
> > >> > > > > Be very careful with this line of thinking. It is only
> > > works after
> > >> > > > > DOMCTL_max_vcpus has succeeded, and before that point, it
> > > is a latent
> > >> > > > > NULL pointer dereference.
> > >> > > >
> > >> > > > I really don't expect that function been used before
> > > DOMCT_max_vcpus is
> > >> > > > set.
> > >> > > > It is only used for hardware emulation or Xen loading image
> > > into the
> > >> > > > hardware
> > >> > > > domain memory. I could add a check d->vcpus to be safe.
> > >> > > >
> > >> > > > >
> > >> > > > > Also, what about vcpus configured with alternative views?
> > >> > > >
> > >> > > > It is not important because the underlying call is
> > > get_page_from_gfn
> > >> > > > that does
> > >> > > > not care about the alternative view (that function take a
> > > domain in
> > >> > > > parameter). I can update the comment.
> > >> > > Since this is a new function, would it make sense to take a
> > > struct
> > >> > > vcpu* as parameter, instead of a struct domain* ?
> > >> >
> > >> > Well, I suggested this patch this way because likely everyone
> > > will use with
> > >> > d->vcpus[0]. And then you would have to wonder why d->vcpus[0]
> > > and not
> > >> > d->vcpus[1]...
> > >>
> > >> Thinking a bit more to this, it might be better/safer to pass
> > > either a domain
> > >> or a vCPU to copy_guest. I can see 2 solutions:
> > >> 1# Introduce a union that use the same parameter:
> > >> union
> > >> {
> > >> struct
> > >> {
> > >> struct domain *d;
> > >> } ipa;
> > >> struct
> > >> {
> > >> struct vcpu *v;
> > >> } gva;
> > >> }
> > >> The structure here would be to ensure that it is clear
> > > that only
> > >> domain (resp. vcpu) should be used with ipa (resp. gva).
> > >>
> > >> 2# Have 2 parameters, vcpu and domain.
> > >>
> > >> Any opinions?
> > >
> > > I think that would be clearer. You could also add a paddr_t/vaddr_t
> > > correspondingly inside the union maybe.
> > >
> > >
> > > Well, you will have nameclash happeni
Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface
Thanks Bjorn for your review comments. Please see below for my comments.
On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS
attribute.
Signed-off-by: Govinda Tatti
---
v3: -New
drivers/pci/pci.c | 3 ++-
include/linux/pci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6078dfc..499e922 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3872,7 +3872,7 @@ static void pci_flr_wait(struct pci_dev *dev)
* Returns true if the device advertises support for PCIe function level
* resets.
*/
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev)
{
u32 cap;
@@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev)
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap);
return cap & PCI_EXP_DEVCAP_FLR;
}
+EXPORT_SYMBOL_GPL(pcie_has_flr);
I'd rather change pcie_flr() so you could *always* call it, and it
would return 0, -ENOTTY, or whatever, based on whether FLR is
supported. Is that feasible?
Sure, I will add pcie_has_flr() logic inside pcie_flr() and return
appropriate
values as suggested by you. Do we still want to retain pcie_has_flr() and
its usage inside pci.c?.Otherwise, I will remove it and do required cleanup.
Please let me know.
Cheers
GOVINDA
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 117083: trouble: blocked/broken
flight 117083 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117083/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken test-arm64-arm64-xl-xsm broken build-armhf broken build-armhf 4 host-install(4)broken REGR. vs. 116956 build-amd64 4 host-install(4)broken REGR. vs. 116956 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9 baseline version: xen 43550972395f9a3a48bb4086a0faf0f8d442e37d Last test of basis 116956 2017-12-07 23:02:27 Z4 days Testing same since 117015 2017-12-08 22:03:21 Z3 days 10 attempts People who touched revisions under test: Andre Przywara Andre Przywara Julien Grall Julien Grall Stefano Stabellini jobs: build-amd64 broken build-armhf broken build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-amd64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-armhf broken broken-step build-armhf host-install(4) broken-step build-amd64 host-install(4) Not pushing. commit 70f7b6ca0e8208034bdc91d20b2f311bbe63a0a9 Author: Andre Przywara Date: Thu Dec 7 16:14:08 2017 + ARM: VGIC: move gic_remove_irq_from_queues() gic_remove_irq_from_queues() was not only misnamed, it also has the wrong abstraction, as it should not live in gic.c. Move it into vgic.c and vgic.h, where it belongs to, and rename it on the way. Signed-off-by: Andre Przywara Reviewed-by: Stefano Stabellini commit 9630c5ae363b4cbf8eb61366530f40c80680af4d Author: Julien Grall Date: Wed Dec 6 14:51:37 2017 + xen/arm: gic-v3: Bail out if gicv3_cpu_init fail When system registers are not enabled, all the access to them will trap in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only on success. As the rest of the code (e.g gicv3_hyp_init) relies on system register, it is better to bail out directly. This will save time on debugging early boot issue on GICv3 platform. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini commit ac2d8d402370f6f93f82871f3b34ddb9a9ccae05 Author: Julien Grall Date: Wed Nov 29 17:46:35 2017 + xen/arm: Surround HSR_SYSREG macro value with () The value of the macro HCR_SYSREG is not surrounded by (). This means the behavior may change depend on how it is used. Thanksfully recent GCC will issue a warning for that. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini commit b819187a15ecea7fe00cffded1bf454b8a6d7dd2 Author: Andre Przywara Date: Thu Oct 19 13:48:37 2017 +0100 ARM: vGIC: fix nr_irq definition The global variable "nr_irqs" is used for x86 and some common Xen code. To make the latter work easily for ARM, it was #defined to NR_IRQS. This not only violated the common habit of capitalizing macros, but also caused issues if one wanted to use a rather innocent "nr_irqs" as a local variable name or as a function parameter. Drop the optimization and make nr_irqs a normal variable for ARM also. Signed-off-by: Andre Przywara commit 2e9b1c655f060b5c4e68bc8499f02253babe1bbc Author: An
Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface
On Mon, Dec 11, 2017 at 06:29:29PM -0600, Govinda Tatti wrote:
>
> Thanks Bjorn for your review comments. Please see below for my comments.
>
> On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
> >On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
> >>This patch exports pcie_has_flr() and it is being used by Xen pciback
> >>driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS
> >>attribute.
> >>
> >>Signed-off-by: Govinda Tatti
> >>---
> >>v3: -New
> >>
> >> drivers/pci/pci.c | 3 ++-
> >> include/linux/pci.h | 1 +
> >> 2 files changed, 3 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >>index 6078dfc..499e922 100644
> >>--- a/drivers/pci/pci.c
> >>+++ b/drivers/pci/pci.c
> >>@@ -3872,7 +3872,7 @@ static void pci_flr_wait(struct pci_dev *dev)
> >> * Returns true if the device advertises support for PCIe function level
> >> * resets.
> >> */
> >>-static bool pcie_has_flr(struct pci_dev *dev)
> >>+bool pcie_has_flr(struct pci_dev *dev)
> >> {
> >>u32 cap;
> >>@@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev)
> >>pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap);
> >>return cap & PCI_EXP_DEVCAP_FLR;
> >> }
> >>+EXPORT_SYMBOL_GPL(pcie_has_flr);
> >I'd rather change pcie_flr() so you could *always* call it, and it
> >would return 0, -ENOTTY, or whatever, based on whether FLR is
> >supported. Is that feasible?
> Sure, I will add pcie_has_flr() logic inside pcie_flr() and return
> appropriate
> values as suggested by you. Do we still want to retain pcie_has_flr() and
> its usage inside pci.c?.Otherwise, I will remove it and do required cleanup.
If you can restructure the code and remove pcie_has_flr() while
retaining the existing behavior of its callers, that would be great.
Bjorn
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/pt: Pass the whole msi addr/data to Xen
On Mon, Dec 11, 2017 at 05:59:08PM +, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:24PM +0800, Chao Gao wrote:
>> Previously, some fields (reserved or unalterable) are filtered by
>> Qemu. This fields are useless for the legacy interrupt format.
>> However, these fields are may meaningful (for intel platform)
>> for the interrupt of remapping format. It is better to pass the whole
>> msi addr/data to Xen without any filtering.
>>
>> The main reason why we want this is QEMU doesn't have the knowledge
>> to decide the interrupt format after we introduce vIOMMU inside Xen.
>> Passing the whole msi message down and let arch-specific vIOMMU to
>> decide the interrupt format.
>>
>> Signed-off-by: Chao Gao
>> Signed-off-by: Lan Tianyu
>> ---
>> v3:
>> - new
>> ---
>> hw/xen/xen_pt_msi.c | 47 ---
>> 1 file changed, 12 insertions(+), 35 deletions(-)
>>
>> diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
>> index 6d1e3bd..f7d6e76 100644
>> --- a/hw/xen/xen_pt_msi.c
>> +++ b/hw/xen/xen_pt_msi.c
>> @@ -47,25 +47,6 @@ static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
>> return addr_hi & 0xff00;
>> }
>>
>> -static uint32_t msi_gflags(uint32_t data, uint64_t addr)
>> -{
>> -uint32_t result = 0;
>> -int rh, dm, dest_id, deliv_mode, trig_mode;
>> -
>> -rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
>> -dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
>> -dest_id = msi_dest_id(addr);
>> -deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
>> -trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
>> -
>> -result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
>> -| (dm << XEN_PT_GFLAGS_SHIFT_DM)
>> -| (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
>> -| (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
>> -
>> -return result;
>> -}
>> -
>> static inline uint64_t msi_addr64(XenPTMSI *msi)
>> {
>> return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
>> @@ -160,23 +141,20 @@ static int msi_msix_update(XenPCIPassthroughState *s,
>> bool masked)
>> {
>> PCIDevice *d = &s->dev;
>> -uint8_t gvec = msi_vector(data);
>> -uint32_t gflags = msi_gflags(data, addr);
>> +uint32_t gflags = masked ? 0 : (1u << XEN_PT_GFLAGSSHIFT_UNMASKED);
>> int rc = 0;
>> uint64_t table_addr = 0;
>>
>> -XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
>> - " (entry: %#x)\n",
>> - is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
>> +XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x addr %"PRIx64
>> + " data %#x gflags %#x (entry: %#x)\n",
>> + is_msix ? "-X" : "", pirq, addr, data, gflags, msix_entry);
>>
>> if (is_msix) {
>> table_addr = s->msix->mmio_base_addr;
>> }
>>
>> -gflags |= masked ? 0 : (1u << XEN_PT_GFLAGSSHIFT_UNMASKED);
>> -
>> -rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
>> - pirq, gflags, table_addr);
>> +rc = xc_domain_update_msi_irq(xen_xc, xen_domid, pirq, addr,
>> + data, gflags, table_addr);
>
>Are you trying to modifie an existing API? That is not going to work. We
>want to be able to build QEMU against older version of Xen, and it
>should work as well.
Yes. I thought it didn't matter. And definitely, I was wrong. I will keep
compatibility by introducing a new API. A wapper function, which calls
the old or new API according to the Xen version, would be used here.
Thanks
Chao
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request
On Mon, Dec 11, 2017 at 06:07:48PM +, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote:
>> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
>> Interrupt Remapping -> Interrupt Request Formats On Intel 64
>> Platforms, fields of MSI data register have changed. This patch
>> avoids wrongly regarding a remappable format interrupt request as
>> an interrupt binded with a pirq.
>>
>> Signed-off-by: Chao Gao
>> Signed-off-by: Lan Tianyu
>> ---
>> v3:
>> - clarify the interrupt format bit is Intel-specific, then it is
>> improper to define MSI_ADDR_IF_MASK in a common header.
>> ---
>> hw/i386/xen/xen-hvm.c | 10 +-
>> hw/pci/msi.c | 5 +++--
>> hw/pci/msix.c | 4 +++-
>> hw/xen/xen_pt_msi.c | 2 +-
>> include/hw/xen/xen.h | 2 +-
>> stubs/xen-hvm.c | 2 +-
>> 6 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
>> index 8028bed..52dc8af 100644
>> --- a/hw/i386/xen/xen-hvm.c
>> +++ b/hw/i386/xen/xen-hvm.c
>> @@ -145,8 +145,16 @@ void xen_piix_pci_write_config_client(uint32_t address,
>> uint32_t val, int len)
>> }
>> }
>>
>> -int xen_is_pirq_msi(uint32_t msi_data)
>> +int xen_is_pirq_msi(uint32_t msi_addr_lo, uint32_t msi_data)
>> {
>> +/* If the MSI address is configured in remapping format, the MSI will
>> not
>> + * be remapped into a pirq. This 'if' test excludes Intel-specific
>> + * remappable msi.
>> + */
>> +#define MSI_ADDR_IF_MASK 0x0010
>
>I don't think that is the right place for a define, they also exist
>outside of the context of the function.
yes.
>That define would be better at the top of this file, I think.(There is
will do.
Thanks
Chao
>probably a better place in the common headers, but I'm not sure were.)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 117060: trouble: blocked/broken/pass
flight 117060 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117060/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xtf broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf-xsm broken build-armhf broken build-i386-prev broken build-armhf-pvops 4 host-install(4)broken REGR. vs. 116952 build-i386-prev 4 host-install(4)broken REGR. vs. 116952 build-amd64-xsm 4 host-install(4)broken REGR. vs. 116952 build-amd64-pvops 4 host-install(4)broken REGR. vs. 116952 build-amd64-prev 4 host-install(4)broken REGR. vs. 116952 build-amd64 4 host-install(4)broken REGR. vs. 116952 build-amd64-xtf 4 host-install(4)broken REGR. vs. 116952 build-i3864 host-install(4)broken REGR. vs. 116952 build-i386-xsm4 host-install(4)broken REGR. vs. 116952 build-i386-pvops 4 host-install(4)broken REGR. vs. 116952 build-armhf-xsm 4 host-install(4)broken REGR. vs. 116952 build-armhf 4 host-install(4)broken REGR. vs. 116952 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1)
[Xen-devel] [PATCH] tools/livepatch: recognize functions in livepatch.ignore.functions
From: Elena Ufimtseva
It is expected that the symbol has type STT_FUNC in livpatch.ignore.functions
sections, but it is incorrect and results in functions not to be ignored.
To actually ignore functions in livepatch.ignore.functions section, attempt to
find the symbol of type STT_FUNC by its name.
Signed-off-by: Elena Ufimtseva
---
create-diff-object.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/create-diff-object.c b/create-diff-object.c
index 82f777e..7e845da 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -859,6 +859,7 @@ static void kpatch_mark_ignored_functions_same(struct
kpatch_elf *kelf)
{
struct section *sec;
struct rela *rela;
+ struct symbol *strsym;
sec = find_section_by_name(&kelf->sections,
".livepatch.ignore.functions");
if (!sec)
@@ -867,8 +868,30 @@ static void kpatch_mark_ignored_functions_same(struct
kpatch_elf *kelf)
list_for_each_entry(rela, &sec->rela->relas, list) {
if (!rela->sym->sec)
ERROR("expected bundled symbol");
- if (rela->sym->type != STT_FUNC)
- ERROR("expected function symbol");
+ if (rela->sym->type != STT_FUNC) {
+ log_debug("expected function symbol and we have %d,
name %s", rela->sym->type, rela->sym->name);
+ if (rela->string) {
+ log_debug(", rela string %s\n", rela->string);
+ strsym = find_symbol_by_name(&kelf->symbols,
rela->string);
+ if (!strsym)
+ ERROR("can't find %s symbol to
ignore\n", rela->string);
+ else {
+ if (strsym->type != STT_FUNC)
+ ERROR("symbol %s is not
function to ignore\n", strsym->name);
+ else {
+ strsym->status = SAME;
+ strsym->sec->status = SAME;
+ if (strsym->sec->secsym)
+
strsym->sec->secsym->status = SAME;
+ if (strsym->sec->rela)
+
strsym->sec->rela->status = SAME;
+ }
+ }
+ }
+ log_debug("\n");
+ continue;
+}
+
log_normal("ignoring function: %s\n", rela->sym->name);
if (rela->sym->status != CHANGED)
log_normal("NOTICE: no change detected in function %s,
unnecessary KPATCH_IGNORE_FUNCTION()?\n", rela->sym->name);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 41/45] arch/x86: remove duplicate includes
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge
---
arch/x86/kernel/itmt.c | 1 -
arch/x86/kernel/process.c | 1 -
arch/x86/kernel/setup.c| 1 -
arch/x86/kernel/smpboot.c | 1 -
arch/x86/platform/efi/efi_64.c | 1 -
arch/x86/xen/spinlock.c| 2 --
6 files changed, 7 deletions(-)
diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
index f73f475..d177940 100644
--- a/arch/x86/kernel/itmt.c
+++ b/arch/x86/kernel/itmt.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 97fb3e5..9824553 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 8af2e8d..c8e0447 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -114,7 +114,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 3d01df7..8dd0f51 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -75,7 +75,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6a151ce..1e5184d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 02f3445..cd97a62 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -23,8 +23,6 @@ static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
static DEFINE_PER_CPU(char *, irq_name);
static bool xen_pvspin = true;
-#include
-
static void xen_qlock_kick(int cpu)
{
int irq = per_cpu(lock_kicker_irq, cpu);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 41/45] arch/x86: remove duplicate includes
On 11/12/17 21:42, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. > > Signed-off-by: Pravin Shedge Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How to make tracking CPU cache-miss on Xen?
On Tue, Dec 12, 2017 at 12:30 AM, George Dunlap wrote: > On Mon, Dec 11, 2017 at 3:05 PM, Boris Ostrovsky > wrote: > > On 12/11/2017 09:36 AM, Meng Xu wrote: > >> On Mon, Dec 11, 2017 at 8:14 AM, Minjun Hong > wrote: > >>> Thanks for your answer, George. > >>> > >>> What I want ultimately is cache misses from the guest, but even I > could not get the cache misses from dom0 also. > >>> That's why I'm confused as I know, it should be possible to get > cache-misses from dom0 (is it right??). > >>> I already enabled CONFIG_XEN_HAVE_VPMU of current kernel to get cache > misses. Is there anything what I miss during Xen install? > >>> > >> If this is for a research project, I would suggest you to write your > >> own code to monitor the cache misses for domU. This could be faster, > >> since it's not complicated to do so. > >> > >> IIRC, PMU in Xen can only monitor the cache misses when VCPUs are > >> pinned to cores. > > > > Counters are virtualized for guests (including dom0) so I am not sure > > pinning is required. Pinning is only needed when you try to collect > > counters for full system. > > > > OTOH, when a VCPU is migrated you start running with a new cache, > > something to keep in mind. > > Well if his goal was to measure cache misses based on different Xen > scheduling algorithms, that might be the point. :-) > > Minjun: BTW, it's standard on this list to quote inline (as I'm > doing), rather than top-posting (having your reply at the top and the > original mail entirely beneath it). > > Thanks, > -George > Thanks to your help, finally, I resolve the problem. I could have access to VPMU and I successfully estimated performance of my work. And, I'm sorry for violation of standard for this list. I will pay attention to this point in the future. I'd like to appreciate your help again. Minjun Hong ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
>>> On 11.12.17 at 21:26, wrote:
> On 12/11/2017 10:06 AM, Jan Beulich wrote:
> On 08.12.17 at 15:38, wrote:
>>> On 08/12/17 08:03, Tim Deegan wrote:
It should be possible to do something like the misconfigured-entry bit
trick by _allocating_ the memory up-front and building the p2m entries
but only making them usable by the {IO}MMUs on first access. That
would make these early p2m walks shorter (because they can skip whole
subtrees that aren't marked present yet) without making major changes
to domain build or introducing run-time failures.
>>>
>>> I am not aware of any way on Arm to misconfigure an entry. We do have
>>> valid and access bits, although they will affect the IOMMU as well. So
>>> it will not be possible to get page-table sharing with this "feature"
>>> enabled.
>>
>> How would you intend to solve the IOMMU part of the problem with
>> PoD? As was pointed out before - IOMMU and PoD are incompatible
>> on x86.
>
> I am not sure why you ask about PoD here when I acknowledge I will look
> at a different solution. And again, misconfiguring an entry is not
> possible on Arm.
I'm sorry if I've overlooked any such acknowledgment; it's certainly
not in context above.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
