Re: [Xen-devel] gcc version used by developers

>>> On 27.11.17 at 20:43, wrote: > what version of gcc do Xen developers use for Xen? Is gcc 5.4 or 6.4 safe > to use? I think it's the other way around - if you find issues with any gcc version new enough for the build process to not bail out, and which aren't described

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

>>> On 27.11.17 at 17:58, wrote: > On 27/11/17 15:41, Daniel Kiper wrote: >> If it is possible we would like to have the Xen image higher than the >> booloader put it and certainly do not overwrite the Xen code and data >> during copy/relocation. Otherwise the Xen may

[Xen-devel] [qemu-mainline test] 116595: regressions - FAIL

remotes/dgibson/tags/ppc-for-2.11-20171127' into staging ppc patch queue 2017-11-27 This series contains a couple of migration fixes for hash guests on POWER9 radix MMU hosts. # gpg: Signature made Mon 27 Nov 2017 04:27:15 GMT # gpg:using RSA key 0x6C

[Xen-devel] 答复: 答复: 答复: Re: Help：Can xen restore several snapshots more faster at same time？

linux-lv5f:/home/huawei/vm/win7_x64 # Parsing config from win7_40.cfg WARNING: you seem to be using "kernel" directive to override HVM guest firmware. Ignore that. Use "firmware_override" instead if you really want a non-default firmware libxl: debug: libxl_create.c:1614:do_domain_create: ao

[Xen-devel] [seabios test] 116591: regressions - FAIL

flight 116591 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116591/ 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

Re: [Xen-devel] [PATCH] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

On 11/27/2017 02:22 PM, Juergen Gross wrote: > On 27/11/17 19:05, Boris Ostrovsky wrote: >> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make >> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses >> eflags using 'pushfq' instruction when testing for IF bit. On PV

[Xen-devel] [qemu-mainline test] 116583: regressions - FAIL

gibson/tags/ppc-for-2.11-20171127' into staging ppc patch queue 2017-11-27 This series contains a couple of migration fixes for hash guests on POWER9 radix MMU hosts. # gpg: Signature made Mon 27 Nov 2017 04:27:15 GMT # gpg:using RSA key 0x6C38CACA

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

On Mon, Nov 27, 2017 at 04:58:52PM +, Andrew Cooper wrote: > On 27/11/17 15:41, Daniel Kiper wrote: > > If it is possible we would like to have the Xen image higher than the > > booloader put it and certainly do not overwrite the Xen code and data > > during copy/relocation. Otherwise the Xen

[Xen-devel] [xen-unstable-smoke test] 116587: tolerable all pass - PUSHED

flight 116587 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/116587/ 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

[Xen-devel] [linux-linus test] 116577: regressions - FAIL

flight 116577 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116577/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 115643

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

From: Eduardo Otubo Date: Thu, 23 Nov 2017 15:18:35 +0100 > v2: > * Replace busy wait with wait_event()/wake_up_all() > * Cannot garantee that at the time xennet_remove is called, the >xen_netback state will not be XenbusStateClosed, so added a >condition for that >

[Xen-devel] [seabios test] 116580: regressions - FAIL

flight 116580 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116580/ 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

Re: [Xen-devel] [PATCH] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

On 27/11/17 19:05, Boris Ostrovsky wrote: > Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make > them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses > eflags using 'pushfq' instruction when testing for IF bit. On PV Xen > guests looking at IF flag directly will

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: > > > On 11/23/2017 03:11 AM, Christian König wrote: >> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: >>> On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: > On 11/22/2017 05:09 AM, Christian

Re: [Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

On 27/11/17 17:01, Jan Beulich wrote: On 26.10.17 at 19:03, wrote: >> --- a/xen/arch/x86/hvm/vmx/vvmx.c >> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >> @@ -361,6 +361,40 @@ static void reg_write(struct cpu_user_regs *regs, >> *pval = value; >> } >> >> +static int

[Xen-devel] [PATCH] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses eflags using 'pushfq' instruction when testing for IF bit. On PV Xen guests looking at IF flag directly will always see it set, resulting in 'ud2'. Introduce

Re: [Xen-devel] [PATCH 4/9] x86/vvmx: Remove unnecessary VMX operand reads

>>> On 26.10.17 at 19:03, wrote: > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -1801,7 +1801,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs) > unsigned long gpa = 0; > int rc; > > -rc = decode_vmx_inst(regs, , , 0);

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

On 27/11/17 15:41, Daniel Kiper wrote: > If it is possible we would like to have the Xen image higher than the > booloader put it and certainly do not overwrite the Xen code and data > during copy/relocation. Otherwise the Xen may crash silently at boot. > > Signed-off-by: Daniel Kiper

Re: [Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

>>> On 26.10.17 at 19:03, wrote: > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -361,6 +361,40 @@ static void reg_write(struct cpu_user_regs *regs, > *pval = value; > } > > +static int operand_read(void *buf, struct vmx_inst_op *op, >

[Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

This is follow-up to our conversation during community call. You asked me to send OP-TEE mediator as a patch, so we can discuss it in the mailing list. So, there it is. I squashed two patches into one and skipped patches that we already discussed. So, this is basically all what is needed to

[Xen-devel] [PATCH V3 20/29] xen: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't extract the domain number. Other places, use

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

>>> On 27.11.17 at 16:41, wrote: > If it is possible we would like to have the Xen image higher than the > booloader put it and certainly do not overwrite the Xen code and data > during copy/relocation. Otherwise the Xen may crash silently at boot. Is this something that

Re: [Xen-devel] [PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

On Mon, Nov 27, 2017 at 04:30:36PM +, George Dunlap wrote: > On 11/27/2017 03:12 PM, Anthony PERARD wrote: > > On Wed, Nov 22, 2017 at 07:20:15PM +, George Dunlap wrote: > >> x86-specific virtual hardware provided by the hypervisor, toolstack, > >> or QEMU. > >> > >> Signed-off-by: George

Re: [Xen-devel] [PATCH v3 08/17] SUPPORT.md: Add x86-specific virtual hardware

On 11/27/2017 03:12 PM, Anthony PERARD wrote: > On Wed, Nov 22, 2017 at 07:20:15PM +, George Dunlap wrote: >> x86-specific virtual hardware provided by the hypervisor, toolstack, >> or QEMU. >> >> Signed-off-by: George Dunlap >> --- >> Changes since v2: >> - Updated

Re: [Xen-devel] [PATCH v3 3/4] x86emul: Support vaes insns

>>> On 10.11.17 at 11:36, wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -1626,6 +1626,7 @@ static bool vcpu_has( > #define vcpu_has_clwb()vcpu_has( 7, EBX, 24, ctxt, ops) > #define vcpu_has_sha()

Re: [Xen-devel] [PATCH v3 2/4] x86emul: Support vpclmulqdq

>>> On 10.11.17 at 11:36, wrote: > @@ -7672,7 +7673,12 @@ x86_emulate( > host_and_vcpu_must_have(pclmulqdq); > if ( vex.opcx == vex_none ) > goto simd_0f3a_common; > -generate_exception_if(vex.l, EXC_UD); > +if ( !vex.l ) > +

Re: [Xen-devel] [PATCH v3 1/4] x86emul: Support GFNI insns

>>> On 10.11.17 at 11:36, wrote: > Signed-off-by: Yang Zhong First and foremost - did you try out your own patch? There not being any (minimal) test added makes this at least questionable. > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++

[Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

If it is possible we would like to have the Xen image higher than the booloader put it and certainly do not overwrite the Xen code and data during copy/relocation. Otherwise the Xen may crash silently at boot. Signed-off-by: Daniel Kiper --- xen/arch/x86/setup.c |8

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On Mon, Nov 27, 2017 at 02:58:38PM +, George Dunlap wrote: > On 11/27/2017 02:39 PM, Roger Pau Monné wrote: > > On Mon, Nov 27, 2017 at 02:12:40PM +, George Dunlap wrote: > >> On 11/27/2017 11:43 AM, Roger Pau Monné wrote: > >>> On Wed, Nov 22, 2017 at 07:20:12PM +, George Dunlap

Re: [Xen-devel] [PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

>>> On 27.11.17 at 15:48, wrote: > On 11/23/2017 11:17 AM, Jan Beulich wrote: > On 22.11.17 at 20:20, wrote: >>> Signed-off-by: George Dunlap >> >> With the XXX suitably addressed >> Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 for-next 7/9] coverage: introduce support for llvm profiling

>>> On 09.11.17 at 12:13, wrote: > Introduce the functionality in order to fill the hooks of the > cov_sysctl_ops struct. Note that the functionality is still not wired > into the build system. > > Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH] migration, xen: Fix block image lock issue on live migration

Hi Julien, Can I get a release-ack for this patch? This fix local live migration of HVM guest when the disk backend is qdisk. osstest doesn't report a regression because the kernel or the glibc is just a bit too old. Thanks, On Wed, Nov 22, 2017 at 09:45:03AM +0100, Juan Quintela wrote: >

Re: [Xen-devel] [PATCH v2 for-next 6/9] kconfig/gcov: rename to coverage

>>> On 09.11.17 at 12:13, wrote: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -115,9 +115,13 @@ subdir-all := $(subdir-y) $(subdir-n) > > $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += > -DINIT_SECTIONS_ONLY > > -ifeq ($(CONFIG_GCOV),y) > +ifeq

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On 11/27/2017 02:39 PM, Roger Pau Monné wrote: > On Mon, Nov 27, 2017 at 02:12:40PM +, George Dunlap wrote: >> On 11/27/2017 11:43 AM, Roger Pau Monné wrote: >>> On Wed, Nov 22, 2017 at 07:20:12PM +, George Dunlap wrote: For now only include xl-specific features, or interaction with

Re: [Xen-devel] [PATCH v2 for-next 4/9] gcov: introduce hooks for the sysctl

>>> On 09.11.17 at 12:13, wrote: > So that other implementations of the sysctl can be added. > > Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 for-next 1/9] kconfig/gcov: remove gcc version choice from kconfig

>>> On 09.11.17 at 12:13, wrote: > Use autodetect only. > > Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v3 14/17] SUPPORT.md: Add statement on PCI passthrough

On 11/23/2017 11:17 AM, Jan Beulich wrote: On 22.11.17 at 20:20, wrote: >> Signed-off-by: George Dunlap > > With the XXX suitably addressed > Acked-by: Jan Beulich Would you give an Ack for the XXX line simply removed

Re: [Xen-devel] [PATCH v13 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

>>> On 30.10.17 at 18:48, wrote: > This patch allows grant table frames to be mapped using the > XENMEM_acquire_resource memory op. > > NOTE: This patch expands the on-stack mfn_list array in acquire_resource() > but it is still small enough to remain on-stack. >

Re: [Xen-devel] [PATCH v2 for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting

>>> On 27.11.17 at 14:02, wrote: > Xen 4.8 and later virtualises CPUID Faulting support for guests. However, the > value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning > that the current cpuid faulting setting is lost on migrate/suspend/resume. >

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On 11/27/2017 02:39 PM, Roger Pau Monné wrote: > On Mon, Nov 27, 2017 at 02:12:40PM +, George Dunlap wrote: >> On 11/27/2017 11:43 AM, Roger Pau Monné wrote: >>> On Wed, Nov 22, 2017 at 07:20:12PM +, George Dunlap wrote: For now only include xl-specific features, or interaction with

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On Mon, Nov 27, 2017 at 02:12:40PM +, George Dunlap wrote: > On 11/27/2017 11:43 AM, Roger Pau Monné wrote: > > On Wed, Nov 22, 2017 at 07:20:12PM +, George Dunlap wrote: > >> For now only include xl-specific features, or interaction with the > >> system. Feature support matrix will be

Re: [Xen-devel] [PATCH v3 16/17] SUPPORT.md: Add limits RFC

On 11/24/2017 08:14 AM, Jan Beulich wrote: On 23.11.17 at 18:21, wrote: >> On 11/23/2017 11:21 AM, Jan Beulich wrote: >> On 22.11.17 at 20:20, wrote: +### Virtual RAM + +Limit-security, x86 PV 64-bit: 2047GiB +

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On 11/27/2017 11:43 AM, Roger Pau Monné wrote: > On Wed, Nov 22, 2017 at 07:20:12PM +, George Dunlap wrote: >> For now only include xl-specific features, or interaction with the >> system. Feature support matrix will be added when features are >> mentioned. >> >> Signed-off-by: George Dunlap

Re: [Xen-devel] [PATCH 1/3] x86: replace bad ASSERT() in xenmem_add_to_physmap_one()

On 11/27/2017 09:11 AM, Jan Beulich wrote: > There are no locks being held, i.e. it is possible to be triggered by > racy hypercall invocations. Subsequent code doesn't really depend on the > checked values, so this is not a security issue. > > Signed-off-by: Jan Beulich

Re: [Xen-devel] Xen PV breakage after IRQ stack code refactoring

On 11/27/2017 12:34 AM, Juergen Gross wrote: > On 27/11/17 05:03, Andy Lutomirski wrote: >> On Sun, Nov 26, 2017 at 9:10 AM, Boris Ostrovsky >> wrote: >>> Andy, >>> >>> (Can't find the original patch in my mailbox) >>> >>> This hunk from 1d3e53e8624a ("x86/entry/64:

Re: [Xen-devel] [PATCH for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting

>>> On 27.11.17 at 12:37, wrote: > On 27/11/17 09:53, Jan Beulich wrote: > On 25.11.17 at 19:15, wrote: >>> @@ -1311,10 +1311,49 @@ long arch_do_domctl( >>> vmsrs->msr_count = nr_msrs; >>> else >>>

[Xen-devel] [PATCH v2 for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting

Xen 4.8 and later virtualises CPUID Faulting support for guests. However, the value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning that the current cpuid faulting setting is lost on migrate/suspend/resume. To move this MSR, use the new guest_{rd,wr}msr() infrastructure.

Re: [Xen-devel] 答复: 答复: Re: Help：Can xen restore several snapshots more faster at same time？

On Mon, Nov 27, 2017 at 12:35:26PM +, Chenjia (C) wrote: > when we use the Xen4.8.7(we compile from the source and install on SUSE 12 ), > if we create the VM, we got the error information: > > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: > /etc/xen/scripts/vif-bridge

[Xen-devel] 答复: 答复: Re: Help：Can xen restore several snapshots more faster at same time？

when we use the Xen4.8.7(we compile from the source and install on SUSE 12 ), if we create the VM, we got the error information: libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge online [8284] exited with error status 127 libxl: error:

Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

Hi Sameer, On 22/11/17 02:17, Goel, Sameer wrote: On 11/20/2017 7:25 AM, Julien Grall wrote: On 19/11/17 07:45, Goel, Sameer wrote: On 10/12/2017 10:36 AM, Julien Grall wrote: Please use #if 0 rather than removing the code + comment on top. But I am not sure why you drop the S2 free code.

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

On 27/11/17 08:28, Jan Beulich wrote: > handle_hvm_io_completion() is being involved in resuming from requests > sent to a device model only, while re-invocation of internally handled > I/O which couldn't be handled in one go simply re-starts the affected > instruction. When an internally handled

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On Wed, Nov 22, 2017 at 07:20:12PM +, George Dunlap wrote: > For now only include xl-specific features, or interaction with the > system. Feature support matrix will be added when features are > mentioned. > > Signed-off-by: George Dunlap > --- > CC: Ian Jackson

Re: [Xen-devel] [PATCH 3/3] improve XENMEM_add_to_physmap_batch address checking

On 27/11/17 09:12, Jan Beulich wrote: > As a follow-up to XSA-212 we should have addressed a similar issue here: > The handles being advanced at the top of xenmem_add_to_physmap_batch() > means we allow hypervisor space accesses (in particular, for "errs", > writes) with suitably crafted input

Re: [Xen-devel] [PATCH 2/3] x86: check paging mode earlier in xenmem_add_to_physmap_one()

On 27/11/17 09:12, Jan Beulich wrote: > There's no point in deferring this until after some initial processing, > and it's actively wrong for the XENMAPSPACE_gmfn_foreign handling to not > have such a check at all. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [Xen-devel] [PATCH 3/3 v3] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform

On 27 November 2017 at 10:30, Julien Grall wrote: > + Graeme > > On 27/11/17 10:06, Jan Beulich wrote: > > On 24.11.17 at 12:39, wrote: >>> >>> --- a/xen/drivers/char/ns16550.c >>> +++ b/xen/drivers/char/ns16550.c >>> @@ -1571,6

Re: [Xen-devel] [PATCH 3/3 v3] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform

+ Graeme On 27/11/17 10:06, Jan Beulich wrote: On 24.11.17 at 12:39, wrote: --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -1571,6 +1571,30 @@ DT_DEVICE_END #endif /* HAS_DEVICE_TREE */ #if defined(CONFIG_ACPI) && defined(CONFIG_ARM)

Re: [Xen-devel] [PATCH v3 05/17] SUPPORT.md: Toolstack core

On 11/24/2017 04:26 PM, Ian Jackson wrote: > George Dunlap writes ("[PATCH v3 05/17] SUPPORT.md: Toolstack core"): >> For now only include xl-specific features, or interaction with the >> system. Feature support matrix will be added when features are >> mentioned. > ... >> +## Toolstack >> + >>

[Xen-devel] [PATCH 3/3] improve XENMEM_add_to_physmap_batch address checking

As a follow-up to XSA-212 we should have addressed a similar issue here: The handles being advanced at the top of xenmem_add_to_physmap_batch() means we allow hypervisor space accesses (in particular, for "errs", writes) with suitably crafted input arguments. This isn't a security issue in this

[Xen-devel] [PATCH 1/3] x86: replace bad ASSERT() in xenmem_add_to_physmap_one()

There are no locks being held, i.e. it is possible to be triggered by racy hypercall invocations. Subsequent code doesn't really depend on the checked values, so this is not a security issue. Signed-off-by: Jan Beulich --- I'm up for to better suggestions for the EXDEV I've

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

On 23/11/17 15:18, Eduardo Otubo wrote: > v2: > * Replace busy wait with wait_event()/wake_up_all() > * Cannot garantee that at the time xennet_remove is called, the >xen_netback state will not be XenbusStateClosed, so added a >condition for that > * There's a small chance for the

[Xen-devel] [PATCH 0/3] XENMEM_add_to_physmap handling adjustments

I'd like to put up the following three changes for consideration of inclusion in 4.10. Especially when taking only release builds into account (relevant to patch 1), they're not much more than cosmetic changes, but imo they still are an overall improvement to code quality. 1: x86: replace bad