flight 131788 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131788/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131743
test-armhf-armhf-libvirt 14 sav
flight 131780 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 broken
test-amd64-i386-qemut-rhel6hvm-intel
>>> On 28.12.18 at 13:04, wrote:
> @@ -113,6 +115,47 @@ uint64_t pv_shim_mem(uint64_t avail)
> return shim_nrpages;
> }
>
> +static void __init mark_pfn_as_ram(struct e820map *e820, uint64_t pfn)
> +{
> +if ( !e820_add_range(e820, pfn << PAGE_SHIFT,
> + (pfn <<
>>> On 08.01.19 at 09:30, wrote:
>> -Original Message-
> [snip]
>> >
>> > The use of iommu_use_hap_pt() here is indeed a problem, but I think it
>> would be sufficient to move the line "hd->status =
>> IOMMU_STATUS_initializing" to just before the if rather than to a
>> completely separat
>>> On 07.01.19 at 18:34, wrote:
> On 07/01/2019 10:36, Jan Beulich wrote:
> On 31.12.18 at 18:34, wrote:
>>> A NT_GNU_BUILD_ID with namesz longer than 4 will cause the strncmp() to use
>>> bytes in adjacent stringtable entries.
>>>
>>> Instead, check for namesz exactly equal to 4,
>> Is that
>>> On 07.01.19 at 18:28, wrote:
> On 07/01/2019 08:59, Jan Beulich wrote:
>>> @@ -271,6 +297,27 @@ int parse_boolean(const char *name, const char *s,
> const char *e)
>>> return -1;
>>> }
>>>
>>> +int cmdline_strcmp(const char *frag, const char *name)
>> So you've decided to retain the s
> -Original Message-
[snip]
> >
> > The use of iommu_use_hap_pt() here is indeed a problem, but I think it
> would be sufficient to move the line "hd->status =
> IOMMU_STATUS_initializing" to just before the if rather than to a
> completely separate function.
>
> Yes, that works too.
>
>
oops. Please ignore this v5 patch.
I just realized Linus suggested in an old email not use BUG()/BUG_ON() in the
code.
I will switch to the WARN() solution and resend again.
Sorry for the junk email.
Dongli Zhang
On 2019/1/8 下午4:15, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is used
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the 'r
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
Reviewed-by: Paul Durrant
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkback/xenbus.c | 27 ++--
>>> On 07.01.19 at 20:16, wrote:
> On Mon, 7 Jan 2019, Jan Beulich wrote:
>> >>> On 03.01.19 at 20:19, wrote:
>> > --- a/xen/common/virtual_region.c
>> > +++ b/xen/common/virtual_region.c
>> > @@ -119,7 +119,11 @@ void __init setup_virtual_regions(const struct
>> > exception_table_entry *start,
>>> On 07.01.19 at 20:33, wrote:
> On Mon, 7 Jan 2019, Jan Beulich wrote:
>> >>> On 03.01.19 at 20:19, wrote:
>> > --- a/xen/arch/x86/alternative.c
>> > +++ b/xen/arch/x86/alternative.c
>> > @@ -194,7 +194,7 @@ void init_or_livepatch apply_alternatives(struct
>> > alt_instr *start,
>> > *
flight 131789 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
>>> On 07.01.19 at 19:29, wrote:
> On Mon, 7 Jan 2019, Jan Beulich wrote:
>> >>> On 04.01.19 at 18:05, wrote:
>> > I realize that you are not convinced by these arguments, but let's find
>> > a way forward. My preference would be to have SYMBOL returning unsigned
>> > long and do unsigned long co
101 - 114 of 114 matches
Mail list logo
