On 22.05.2020 18:33, Tamas K Lengyel wrote:
> When running shallow forks without device models it may be undesirable for Xen
> to inject interrupts. With Windows forks we have observed the kernel going
> into
> infinite loops when trying to process such interrupts, likely because it
> attempts
>
On 19.05.20 10:06, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 19 May 2020 08:45
To: Jürgen Groß ; Kevin Tian ; Julien Grall
;
Jun Nakajima ; Wei Liu ; Ian Jackson
;
Daniel De Graaf ; Paul Durrant
Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
; Andrew
On Thu, 2020-05-14 at 17:36 +0200, Juergen Gross wrote:
> With support of core scheduling sched_unit_migrate_finish() gained a
> call of sync_vcpu_execstate() as it was believed to be called as a
> result of vcpu migration in any case.
>
> In case of migrating a vcpu away from a physical cpu for
On Mon, May 25, 2020 at 6:18 AM Tamas K Lengyel wrote:
>
> On Mon, May 25, 2020 at 12:06 AM Jan Beulich wrote:
> >
> > On 22.05.2020 18:33, Tamas K Lengyel wrote:
> > > When running shallow forks without device models it may be undesirable
> > > for Xen
> > > to inject interrupts. With Windows
On Mon, May 25, 2020 at 8:06 AM Jan Beulich wrote:
>
> On 25.05.2020 15:46, Tamas K Lengyel wrote:
> > On Mon, May 25, 2020 at 7:06 AM Jan Beulich wrote:
> >>
> >> On 25.05.2020 14:18, Tamas K Lengyel wrote:
> >>> On Mon, May 25, 2020 at 12:06 AM Jan Beulich wrote:
>
> On 22.05.2020
The first two patches are bug fixes, in part pointed out by the
3rd patch. The remainder is further enabling.
1: address x86_insn_is_mem_{access,write}() omissions
2: rework CMP and TEST emulation
3: also test decoding and mem access / write logic
4: disable FPU/MMX/SIMD insn emulation when !HVM
To avoid introducing another boolean into emulator state, the
rex_prefix field gets (ab)used to convey the real/VM86 vs protected mode
info (affecting structure layout, albeit not size) to x86_emul_blk().
Signed-off-by: Jan Beulich
---
TBD: The full 16-bit padding fields in the 32-bit structures
While the Intel SDM claims that FRSTOR itself may raise #MF upon
completion, this was confirmed by Intel to be a doc error which will be
corrected in due course; behavior is like FLDENV, and like old hard copy
manuals describe it.
Re-arrange a switch() statement's case label order to allow for
Note that the ISA extensions document revision 038 doesn't specify
exception behavior for ModRM.mod == 0b11; assuming #UD here.
No tests are being added to the harness - this would be quite hard,
we can't just issue the insns against RAM. Their similarity with
MOVDIR64B should have the test case
Note that FPU selector handling as well as MXCSR mask saving for now
does not honor differences between host and guest visible featuresets.
While for Intel operation of the insns with CR4.OSFXSR=0 is
implementation dependent, use the easiest solution there: Simply don't
look at the bit in the
flight 150359 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On Mon, May 25, 2020 at 7:06 AM Jan Beulich wrote:
>
> On 25.05.2020 14:18, Tamas K Lengyel wrote:
> > On Mon, May 25, 2020 at 12:06 AM Jan Beulich wrote:
> >>
> >> On 22.05.2020 18:33, Tamas K Lengyel wrote:
> >>> When running shallow forks without device models it may be undesirable
> >>> for
On 25.05.2020 15:46, Tamas K Lengyel wrote:
> On Mon, May 25, 2020 at 7:06 AM Jan Beulich wrote:
>>
>> On 25.05.2020 14:18, Tamas K Lengyel wrote:
>>> On Mon, May 25, 2020 at 12:06 AM Jan Beulich wrote:
On 22.05.2020 18:33, Tamas K Lengyel wrote:
> When running shallow forks
For lbr_tsx_fixup_check() simply name a few more specific erratum
numbers.
For bdf93_fixup_check(), however, more models are affected. Oddly enough
despite being the same model and stepping, the erratum is listed for
Xeon E3 but not its Core counterpart. Apply the workaround uniformly,
and also
On 25.05.2020 14:18, Tamas K Lengyel wrote:
> On Mon, May 25, 2020 at 12:06 AM Jan Beulich wrote:
>>
>> On 22.05.2020 18:33, Tamas K Lengyel wrote:
>>> When running shallow forks without device models it may be undesirable for
>>> Xen
>>> to inject interrupts. With Windows forks we have observed
In a pure PV environment (the PV shim in particular) we don't really
need emulation of all these. To limit #ifdef-ary utilize some of the
CASE_*() macros we have, by providing variants expanding to
(effectively) nothing (really a label, which in turn requires passing
-Wno-unused-label to the
On Mon, May 25, 2020 at 8:14 AM Tamas K Lengyel wrote:
>
> On Mon, May 25, 2020 at 8:06 AM Jan Beulich wrote:
> >
> > On 25.05.2020 15:46, Tamas K Lengyel wrote:
> > > On Mon, May 25, 2020 at 7:06 AM Jan Beulich wrote:
> > >>
> > >> On 25.05.2020 14:18, Tamas K Lengyel wrote:
> > >>> On Mon,
Introduce a new blk() hook, paralleling the rmw() one in a certain way,
but being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.
Note that SDM revision 071 doesn't
x86emul_is_mem_{access,write}() (and their interaction with
x86_decode()) have become sufficiently complex that we should have a way
to test this logic. Start by covering legacy encoded GPR insns, with the
exception of a few the main emulator doesn't support yet (left as
comments in the respective
Unlike similarly encoded insns these don't write their memory operands,
and hence x86_is_mem_write() should return false for them. However,
rather than adding special logic there, rework how their emulation gets
done, by making decoding attributes properly describe the r/o nature of
their memory
This bug report is a follow-up to the thread "Domu windows 2012 crash"
on the xen-users list. In there we found out that it is possible to set
a value for shadow_memory that is lower than a safe minimum value.
This became apparent after XSA-304, which caused using more of this type
of memory.
On Mon, May 25, 2020 at 12:06 AM Jan Beulich wrote:
>
> On 22.05.2020 18:33, Tamas K Lengyel wrote:
> > When running shallow forks without device models it may be undesirable for
> > Xen
> > to inject interrupts. With Windows forks we have observed the kernel going
> > into
> > infinite loops
On Mon, 2020-05-25 at 15:12 +0200, Jan Beulich wrote:
> On 25.05.2020 09:18, Dario Faggioli wrote:
> >
> > > Signed-off-by: Juergen Gross
> > > Reviewed-by: Jan Beulich
> > >
> > Reviewed-by: Dario Faggioli
>
> Hmm, I'm puzzled: This had gone in a week and a half ago with your
> R-b sent on
From: Tamas K Lengyel
It is unclear whether mem_sharing was ever made to work on other architectures
but at this time the only verified platform for it is vmx. No plans to support
or maintain it on other architectures. Make this explicit by checking during
initialization.
Signed-off-by: Tamas K
Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says
"Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET
timer once the SoCs entered PC10."
Again follow this for Xen as well, noting though that even the
pre-existing PCI ID refers to a H-processor line variant (the 6-core
On 25.05.2020 17:18, Jan Beulich wrote:
> Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says
>
> "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET
> timer once the SoCs entered PC10."
>
> Again follow this for Xen as well, noting though that even the
> pre-existing PCI
On 25/05/2020 16:04, Jan Beulich wrote:
> For lbr_tsx_fixup_check() simply name a few more specific erratum
> numbers.
>
> For bdf93_fixup_check(), however, more models are affected. Oddly enough
> despite being the same model and stepping, the erratum is listed for
> Xeon E3 but not its Core
When running shallow forks, ie. VM forks without device models (QEMU), it may
be undesirable for Xen to inject interrupts. When creating such forks from
Windows VMs we have observed the kernel trying to process interrupts
immediately after the fork is executed. However without QEMU running such
Toolstack side for creating forks with interrupt injection blocked.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Roger Pau Monné
Acked-by: Ian Jackson
---
tools/libxc/include/xenctrl.h | 3 ++-
tools/libxc/xc_memshr.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git
On 25.05.2020 09:18, Dario Faggioli wrote:
> On Thu, 2020-05-14 at 17:36 +0200, Juergen Gross wrote:
>> With support of core scheduling sched_unit_migrate_finish() gained a
>> call of sync_vcpu_execstate() as it was believed to be called as a
>> result of vcpu migration in any case.
>>
>> In case
First of all explain in comments what the functions' purposes are. Then
make them actually match their comments.
Note that fc6fa977be54 ("x86emul: extend x86_insn_is_mem_write()
coverage") didn't actually fix the function's behavior for {,V}STMXCSR:
Both are covered by generic code higher up in
On 25/05/2020 17:42, Jürgen Groß wrote:
> On 25.05.20 18:04, Martin Lucina wrote:
>> Hi,
>>
>> I'm trying to bootstrap a new PVH-only Xen domU OS "from scratch", to
>> replace our existing use of Mini-OS for the early boot/low-level support
>> layer in MirageOS. I've done this by creating new Xen
On 25/05/2020 16:23, Jan Beulich wrote:
> On 25.05.2020 17:18, Jan Beulich wrote:
>> Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says
>>
>> "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET
>> timer once the SoCs entered PC10."
>>
>> Again follow this for Xen as well,
Hi,
I'm trying to bootstrap a new PVH-only Xen domU OS "from scratch", to
replace our existing use of Mini-OS for the early boot/low-level support
layer in MirageOS. I've done this by creating new Xen bindings for Solo5
[1], basing them on our existing virtio code [2].
Unfortunately, I can't
On 25.05.20 18:04, Martin Lucina wrote:
Hi,
I'm trying to bootstrap a new PVH-only Xen domU OS "from scratch", to
replace our existing use of Mini-OS for the early boot/low-level support
layer in MirageOS. I've done this by creating new Xen bindings for Solo5
[1], basing them on our existing
flight 150363 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150363/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 25/05/2020 17:04, Martin Lucina wrote:
> Hi,
>
> I'm trying to bootstrap a new PVH-only Xen domU OS "from scratch", to
> replace our existing use of Mini-OS for the early boot/low-level support
> layer in MirageOS. I've done this by creating new Xen bindings for Solo5
> [1], basing them on our
On 2020-05-20 16:53, Andrew Cooper wrote:
> On 20/05/2020 15:59, Elliot Killick wrote:
>> On 2020-05-20 12:31, Andrew Cooper wrote:
>>> On 20/05/2020 12:46, Elliot Killick wrote:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name :
flight 150367 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150367/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Sun, May 24, 2020 at 10:50 PM Jason Andryuk wrote:
>
> This series addresses some Coverity reports. To handle closing FDs, a
> state struct is introduced to track FDs closed in both main() and
> data_loop().
I've realized the changes here are insufficient to handle the FD
leaks. That is,
flight 150369 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 150360
Tests which did not
flight 150360 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150360/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150308
test-amd64-amd64-xl-qemuu-win7-amd64 17
flight 150358 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150358/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail in 150355 pass in 150358
test-amd64-amd64-xl-rtds 17
Hello All,
This is gentle reminder about this RFC.
Sadly, Andrii Anisov has left our team. But I'm commited to continue
his work on time accounting and real time scheduling.
I do realize, that proposed patches have become moldy. I can rebase
them onto current master, if it would help.
On
flight 150362 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150362/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 150356
Tests which did not
On 25.05.2020 19:30, Andrew Cooper wrote:
> On 25/05/2020 16:23, Jan Beulich wrote:
>> On 25.05.2020 17:18, Jan Beulich wrote:
>>> Linux commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 says
>>>
>>> "Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET
>>> timer once the SoCs entered
46 matches
Mail list logo
