>>> On 07.12.17 at 19:32, wrote:
> On 07/12/17 13:58, Jan Beulich wrote:
>> Quite a few casts can be dropped this way, and type-safeness is being
>> increased by not using void * (same goes for decode_vex_gpr()). Drop
>> casts and no longer needed intermediate variables where possible. Take
>> the
* Juergen Gross wrote:
> When booted via the special PVH entry save the RSDP address set in the
> boot information block in struct boot_params. This will enable Xen to
> locate the RSDP at an arbitrary address.
>
> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
> which
* Juergen Gross wrote:
> Xen PVH guests receive the address of the RSDP table from Xen. In order
> to support booting a Xen PVH guest via grub2 using the standard x86
> boot entry we need a way fro grub2 to pass the RSDP address to the
> kernel.
>
> For this purpose expand the struct setup_head
* Juergen Gross wrote:
> In case the rsdp address in struct boot_params is specified don't try
> to find the table by searching, but take the address directly as set
> by the boot loader.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/acpi/osl.c | 8
> 1 file changed, 8 insertions(
flight 116940 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116940/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 116762
test-armhf-arm
flight 116956 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116956/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 116937 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
Just FYI: I sent out a v2 of this patch but in doing so I moved a few
people from the "to" line to the "cc" line.
For anyone who previously did not comment but still wanted to follow the
discussion, here's the link to the v2 email:
https://lkml.org/lkml/2017/12/7/1624
Thanks,
-Maran
On 12/1
On Wed, 6 Dec 2017, Julien Grall wrote:
> From: Julien Grall
>
> When system registers are not enabled, all the access to them will trap
^ accesses
> in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only
> on success. As the rest of
On Wed, 6 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 12/06/2017 01:22 AM, Stefano Stabellini wrote:
> > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > The only differences between copy_to_guest and access_guest_memory_by_ipa
> > > are:
> > > - The latter does not support copying data
Hi Stefano,
On 7 December 2017 at 22:43, Stefano Stabellini wrote:
> On Thu, 23 Nov 2017, Julien Grall wrote:
>> @@ -2039,10 +1982,11 @@ static void do_trap_data_abort_guest(struct
>> cpu_user_regs *regs,
>> case FSC_FLT_PERM:
>> {
>> const struct npfec npfec = {
>> -
On Thu, 7 Dec 2017, Julien Grall wrote:
> A lot of places in the ARM64 assembly code requiring to load the
> physical address of a symbol. Rather than open-coding the translation,
> introduce a new macro that will load the physical address of a symbol.
>
> Lastly, use this new macro to replace all
On Thu, 7 Dec 2017, Julien Grall wrote:
> There are quite a few fixmap slots that have not been used for a while.
> Remove them.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/include/asm-arm/config.h | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(
The start info structure that is defined as part of the x86/HVM direct
boot ABI and used for starting Xen PVH guests would be more versatile if
it also included a way to efficiently pass information about the memory
map to the guest.
That way Xen PVH guests would not be forced to use a hypercall t
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
Changes from v1:
* Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
e820 map instead of using the second module entry to pass the table.
* Cleaned things up a bit to reduce the number of xen vs non-xen special
cases.
Juergen also had a suggestion to split the diff
On Thu, 23 Nov 2017, Julien Grall wrote:
> The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest
> are used trap stage-2 abort. While the former is only handling prefetch
> abort and the latter data abort, they are very similarly and does not
> warrant to have separate helpers.
>
On Thu, 23 Nov 2017, Julien Grall wrote:
> mmio_info_t is currently filled by do_trap_data_guest_abort but only
> important when emulation an MMIO region.
>
> A follow-up patch will merge stage-2 prefetch abort and stage-2 data abort
> in a single helper. To prepare that, mmio_info_t is now filled
This patch contains Xen/libxl specific changes to support PCI reset
(flr/slot/bus) in Xen pciback driver based on SysFS 'reset' attribute.
It depends on the following kernel patch.
- Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS
attribute
Govinda Tatti (1):
Xen/libxl: Perfor
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.
- It starts with the device being bound to us, for which we do a function
reset (done via SysFS so the PCI lock is held).
- If the device is unbound from us, we also do a function re
On Thu, 23 Nov 2017, Julien Grall wrote:
> mmio_info_t is used to gather information in order do emulation a
^ of a
Aside from this
Reviewed-by: Stefano Stabellini
> region. Guest virtual address is unlikely to be a useful inform
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(-)
d
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.
- It starts with the device being bound to us, for which we do a function
reset (done via SysFS so the PCI lock is held).
- If the device is unbound from us, we also do a function re
This patch contains Xen pciback driver changes to support PCI reset
(flr/slot/bus) based on SysFS 'reset' attribute. The following Xen
libxl patch depends on these kernel patches.
- Xen/libxl: Perform PCI reset using 'reset' SysFS attribute
Govinda Tatti (2):
Drivers/PCI: Export pcie_has_flr() i
On Thu, 23 Nov 2017, Julien Grall wrote:
> p2m_tlb_flush is called in 2 places: p2m_alloc_table and
> p2m_force_tlb_flush_sync.
>
> p2m_alloc_table is called when the domain is initialized and could be
> replace by a call to p2m_force_tlb_flush_sync with the P2M write locked.
>
> This seems a bit
On Thu, 23 Nov 2017, Julien Grall wrote:
> Multiple places in the code requires to flush the TLBs wonly when
^ only
Aside from this
Reviewed-by: Stefano Stabellini
> p2m->need_flush is set.
>
> Rather than open-coding it, introduce a ne
On Thu, 23 Nov 2017, Julien Grall wrote:
> Rename p2m_flush_tlb and p2m_flush_tlb_sync to respectively
> p2m_tlb_flush and p2m_force_tlb_flush_sync.
>
> At first glance, inverting 'flush' and 'tlb' might seem pointless but
> would be helpful in the future in order to get more easily some code por
This run is configured for baseline tests only.
flight 72525 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64
flight 116935 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116935/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116902
test-armhf-armhf-libvirt-raw 13 saveresto
Hi, Stefano, Jan
On Thu, Dec 7, 2017 at 10:45 AM, Jan Beulich wrote:
On 07.12.17 at 00:44, wrote:
>> Oleksandr would like to call set_px_pminfo from a non-hypercall context,
>> meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct
>> xen_processor_performance contains a
>>
>>
flight 116931 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116931/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116861
REGR. vs. 116754
Test
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:
Hi,
On 26/10/17 09:28, Julien Grall wrote:
> Hi Andre,
>
> On 10/19/2017 01:48 PM, Andre Przywara wrote:
>> The functions to actually populate a list register were accessing
>> the VGIC internal pending_irq struct, although they should be abstracting
>> from that.
>> Break the needed information
On 07/12/17 13:59, Jan Beulich wrote:
> Specifically in the context of putting together subsequent patches I've
> noticed that together with the touch() macro using -Os further
> increases the chances of the compiler using memory operands for the
> instructions we actually care to test.
>
> Signed-
On 07/12/17 13:58, Jan Beulich wrote:
> Quite a few casts can be dropped this way, and type-safeness is being
> increased by not using void * (same goes for decode_vex_gpr()). Drop
> casts and no longer needed intermediate variables where possible. Take
> the opportunity and also switch the last pa
flight 116929 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116929/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
116891
Regressions
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 on
There are quite a few fixmap slots that have not been used for a while.
Remove them.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/config.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 45f472f
A lot of places in the ARM64 assembly code requiring to load the
physical address of a symbol. Rather than open-coding the translation,
introduce a new macro that will load the physical address of a symbol.
Lastly, use this new macro to replace all the current opencoded version.
Note that most of
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
>>>
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 M
On 12/6/17 4:31 PM, Julien Grall wrote:
Hi Stuart,
On 12/05/2017 03:36 PM, Stuart Yoder wrote:
There are limit on pCPUs, though. But this is not a problem, because
XEN scheduler will decide which guest will access OP-TEE right now.
OP-TEE don't have own scheduler at all, by the way. It is s
flight 116921 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116921/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
115643
test-amd64-am
gic.h is supposed to hold defines and prototypes for the hardware side
of the GIC interrupt controller. A lot of parts in Xen should not be
bothered with that, as they either only care about the VGIC or use
more generic interfaces.
Remove unneeded inclusions of gic.h from files where they are actua
Currently gic.c holds code to handle hardware IRQs as well as code to
bridge VGIC requests to the GIC virtualization hardware.
Despite being named gic.c, this file reaches into the VGIC and uses data
structures describing virtual IRQs.
To improve abstraction, move the VGIC functions into a separate
The functions to actually populate a list register were accessing
the VGIC internal pending_irq struct, although they should be abstracting
from that.
Break the needed information down to remove the reference to pending_irq
from gic-v[23].c.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v2.
At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.
Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).
This removes said
Currently gic_dump_info() not only dumps the hardware state of the GIC,
but also the VGIC internal virtual IRQ lists.
Split the latter off and move it into gic-vgic.c to observe the abstraction.
Signed-off-by: Andre Przywara
---
xen/arch/arm/domain.c | 1 +
xen/arch/arm/gic-vgic.c | 11 ++
Hi,
a reworked version of this series, addressing Stefano's comments.
Although I don't fully agree, I decided to drop the patches that Stefano
didn't like (3/12, 5/12, 8/12), instead moved the functions in question
into the new gic-vgic.c file, where they are out of the way for any new
VGIC as wel
In gic_restore_pending_irqs() we push our pending virtual IRQs into the
list registers. This function is called once from a GIC context and once
from a VGIC context. Refactor the calls so that we have only one callsite
from the VGIC context. This will help separating the two worlds later.
Signed-o
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 nam
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
---
xen/arch/arm/gic.c | 9
In event.h we very deeply dive into the VGIC to learn if an event for
a guest is pending.
Rework that function to abstract the VGIC specific part out. Also
reorder the queries there, as we only actually need to check for the
event channel if there are no other pending IRQs.
Signed-off-by: Andre Pr
At the moment we happily access the VGIC internal struct pending_irq
(which describes a virtual IRQ) in irq.c.
Factor out the actually needed functionality to learn the associated
hardware IRQ and move that into gic-vgic.c to improve abstraction.
Signed-off-by: Andre Przywara
Acked-by: Stefano St
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 .
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
>>> On 07.12.17 at 16:22, wrote:
> On 07/12/17 09:39, Jan Beulich wrote:
> On 06.12.17 at 18:52, wrote:
>>> But I think this is bringing another class of problem. When a
>>> misconfigured is accessed, we would need to clean & invalidate the cache
>>> for that region.
>>
>> Why? (Please remem
>>> 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 CM
On Thu, Dec 07, 2017 at 04:08:31AM -0700, Jan Beulich wrote:
> >>> On 04.12.17 at 11:24, wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -653,7 +653,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > module_t *mod = (module_t *)__va(mbi->mods_addr);
> >
On Tue, 2017-12-05 at 21:58 +0530, Praveen Kumar wrote:
> On Tue, Sep 5, 2017 at 11:26 PM, Dario Faggioli
> wrote:
> >
> > I'm asking because I do have it half done myself, and it would not
> > take
> > too much time to me to finish it.
> >
> > If you're still on it, I'll leave it to you, but if
On Tue, 2017-12-05 at 21:49 +0530, Praveen Kumar wrote:
> Hi All,
>
Hi,
> Can you please provide your comments over the changes shared. Thanks
> in advance.
>
Sorry, I noticed this series only a few days ago, and was busy. FWIW,
I'll try to have a look at the patches next week.
BTW, can you upd
(+ Marc)
@Marc: My Arm cache knowledge is somewhat limited. Feel free to correct
me if I am wrong.
On 07/12/17 09:39, Jan Beulich wrote:
On 06.12.17 at 18:52, wrote:
On 12/06/2017 03:15 PM, Jan Beulich wrote:
What we do in x86 is that we flag all entries at the top level as
misconfigured a
On 07/12/17 13:52, Julien Grall wrote:
> (+ Marc)
>
> Hi,
>
> @Marc: My Arm cache knowledge is somewhat limited. Feel free to correct
> me if I am wrong.
>
> Before answering to the rest of the e-mail, let me reinforce what I said
> in my first e-mail. Set/Way are very complex to emulate and a
On 12/07/2017 04:16 PM, Jan Beulich wrote:
> ..., at least as far as currently possible, i.e. when a mapping can be
> obtained.
>
> Signed-off-by: Jan Beulich
Thank you for the patch!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
>>> On 07.12.17 at 14:52, wrote:
> On 06/12/17 17:49, George Dunlap wrote:
>> Do you want to reset the p2m multiple times? I thought the goal was
>> simply to keep the amount of p2m space you need to flush to a minimum;
>> if you expect the memory which has been faulted in by the *last* flush
>>
The functions have a single caller only and are now guest paging type
independent (except for the tracing part), so have no need to exist as
standalone ones, let alone multiple times. Replace the two prior hooks
with just a single one for dealing with tracing.
Signed-off-by: Jan Beulich
---
v3: N
By adding guest PTE size to shadow emulation context, the work begun by
commit 2c80710a78 ("x86/shadow: compile most write emulation code just
once") can be completed, paving the road for further movement into
common code.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/mm/shadow/comm
..., at least as far as currently possible, i.e. when a mapping can be
obtained.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1187,6 +1187,61 @@ static int hvmemul_write(
return X86EMUL_OKAY;
}
+static int hvmemul_rmw(
+
..., at least as far as currently possible, i.e. when a mapping can be
obtained.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1296,8 +1296,83 @@ static int hvmemul_cmpxchg(
bool lock,
struct x86_emulate_ctxt *ctxt)
{
-
In order to correctly emulate read-modify-write insns, especially
LOCKed ones, we should not issue reads and writes separately. Use a
new hook to combine both, and don't uniformly read the memory
destination anymore. Instead, DstMem opcodes without Mov now need to
have done so in their respective c
If the ->cmpxchg() hook finds a mismatch, we should deal with this the
same way as when the "manual" comparison reports a mismatch.
This involves reverting bfce0e62c3 ("x86/emul: Drop
X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now
becoming a value distinct from X86EMUL_RETRY.
In
This is necessary for the hook to correctly perform the operation.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -346,6 +346,7 @@ static int fuzz_cmpxchg(
void *old,
void *new,
I'm in the process of putting together a gas change issuing at least
warnings when the intended size of a memory operation can't be deduced
from another (register) operand. Add missing suffixes to silence such
future diagnostics.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emul
As mentioned in Linux commit 87c00572ba ("kvm: x86: emulate monitor and
mwait instructions as nop"), older OS X versions (for example) may make
use of the insns without checking CPUID flags (presumably implying
availability from family/model).
While the instruction prefix check appears to contradi
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5047,6 +5047,24 @@ x86_emulate(
goto done;
break;
+case 0xf8: /* swapgs */
+generate_exception_if(!mode_64bit()
Use the generic stub exception handling instead.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
---
v3: Re-base.
v2: Re-base.
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -134,8 +134,6 @@ int emul_test_read_xcr(
}
int emul_test_get_fpu(
While this means quite some reduction of (source) code, the main
purpose is to no longer have exceptions raised from other than stubs.
Signed-off-by: Jan Beulich
---
v3: Re-base.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1262,28 +1262,25 @@ sta
Experimentally MPX instructions have been confirmed to behave as NOPs
unless both related XCR0 bits are set to 1. By implication branches
then also don't clear BNDn.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2143,12 +
Use hooks, just like done for other special purpose registers.
This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator
itself as well as adding support for XGETBV emulation.
For now fuzzer reads will obtain the real values (minus the fuzzing of
the hook pointer itself).
Signed-of
This allows the section contents to be disassembled without going
through any extra hoops, simplifying the analysis of problems in test
and/or emulation code.
The blobs being emitted as (r/o) data means we need to accept an
assembler warning here (about the differing section attributes).
Signed-o
Yes, recent AMD CPUs don't support them anymore, but I think we should
nevertheless cope.
Signed-off-by: Jan Beulich
---
v3: Re-base.
--- a/.gitignore
+++ b/.gitignore
@@ -223,6 +223,7 @@
tools/security/xensec_tool
tools/tests/x86_emulator/*.bin
tools/tests/x86_emulator/*.tmp
+tools/tests/x86
Anthony PERARD writes ("[OSSTEST RFC 05/16] TestSupport: Adapt
target_https_mitm_proxy_setup to CentOS"):
> The location for new certificates is different, and
> update-ca-certificates is Debian specific.
...
> +my $dest;
> +my $update_ca_cmd;
> +if ($ho->{OS} eq "centos" ) {
I'm not
Signed-off-by: Jan Beulich
--- a/.gitignore
+++ b/.gitignore
@@ -230,6 +230,7 @@
tools/tests/x86_emulator/sse*.[ch]
tools/tests/x86_emulator/test_x86_emulator
tools/tests/x86_emulator/x86_emulate
+tools/tests/x86_emulator/xop*.[ch]
tools/tests/xen-access/xen-access
tools/tests/xenstore/xs-te
Convert the few existing opcodes so far supported.
Also adjust two vex_* case labels to better be ext_* (the values are
identical).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -458,6 +458,20 @@ static const opcode_desc_
Anthony PERARD writes ("[OSSTEST RFC 15/16] make-centos-flight: Create a flight
with CentOS as dom0"):
> This is based on make-flight, with the added all_host_os=centos runvar,
> and without test that can not be run.
>
> Anything based on the recipe "test-debian" or "test-pair" is remove, as
> th
Anthony PERARD writes ("[OSSTEST RFC 16/16] Osstest/TestSupport: Handle
qemu-img location on CentOS"):
> Signed-off-by: Anthony PERARD
...
> +foreach (qw(/usr/local/lib /usr/lib /usr/lib64)) {
Yuk.
Acked-by: Ian Jackson
But, shouldn't it include /usr/local/lib64 too ?
Ian.
_
Signed-off-by: Jan Beulich
---
v3: Re-base.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -13,7 +13,8 @@ run: $(TARGET)
SIMD := sse sse2 sse4 avx avx2
FMA := fma4 fma
-TESTCASES := blowfish $(SIMD) $(FMA)
+SG := avx2-sg
+TESTCASES := blowfish $(SIMD) $(FMA
I.e. those not being equivalents of SSEn ones, but with the exception
of the various gather operations.
Signed-off-by: Jan Beulich
---
v3: vbroadcasts{d,s} support register operands as of AVX2. Re-base.
v2: Add all vpmaskmov{d,q} handling here.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools
Anthony PERARD writes ("[OSSTEST RFC 13/16] WORKAROUND: Osstest/TestSupport:
Make target_reboot works with systemd"):
> On host running with systemd as init, doing `ssh host reboot` will
> result in ssh returning an error.
> This patch works around by not waiting for the reboot command to return.
Anthony PERARD writes ("[OSSTEST RFC 11/16] ts-centos-xen-pkg-install: Adjust
daemons configuration"):
> Ajust configuration of xenconsoled and libvirtd.
See my comments about ts-xen-install. It already does this. Please
don't duplicate things.
Thanks,
Ian.
__
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -12,7 +12,7 @@ run: $(TARGET)
./$(TARGET)
SIMD := sse sse2 sse4 avx
-FMA := fma4
+FMA := fma4 fma
TESTCASES := blowfish $(SIMD) sse2-avx sse4-avx $(FMA)
blowfish-cflags :=
Signed-off-by: Jan Beulich
---
v3: Re-base.
--- a/.gitignore
+++ b/.gitignore
@@ -226,6 +226,7 @@
tools/tests/x86_emulator/asm
tools/tests/x86_emulator/avx*.[ch]
tools/tests/x86_emulator/blowfish.h
+tools/tests/x86_emulator/fma*.[ch]
tools/tests/x86_emulator/sse*.[ch]
tools/tests/x86_emulato
Anthony PERARD writes ("[OSSTEST RFC 10/16] ts-centos-xen-pkg-install: Install
of Xen package on CentOS"):
> Install candidate packages that have been built by CBS, the CentOS
> Community Build Service.
...
> +name=VirtSIG-\$releasever - Xen 4.8 CBS $subtag
> +baseurl=http://cbs.centos.org/repos/v
Note that this avoids emulating the behavior of VCVTPS2PH found on at
least some Intel CPUs, which update MXCSR even when the memory write
faults.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -3053,6 +3053,47
Anthony PERARD writes ("[OSSTEST RFC 14/16] sg-run-job: Select host install
script based on all_host_os runvar"):
> This also select a different xen installation script.
This is wrong, I'm afraid. In general, the recipes should not read
runvars (with the exception perhaps of runvars that are spe
On Thu, Dec 07, 2017 at 08:41:14AM +, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 06 December 2017 16:10
>> To: 'Chao Gao'
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Andrew Cooper ; Tim
Specifically in the context of putting together subsequent patches I've
noticed that together with the touch() macro using -Os further
increases the chances of the compiler using memory operands for the
instructions we actually care to test.
Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
Quite a few casts can be dropped this way, and type-safeness is being
increased by not using void * (same goes for decode_vex_gpr()). Drop
casts and no longer needed intermediate variables where possible. Take
the opportunity and also switch the last parameter to bool.
Signed-off-by: Jan Beulich
>>> On 07.12.17 at 14:50, wrote:
> On Thu, Dec 7, 2017 at 10:57 AM, Jan Beulich wrote:
> On 06.12.17 at 20:23, wrote:
>>> On Wed, Dec 6, 2017 at 7:01 PM, Jan Beulich wrote:
>>> On 25.07.17 at 19:26, wrote:
> @@ -175,37 +182,6 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
(+ Marc)
Hi,
@Marc: My Arm cache knowledge is somewhat limited. Feel free to correct
me if I am wrong.
Before answering to the rest of the e-mail, let me reinforce what I said
in my first e-mail. Set/Way are very complex to emulate and an OS using
them should never expect good performance i
1 - 100 of 192 matches
Mail list logo
