* [PATCH] x86/boot: re-arrange how/when we do disk I/O
@ 2017-06-12 15:11 Jan Beulich
2017-06-12 15:27 ` Jan Beulich
2017-06-12 15:33 ` Andrew Cooper
0 siblings, 2 replies; 6+ messages in thread
From: Jan Beulich @ 2017-06-12 15:11 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Julien Grall, Paul Durrant
[-- Attachment #1: Type: text/plain, Size: 6536 bytes --]
We place the trampoline no lower than at 256k, so we have ample space
to read the MBRs of BIOS disks into an aligned buffer right below the
trampoline (not doing so has been found to be a problem on a buggy BIOS
coming with a Skull Canyon NUC). To facilitate that move MBR reading
past EDD info retrieval.
Also add a wrap check to the EDD info retrieval loop, to match that in
the MBR reading one.
Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
---
Using 512-byte sector size as default right now - perhaps worth
considering to use 4k instead. I'm also not sure whether we shouldn't
sanity check the sector size some more.
--- a/xen/arch/x86/boot/edd.S
+++ b/xen/arch/x86/boot/edd.S
@@ -26,46 +26,6 @@
get_edd:
cmpb $2, bootsym(opt_edd) # edd=off ?
je edd_done
- cmpb $1, bootsym(opt_edd) # edd=skipmbr ?
- je edd_start
-
-# Read the first sector of each BIOS disk device and store the 4-byte signature
-edd_mbr_sig_start:
- movb $0x80, %dl # from device 80
- movw $bootsym(boot_mbr_signature),%bx # store buffer ptr in bx
-edd_mbr_sig_read:
- pushw %bx
- movb $0x02, %ah # 0x02 Read Sectors
- movb $1, %al # read 1 sector
- movb $0, %dh # at head 0
- movw $1, %cx # cylinder 0, sector 0
- pushw %es
- pushw %ds
- popw %es
- movw $bootsym(boot_edd_info), %bx # disk's data goes into info
- pushw %dx # work around buggy BIOSes
- stc # work around buggy BIOSes
- int $0x13
- sti # work around buggy BIOSes
- popw %dx
- popw %es
- popw %bx
- jc edd_mbr_sig_done # on failure, we're done.
- cmpb $0, %ah # some BIOSes do not set CF
- jne edd_mbr_sig_done # on failure, we're done.
- cmpw $0xaa55, bootsym(boot_edd_info)+0x1fe
- jne .Ledd_mbr_sig_next
- movl bootsym(boot_edd_info)+EDD_MBR_SIG_OFFSET,%eax
- movb %dl, (%bx) # store BIOS drive number
- movl %eax, 4(%bx) # store signature from MBR
- incb bootsym(boot_mbr_signature_nr) # note that we stored something
- addw $8, %bx # increment sig buffer ptr
-.Ledd_mbr_sig_next:
- incb %dl # increment to next device
- jz edd_mbr_sig_done
- cmpb $EDD_MBR_SIG_MAX,bootsym(boot_mbr_signature_nr)
- jb edd_mbr_sig_read
-edd_mbr_sig_done:
# Do the BIOS Enhanced Disk Drive calls
# This consists of two calls:
@@ -136,10 +96,71 @@ edd_legacy_done:
edd_next:
incb %dl # increment to next device
+ jz edd_done
cmpb $EDD_INFO_MAX,bootsym(boot_edd_info_nr)
jb edd_check_ext
edd_done:
+ cmpb $1, bootsym(opt_edd) # edd=skipmbr ?
+ je .Ledd_mbr_sig_skip
+
+# Read the first sector of each BIOS disk device and store the 4-byte signature
+.Ledd_mbr_sig_start:
+ pushw %es
+ movb $0x80, %dl # from device 80
+ movw $bootsym(boot_mbr_signature), %bx # store buffer ptr in bx
+.Ledd_mbr_sig_read:
+ pushw %bx
+ movw $bootsym(boot_edd_info), %bx
+ movzbw bootsym(boot_edd_info_nr), %cx
+ jcxz .Ledd_mbr_sig_default
+.Ledd_mbr_sig_find_info:
+ cmpb %dl, (%bx)
+ ja .Ledd_mbr_sig_default
+ je .Ledd_mbr_sig_get_size
+ add $EDDEXTSIZE+EDDPARMSIZE, %bx
+ loop .Ledd_mbr_sig_find_info
+.Ledd_mbr_sig_default:
+ movw $(512 >> 4), %bx
+ jmp .Ledd_mbr_sig_set_buf
+.Ledd_mbr_sig_get_size:
+ movw EDDEXTSIZE+0x18(%bx), %bx # sector size
+ shr $4, %bx # convert to paragraphs
+ jz .Ledd_mbr_sig_default
+.Ledd_mbr_sig_set_buf:
+ movw %ds, %ax
+ subw %bx, %ax # disk's data goes right ahead
+ movw %ax, %es # of trampoline
+ xorw %bx, %bx
+ movw %bx, %es:0x1fe(%bx) # clear BIOS magic just in case
+ pushw %dx # work around buggy BIOSes
+ stc # work around buggy BIOSes
+ movw $0x0201, %ax # read 1 sector
+ movb $0, %dh # at head 0
+ movw $1, %cx # cylinder 0, sector 0
+ int $0x13
+ sti # work around buggy BIOSes
+ popw %dx
+ movw %es:0x1fe(%bx), %si
+ movl %es:EDD_MBR_SIG_OFFSET(%bx), %ecx
+ popw %bx
+ jc .Ledd_mbr_sig_done # on failure, we're done.
+ testb %ah, %ah # some BIOSes do not set CF
+ jnz .Ledd_mbr_sig_done # on failure, we're done.
+ cmpw $0xaa55, %si
+ jne .Ledd_mbr_sig_next
+ movb %dl, (%bx) # store BIOS drive number
+ movl %ecx, 4(%bx) # store signature from MBR
+ incb bootsym(boot_mbr_signature_nr) # note that we stored something
+ addw $8, %bx # increment sig buffer ptr
+.Ledd_mbr_sig_next:
+ incb %dl # increment to next device
+ jz .Ledd_mbr_sig_done
+ cmpb $EDD_MBR_SIG_MAX, bootsym(boot_mbr_signature_nr)
+ jb .Ledd_mbr_sig_read
+.Ledd_mbr_sig_done:
+ popw %es
+.Ledd_mbr_sig_skip:
ret
GLOBAL(boot_edd_info_nr)
@@ -149,4 +170,4 @@ GLOBAL(boot_mbr_signature_nr)
GLOBAL(boot_mbr_signature)
.fill EDD_MBR_SIG_MAX*8,1,0
GLOBAL(boot_edd_info)
- .fill 512,1,0 # big enough for a disc sector
+ .fill EDD_INFO_MAX * (EDDEXTSIZE + EDDPARMSIZE), 1, 0
[-- Attachment #2: x86-MBR-below-trampoline.patch --]
[-- Type: text/plain, Size: 6580 bytes --]
x86/boot: re-arrange how/when we do disk I/O
We place the trampoline no lower than at 256k, so we have ample space
to read the MBRs of BIOS disks into an aligned buffer right below the
trampoline (not doing so has been found to be a problem on a buggy BIOS
coming with a Skull Canyon NUC). To facilitate that move MBR reading
past EDD info retrieval.
Also add a wrap check to the EDD info retrieval loop, to match that in
the MBR reading one.
Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
---
Using 512-byte sector size as default right now - perhaps worth
considering to use 4k instead. I'm also not sure whether we shouldn't
sanity check the sector size some more.
--- a/xen/arch/x86/boot/edd.S
+++ b/xen/arch/x86/boot/edd.S
@@ -26,46 +26,6 @@
get_edd:
cmpb $2, bootsym(opt_edd) # edd=off ?
je edd_done
- cmpb $1, bootsym(opt_edd) # edd=skipmbr ?
- je edd_start
-
-# Read the first sector of each BIOS disk device and store the 4-byte signature
-edd_mbr_sig_start:
- movb $0x80, %dl # from device 80
- movw $bootsym(boot_mbr_signature),%bx # store buffer ptr in bx
-edd_mbr_sig_read:
- pushw %bx
- movb $0x02, %ah # 0x02 Read Sectors
- movb $1, %al # read 1 sector
- movb $0, %dh # at head 0
- movw $1, %cx # cylinder 0, sector 0
- pushw %es
- pushw %ds
- popw %es
- movw $bootsym(boot_edd_info), %bx # disk's data goes into info
- pushw %dx # work around buggy BIOSes
- stc # work around buggy BIOSes
- int $0x13
- sti # work around buggy BIOSes
- popw %dx
- popw %es
- popw %bx
- jc edd_mbr_sig_done # on failure, we're done.
- cmpb $0, %ah # some BIOSes do not set CF
- jne edd_mbr_sig_done # on failure, we're done.
- cmpw $0xaa55, bootsym(boot_edd_info)+0x1fe
- jne .Ledd_mbr_sig_next
- movl bootsym(boot_edd_info)+EDD_MBR_SIG_OFFSET,%eax
- movb %dl, (%bx) # store BIOS drive number
- movl %eax, 4(%bx) # store signature from MBR
- incb bootsym(boot_mbr_signature_nr) # note that we stored something
- addw $8, %bx # increment sig buffer ptr
-.Ledd_mbr_sig_next:
- incb %dl # increment to next device
- jz edd_mbr_sig_done
- cmpb $EDD_MBR_SIG_MAX,bootsym(boot_mbr_signature_nr)
- jb edd_mbr_sig_read
-edd_mbr_sig_done:
# Do the BIOS Enhanced Disk Drive calls
# This consists of two calls:
@@ -136,10 +96,71 @@ edd_legacy_done:
edd_next:
incb %dl # increment to next device
+ jz edd_done
cmpb $EDD_INFO_MAX,bootsym(boot_edd_info_nr)
jb edd_check_ext
edd_done:
+ cmpb $1, bootsym(opt_edd) # edd=skipmbr ?
+ je .Ledd_mbr_sig_skip
+
+# Read the first sector of each BIOS disk device and store the 4-byte signature
+.Ledd_mbr_sig_start:
+ pushw %es
+ movb $0x80, %dl # from device 80
+ movw $bootsym(boot_mbr_signature), %bx # store buffer ptr in bx
+.Ledd_mbr_sig_read:
+ pushw %bx
+ movw $bootsym(boot_edd_info), %bx
+ movzbw bootsym(boot_edd_info_nr), %cx
+ jcxz .Ledd_mbr_sig_default
+.Ledd_mbr_sig_find_info:
+ cmpb %dl, (%bx)
+ ja .Ledd_mbr_sig_default
+ je .Ledd_mbr_sig_get_size
+ add $EDDEXTSIZE+EDDPARMSIZE, %bx
+ loop .Ledd_mbr_sig_find_info
+.Ledd_mbr_sig_default:
+ movw $(512 >> 4), %bx
+ jmp .Ledd_mbr_sig_set_buf
+.Ledd_mbr_sig_get_size:
+ movw EDDEXTSIZE+0x18(%bx), %bx # sector size
+ shr $4, %bx # convert to paragraphs
+ jz .Ledd_mbr_sig_default
+.Ledd_mbr_sig_set_buf:
+ movw %ds, %ax
+ subw %bx, %ax # disk's data goes right ahead
+ movw %ax, %es # of trampoline
+ xorw %bx, %bx
+ movw %bx, %es:0x1fe(%bx) # clear BIOS magic just in case
+ pushw %dx # work around buggy BIOSes
+ stc # work around buggy BIOSes
+ movw $0x0201, %ax # read 1 sector
+ movb $0, %dh # at head 0
+ movw $1, %cx # cylinder 0, sector 0
+ int $0x13
+ sti # work around buggy BIOSes
+ popw %dx
+ movw %es:0x1fe(%bx), %si
+ movl %es:EDD_MBR_SIG_OFFSET(%bx), %ecx
+ popw %bx
+ jc .Ledd_mbr_sig_done # on failure, we're done.
+ testb %ah, %ah # some BIOSes do not set CF
+ jnz .Ledd_mbr_sig_done # on failure, we're done.
+ cmpw $0xaa55, %si
+ jne .Ledd_mbr_sig_next
+ movb %dl, (%bx) # store BIOS drive number
+ movl %ecx, 4(%bx) # store signature from MBR
+ incb bootsym(boot_mbr_signature_nr) # note that we stored something
+ addw $8, %bx # increment sig buffer ptr
+.Ledd_mbr_sig_next:
+ incb %dl # increment to next device
+ jz .Ledd_mbr_sig_done
+ cmpb $EDD_MBR_SIG_MAX, bootsym(boot_mbr_signature_nr)
+ jb .Ledd_mbr_sig_read
+.Ledd_mbr_sig_done:
+ popw %es
+.Ledd_mbr_sig_skip:
ret
GLOBAL(boot_edd_info_nr)
@@ -149,4 +170,4 @@ GLOBAL(boot_mbr_signature_nr)
GLOBAL(boot_mbr_signature)
.fill EDD_MBR_SIG_MAX*8,1,0
GLOBAL(boot_edd_info)
- .fill 512,1,0 # big enough for a disc sector
+ .fill EDD_INFO_MAX * (EDDEXTSIZE + EDDPARMSIZE), 1, 0
[-- Attachment #3: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
2017-06-12 15:11 [PATCH] x86/boot: re-arrange how/when we do disk I/O Jan Beulich
@ 2017-06-12 15:27 ` Jan Beulich
2017-06-12 16:59 ` Julien Grall
2017-06-12 15:33 ` Andrew Cooper
1 sibling, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2017-06-12 15:27 UTC (permalink / raw)
To: Julien Grall; +Cc: Andrew Cooper, Paul Durrant, xen-devel
>>> On 12.06.17 at 17:11, <JBeulich@suse.com> wrote:
> We place the trampoline no lower than at 256k, so we have ample space
> to read the MBRs of BIOS disks into an aligned buffer right below the
> trampoline (not doing so has been found to be a problem on a buggy BIOS
> coming with a Skull Canyon NUC). To facilitate that move MBR reading
> past EDD info retrieval.
>
> Also add a wrap check to the EDD info retrieval loop, to match that in
> the MBR reading one.
>
> Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
As to 4.9 inclusion, I think I should have mentioned right away
that such a change of course isn't without risk: We're trying to
work around a BIOS bug by relying on other information
coming from the BIOS being correct / usable. Obviously there is
the risk that this regresses with some other BIOS having a bug
elsewhere.
I'm therefore leaning towards suggesting to take this change
only for master right now, and consider pulling it into the 4.9
branch in a couple of weeks time, when the patch has seen at
least a little more testing on a wider set of systems.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
2017-06-12 15:11 [PATCH] x86/boot: re-arrange how/when we do disk I/O Jan Beulich
2017-06-12 15:27 ` Jan Beulich
@ 2017-06-12 15:33 ` Andrew Cooper
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Cooper @ 2017-06-12 15:33 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Julien Grall, Paul Durrant
On 12/06/17 16:11, Jan Beulich wrote:
> We place the trampoline no lower than at 256k, so we have ample space
> to read the MBRs of BIOS disks into an aligned buffer right below the
> trampoline (not doing so has been found to be a problem on a buggy BIOS
> coming with a Skull Canyon NUC). To facilitate that move MBR reading
> past EDD info retrieval.
>
> Also add a wrap check to the EDD info retrieval loop, to match that in
> the MBR reading one.
>
> Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
2017-06-12 15:27 ` Jan Beulich
@ 2017-06-12 16:59 ` Julien Grall
2017-06-26 13:03 ` Julien Grall
0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2017-06-12 16:59 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Paul Durrant, xen-devel
Hi Jan,
On 12/06/17 16:27, Jan Beulich wrote:
>>>> On 12.06.17 at 17:11, <JBeulich@suse.com> wrote:
>> We place the trampoline no lower than at 256k, so we have ample space
>> to read the MBRs of BIOS disks into an aligned buffer right below the
>> trampoline (not doing so has been found to be a problem on a buggy BIOS
>> coming with a Skull Canyon NUC). To facilitate that move MBR reading
>> past EDD info retrieval.
>>
>> Also add a wrap check to the EDD info retrieval loop, to match that in
>> the MBR reading one.
>>
>> Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
>
> As to 4.9 inclusion, I think I should have mentioned right away
> that such a change of course isn't without risk: We're trying to
> work around a BIOS bug by relying on other information
> coming from the BIOS being correct / usable. Obviously there is
> the risk that this regresses with some other BIOS having a bug
> elsewhere.
>
> I'm therefore leaning towards suggesting to take this change
> only for master right now, and consider pulling it into the 4.9
> branch in a couple of weeks time, when the patch has seen at
> least a little more testing on a wider set of systems.
I agree on your conclusion. I would suggest to add a release note if it
is not backported before the release.
I will keep track of this.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
2017-06-12 16:59 ` Julien Grall
@ 2017-06-26 13:03 ` Julien Grall
2017-06-26 15:14 ` Paul Durrant
0 siblings, 1 reply; 6+ messages in thread
From: Julien Grall @ 2017-06-26 13:03 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, lars.kurth@citrix.com, Paul Durrant, xen-devel
Hi,
On 12/06/17 17:59, Julien Grall wrote:
> Hi Jan,
>
> On 12/06/17 16:27, Jan Beulich wrote:
>>>>> On 12.06.17 at 17:11, <JBeulich@suse.com> wrote:
>>> We place the trampoline no lower than at 256k, so we have ample space
>>> to read the MBRs of BIOS disks into an aligned buffer right below the
>>> trampoline (not doing so has been found to be a problem on a buggy BIOS
>>> coming with a Skull Canyon NUC). To facilitate that move MBR reading
>>> past EDD info retrieval.
>>>
>>> Also add a wrap check to the EDD info retrieval loop, to match that in
>>> the MBR reading one.
>>>
>>> Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
>>
>> As to 4.9 inclusion, I think I should have mentioned right away
>> that such a change of course isn't without risk: We're trying to
>> work around a BIOS bug by relying on other information
>> coming from the BIOS being correct / usable. Obviously there is
>> the risk that this regresses with some other BIOS having a bug
>> elsewhere.
>>
>> I'm therefore leaning towards suggesting to take this change
>> only for master right now, and consider pulling it into the 4.9
>> branch in a couple of weeks time, when the patch has seen at
>> least a little more testing on a wider set of systems.
>
> I agree on your conclusion. I would suggest to add a release note if it
> is not backported before the release.
>
> I will keep track of this.
I haven't seen any update on this. Can someone describe briefly the
problem so we can add it in the section "known issues" of the release notes?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
2017-06-26 13:03 ` Julien Grall
@ 2017-06-26 15:14 ` Paul Durrant
0 siblings, 0 replies; 6+ messages in thread
From: Paul Durrant @ 2017-06-26 15:14 UTC (permalink / raw)
To: 'Julien Grall', Jan Beulich; +Cc: Andrew Cooper, Lars Kurth, xen-devel
> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@arm.com]
> Sent: 26 June 2017 14:04
> To: Jan Beulich <JBeulich@suse.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Paul Durrant
> <Paul.Durrant@citrix.com>; xen-devel <xen-devel@lists.xenproject.org>;
> Lars Kurth <lars.kurth@citrix.com>
> Subject: Re: [PATCH] x86/boot: re-arrange how/when we do disk I/O
>
> Hi,
>
> On 12/06/17 17:59, Julien Grall wrote:
> > Hi Jan,
> >
> > On 12/06/17 16:27, Jan Beulich wrote:
> >>>>> On 12.06.17 at 17:11, <JBeulich@suse.com> wrote:
> >>> We place the trampoline no lower than at 256k, so we have ample space
> >>> to read the MBRs of BIOS disks into an aligned buffer right below the
> >>> trampoline (not doing so has been found to be a problem on a buggy
> BIOS
> >>> coming with a Skull Canyon NUC). To facilitate that move MBR reading
> >>> past EDD info retrieval.
> >>>
> >>> Also add a wrap check to the EDD info retrieval loop, to match that in
> >>> the MBR reading one.
> >>>
> >>> Reported-by: Paul Durrant <Paul.Durrant@citrix.com>
> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>> Tested-by: Paul Durrant <Paul.Durrant@citrix.com>
> >>
> >> As to 4.9 inclusion, I think I should have mentioned right away
> >> that such a change of course isn't without risk: We're trying to
> >> work around a BIOS bug by relying on other information
> >> coming from the BIOS being correct / usable. Obviously there is
> >> the risk that this regresses with some other BIOS having a bug
> >> elsewhere.
> >>
> >> I'm therefore leaning towards suggesting to take this change
> >> only for master right now, and consider pulling it into the 4.9
> >> branch in a couple of weeks time, when the patch has seen at
> >> least a little more testing on a wider set of systems.
> >
> > I agree on your conclusion. I would suggest to add a release note if it
> > is not backported before the release.
> >
> > I will keep track of this.
>
> I haven't seen any update on this. Can someone describe briefly the
> problem so we can add it in the section "known issues" of the release notes?
>
Julien,
The symptom is an apparent failure to progress beyond the grub stage when trying to boot Xen on a skull canyon. You see the messages about loading the modules, but then nothing more except maybe a reset of the vga mode (depending on what your xen command line looks like).
The problem is a buggy BIOS which wedges in the int13 handler in some cases. Xen 4.9 happens to tickle this bug whereas Xen 4.8 got away with it.
Cheers,
Paul
> Cheers,
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-26 15:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-12 15:11 [PATCH] x86/boot: re-arrange how/when we do disk I/O Jan Beulich
2017-06-12 15:27 ` Jan Beulich
2017-06-12 16:59 ` Julien Grall
2017-06-26 13:03 ` Julien Grall
2017-06-26 15:14 ` Paul Durrant
2017-06-12 15:33 ` Andrew Cooper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).