>>> On 23.06.15 at 09:29, wrote:
> FreeBSD never supported PV Dom0 operation, it only had a very minimal
> and crappy i386 PV DomU support which has now been completely removed.
> Maybe you are confusing it with NetBSD, which does have PV Dom0 support
> since a long time ago?
Very likely.
> Yes,
El 23/06/15 a les 9.20, Jan Beulich ha escrit:
On 22.06.15 at 19:02, wrote:
>> OK, I didn't get the part of the question. AFAICT yes, FreeBSD will
>> access the low 256 bytes of the config space. For example the stub to
>> write to a cfg register is as follows:
>>
>> void
>> pci_cfgregwrite
>>> On 22.06.15 at 19:02, wrote:
> OK, I didn't get the part of the question. AFAICT yes, FreeBSD will
> access the low 256 bytes of the config space. For example the stub to
> write to a cfg register is as follows:
>
> void
> pci_cfgregwrite(int bus, int slot, int func, int reg, u_int32_t data
El 19/06/15 a les 16.58, Jan Beulich ha escrit:
On 19.06.15 at 16:07, wrote:
>> I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
>> for it to have any effect we need to stop unconditionally mapping
>> everything as MMIO regions on PVH Dom0.
>
> Right, I didn't mean to
>>> On 19.06.15 at 16:07, wrote:
> I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
> for it to have any effect we need to stop unconditionally mapping
> everything as MMIO regions on PVH Dom0.
Actually I don't think we need this as a prereq (it's rather a pretty
orthogonal
>>> On 19.06.15 at 16:07, wrote:
> I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
> for it to have any effect we need to stop unconditionally mapping
> everything as MMIO regions on PVH Dom0.
Right, I didn't mean to imply PVH would have any chance of working
right now.
B
>>> On 19.06.15 at 15:05, wrote:
>>And now that I started looking into what it takes to make this
>>work, I'm having a deja vu: In order for us to reliably intercept
>>all CFG accesses, we need to whitelist the MMCFG pages of
>>devices we know we don't care about being written. I.e. we
>>need to s
El 19/06/15 a les 15.00, Jan Beulich ha escrit:
On 11.06.15 at 11:51, wrote:
>> On 11/06/15 09:35, Jan Beulich wrote:
>>> While I continue to be of the opinion that all direct writes to
>>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>>> MSI per entry mask) outside of the hy
On June 19, 2015 9:00:39 AM EDT, Jan Beulich wrote:
On 11.06.15 at 11:51, wrote:
>> On 11/06/15 09:35, Jan Beulich wrote:
>>> While I continue to be of the opinion that all direct writes to
>>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>>> MSI per entry mask) outside of t
>>> On 11.06.15 at 11:51, wrote:
> On 11/06/15 09:35, Jan Beulich wrote:
>> While I continue to be of the opinion that all direct writes to
>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>> MSI per entry mask) outside of the hypervisor are wrong and
>> should be eliminated, the s
On Fri, Jun 12, 2015 at 02:51:02PM +0100, Jan Beulich wrote:
> >>> On 12.06.15 at 15:21, wrote:
> > On Thu, Jun 11, 2015 at 09:35:51AM +0100, Jan Beulich wrote:
> >> >>> On 05.06.15 at 13:28, wrote:
> >> > Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> >> > may (and now do
>>> On 12.06.15 at 15:21, wrote:
> On Thu, Jun 11, 2015 at 09:35:51AM +0100, Jan Beulich wrote:
>> >>> On 05.06.15 at 13:28, wrote:
>> > Qemu shouldn't be fiddling with this bit directly, as the hypervisor
>> > may (and now does) use it for its own purposes. Provide it with a
>> > replacement int
On Thu, Jun 11, 2015 at 09:35:51AM +0100, Jan Beulich wrote:
> >>> On 05.06.15 at 13:28, wrote:
> > Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> > may (and now does) use it for its own purposes. Provide it with a
> > replacement interface, allowing the hypervisor to track
On 11/06/15 09:35, Jan Beulich wrote:
On 05.06.15 at 13:28, wrote:
>> Qemu shouldn't be fiddling with this bit directly, as the hypervisor
>> may (and now does) use it for its own purposes. Provide it with a
>> replacement interface, allowing the hypervisor to track host and guest
>> masking
>>> On 05.06.15 at 13:28, wrote:
> Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> may (and now does) use it for its own purposes. Provide it with a
> replacement interface, allowing the hypervisor to track host and guest
> masking intentions independently (clearing the bit
>>> On 05.06.15 at 17:57, wrote:
> On 05/06/15 12:28, Jan Beulich wrote:
>> Qemu shouldn't be fiddling with this bit directly, as the hypervisor
>> may (and now does) use it for its own purposes. Provide it with a
>> replacement interface, allowing the hypervisor to track host and guest
>> masking
On 05/06/15 12:28, Jan Beulich wrote:
> Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> may (and now does) use it for its own purposes. Provide it with a
> replacement interface, allowing the hypervisor to track host and guest
> masking intentions independently (clearing the
Qemu shouldn't be fiddling with this bit directly, as the hypervisor
may (and now does) use it for its own purposes. Provide it with a
replacement interface, allowing the hypervisor to track host and guest
masking intentions independently (clearing the bit only when both want
it clear).
Signed-off
18 matches
Mail list logo
