On 8/14/19 8:26 PM, Daniel Vetter wrote:
On Tue, Aug 13, 2019 at 10:32:00AM +0300, Oleksandr Andrushchenko wrote:
On 8/13/19 9:27 AM, Nishka Dasgupta wrote:
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
arg
Hi Roger!
Some good news, some bad news ;-)
Good news is that on the newer BIOS, your original patch seems to work fine.
IOW, with newer BIOS:
1. without your original patch I see garbled screen
2. with your original patch everything boots normally.
Bad news is that with older BIOS, you
Code in intel.c:early_init_intel() modifies IA32_MISC_ENABLE MSR. Those
modifications must be restored after resuming from S3 (see e.g. Linux wakeup
code), otherwise bad things may happen (e.g. wakeup code may cause #GP when
trying to set IA32_EFER.NXE [1]).
This bug was noticed on a ThinkPad x230
flight 140282 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140282/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail in
140232 pass in 140282
test-armhf
microcode_update_lock is to prevent logic threads of a same core from
updating microcode at the same time. But due to using a global lock, it
also prevented parallel microcode updating on different cores.
Remove this lock in order to update microcode in parallel. It is safe
because we have already
register an nmi callback. And this callback does busy-loop on threads
which are waiting for loading completion. Control threads send NMI to
slave threads to prevent NMI acceptance during ucode loading.
Signed-off-by: Chao Gao
---
Changes in v9:
- control threads send NMI to all other threads. Sl
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.
Gather all cores
to replace the current per-cpu cache 'uci->mc'.
With the assumption that all CPUs in the system have the same signature
(family, model, stepping and 'pf'), one microcode update matches with
one cpu should match with others. Having multiple microcode revisions
on different cpus would cause system u
to a more generic function. So that it can be used alone to check
an update against the CPU signature and current update revision.
Note that enum microcode_match_result will be used in common code
(aka microcode.c), it has been placed in the common header.
Signed-off-by: Chao Gao
Reviewed-by: Ro
Two buffers, '->equiv_cpu_table' and '->mpb', inside 'mc_amd' might be
allocated and in the error-handing path they are not freed properly.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
Changes in v9:
- use xzalloc() to get rid of explicitly initializing some fields
to NULL/0.
changes
Remove the per-cpu cache field in struct ucode_cpu_info since it has
been replaced by a global cache. It would leads to only one field
remaining in ucode_cpu_info. Then, this struct is removed and the
remaining field (cpu signature) is stored in per-cpu area.
The cpu status notifier is also remove
Sometimes, an ucode with a level lower than or equal to current CPU's
patch level is useful. For example, to work around a broken bios which
only loads ucode for BSP, when BSP parses an ucode blob during bootup,
it is better to save an ucode with lower or equal level for APs
No functional change i
Previously, a per-cpu ucode cache is maintained. Then each CPU had one
per-cpu update cache and there might be multiple versions of microcode.
Thus microcode_resume_cpu tried best to update microcode by loading
every update cache until a successful load.
But now the cache struct is simplified a lo
Both are loading the cached patch. Since APs call the unified function,
microcode_update_one(), during wakeup, the 'start_update' parameter
which originally used to distinguish BSP and APs is redundant. So remove
this parameter.
Signed-off-by: Chao Gao
---
Note that here is a functional change: r
During late microcode loading, apply_microcode() is invoked in
cpu_request_microcode(). To make late microcode update more reliable,
we want to put the apply_microcode() into stop_machine context. So
we split out it from cpu_request_microcode(). In general, for both
early loading on BSP and late lo
Introduce a vendor hook, .end_update, for svm_host_osvw_init().
The hook function is called on each cpu after loading an update.
It is a preparation for spliting out apply_microcode() from
cpu_request_microcode().
Note that svm_host_osvm_init() should be called regardless of the
result of loading
apply_microcode()'s always loading the cached ucode patch forces
a patch to be stored before being loading. Make apply_microcode()
accept a patch pointer to remove the limitation so that a patch
can be stored after a successful loading.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
---
xen/a
Some callbacks in microcode_ops or related functions take a cpu
id parameter. But at current call sites, the cpu id parameter is
always equal to current cpu id. Some of them even use an assertion
to guarantee this. Remove this redundent 'cpu' parameter.
Signed-off-by: Chao Gao
Reviewed-by: Jan Be
To create a microcode patch from a vendor-specific update,
allocate_microcode_patch() copied everything from the update.
It is not efficient. Essentially, we just need to go through
ucodes in the blob, find the one with the newest revision and
install it into the microcode_patch. In the process, bu
Changes in version 9:
- add Jan's Reviewed-by
- rendevzous threads in NMI handler to disable NMI. Note that NMI can
be served as usual on threads that are chosen to initiate ucode loading
on each core.
- avoid unnecessary memory allocation or copy when creating a microcode
patch (patch 12)
-
flight 140255 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 139876
test-amd64-amd64-x
flight 140269 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl7 xen-boot fail REGR. vs. 139910
test-amd64-i386-xl-r
flight 140277 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139829
Tests which did not
flight 140251 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On 8/16/19 9:30 AM, tony.ngu...@bt.com wrote:
> Convert memory_region_dispatch_{read|write} operand "unsigned size"
> into a "MemOp op".
>
> Signed-off-by: Tony Nguyen
> Reviewed-by: Richard Henderson
> ---
> include/exec/memop.h | 20 ++--
> include/exec/memory.h | 9 +---
On 18/08/2019 18:20, Wei Liu wrote:
> On Fri, Jun 21, 2019 at 11:30:05AM +0200, Olaf Hering wrote:
>> xl(1) opens xl.conf in XEN_CONFIG_DIR.
>> Substitute this variable also in the man page.
>>
>> Signed-off-by: Olaf Hering
>> ---
>> docs/man/xl.1.pod.in | 2 +-
>> docs/man/xl.conf.5.pod.in
On Fri, Jun 21, 2019 at 11:30:05AM +0200, Olaf Hering wrote:
> xl(1) opens xl.conf in XEN_CONFIG_DIR.
> Substitute this variable also in the man page.
>
> Signed-off-by: Olaf Hering
> ---
> docs/man/xl.1.pod.in | 2 +-
> docs/man/xl.conf.5.pod.in | 2 +-
> 2 files changed, 2 insertions(+),
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tre
flight 140241 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
test-amd64-i386-qemu
On 8/16/19 8:38 AM, tony.ngu...@bt.com wrote:
> +static void adjust_endianness(MemoryRegion *mr, uint64_t *data, MemOp op)
> {
> +if ((op & MO_BSWAP) != mr->ops->endianness) {
> +switch (op & MO_SIZE) {
You'll want to use devend_memop() here, as previously discussed.
> @@ -2331,7 +23
On 8/16/19 8:38 AM, tony.ngu...@bt.com wrote:
> static uint64_t full_ldub_mmu(CPUArchState *env, target_ulong addr,
>TCGMemOpIdx oi, uintptr_t retaddr)
> {
> -return load_helper(env, addr, oi, retaddr, 1, false, false,
> - full_ldub_mmu);
On 8/16/19 8:38 AM, tony.ngu...@bt.com wrote:
> Preparation for collapsing the two byte swaps adjust_endianness and
> handle_bswap into the former.
>
> Call memory_region_dispatch_{read|write} with endianness encoded into
> the "MemOp op" operand.
>
> This patch does not change any behaviour as
>
flight 140238 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140238/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR.
vs. 139698
build-amd64
flight 140295 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140295/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f7efd9c792738f579e3c7062d8d3e90b21d8a771
baseline version:
xen 243c
On 8/16/19 7:28 AM, tony.ngu...@bt.com wrote:
> Tony Nguyen (42):
> configure: Define TARGET_ALIGNED_ONLY in configure
> tcg: TCGMemOp is now accelerator independent MemOp
> memory: Introduce size_memop
> target/mips: Access MemoryRegion with MemOp
> hw/s390x: Access MemoryRegion with Mem
Hi,
Would you please help confirm why the condition at line 908 is ">="?
In my opinion, we would only hit "skb_shinfo(skb)->nr_frag == MAX_SKB_FRAGS" at
line 908.
890 static RING_IDX xennet_fill_frags(struct netfront_queue *queue,
891 struct sk_buff *skb,
892
flight 140235 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140235/
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 139794
test-amd64-amd64-xl-qemuu-
37 matches
Mail list logo
