On 27/09/2017 16:35, Kevin O'Connor wrote:
> On Wed, Sep 27, 2017 at 04:15:49PM +0200, Paolo Bonzini wrote:
>> On 27/09/2017 15:58, Kevin O'Connor wrote:
>>> On Wed, Sep 27, 2017 at 09:36:01AM +0200, Paolo Bonzini wrote:
On 21/06/2017 00:44, Kevin O'Connor wrote:
>> Yes, I think so. I'm
On Wed, Sep 27, 2017 at 04:15:49PM +0200, Paolo Bonzini wrote:
> On 27/09/2017 15:58, Kevin O'Connor wrote:
> > On Wed, Sep 27, 2017 at 09:36:01AM +0200, Paolo Bonzini wrote:
> >> On 21/06/2017 00:44, Kevin O'Connor wrote:
> Yes, I think so. I'm not sure why virtqueues are allocated
>
On 27/09/2017 15:58, Kevin O'Connor wrote:
> On Wed, Sep 27, 2017 at 09:36:01AM +0200, Paolo Bonzini wrote:
>> On 21/06/2017 00:44, Kevin O'Connor wrote:
Yes, I think so. I'm not sure why virtqueues are allocated
in low memory. Either cargo culting, or a remain of when
virtio was
On Wed, Sep 27, 2017 at 09:36:01AM +0200, Paolo Bonzini wrote:
> On 21/06/2017 00:44, Kevin O'Connor wrote:
> >> Yes, I think so. I'm not sure why virtqueues are allocated
> >> in low memory. Either cargo culting, or a remain of when
> >> virtio was a 16-bit driver, if it ever was.
> > The
On 21/06/2017 00:44, Kevin O'Connor wrote:
>> Yes, I think so. I'm not sure why virtqueues are allocated
>> in low memory. Either cargo culting, or a remain of when
>> virtio was a 16-bit driver, if it ever was.
> The 'struct drive_s' storage currently must be allocated in the
> f-segment so
On Fri, Jul 07, 2017 at 04:14:01PM +0200, Paolo Bonzini wrote:
>
>
> On 21/06/2017 00:44, Kevin O'Connor wrote:
> > On Tue, Jun 20, 2017 at 04:05:32PM -0400, Paolo Bonzini wrote:
> >>> If virtio-scsi didn't need to allocate any space in the f-segment,
> >>> does this problem go away in practice?
On 21/06/2017 00:44, Kevin O'Connor wrote:
> On Tue, Jun 20, 2017 at 04:05:32PM -0400, Paolo Bonzini wrote:
>>> If virtio-scsi didn't need to allocate any space in the f-segment,
>>> does this problem go away in practice?
>>
>> Yes, I think so. I'm not sure why virtqueues are allocated
>> in
On Tue, Jun 20, 2017 at 04:05:32PM -0400, Paolo Bonzini wrote:
> > If virtio-scsi didn't need to allocate any space in the f-segment,
> > does this problem go away in practice?
>
> Yes, I think so. I'm not sure why virtqueues are allocated
> in low memory. Either cargo culting, or a remain of
> Alas, none of these options seem appealing to me.
>
> If virtio-scsi didn't need to allocate any space in the f-segment,
> does this problem go away in practice?
Yes, I think so. I'm not sure why virtqueues are allocated
in low memory. Either cargo culting, or a remain of when
virtio was a
On Tue, Jun 20, 2017 at 04:14:12PM +0200, Paolo Bonzini wrote:
> We have four policies:
>
> 1) LUN0 only
>
> 2) higher LUNs in lower targets win
>
> 3) LUN0 in all targets win
>
> 4) LUNs up to N and bootable ones in all targets win
>
> (2) causes regressions so it's worse. (3) and (4)
On 20/06/2017 15:59, Roman Kagan wrote:
> On Tue, Jun 20, 2017 at 02:42:15PM +0200, Paolo Bonzini wrote:
> But does the LUN processing order matter per se? Doesn't fixing it only
> change which LUNs are more likely to fall out?
For a long time, only LUN0 was booted from (or in fact available
On Tue, Jun 20, 2017 at 02:42:15PM +0200, Paolo Bonzini wrote:
> On 19/06/2017 23:55, Roman Kagan wrote:
> > On Mon, Jun 19, 2017 at 06:21:09PM +0200, Paolo Bonzini wrote:
> >> The introduction of REPORT LUNS caused a potential regression when
> >> many disks are present on the same SCSI target.
On 19/06/2017 23:55, Roman Kagan wrote:
> On Mon, Jun 19, 2017 at 06:21:09PM +0200, Paolo Bonzini wrote:
>> The introduction of REPORT LUNS caused a potential regression when
>> many disks are present on the same SCSI target. If LUN0 is processed
>> too late, SeaBIOS might run out of memory and
On Mon, Jun 19, 2017 at 06:21:09PM +0200, Paolo Bonzini wrote:
> The introduction of REPORT LUNS caused a potential regression when
> many disks are present on the same SCSI target. If LUN0 is processed
> too late, SeaBIOS might run out of memory and fail to register it.
>
> There are two kinds
The introduction of REPORT LUNS caused a potential regression when
many disks are present on the same SCSI target. If LUN0 is processed
too late, SeaBIOS might run out of memory and fail to register it.
There are two kinds of problems:
- QEMU presents the results of REPORT LUNS in the opposite
15 matches
Mail list logo
