On Wed, Feb 28, 2018 at 04:34:01AM -0700, Jan Beulich wrote:
> >>> On 28.02.18 at 12:20, wrote:
> > I've been giving some thought to this, and I cannot find a good
> > solution. So far the less worse one would be:
> >
> > +--+ YES +-+
> > |Is broken set?|-->|No a
>>> On 28.02.18 at 12:20, wrote:
> I've been giving some thought to this, and I cannot find a good
> solution. So far the less worse one would be:
>
> +--+ YES +-+
> |Is broken set?|-->|No action|
> +--+ +-+
> |
> |
On Tue, Feb 27, 2018 at 07:10:51AM -0700, Jan Beulich wrote:
> >>> On 27.02.18 at 12:57, wrote:
> > On Tue, Feb 27, 2018 at 03:01:44AM -0700, Jan Beulich wrote:
> >> >>> On 27.02.18 at 10:21, wrote:
> >> > With the current approach in the unmap case there will be stale
> >> > mappings left behind
>>> On 27.02.18 at 12:57, wrote:
> On Tue, Feb 27, 2018 at 03:01:44AM -0700, Jan Beulich wrote:
>> >>> On 27.02.18 at 10:21, wrote:
>> > With the current approach in the unmap case there will be stale
>> > mappings left behind.
>> >
>> > I guess it's better then to not modify the memory decoding
On Tue, Feb 27, 2018 at 03:01:44AM -0700, Jan Beulich wrote:
> >>> On 27.02.18 at 10:21, wrote:
> > On Tue, Feb 27, 2018 at 01:32:24AM -0700, Jan Beulich wrote:
> >> >>> On 26.02.18 at 19:00, wrote:
> >> > On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
> >> >> >>> On 23.01.18 at 16:
>>> On 27.02.18 at 10:21, wrote:
> On Tue, Feb 27, 2018 at 01:32:24AM -0700, Jan Beulich wrote:
>> >>> On 26.02.18 at 19:00, wrote:
>> > On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
>> >> >>> On 23.01.18 at 16:07, wrote:
>> >> > +static void maybe_defer_map(struct domain *d, cons
On Tue, Feb 27, 2018 at 01:32:24AM -0700, Jan Beulich wrote:
> >>> On 26.02.18 at 19:00, wrote:
> > On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
> >> >>> On 23.01.18 at 16:07, wrote:
> >> > +bool vpci_process_pending(struct vcpu *v)
> >> > +{
> >> > +while ( v->vpci.mem )
> >>
>>> On 26.02.18 at 19:00, wrote:
> On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
>> >>> On 23.01.18 at 16:07, wrote:
>> > +bool vpci_process_pending(struct vcpu *v)
>> > +{
>> > +while ( v->vpci.mem )
>> > +{
>> > +struct map_data data = {
>> > +.d = v->
On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
> (re-sending with xen-devel re-added; not sure how it got lost)
>
> >>> On 23.01.18 at 16:07, wrote:
> > ---
> > tools/tests/vpci/emul.h | 1 +
> > xen/arch/x86/hvm/ioreq.c | 4 +
>
> Again the Cc to Paul is missing (no matter
(re-sending with xen-devel re-added; not sure how it got lost)
>>> On 23.01.18 at 16:07, wrote:
> ---
> tools/tests/vpci/emul.h | 1 +
> xen/arch/x86/hvm/ioreq.c | 4 +
Again the Cc to Paul is missing (no matter that it's just a tiny change).
> +static int map_range(unsigned long s, unsi
On Tue, Jan 23, 2018 at 03:07:31PM +, Roger Pau Monne wrote:
> +static void bar_write(const struct pci_dev *pdev, unsigned int reg,
> + uint32_t val, void *data)
> +{
> +struct vpci_bar *bar = data;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devf
Introduce a set of handlers that trap accesses to the PCI BARs and the
command register, in order to snoop BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangese
12 matches
Mail list logo
